2.063 merge

[David Nadlinger]

On Sunday, 16 June 2013 at 10:46:46 UTC, Jacob Carlborg wrote:
> On 2013-06-15 18:16, David Nadlinger wrote:
>
>> Even if you managed to create an extra section for it without 
>> dropping
>> down to using the MC stuff directly (and thus making use of 
>> the stock
>> LLVM tools no longer as easily possible), you'd still have to 
>> identify
>> that section.
>
> Ok, so it's the section containing the data that is also the 
> problem? I though it would be possible to add custom sections 
> without any problems. I thought it was a problem with the 
> bracketing sections being empty or similar.

Oh, sorry, what I wrote there really doesn't make much sense, I 
wonder what I was thinking. The problem is this: While it is 
possible to specify the section an LLVM global is emitted to, 
this in itself doesn't help you at all, because you still need to 
locate that section at runtime.

And sections are fundamentally a link-time concept, not a 
run-time one – one ELF *segment* (the address/size of which you 
can easily get using dl_iterate_phdr or similar) is made up of an 
arbitrary number of sections. For example, a .minfo section might 
typically end up in the main LOAD segment of the executable.

Sure, it would in theory be possible to retrieve the start 
address of all shared objects using dl_iterate_phdr and then 
parse them using libelf to actually find the sections in there, 
but at this point, just using one global constructor per module 
seems like the much simpler approach.

The DMD approach circumvents this problem by letting the linker 
provide the section start/end using the bracketing scheme, but 
for this, you need to emit the sections in a defined order, and I 
don't think this is possible in LLVM without dropping down to the 
MC layer.

David