llvm dev - Jan 2009 - [LLVMdev] Getting address of label in jitted code[MESSAGE NOT SCANNED]

Dan Gohman wrote:
> On Jan 23, 2009, at 3:23 AM, Mark Shannon wrote:
> 
>> Dan,
>>
>>> On Jan 22, 2009, at 3:45 AM, Mark Shannon wrote:
>>>
>>>> Hi,
>>>>
>>>> I need to get the address of a label in jitted code.
>>>> (This is so that I can insert a jump into the machine code to
resume
>>>> interpretation from compiled code)
>>> Hello,
>>>
>>> What's your plan for restoring register and memory state?
>> Put everything in memory at the yield point,
>> (its for x86 only at the moment).
>> Not super efficient, but should work.
> 
> 
> Is your interpreter stackless? If it's stackless, you can put
> your entrypoint at the beginning of a Function, and then just
> call it.
No it has a stack, but I can guarantee that the ENTIRE state of the VM 
is recoverable. (I force all variables into memory at the yield point).
And I need to insert the jump at runtime, but only under certain 
conditions, so I don't want to split the code into
sub-functions.
> 
> LLVM doesn't support taking the real address of a label. It may
> some day, but that won't by itself make it safe to jump into
> compiled code from separately-compiled code. To do that, you'd
> need to arrange some stable set of assumptions about the state
> of the machine at the time of the jump, and a way to tell the
> code generator where and how to stay within the assumptions.
> And that's essentially what function calling conventions
> already are.
I can guarantee correctness, I just need  to be able to get that address!

Please answer the question, I answered yours ;)

Mark.

On Jan 23, 2009, at 10:06 AM, Mark Shannon wrote:
> Dan Gohman wrote:
>>
>> LLVM doesn't support taking the real address of a label. It may
>> some day, but that won't by itself make it safe to jump into
>> compiled code from separately-compiled code. To do that, you'd
>> need to arrange some stable set of assumptions about the state
>> of the machine at the time of the jump, and a way to tell the
>> code generator where and how to stay within the assumptions.
>> And that's essentially what function calling conventions
>> already are.
>
> I can guarantee correctness, I just need  to be able to get that  
> address!
>
> Please answer the question, I answered yours ;)
I did. The answer is LLVM doesn't support it.

The other answer is that patches to add support for this would
be welcome, even if we remain unconvinced about the specific
use case you're proposing. From LLVM's perspective, it would be
valuable as a way to generate more efficient code for GCC's
labels-as-values extension.

Dan

Dan & Nicolas,

Thanks for your replies.

One more thing though,
How does llvm.dbg.stoppoint work?
Either it's not implemented (in which case perhaps it should be 
removed), or it must store a code address somewhere, and that is the 
information I want.

Finally,
I would love to implement a llvm.dbg.address_here(), or similar 
intrinsic, but I don't think I can justify the time :(

Cheers,
Mark.