www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.ldc - 2.063 merge

reply "David Nadlinger" <code klickverbot.at> writes:
Hi all,

I started to work on merging the 2.063 frontend: 
https://github.com/klickverbot/ldc/tree/merge-2.063

Almost compiles Phobos, but an implementation of 
ClassReferenceExp::toConstElem is missing. This shouldn't be hard 
to add, utilizing the struct initializer code.

After that, it's adapting the new section detection mechanism in 
druntime (which shouldn't be too hard, as I got a pretty good 
overview of the problem space already), and maybe implementing 
the DSO registry stuff for proper shared library support.

David
Jun 11 2013
next sibling parent reply "David Nadlinger" <code klickverbot.at> writes:
The merge-2.063 branch survives building Phobos now.

Yay! It's bugfixing time!

David
Jun 12 2013
parent reply "Kai Nacke" <kai redstar.de> writes:
On Wednesday, 12 June 2013 at 18:45:40 UTC, David Nadlinger wrote:

 The merge-2.063 branch survives building Phobos now.

 Yay! It's bugfixing time!

 David


Sounds great!

I'll give it a try...

Kai
Jun 12 2013
parent "David Nadlinger" <code klickverbot.at> writes:
On Wednesday, 12 June 2013 at 19:09:47 UTC, Kai Nacke wrote:

 On Wednesday, 12 June 2013 at 18:45:40 UTC, David Nadlinger 
 wrote:

 The merge-2.063 branch survives building Phobos now.

 Yay! It's bugfixing time!

 David


 Sounds great!

 I'll give it a try...


There are some strange issues with the AA value type not being 
resolved (type->ty == Tident) in std.traits.

Sigh…

David
Jun 12 2013
prev sibling parent reply "David Nadlinger" <code klickverbot.at> writes:
Seems like the ModuleInfo layout changed, tackling that before 
trying to fix anything else.

David
Jun 12 2013
parent reply "David Nadlinger" <code klickverbot.at> writes:
On Wednesday, 12 June 2013 at 19:26:30 UTC, David Nadlinger wrote:

 Seems like the ModuleInfo layout changed, tackling that before 
 trying to fix anything else.


Scrap that – the fact that we are not emitting the extra minfo 
data is screwing up ModuleInfo iteration, which leads to no 
module constructors being called at all.

This is obviously a big problem.

David
Jun 12 2013
parent reply "David Nadlinger" <code klickverbot.at> writes:
On Wednesday, 12 June 2013 at 19:34:39 UTC, David Nadlinger wrote:

 Scrap that – the fact that we are not emitting the extra minfo 
 data is screwing up ModuleInfo iteration, which leads to no 
 module constructors being called at all.


If each LLVM module we generate would be emitted as an object 
file, this would be easy to resolve: Just emit 
_minfo_beg/_minfo_end and a constructor calling _d_dso_registry 
in module-level inline asm.

Still not quite clean on how to get this to work with IR-level 
linking…

David
Jun 12 2013
next sibling parent reply "David Nadlinger" <code klickverbot.at> writes:
On Wednesday, 12 June 2013 at 22:08:10 UTC, David Nadlinger wrote:

 On Wednesday, 12 June 2013 at 19:34:39 UTC, David Nadlinger 
 wrote:

 Scrap that – the fact that we are not emitting the extra minfo 
 data is screwing up ModuleInfo iteration, which leads to no 
 module constructors being called at all.


 If each LLVM module we generate would be emitted as an object 
 file, this would be easy to resolve: Just emit 
 _minfo_beg/_minfo_end and a constructor calling _d_dso_registry 
 in module-level inline asm.

 Still not quite clean on how to get this to work with IR-level 
 linking…


I added an rt.sections_ldc module that is just based on what we 
had before (i.e. reads the _Dmodule_ref chain). Entirely untested 
so far, there are probably big issues with it still (it might not 
even compile on non-Linux systems).

Next step would be to get the DMD testsuite to pass. I'm using a 
DMD-built d_do_test right now, as I think d_do_test is still 
miscompiled.

David
Jun 13 2013
parent "Temtaime" <temtaime gmail.com> writes:
Great work, man.
Good luck.
Jun 13 2013
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-06-13 00:08, David Nadlinger wrote:


 If each LLVM module we generate would be emitted as an object file, this
 would be easy to resolve: Just emit _minfo_beg/_minfo_end and a
 constructor calling _d_dso_registry in module-level inline asm.

 Still not quite clean on how to get this to work with IR-level linking…


If the bracketing symbols is causing problems what about iterating the 
segments and sections until you find the section with the module info data?

-- 
/Jacob Carlborg
Jun 15 2013
parent reply "David Nadlinger" <code klickverbot.at> writes:
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
Jun 15 2013
parent reply Jacob Carlborg <doob me.com> writes:
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
Jun 16 2013
parent reply "David Nadlinger" <code klickverbot.at> writes:
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
Jun 16 2013
parent Jacob Carlborg <doob me.com> writes:
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
Jun 16 2013