I added the current state to the main repository as a branch. It should be stable enough so that we can easily work on fixing the remaining bugs on Linux x86_64. One of them seems to be a declare/define resp. symbol visibility issue that causes linking errors on most of the .

There are still crashes in the 32 bit version I have still to investigate, and I didn't try other OSes yet.

On Saturday, 15 June 2013 at 15:11:50 UTC, Jacob Carlborg wrote:
> If the bracketing symbols is causing problems what about iterating the segments and sections until you find the section with the module info data?

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. I outlined an alternative approach on the druntime ML.

David

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.

>  I outlined an alternative approach on the druntime ML.

I see.

-- 
/Jacob Carlborg

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

On 2013-06-16 17:03, David Nadlinger wrote:

> 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.

Using a global module constructor doesn't sound that bad.

-- 
/Jacob Carlborg