Can someone explain to me how the llvm invoke the works?
I have the statement:
invoke void # _ZN7sc_core9sc_signalIN5sc_dt6sc_intILi16EEEEC1Ev (% "class.sc_core :: sc_signal.57" *% operator1) to label %invoke.cont unwind label %lpad
It seems to me that it makes a call to a function and then jumps to a label. But which label? label %invoke.cont or label %lpad??
How to identify the label for which it jumps?
LLVM Language Reference
Syntax
<result> = invoke [cconv] [ret attrs] <ptr to function ty> <function ptr val>(<function args>) [fn attrs]
to label <normal label> unwind label <exception label>
Overview
The ‘invoke‘ instruction causes control to transfer to a specified function, with the possibility of control flow transfer to either the ‘normal‘ label or the ‘exception‘ label. If the callee function returns with the “ret” instruction, control flow will return to the “normal” label. If the callee (or any indirect callees) returns via the “resume” instruction or other exception handling mechanism, control is interrupted and continued at the dynamically nearest “exception” label.
The syntax specification identifies the first label as the normal label, used for ret, and the second label as the exception label, used for exceptions. This is easy to remember because the term 'unwind' refers to cleanup performed when exceptions are thrown. So the instruction explicitly identifies the 'unwind label'. And the code used for this is often referred to as a 'landing pad', thus the label 'lpad' works as a reminder of what that basic block does.
Related
I have the following line of code throwing an exception in LLVM IR C++ API:
AllocaInst *allocate = builder->CreateAlloca(objectType);
When run, it throws the following exception:
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x38)
* frame #0: 0x00000001000302fa birdd`llvm::BasicBlock::getModule() const + 4
frame #1: 0x0000000100003018 birdd`llvm::IRBuilderBase::CreateAlloca(llvm::Type*, llvm::Value*, llvm::Twine const&) [inlined] llvm::BasicBlock::getModule(this=<unavailable>) at BasicBlock.h:117:68 [opt]
frame #2: 0x0000000100003013 birdd`llvm::IRBuilderBase::CreateAlloca(this=0x0000000101102230, Ty=0x0000000101801000, ArraySize=0x0000000000000000, Name=0x00007ffeefbff038) at IRBuilder.h:1598 [opt]
This gave me an indication that the getModule() is returning an invalid pointer. Funny thing is the builder and the module share the same LLVMContext.
So I decided to run it through verifyModule as follows:
verifyModule(*builder->GetInsertBlock()->getModule());
The same error. But when I access the module object directly, it appears to be fine.
Here is my initialisation code:
static LLVMContext context;
std::unique_ptr<Module> module = std::make_unique<Module>("Main", context);
std::unique_ptr<IRBuilder<>> builder = std::make_unique<llvm::IRBuilder<>>(context);
I'm stuck. Any help will be appreciated!
IRBuilder will not be able to pick up Module from context (same context may be used by multiple modules) and in any case Module alone would not be enough - builder also needs to know the point at which instructions should be inserted. So you'd either need to provide it with a BasicBlock at construction time or set it explicitly via
builder->SetInsertPoint(BB);
or even
builder->SetInsertPoint(Inst);
if you want to insert not at BB's end.
A few side notes:
I'd suggest to follow LLVM's coding style of upper-cased variable names (this would make maintenance easier later on).
Builders are cheap to create so most often they are just created as local variables in functions that need them:
IRBuilder<> IRB;
I'm currently writing some kind of a "skeleton" for tests to be performed using Lauterbach scripts.
In this skeleton I want to have a part in which all test specific definitions shall be done, e.g. functions to set breaks on, variables to be altered etc. This part shall be just near the top of the script file, so that other users do not have to go through the complete script file, changing values here and there.
Some of the variables that'll be used are defined function-local within the C-code to be tested. So, these become available to the Lauterbach script only once the scope of that function has been entered - which is deeply within the skeleton script code.
Is there a way to define a macro for these variables just way before the scope has been entered?
Let's give some example structure:
LOCAL &funcToTest // the function we want to test
LOCAL &varToBeSet // a variable within the function we want to alter
LOCAL &valueToBeSet // the value we want to set &varToBeSet to
... // some more definitions here
&funcToTest=someFunc
&varToBeSet=status
&valueToBeSet=1
... // some test code following here that sets up log files, screen areas
... // start the program to be tested etc.
IF (Register(PC)==ADDRESS.OFFSET(&funcToTest))
(
// OK - we've hit the breakpoint inside the function to test
... // Run to some point where we can set the local variable
Var.Set &varToBeSet=&valueToBeSet
... // Go on with the program and see what happens - this will be logged
)
The problem is that Lauterbach complains at the line &varToBeSet=status
with Symbol not found in this context - which is correct, because it is a local variable.
Looking at the symbols via View->Symbols->SymbolsTreeView (or by giving the command Symbol.List.Tree) I can find the symbol (in this particular case found under the node some_module.some_function.status). Clicking on it gives the information in the TRACE32 status status line \\some_app\some_module\some_func\status with type (auto STATUS), scope local, location stack.
Changing my script to read &varToBeSet=\\some_app\some_module\some_func\status instead of &varToBeSet=status, however, does not help much. In this case Lauterbach complains with no access to that symbol.
Is there a way, I can delay evaluation of the macro to some point where it is actually used instead of having it evaluated when it is defined?
Use quotes:
&varToBeSet="\\some_app\some_module\some_func\status"
Using Ember.2.1.0-beta4
I am getting the "ember-views.render-double-modify" in a function triggered by the "didReceiveAttrs" of a subcomponent.
I tracked down the statement this.set('_columns', columns) that triggers the error. However, AFAIK this is the first time the attribute is modified.
To debug it, I created an observer for the modified attribute, and put a breakpoint there. However, the observer is only called once and the error is still there, so it looks like this is the first call.
How should I debug this -- is this an Ember bug, or are there other restrictions on setting attributes that aren't clear in the error? Note that the attribute is used in the component's template. Also the attribute is used in other computed attributes (e.g. _columns.#each.width and _columns.[]).
For posterity's sake, the answer in my case was: _columns is used in the template. Thus, for didReceiveAttrs of the subcomponent to be called, the previous value of _columns was already used.
The error message is a little misleading, but the idea, I think, is that once you start to render you can't change properties until you are done. If necessary, use Ember.run.scheduleOnce('afterRender', ...).
I'm trying out this code in applescript:
the first one works, the second doesn't
global theOpts
on saySomething()
--some code that it runs
end
set theOpts to {saySomething}
--the one that does
set t to theOpts's item 1
t()
--the one that doesn't
on runByIdx(idx)
set thefun to item 1 of theOpts
thefun()
end runByIdx
Is there a way I can get this to work?
What I want to do in summary is have a list of handlers that I can call by index rather than by name.
Don't do that. It's an undocumented behavior and known design flaw. Handlers aren't meant to be manipulated as objects, and it breaks the handler's bindings to the enclosing script.
The right way to do it is to wrap each handler in its own script object, and put those script objects in the list instead.
script Foo
on doIt()
say "this"
end doIt
end script
script Bar
on doIt()
say "that"
end doIt
end script
set opts to {Foo, Bar}
doIt() of item 1 of opts
Though you should also not underestimate the value of a simple if...else if... block:
if idx = 1 then
doThis()
else idx = 2 then
doThat()
else ...
Basically it depends on what problem you're trying to solve. But I'd lean towards the latter approach (i.e. KISS) unless it's a task that requires the extra flexibility, otherwise you're just adding unnecessary complexity and making work for yourself.
(FWIW, the AppleScript book I co-wrote a few years back has a chapter on working with script objects. The section on libraries doesn't cover the new library system in 10.9+, and the section on OOP has a corker of a technical error if you know where to look:p, but it's probably the best explanation of this subject you'll find so worth a look if you really want to know more.)
This way both work...
global theOpts
on saySomething()
return 1
end saySomething
set theOpts to {saySomething()}
--the one that does
set t to theOpts's item 1
--t
runByIdx(1)
on runByIdx(idx)
set thefun to item idx of theOpts
thefun
end runByIdx
What does that IR line mean
define i32 <badref>() {
for defining a new function and writing it in the file
Typically you get <badref> printed out when the IR is malformed. You should run the verifier pass on your module to see if it can help you find out what the precise problem is.
In this particular case I'm guessing you have created a new unnamed function but have not yet added it to a module - without a module it cannot number the global values, so it cannot name the function.