This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Problems building GNAT on OS X with top-of-tree
- From: Geert Bosch <bosch at gnat dot com>
- To: Dale Johannesen <dalej at apple dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Wed, 16 Oct 2002 15:52:55 -0400
- Subject: Re: Problems building GNAT on OS X with top-of-tree
On Wednesday, Oct 16, 2002, at 15:10 America/New_York, Dale Johannesen
wrote:
OK, the problem is code that looks like this:
.comm _ada__exceptions__subprogram_descriptors,8
....
addis
r9,r31,ha16(_ada__exceptions__subprogram_descriptors-L42$pb)
lwz
r9,lo16(_ada__exceptions__subprogram_descriptors-L42$pb)(r9)
This object looks like something the Ada FE created.
.comm data must be addressed by the non_lazy_ptr mechanism:
int x[20];
main() { foo(x); }
addis r9,r31,ha16(L_x$non_lazy_ptr-L1$pb)
lwz r3,lo16(L_x$non_lazy_ptr-L1$pb)(r9)
.comm _x,80
.data
.non_lazy_symbol_pointer
L_x$non_lazy_ptr:
.indirect_symbol _x
.long 0
The mechanism is in config/darwin.c and config/rs6000/rs6000.c.
machopic_legitimize_pic_address is probably a good place to start.
OK, I see. Indeed, using -fno-common eliminates/suppresses the problem.
However, I don't see how the front end should have to know
about these details. I looked at darwin.c, and I see the implementation
of the scheme using lazy and non-lazy pointers, but there does not
seem to be any documentation at a sufficiently high level to be able
to understand what is going on there.
I'm focussing now on finding out why this problems does not occur with
the C front end, which seems to use the same method for outputting
variables in the common section.
-Geert