Problems building GNAT on OS X with top-of-tree

Problems building GNAT on OS X with top-of-tree

[Geert Bosch]

I am trying to get up to speed with the head of the GCC tree, but while
building stage2 of the GNAT, any non-trivial file fails to compile with
assembler errors as follows:

stage1/xgcc -Bstage1/ -B/usr/local/powerpc-apple-darwin6.1/bin/ -c -g 
-O2      -gnatpg -gnata -g -O1 -fno-inline \
  -I- -I. -Iada -I/Users/bosch/gcc/gcc/ada 
/Users/bosch/gcc/gcc/ada/a-except.adb -o ada/a-except.o
a-except.s:unknown:Can't emit reloc {- symbol "L65$pb"} @ file address 
9408.
a-except.s:unknown:Can't emit reloc {- symbol "L65$pb"} @ file address 
9404.
a-except.s:unknown:Can't emit reloc {- symbol "L64$pb"} @ file address 
9296.
a-except.s:unknown:Can't emit reloc {- symbol "L64$pb"} @ file address 
9292.
a-except.s:unknown:Can't emit reloc {- symbol "L64$pb"} @ file address 
9216.
a-except.s:unknown:Can't emit reloc {- symbol "L64$pb"} @ file address 
9212.
a-except.s:unknown:Can't emit reloc {- symbol "L63$pb"} @ file address 
9056.
a-except.s:unknown:Can't emit reloc {- symbol "L63$pb"} @ file address 
9052.
a-except.s:unknown:Can't emit reloc {- symbol "L63$pb"} @ file address 
8868.
a-except.s:unknown:Can't emit reloc {- symbol "L63$pb"} @ file address 
8864.
a-except.s:unknown:Can't emit reloc {- symbol "L63$pb"} @ file address 
8680.
a-except.s:unknown:Can't emit reloc {- symbol "L63$pb"} @ file address 
8676.
a-except.s:unknown:Can't emit reloc {- symbol "L63$pb"} @ file address 
8572.
a-except.s:unknown:Can't emit reloc {- symbol "L63$pb"} @ file address 
8568.
a-except.s:unknown:Can't emit reloc {- symbol "L63$pb"} @ file address 
8532.
a-except.s:unknown:Can't emit reloc {- symbol "L63$pb"} @ file address 
8528.
a-except.s:unknown:Can't emit reloc {- symbol "L63$pb"} @ file address 
8452.
a-except.s:unknown:Can't emit reloc {- symbol "L63$pb"} @ file address 
8448.
a-except.s:unknown:Can't emit reloc {- symbol "L63$pb"} @ file address 
8360.
a-except.s:unknown:Can't emit reloc {- symbol "L63$pb"} @ file address 
8356.
a-except.s:unknown:Can't emit reloc {- symbol "L43$pb"} @ file address 
6140.
a-except.s:unknown:Can't emit reloc {- symbol "L43$pb"} @ file address 
6136.
a-except.s:unknown:Can't emit reloc {- symbol "L43$pb"} @ file address 
5980.
a-except.s:unknown:Can't emit reloc {- symbol "L43$pb"} @ file address 
5976.
a-except.s:unknown:Can't emit reloc {- symbol "L43$pb"} @ file address 
5952.
a-except.s:unknown:Can't emit reloc {- symbol "L43$pb"} @ file address 
5948.
a-except.s:unknown:Can't emit reloc {- symbol "L43$pb"} @ file address 
5824.
a-except.s:unknown:Can't emit reloc {- symbol "L43$pb"} @ file address 
5820.
a-except.s:unknown:Can't emit reloc {- symbol "L42$pb"} @ file address 
5468.
a-except.s:unknown:Can't emit reloc {- symbol "L42$pb"} @ file address 
5464.

I guess this refers to code like:
         addis r9,r31,ha16(
L_system__soft_links__get_jmpbuf_address$non_lazy_ptr-
L42$pb)
         lwz 
r9,lo16(L_system__soft_links__get_jmpbuf_address$non_lazy_ptr-
L42$pb)(r9)

Indeed, this looks dubious and IIRC, there was a similar problem a long
while ago. Do these symptoms ring a bell with anyone? If not, I'll see
if I can debug this and see why this code gets generated. Thanks in
advance for any help.

   -Geert

Re: Problems building GNAT on OS X with top-of-tree

[Dale Johannesen]

On Tuesday, October 15, 2002, at 06:32  PM, Geert Bosch wrote:
> a-except.s:unknown:Can't emit reloc {- symbol "L42$pb"} @ file address  
> 5464.
>
> I guess this refers to code like:
>         addis  
> r9,r31,ha16(L_system__soft_links__get_jmpbuf_address$non_lazy_ptr- 
> L42$pb)
>         lwz  
> r9,lo16(L_system__soft_links__get_jmpbuf_address$non_lazy_ptr- 
> L42$pb)(r9)

The code you quote here looks correct.  Probably the definition of  
L42$pb
is missing; it should be near the top of the function.  The RTL for it
should be generated by gen_load_macho_picbase() called from
rs6000_emit_prologue().

Re: Problems building GNAT on OS X with top-of-tree

[Dale Johannesen]

On Tuesday, October 15, 2002, at 06:32  PM, Geert Bosch wrote:
> a-except.s:unknown:Can't emit reloc {- symbol "L65$pb"} @ file address 
> 9404.
> I guess this refers to code like:
>         addis r9,r31,ha16(
> L_system__soft_links__get_jmpbuf_address$non_lazy_ptr-
> L42$pb)
>         lwz 
> r9,lo16(L_system__soft_links__get_jmpbuf_address$non_lazy_ptr-
> L42$pb)(r9)

Another possibility is that
L_system__soft_links__get_jmpbuf_address$non_lazy_ptr
is not defined.  In either case I'd expect to see an "undefined symbol"
message from the assembler though.  If neither of those is it, send me
a .s file and I'll figure it out.

Re: Problems building GNAT on OS X with top-of-tree

[Geert Bosch]

On Wednesday, Oct 16, 2002, at 13:12 America/New_York, Dale Johannesen 
wrote:
> Another possibility is that
> L_system__soft_links__get_jmpbuf_address$non_lazy_ptr
> is not defined.  In either case I'd expect to see an "undefined symbol"
> message from the assembler though.  If neither of those is it, send me
> a .s file and I'll figure it out.

It's defined in the .data segment, while the reference is in the .code
segment. I can see how this wouldn't work...

   -Geert

Re: Problems building GNAT on OS X with top-of-tree

[Dale Johannesen]

On Wednesday, October 16, 2002, at 10:37  AM, Geert Bosch wrote:

>
> On Wednesday, Oct 16, 2002, at 13:12 America/New_York, Dale Johannesen 
> wrote:
>> Another possibility is that
>> L_system__soft_links__get_jmpbuf_address$non_lazy_ptr
>> is not defined.  In either case I'd expect to see an "undefined 
>> symbol"
>> message from the assembler though.  If neither of those is it, send me
>> a .s file and I'll figure it out.
>
> It's defined in the .data segment, while the reference is in the .code
> segment. I can see how this wouldn't work...

No, that is supposed to be OK.  non_lazy_ptr's are used for
references to the address of a function (pointer-to-function) like this:

extern int (*f)(int (*)());
main() {
    (*f)(f);
}

.text   ....
_main:  ....
         bcl 20,31,L1$pb
L1$pb:   ....
         addis r9,r31,ha16(L_f$non_lazy_ptr-L1$pb)
         lwz r11,lo16(L_f$non_lazy_ptr-L1$pb)(r9)
         addis r9,r31,ha16(L_f$non_lazy_ptr-L1$pb)
         lwz r9,lo16(L_f$non_lazy_ptr-L1$pb)(r9)
         lwz r0,0(r11)
         lwz r3,0(r9)
         mr r12,r0
         mtctr r12
         bctrl
         ....
.data
.non_lazy_symbol_pointer
L_f$non_lazy_ptr:
         .indirect_symbol _f

So what's different about yours?

Re: Problems building GNAT on OS X with top-of-tree

[Geert Bosch]

On Wednesday, Oct 16, 2002, at 13:47 America/New_York, Dale Johannesen 
wrote:
> No, that is supposed to be OK.  non_lazy_ptr's are used for
> references to the address of a function (pointer-to-function) like 
> this:
>
> extern int (*f)(int (*)());
> main() {
>    (*f)(f);
> }
>
> .text   ....
> _main:  ....
>         bcl 20,31,L1$pb
> L1$pb:   ....
>         addis r9,r31,ha16(L_f$non_lazy_ptr-L1$pb)
>         lwz r11,lo16(L_f$non_lazy_ptr-L1$pb)(r9)
>         addis r9,r31,ha16(L_f$non_lazy_ptr-L1$pb)
>         lwz r9,lo16(L_f$non_lazy_ptr-L1$pb)(r9)
>         lwz r0,0(r11)
>         lwz r3,0(r9)
>         mr r12,r0
>         mtctr r12
>         bctrl
>         ....
> .data
> .non_lazy_symbol_pointer
> L_f$non_lazy_ptr:
>         .indirect_symbol _f
>
> So what's different about yours?

It seems to be the same. It doesn't help that the assembly
message seems to refer to a location in the output file, which
is not written to disk. Anyway, I'll send you the a-except.s
file in a private email. Thanks for your help!

   -Geert

.text
...
L42$pb:
         ...
         addis r9,r31,ha16(
L_system__soft_links__get_jmpbuf_address$non_lazy_ptr-L42$pb)
         lwz r9,lo16(
L_system__soft_links__get_jmpbuf_address$non_lazy_ptr-L42$pb)(r9)
         lwz r9,0(r9)
         mtctr r9
         bctrl
         ...

.data
...
.non_lazy_symbol_ptr
...
L_system__soft_links__get_jmpbuf_address$non_lazy_ptr:
         .indirect_symbol _system__soft_links__get_jmpbuf_address
         .long   0

Re: Problems building GNAT on OS X with top-of-tree

[Geoffrey Keating]

On Thursday, October 17, 2002, at 02:52  PM, Dale Johannesen wrote:

>
> On Thursday, October 17, 2002, at 02:38  PM, Geoffrey Keating wrote:
>> On Thursday, October 17, 2002, at 02:10  PM, Dale Johannesen wrote:
>>>
>>> Actually this looks like it is connected to Geoff's recent patch
>>> http://gcc.gnu.org/ml/gcc-patches/2002-09/msg01259.html
>>> which introduced the LSJR label.  Geoff, is
>>> current_function_uses_pic_offset_table not getting set anywhere?
>>> That would account for his symptom.
>>>
>> It is supposed to be set by machopic_function_base_name, which is 
>> called to generate the label.  Looking at the code, my suspicion is 
>> that  the original load_macho_picbase pattern is getting deleted by 
>> flow because it appears dead, but that also deletes the label that 
>> the macho_correct_pic needs.
>>
>> If so, the solution is to use a real CODE_LABEL instead of having the 
>> label inside load_macho_picbase, but this will be a complex change.
>
> Hmm.  How do you keep the bcl and the following label together through 
> the scheduler?
> SCHED_GROUP_P used to work on labels, but it doesn't any more, and I 
> never found
> another way to do it.  Would a USE of the label work?

That's a tricky one.

What you really want to do is say

(parallel [(set (pc) (label_ref (code_label ...)))
   (set (reg:SI lr) (label_ref (code_label ...)))])

because that accurately describes what load_macho_picbase really does, 
but reload can't deal with that, it doesn't like jump instructions that 
have output reloads.

Since we can't do the nice thing, probably a good second-best is, for 
functions that need this restore (perhaps those that have 
current_function_has_nonlocal_label set) to ensure that the original 
load_macho_picbase never gets deleted by adding a suitable USE of the 
PIC register.

Re: Problems building GNAT on OS X with top-of-tree

[Dale Johannesen]

On Thursday, October 17, 2002, at 02:38  PM, Geoffrey Keating wrote:
> On Thursday, October 17, 2002, at 02:10  PM, Dale Johannesen wrote:
>>
>> Actually this looks like it is connected to Geoff's recent patch
>> http://gcc.gnu.org/ml/gcc-patches/2002-09/msg01259.html
>> which introduced the LSJR label.  Geoff, is
>> current_function_uses_pic_offset_table not getting set anywhere?
>> That would account for his symptom.
>>
> It is supposed to be set by machopic_function_base_name, which is 
> called to generate the label.  Looking at the code, my suspicion is 
> that  the original load_macho_picbase pattern is getting deleted by 
> flow because it appears dead, but that also deletes the label that the 
> macho_correct_pic needs.
>
> If so, the solution is to use a real CODE_LABEL instead of having the 
> label inside load_macho_picbase, but this will be a complex change.

Hmm.  How do you keep the bcl and the following label together through 
the scheduler?
SCHED_GROUP_P used to work on labels, but it doesn't any more, and I 
never found
another way to do it.  Would a USE of the label work?

>> (This is probably unrelated to your earlier bug.)
>
> Well, it's certainly related, in the sense that if I hadn't fixed that 
> bug this code would now fail at runtime instead of compile-time…

(I meant Geert Bosch's earlier bug, not yours.  Sorry to be unclear.)

Re: Problems building GNAT on OS X with top-of-tree

[Geoffrey Keating]

On Thursday, October 17, 2002, at 02:10  PM, Dale Johannesen wrote:

>
> On Thursday, October 17, 2002, at 01:44  PM, Geert Bosch wrote:
>> ali.s:unknown:Can't emit reloc {- symbol "LSJR827"} @ file address 
>> 30708.
>> ali.s:unknown:Can't emit reloc {- symbol "LSJR827"} @ file address 
>> 30704.
>> ali.s:unknown:Undefined local symbol L149$pb
>>
>> The piece of assembly in question is:
>> LSJR827:
>>         mflr r31
>>         addis r31,r31,ha16(L149$pb-LSJR827)
>>         addi r31,r31,lo16(L149$pb-LSJR827)
>
> Actually this looks like it is connected to Geoff's recent patch
> http://gcc.gnu.org/ml/gcc-patches/2002-09/msg01259.html
> which introduced the LSJR label.  Geoff, is
> current_function_uses_pic_offset_table not getting set anywhere?
> That would account for his symptom.
>
It is supposed to be set by machopic_function_base_name, which is 
called to generate the label.  Looking at the code, my suspicion is 
that  the original load_macho_picbase pattern is getting deleted by 
flow because it appears dead, but that also deletes the label that the 
macho_correct_pic needs.

If so, the solution is to use a real CODE_LABEL instead of having the 
label inside load_macho_picbase, but this will be a complex change.

> (This is probably unrelated to your earlier bug.)

Well, it's certainly related, in the sense that if I hadn't fixed that 
bug this code would now fail at runtime instead of compile-time…

Re: Problems building GNAT on OS X with top-of-tree

[Dale Johannesen]

On Thursday, October 17, 2002, at 01:44  PM, Geert Bosch wrote:
> ali.s:unknown:Can't emit reloc {- symbol "LSJR827"} @ file address 
> 30708.
> ali.s:unknown:Can't emit reloc {- symbol "LSJR827"} @ file address 
> 30704.
> ali.s:unknown:Undefined local symbol L149$pb
>
> The piece of assembly in question is:
> LSJR827:
>         mflr r31
>         addis r31,r31,ha16(L149$pb-LSJR827)
>         addi r31,r31,lo16(L149$pb-LSJR827)

Actually this looks like it is connected to Geoff's recent patch
http://gcc.gnu.org/ml/gcc-patches/2002-09/msg01259.html
which introduced the LSJR label.  Geoff, is
current_function_uses_pic_offset_table not getting set anywhere?
That would account for his symptom.

(This is probably unrelated to your earlier bug.)

Re: Problems building GNAT on OS X with top-of-tree

[Dale Johannesen]

On Thursday, October 17, 2002, at 01:44  PM, Geert Bosch wrote:
> ali.s:unknown:Can't emit reloc {- symbol "LSJR827"} @ file address 
> 30708.
> ali.s:unknown:Can't emit reloc {- symbol "LSJR827"} @ file address 
> 30704.
> ali.s:unknown:Undefined local symbol L149$pb
>
> The piece of assembly in question is:
> LSJR827:
>         mflr r31
>         addis r31,r31,ha16(L149$pb-LSJR827)
>         addi r31,r31,lo16(L149$pb-LSJR827)
>
> This reference is generated by machopic_function_base_name () in 
> darwin.c,
> but there is no documentation as to who should generate this label...

It is generated by gen_load_macho_picbase() which should be called from
rs6000_emit_prologue().

Re: Problems building GNAT on OS X with top-of-tree

[Geert Bosch]

Dale wrote:
>> 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.
>
> You could do that.   Alternatively, I see that the correct sequence is
> generated for ada__exceptions__null_occurrence, which is also a .comm
> symbol.  You might look and see what's different about the symbols.
> This is probably just a matter of getting some field set correctly.

Actually, I tried to build with -fno-common and a few files later,
while compiling ali.adb with stage1/gnat, we fail in a clearer way:

ali.s:unknown:Can't emit reloc {- symbol "LSJR827"} @ file address 
30708.
ali.s:unknown:Can't emit reloc {- symbol "LSJR827"} @ file address 
30704.
ali.s:unknown:Undefined local symbol L149$pb

The piece of assembly in question is:
LSJR827:
         mflr r31
         addis r31,r31,ha16(L149$pb-LSJR827)
         addi r31,r31,lo16(L149$pb-LSJR827)

This reference is generated by machopic_function_base_name () in 
darwin.c,
but there is no documentation as to who should generate this label...

   -Geert

Re: Problems building GNAT on OS X with top-of-tree

[Dale Johannesen]

On Wednesday, October 16, 2002, at 12:52  PM, Geert Bosch wrote:
> 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.

Right.  I didn't write it, and I still find it confusing.

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

You could do that.   Alternatively, I see that the correct sequence is
generated for ada__exceptions__null_occurrence, which is also a .comm
symbol.  You might look and see what's different about the symbols.
This is probably just a matter of getting some field set correctly.

Re: Problems building GNAT on OS X with top-of-tree

[Geert Bosch]

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