PIC

[Simon Marlow]

On 28 June 2004 00:19, Wolfgang Thaller wrote:

> Hi!
> 
> I've been playing around with the NCG in the new backend lately,
> trying to implement position independent code generation and dynamic
> linking (for Mac OS X first, of course ;-) ).

Nice!

> Right now, I'm aiming for being able to use self-contained Haskell
> code in a dynamic library as a plug-in for some foreign-language
> program - All Haskell code + libraries + RTS in the same dynamic
> library. 
> 
> PIC/dynamic code generation for Mac OS X "almost" works now; there are
> sill a few problems left:
> 
> *) Info tables have a reference to a SRT, and info tables are in the
> text segment, so that reference can't be relocated, and the linker
> complains.
> A solution might be to store the offset from the info table to the SRT
> instead instead of the SRT's address. I can convince the Mac OS X
> assembler to do that, but GCC doesn't like it. It's easy however to
> make the mangler convert ".long XYZ_srt" to ".long XYZ_srt -
> XYZ_info". We could also set the low bit of the offset value to
> distinguish it from an absolute address.

Sounds like a reasonable solution to me.

> *) The code generator is giving me two different CLabels (with
> different uniques) for the same label (i.e. they pretty-print as the
> same label).
> I have to do my (map head . group . sort) on the pretty-printed labels
> instead of the labels themselves, but that's very ugly...

Hmm, we need to investigate this one.  There's probably a way to fix it.
Do you know why the two different CLabels arise?

This reminds me - in the tablesNextToCode case, we want to omit either
the info table label or the entry label, and just use one.  There's no
reason to have both labels bloating the symbol tables any more (in fact,
there probably never was a *good* reason, just that it was marginally
simpler to have both).  I plan to look into this at some point.

> *) Is there any way to find out if a label is defined within the
> current module?

You mean a function from CLabel -> Bool?  No, unfortunately not.  There
is externallyVisibleCLabel: if this returns False, then the label is
definitely local to this module, but if it returns True, then the label
may or may not be defined in this module. 

Perhaps we can find a way around this.  Which labels do you need this
information for?

> Right now, the PIC generated by the NCG on Mac OS X is about the same
> as what I get when I run GCC-generated Mac OS X PIC through the
> mangler; the code works when run as an executable, and it is position
> independent except for those SRT references noted above.
> I've had a look at how PIC code works on Windows and Linux, and I
> think support for that can be integrated into my code. I've put the
> indirections for dynamic linking into cmmToCmm (with some
> platform-specific helper functions for deciding when to use
> indirections); generating position-independent references to labels is
> left entirely to MachCodeGen, as things work too differently between
> platforms.
> 
> Well, that's a status report of just a few hours' hacking... I guess
> I've only just now arrived at the hard part :-).

This sounds fantastic.

On Linux, PIC uses a register to point to the indirection table, doesn't
it?  This will cause us problems (we'll have to lose a register).

Cheers,
	Simon