Re: [Qemu-devel] Patch to fix Mac OS X compilation

[Jonas Maebe]

On 21 feb 2005, at 21:08, Fabrice Bellard wrote:

> > PS: symbols which are still in the dynamic symbol table and therefore 
> > not properly relocated under Mac OS X (also not in Qemu 0.61) are 
> > rclw_table, rclb_table and parity_table. The hack to declare them as 
> > "static" does not currently work for them, because then you get 
> > definition conflicts. A proper fix would be to add support for 
> > parsing the dynamic symbol table as well.
> > A hack would be to move some things to different include files so the 
> > "static" definition is the only one that appears when compiling op.o, 
> > and the "extern" definitions when compiling other files. Another 
> > solution is to parse the output of "otool -IV op.o", as these 
> > variables/symbols are shown by that one in the contents of the 
> > "(__DATA,__nl_symbol_ptr)" section.
>
> What not just keeping them as they are now ? Are you sure the code is 
> badly relocated ?

Yes. Just search for "warning" in the generated op.h (i.e., they are 
not relocated at all).

> It seems that a reference to the equivalent of the ELF GOT is used to 
> access these tables

That is correct.

> - I don't understand why a specific relocation is needed.

It's not a special relocation, but a different symbol table. Mach-O 
object files contain two symbol tables: one which contains all private 
symbols (called the "symbol table", and which is already fully parsed 
by dyngen), and one which contains all imported and exported symbols 
(the "dynamic symbol table").

This dynamic symbol table command is loaded by dyngen (search for 
"dysymtab"), but the table itself is not loaded nor parsed. As such, 
when you find a relocated symbol in an instruction (which only contains 
a section number, an index and things like that, but no name) and this 
is an external (or exported) symbol, then dyngen won't be able to find 
its name (since it will only search the regular symbol table).

When dyngen can't find the name of a relocation, it can't create a 
fixup for it since it needs to print the name in the generated op.h

> The real problem is that gcc for Mac OS X does not support the 
> "visibility" attribute. Setting the visibility of the symbol to 
> "hidden" would solve the problem !

That's possible. If this attribute would result in the symbols becoming 
private, they would indeed move from the dynamic symbol table to the 
regular symbol table.


Jonas