[Bug c++/11331] New: [Regression 3.4] ld: BFD 2.14.90 20030602 internal error

[Bug c++/11331] New: [Regression 3.4] ld: BFD 2.14.90 20030602 internal error

[danglin at gcc dot gnu dot org]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11331

           Summary: [Regression 3.4] ld: BFD 2.14.90 20030602 internal error
           Product: gcc
           Version: 3.4
            Status: UNCONFIRMED
          Severity: critical
          Priority: P3
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: danglin at gcc dot gnu dot org
                CC: dave at hiauly1 dot hia dot nrc dot ca,gcc-bugs at gcc
                    dot gnu dot org,jakub at redhat dot com
 GCC build triplet: hppa-unknown-linux-gnu
  GCC host triplet: hppa-unknown-linux-gnu
GCC target triplet: hppa-unknown-linux-gnu

The following error occurs linking libstdc++.so:

/home/dave/gcc-3.4/objdir/gcc/xgcc -shared-libgcc -B/home/dave/gcc-3.4/objdir/gc
c/ -nostdinc++  -L/home/dave/gcc-3.4/objdir/hppa-linux/libstdc++-v3/src -L/home/
dave/gcc-3.4/objdir/hppa-linux/libstdc++-v3/src/.libs -B/home/dave/opt/gnu/hppa-
linux/bin/ -B/home/dave/opt/gnu/hppa-linux/lib/ -isystem /home/dave/opt/gnu/hppa
-linux/include -isystem /home/dave/opt/gnu/hppa-linux/sys-include -shared -nostd
lib /home/dave/opt/gnu/lib/crti.o /home/dave/gcc-3.4/objdir/gcc/crtbeginS.o  .li
bs/allocator-inst.o .libs/codecvt.o .libs/complex_io.o .libs/concept-inst.o .lib
s/ctype.o .libs/demangle.o .libs/ext-inst.o .libs/fstream-inst.o .libs/functexce
pt.o .libs/globals.o .libs/io-inst.o .libs/ios.o .libs/istream-inst.o .libs/limi
ts.o .libs/locale.o .libs/locale-inst.o .libs/localename.o .libs/misc-inst.o .li
bs/ostream-inst.o .libs/sstream-inst.o .libs/stdexcept.o .libs/streambuf-inst.o
.libs/string-inst.o .libs/strstream.o .libs/valarray-inst.o .libs/wstring-inst.o
 .libs/codecvt_members.o .libs/collate_members.o .libs/ctype_members.o .libs/mes
sages_members.o .libs/monetary_members.o .libs/numeric_members.o .libs/time_memb
ers.o .libs/basic_file.o .libs/c++locale.o -Wl,--whole-archive ../libmath/.libs/
libmath.a ../libsupc++/.libs/libsupc++convenience.a -Wl,--no-whole-archive  -L/h
ome/dave/gcc-3.4/objdir/hppa-linux/libstdc++-v3/src -L/home/dave/gcc-3.4/objdir/
hppa-linux/libstdc++-v3/src/.libs -lm ../libmath/.libs/libmath.a -lm ../libsupc+
+/.libs/libsupc++convenience.a -lm -L/home/dave/gcc-3.4/objdir/gcc -L/home/dave/
opt/gnu/hppa-linux/bin -L/home/dave/opt/gnu/hppa-linux/lib -L/home/dave/opt/gnu/
lib -L/home/dave/opt/gnu/lib/gcc-lib/hppa-linux/3.4 -L/home/dave/opt/gnu/lib/gcc
-lib/hppa-linux/3.4/../../../../hppa-linux/lib -L/home/dave/opt/gnu/lib/gcc-lib/
hppa-linux/3.4/../../.. -lgcc_s -lgcc -lc -lgcc_s -lm -lgcc_s -lgcc -lc -lgcc_s
  /home/dave/gcc-3.4/objdir/gcc/crtendS.o /home/dave/opt/gnu/lib/crtn.o  -Wl,-O1
 -Wl,--version-script=libstdc++-symbol.ver -Wl,-soname -Wl,libstdc++.so.6 -o .li
bs/libstdc++.so.6.0.0
/home/dave/opt/gnu/bin/ld: BFD 2.14.90 20030602 internal error, aborting at ../.
./src/bfd/elf32-hppa.c line 3864 in elf32_hppa_relocate_section

/home/dave/opt/gnu/bin/ld: Please report this bug.

collect2: ld returned 1 exit status

The regression was introduced by the following patch:

2003-06-23  Jakub Jelinek  <jakub@redhat.com>

        * method.c (thunk_labelno): New variable.
        (make_alias_for_thunk): New function.
        (use_thunk): Use it if defined ASM_OUTPUT_DEF.  Put the thunk
        into the same section as the function it is calling.
        Include gt-cp-method.h.
        * Make-lang.in (gt-cp-method.h): Depend on s-gtype.
        (cp/method.o): Depend on gt-cp-method.h.
        * config-lang.in (gtfiles): Add $(srcdir)/cp/method.c.

This patch changes the method by which a thunk branches to the thunk
function.  The target of the branch is now effectively a local symbol.
This local symbol lies in a linkonce section.

On the hppa-linux port, the jump to the thunk function is currently
implemented using a function descriptor in the data section.  This
provides a branch that is unlimited in length.  When a linkonce section
is not used, the the GNU linker does not garbage collect relocations
for symbols in the unused section.  The linker aborts when hit hits a
function descriptor with an undefined symbol.

Specifically, the assembly code that causes the problem is:

        .section        .gnu.linkonce.t._ZNSdD1Ev,"ax",@progbits
        .align 4
        .weak   _ZNSdD1Ev
        .type   _ZNSdD1Ev, @function
.LFB1804:
_ZNSdD1Ev:
        .PROC

	...

        .PROCEND

	...

        .set    .LTHUNK1,_ZNSdD1Ev
        .align 4
        .weak   _ZThn8_NSdD1Ev
        .type   _ZThn8_NSdD1Ev, @function
_ZThn8_NSdD1Ev:
        .PROC
        .CALLINFO FRAME=64,CALLS,SAVE_RP
        .ENTRY
        addil LT'.LTHN0,%r19
        ldw RT'.LTHN0(%r1),%r22
        ldw 0(%sr0,%r22),%r22
        bb,>=,n %r22,30,.+16
        depi 0,31,2,%r22
        ldw 4(%sr0,%r22),%r19
        ldw 0(%sr0,%r22),%r22
        be 0(%sr4,%r22)
        ldo -8(%r26),%r26
        .EXIT
        .PROCEND
        .data
        .align 4
.LTHN0:
        .word P'.LTHUNK1
        .section        .gnu.linkonce.t._ZNSdD1Ev     
        .size   _ZThn8_NSdD1Ev, .-_ZThn8_NSdD1Ev

What is new is the .set involving .LTHUNK1 and the use .LTHUNK1 in the
function descriptor at .LTHN0.  As a result, we have a function descriptor
referring to a local symbol in a linkonce section (.gnu.linkonce.t._ZNSdD1Ev).
Previously, the label _ZNSdD1Ev appeared in the function descriptor and
this didn't cause problems.

[Bug c++/11331] [Regression 3.4] ld: BFD 2.14.90 20030602 internal error

[pinskia at physics dot uc dot edu]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11331



------- Additional Comments From pinskia at physics dot uc dot edu  2003-06-26 19:49 -------
I think this is related to bug 11297 	which is for ppc but they look like the same bug.  This 
is a gcc (and a ld bug since ld has a internal error).

[Bug c++/11331] [Regression 3.4] ld: BFD 2.14.90 20030602 internal error

[dave at hiauly1 dot hia dot nrc dot ca]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11331



------- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca  2003-06-26 20:14 -------
Subject: Re:  [Regression 3.4] ld: BFD 2.14.90 20030602 interna

> ------- Additional Comments From pinskia at physics dot uc dot edu
> 2003-06-26 19:49 -------
> I think this is related to bug 11297 	which is for ppc but they look like
> the same bug.  This 
> is a gcc (and a ld bug since ld has a internal error).

Yes, looks like the same bug.  I'm in the process of trying to rewrite
pa_asm_output_mi_thunk to work around the problem.  If it works, the
thunk code will be improved.  However, what we had before was perfectly
functional :(

Dave

[Bug c++/11331] [Regression 3.4] ld: BFD 2.14.90 20030602 internal error

[jakub at gcc dot gnu dot org]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11331



------- Additional Comments From jakub at gcc dot gnu dot org  2003-06-26 20:32 -------
Well, if you want to leave current inefficient thunk, I could certainly add
  aname = IDENTIFIER_POINTER (DECL_ASSEMBLER_NAME (function));
  DECL_ATTRIBUTES (alias)
    = build_tree_list (build_identifier ("alias"),
                       build_tree_list (NULL,
                                        build_string (strlen (aname) + 1,
                                                      aname)));
to make_alias_for_thunk and you can then look up alias attribute in pa_asm_output_thunk and call that instead of the alias. But IMHO it is better
to just optimize the thunks.

[Bug c++/11331] [Regression 3.4] ld: BFD 2.14.90 20030602 internal error

[dave at hiauly1 dot hia dot nrc dot ca]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11331



------- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca  2003-06-27 01:00 -------
Subject: Re:  [Regression 3.4] ld: BFD 2.14.90 20030602 internal error

> ------- Additional Comments From jakub at gcc dot gnu dot org  2003-06-26 20:32 -------
> Well, if you want to leave current inefficient thunk, I could certainly add
>   aname = IDENTIFIER_POINTER (DECL_ASSEMBLER_NAME (function));
>   DECL_ATTRIBUTES (alias)
>     = build_tree_list (build_identifier ("alias"),
>                        build_tree_list (NULL,
>                                         build_string (strlen (aname) + 1,
>                                                       aname)));
> to make_alias_for_thunk and you can then look up alias attribute in pa_asm_output_thunk and call that instead of the alias. But IMHO it is better
> to just optimize the thunks.

This solution is not optimal on the PA.  After a considerable
amount of study, I have concluded that I must request that your patch
be reverted.  Placing the thunk in the same linkonce section as the
method will force us to generate a long branch to the method.  This
will cause worse code to be generated than now.

Before your patch, it was possible to use a one instruction pc-relative
branch from a thunk when the thunk could be in its own section.  If a
long branch was needed, the linker would add automatically a long branch
stub.  When you place the thunk into the same linkonce section as the
method, we can no longer be certain that a pc-relative branch will have
the range to reach its target, nor will it be guaranteed that it can reach
a long branch stub.

Placement of thunks before the method is preferable on the PA.  This
allows at least twenty thousand thunks before a long branch is needed
to reach the method.  With thunks after the method, we might need long
branches from all thunks if the method is large.

It's not clear from your original posting, but it does not appear that
your change actually provided improved code efficiency on x86 and x86_64
where it was tested.  If this is beneficial on these and other ports,
then I suggest that some additional define be required to enable
the change so that ports that would prefer the old implementation
would still have that option (I understand that this change also
likely broke the powerpc port).

Dave

[Bug c++/11331] [Regression 3.4] ld: BFD 2.14.90 20030602 internal error

[jakub at gcc dot gnu dot org]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11331



------- Additional Comments From jakub at gcc dot gnu dot org  2003-06-27 09:36 -------
I admit I know nothing about PA assembly, but I find it very surprising
a branch (even if long branch) is more expensive than short branch to .plt
and call through that or load from .got and indirect jump to that.
As to what advantages does it bring on other arches, I'll mention just a few,
others have similar advantages:
ia32, -fpic -O2 before the patch:
        movl    4(%esp), %eax
        movl    (%eax), %ecx
        addl    -12(%ecx), %eax
        movl    %eax, 4(%esp)
        call    .L85
.L85:   popl    %ecx
        addl    $_GLOBAL_OFFSET_TABLE_+[.-.L85], %ecx
        movl    _ZN1CD1Ev@GOT(%ecx), %ecx
        jmp     *%ecx

ia32, -fpic -O2 after the patch (plus likely one less dynamic relocation):
        movl    4(%esp), %eax
        movl    (%eax), %ecx
        addl    -12(%ecx), %eax
        movl    %eax, 4(%esp)
        jmp     .LTHUNK0

amd64, -fpic -O2 before:
        movq    (%rdi), %r10
        addq    -24(%r10), %rdi
        jmp     *_ZN1CD1Ev@GOTPCREL(%rip)

amd64, -fpic -O2 after:
        movq    (%rdi), %r10
        addq    -24(%r10), %rdi
        jmp     .LTHUNK0

s390, -fPIC -O2 before:
        lhi     %r1,-12
        a       %r1,0(%r2)
        a       %r2,0(%r1)
        basr    %r1,0
.L96:   l       %r0,.L97-4-.L96(%r1)
        a       %r1,.L97-.L96(%r1)
        ar      %r1,%r0
        l       %r1,0(%r1)
        br      %r1
        .align  4
        .long   _ZN1CD1Ev@GOT
.L97:   .long   _GLOBAL_OFFSET_TABLE_-.L96

s390, -fPIC -O2 after:
        lhi     %r1,-12
        a       %r1,0(%r2)
        a       %r2,0(%r1)
        basr    %r1,0
.L96:   a       %r1,.L97-.L96(%r1)
        br      %r1
        .align  4
.L97:   .long   .LTHUNK0-.L96

s390x, -fpic -O2 before:
        lghi    %r1,-24
        ag      %r1,0(%r2)
        ag      %r2,0(%r1)
        jg      _ZN1CD1Ev@PLT
# Where in the better case resolved plt slot looks like:
        larl    %r1,XX@GOTENT
        lg      %r1,0(%r1)
        bcr     %r15,%r1

s390x, -fpic -O2 after:
        lghi    %r1,-24
        ag      %r1,0(%r2)
        ag      %r2,0(%r1)
        jg      .LTHUNK0

ppc32, -fpic -O2 before:
        lwz 9,0(3)
        lwz 0,-12(9)
        add 3,3,0
        b _ZN1CD1Ev@plt
# Where plt slot after resolving will likely be a relative branch

ppc32, -fpic -O2 after:
        lwz 9,0(3)
        lwz 0,-12(9)
        add 3,3,0
        b .LTHUNK0@local

Also, what is totally unclear to me is why simple short branch is acceptable
on hppa without -fpic but i not with -fpic. Do you have different size limitations for shared libraries and binaries?

[Bug c++/11331] [Regression 3.4] ld: BFD 2.14.90 20030602 internal error

[dave at hiauly1 dot hia dot nrc dot ca]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11331



------- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca  2003-06-27 16:40 -------
Subject: Re:  [Regression 3.4] ld: BFD 2.14.90 20030602 internal error

> ------- Additional Comments From jakub at gcc dot gnu dot org  2003-06-27 09:36 -------
> I admit I know nothing about PA assembly, but I find it very surprising
> a branch (even if long branch) is more expensive than short branch to .plt
> and call through that or load from .got and indirect jump to that.

Indirect calls are done somewhat differently on the PA.  The forms that
you mention don't exist on the PA.

Have you looked at PR 11297?  It looks as if there is a similar problem
on powerpc-unknown-linux-gnu.  See comment #8 by Matt Kraai.

While I believe that it's possible to avoid the above problem using
various flavors of pc-relative branches for the jump, this requires
a significant amount of time to implement and test given the varying
capabilities of the different assemblers and linkers on the various
PA ports.

As I previously stated, the principal objection to your patch is
the placement of the thunk in the same section as the method.  We have
more flexibility in the selection of branch type on the linux port if
this is not done.  It's better if the thunk is in its own section when
-ffunction-sections is specified.  In this case, we can generate a
short pc-relative branch and be certain that it can reach its target.

Dave

[Bug target/11331] [Regression 3.4] ld: BFD 2.14.90 20030602 internal error

[pinskia at physics dot uc dot edu]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11331


pinskia at physics dot uc dot edu changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c++                         |target

[Bug target/11331] [Regression 3.4] ld: BFD 2.14.90 20030602 internal error

[pinskia at physics dot uc dot edu]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11331


pinskia at physics dot uc dot edu changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-code
           Priority|P3                          |P1

[Bug target/11331] [3.4 Regression] ld: BFD 2.14.90 20030602 internal error

[pinskia at gcc dot gnu dot org]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11331


pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[Regression 3.4] ld: BFD    |[3.4 Regression] ld: BFD
                   |2.14.90 20030602 internal   |2.14.90 20030602 internal
                   |error                       |error


------- Additional Comments From pinskia at gcc dot gnu dot org  2003-08-09 16:51 -------
Does this still exists on the mainline any more?

[Bug target/11331] [3.4 Regression] ld: BFD 2.14.90 20030602 internal error

[dave at hiauly1 dot hia dot nrc dot ca]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11331



------- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca  2003-08-09 19:08 -------
Subject: Re:  [3.4 Regression] ld: BFD 2.14.90 20030602 inte

> PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11331
> 
> 
> pinskia at gcc dot gnu dot org changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>             Summary|[Regression 3.4] ld: BFD    |[3.4 Regression] ld: BFD
>                    |2.14.90 20030602 internal   |2.14.90 20030602 internal
>                    |error                       |error
> 
> 
> ------- Additional Comments From pinskia at gcc dot gnu dot org  2003-08-09
> 16:51 -------
> Does this still exists on the mainline any more?

I guess this is now fixed.  The hppa-linux port is bootstrapping again.
I fixed a typo in pa_asm_output_mi_thunk this morning which caused a
problem on hppa2.0-hp-hpux11.11.

We now use alternate call sequences to work around the linker problem.
The length returned by attr_length_call in pa.c still does not reflect
reality and needs more work.  So far, the thunk/call rewrite has taken
about three weeks work and I'm not sure what we have is correct yet.
I'm thinking we should be using `(*targetm.binds_local_p)' to check
for local calls.  Currently, I'm just checking TREE_PUBLIC.

Dave

[Bug target/11331] [3.4 Regression] ld: BFD 2.14.90 20030602 internal error

[dave at hiauly1 dot hia dot nrc dot ca]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11331



------- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca  2003-08-09 19:47 -------
Subject: Re:  [3.4 Regression] ld: BFD 2.14.90 20030602 internal error

> I guess this is now fixed.  The hppa-linux port is bootstrapping again.

Correction, all languages except for ada now build under hppa-linux.

Dave

[Bug target/11331] [3.4 Regression] ld: BFD 2.14.90 20030602 internal error

[pinskia at gcc dot gnu dot org]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11331


pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |FIXED


------- Additional Comments From pinskia at gcc dot gnu dot org  2003-08-11 15:12 -------
Can you report the Ada bootstrap problem in a different bug.
Closing as this is fixed.

[Bug target/11331] [3.4 Regression] ld: BFD 2.14.90 20030602 internal error

[pinskia at gcc dot gnu dot org]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11331



------- Additional Comments From pinskia at gcc dot gnu dot org  2003-08-11 15:21 -------
I found the Ada was already reported in bug 11414, no need to file another one.