Problems with linker on Alpha

Problems with linker on Alpha

[Michael Cree]

Richard,

I hope you don't mind an email sent to you personally regarding problems 
with the linker on Alpha (I've also CCed the debian-alpha and binutils 
mail lists).

I've noted some problems with ld on Alpha and am wanting to put some 
effort into fixing them but will need a bit of guidance and assistance.

First off is bug 12608 [1] which I believe I have identified the problem 
and have posted a patch to the bug tracker.  I am hoping that if it is 
acceptable that you can commit it.

Secondly, I noted a number of test suite failures in the ld component 
while building binutils.  Some of them are with plugins which might 
explain why bugs/crashes seem to randomly appear and disappear with 
larger software packages using plugins. I would like to investigate the 
test suite failures but am yet to understand the automated system using 
expect and isolate each test so that I can run them manually.  Are you 
able to give me a bit of guidance on that?

Thirdly, a number of large C++ programs (such as firefox/xulrunner, 
webkit, libreoffice) bomb out with GPREL16 relocation truncation errors 
when using the -relax option but link successfully when using 
--no-relax.  I have reopened bug 5276 [2] which describes this problem. 
  It would be nice to get this problem fixed!

Fourthly, the Debian supplied gcc-4.6 fails to build on Debian because 
of a boostrap comparison failure, so I attempted to build upstream 
gcc-4.6 branch source which got past the bootstrap comparison but failed 
later on with the following error:

/usr/bin/ld: BFD (GNU Binutils for Debian) 2.21.51.20110419 internal 
error, aborting at ../../bfd/elf64-alpha.c line 2064 in 
elf64_alpha_gc_sweep_hook

when linking libstdc++.  This is using the Debian supplied bintuils 
version 2.21.51.20110419-2, also with my patch to fix the TLS issue. 
Maybe I should make a bug entry for it.

So there are a number of issues that I would like to work on but while I 
believe I solved bug 12608 some of the others are more challenging and I 
need some guidance to be able to make (or speed up) progress. I should 
be grateful if you could assist!

Cheers
Michael.

[1] http://sourceware.org/bugzilla/show_bug.cgi?id=12608
[2] http://sourceware.org/bugzilla/show_bug.cgi?id=5276

Re: Problems with linker on Alpha

[Richard Henderson]

On 04/30/2011 07:25 PM, Michael Cree wrote:
> First off is bug 12608 [1] which I believe I have identified the
> problem and have posted a patch to the bug tracker.  I am hoping that
> if it is acceptable that you can commit it.

I'll have a look.

> Secondly, I noted a number of test suite failures in the ld component
> while building binutils.  Some of them are with plugins which might
> explain why bugs/crashes seem to randomly appear and disappear with
> larger software packages using plugins. I would like to investigate
> the test suite failures but am yet to understand the automated system
> using expect and isolate each test so that I can run them manually.
> Are you able to give me a bit of guidance on that?

"Large number"?  I get

                === binutils Summary ===

# of expected passes            81
# of unsupported tests          2
Host   is x86_64-unknown-linux-gnu

                === gas Summary ===

# of expected passes            132
# of expected failures          1
# of unsupported tests          1
Host   is x86_64-unknown-linux-gnu

                === ld tests ===

Running target alpha-qemu
FAIL: plugin claimfile lost symbol
FAIL: plugin claimfile replace symbol
FAIL: plugin claimfile resolve symbol
XPASS: Preserve default . = 0
XPASS: Preserve explicit . = 0

                === ld Summary ===

# of expected passes            278
# of unexpected failures        3
# of unexpected successes       2
# of expected failures          7

That plugin test, as far as I know, isn't system specific and fails
for all targets.

> Thirdly, a number of large C++ programs (such as firefox/xulrunner,
> webkit, libreoffice) bomb out with GPREL16 relocation truncation
> errors when using the -relax option but link successfully when using
> --no-relax.  I have reopened bug 5276 [2] which describes this
> problem.  It would be nice to get this problem fixed!

Yeah.  Uros just reported this same problem with gcc itself.

Also, I'm aware of an ld -relax bug that causes the Linux kernel
to be mis-compiled.  Thankfully at the moment the default is to
not apply relaxation during the kernel link.

> Fourthly, the Debian supplied gcc-4.6 fails to build on Debian
> because of a boostrap comparison failure, so I attempted to build
> upstream gcc-4.6 branch source which got past the bootstrap
> comparison but failed later on with the following error:
> 
> /usr/bin/ld: BFD (GNU Binutils for Debian) 2.21.51.20110419 internal error, aborting at ../../bfd/elf64-alpha.c line 2064 in elf64_alpha_gc_sweep_hook
> 
> when linking libstdc++.  This is using the Debian supplied bintuils
> version 2.21.51.20110419-2, also with my patch to fix the TLS issue.
> Maybe I should make a bug entry for it.

Yes, please to enter a bug for it.  I hadn't seen this one before,
possibly because I've been cheating and only building C.

I've been working on getting QEMU working for alpha-softmmu recently,
hoping to be able to debug some of the alpha problems that have been
creeping in "natively".


r~

Re: Problems with linker on Alpha

[Alan Modra]

On Mon, May 02, 2011 at 12:26:22PM -0700, Richard Henderson wrote:
> That plugin test, as far as I know, isn't system specific and fails
> for all targets.

Passes as of 2011-04-18

-- 
Alan Modra
Australia Development Lab, IBM

Re: Problems with linker on Alpha

[Michael Cree]

On 03/05/11 07:26, Richard Henderson wrote:
> On 04/30/2011 07:25 PM, Michael Cree wrote:
>> Secondly, I noted a number of test suite failures in the ld component
>> while building binutils.
>
> "Large number"?  I get
[...snip...]
>                  === ld tests ===
>
> Running target alpha-qemu
> FAIL: plugin claimfile lost symbol
> FAIL: plugin claimfile replace symbol
> FAIL: plugin claimfile resolve symbol
> XPASS: Preserve default . = 0
> XPASS: Preserve explicit . = 0
>
>                  === ld Summary ===
>
> # of expected passes            278
> # of unexpected failures        3
> # of unexpected successes       2
> # of expected failures          7

Building binutils 2.21.51.20110419-2 from Debian (also with my fix tls 
patch) I get:

                 === ld tests ===

Running target unix
FAIL: Build libpr9676-4a.so
FAIL: Build libpr9679.so
FAIL: vers24a
FAIL: vers24b
FAIL: vers24c
FAIL: vers30
FAIL: vers31
FAIL: plugin claimfile lost symbol
FAIL: plugin claimfile replace symbol
FAIL: plugin claimfile resolve symbol
XPASS: Preserve default . = 0
XPASS: Preserve explicit . = 0

                 === ld Summary ===

# of expected passes            505
# of unexpected failures        10
# of unexpected successes       2
# of expected failures          34
# of untested testcases         1

I see there's a lot more tests done with the unix target, nevertheless 
I'll re-test with binutils master cvs to see if some of those unexpected 
failures go away.

Cheers
Michael.

Re: Problems with linker on Alpha

[Michael Cree]

On 03/05/11 21:21, Michael Cree wrote:
> On 03/05/11 07:26, Richard Henderson wrote:
>> On 04/30/2011 07:25 PM, Michael Cree wrote:
>>> Secondly, I noted a number of test suite failures in the ld component
>>> while building binutils.

> === ld Summary ===
>
> # of expected passes 505
> # of unexpected failures 10
> # of unexpected successes 2
> # of expected failures 34
> # of untested testcases 1
>
> I see there's a lot more tests done with the unix target, nevertheless
> I'll re-test with binutils master cvs to see if some of those unexpected
> failures go away.

No, they don't go away.  The unexpected failures are still there when 
compiling and testing cvs master.

Cheers
Michael.

Re: Problems with linker on Alpha

[Witold Baryluk]

[-- Attachment #1: Type: text/plain, Size: 3693 bytes --]

On 05-02 12:26, Richard Henderson wrote:
> On 04/30/2011 07:25 PM, Michael Cree wrote:
> > First off is bug 12608 [1] which I believe I have identified the
> > problem and have posted a patch to the bug tracker.  I am hoping that
> > if it is acceptable that you can commit it.
> 
> I'll have a look.
> 
> > Secondly, I noted a number of test suite failures in the ld component
> > while building binutils.  Some of them are with plugins which might
> > explain why bugs/crashes seem to randomly appear and disappear with
> > larger software packages using plugins. I would like to investigate
> > the test suite failures but am yet to understand the automated system
> > using expect and isolate each test so that I can run them manually.
> > Are you able to give me a bit of guidance on that?
> 
> "Large number"?  I get
> 
>                 === binutils Summary ===
> 
> # of expected passes            81
> # of unsupported tests          2
> Host   is x86_64-unknown-linux-gnu
> 
>                 === gas Summary ===
> 
> # of expected passes            132
> # of expected failures          1
> # of unsupported tests          1
> Host   is x86_64-unknown-linux-gnu
> 
>                 === ld tests ===
> 
> Running target alpha-qemu
> FAIL: plugin claimfile lost symbol
> FAIL: plugin claimfile replace symbol
> FAIL: plugin claimfile resolve symbol
> XPASS: Preserve default . = 0
> XPASS: Preserve explicit . = 0
> 
>                 === ld Summary ===
> 
> # of expected passes            278
> # of unexpected failures        3
> # of unexpected successes       2
> # of expected failures          7
> 
> That plugin test, as far as I know, isn't system specific and fails
> for all targets.
> 
> > Thirdly, a number of large C++ programs (such as firefox/xulrunner,
> > webkit, libreoffice) bomb out with GPREL16 relocation truncation
> > errors when using the -relax option but link successfully when using
> > --no-relax.  I have reopened bug 5276 [2] which describes this
> > problem.  It would be nice to get this problem fixed!
> 
> Yeah.  Uros just reported this same problem with gcc itself.
> 
> Also, I'm aware of an ld -relax bug that causes the Linux kernel
> to be mis-compiled.  Thankfully at the moment the default is to
> not apply relaxation during the kernel link.
> 
> > Fourthly, the Debian supplied gcc-4.6 fails to build on Debian
> > because of a boostrap comparison failure, so I attempted to build
> > upstream gcc-4.6 branch source which got past the bootstrap
> > comparison but failed later on with the following error:
> > 
> > /usr/bin/ld: BFD (GNU Binutils for Debian) 2.21.51.20110419 internal error, aborting at ../../bfd/elf64-alpha.c line 2064 in elf64_alpha_gc_sweep_hook

I'm now also comiling vanila gcc-4.6.0 on both unstable as well lenny to see if this is a regression
in binutils or other components.

> > 
> > when linking libstdc++.  This is using the Debian supplied bintuils
> > version 2.21.51.20110419-2, also with my patch to fix the TLS issue.
> > Maybe I should make a bug entry for it.
> 
> Yes, please to enter a bug for it.  I hadn't seen this one before,
> possibly because I've been cheating and only building C.
> 
> I've been working on getting QEMU working for alpha-softmmu recently,
> hoping to be able to debug some of the alpha problems that have been
> creeping in "natively".

Hi, thanks into looking into alpha issues.

As of QEMU i must say "Cool!".
I was going to work on qemu-alpha after fixing linker and compiler issue
in current versions. Is there any repository for you work?

Regards,
Witek

-- 
Witold Baryluk

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Problems with linker on Alpha

[Michael Cree]

On 03/05/11 21:21, Michael Cree wrote:
> On 03/05/11 07:26, Richard Henderson wrote:
>> On 04/30/2011 07:25 PM, Michael Cree wrote:
>>> Secondly, I noted a number of test suite failures in the ld component
>>> while building binutils.
>
> Building binutils 2.21.51.20110419-2 from Debian (also with my fix tls
> patch) I get:
>
> === ld tests ===
>
> Running target unix
> FAIL: Build libpr9676-4a.so

It passes on amd64 and powerpc.  Amd64 has in the readelf output of 
libpr9676-4a.so the following line:

     52: 0000000000000650     6 FUNC    LOCAL  DEFAULT   12 foo

(and similarly powerpc) which is tested for by (and matches) the 
following regular expression:

  +[0-9]+: +[0-9a-f]+ +[0-9a-f]+ +FUNC +LOCAL +DEFAULT +[0-9]+ +_?foo

that is in pr9676.rd.

But the output of readelf of libpr9676-4a.so on Alpha contains the 
following:

     45: 00000000000007c0     8 FUNC    LOCAL  DEFAULT [<other>: 80] 
11 foo

That is, it contains an extra "[<other>: 80]" which does not match the 
regular expression in the test.

So my question is, what is this "[<other>: 80]"?  Does it matter?  Is 
this failure a false report?

Cheers
Michael.

Re: Problems with linker on Alpha

[Richard Henderson]

On 05/06/2011 03:25 AM, Michael Cree wrote:
> So my question is, what is this "[<other>: 80]"?  Does it matter?  Is this failure a false report?

It's these:

/* Legal values for st_other field of Elf64_Sym.  */
#define STO_ALPHA_NOPV          0x80    /* No PV required.  */
#define STO_ALPHA_STD_GPLOAD    0x88    /* PV only used for initial ldgp.  */

They're used for relaxation, and they don't matter for the purposes of this test.

I think the regexp can be equivalently written

 +[0-9]+: +[0-9a-f]+ +[0-9a-f]+ +FUNC +LOCAL +DEFAULT .+ _?foo 

I.e. accept whatever in between DEFAULT and foo.


r~

Re: Problems with linker on Alpha

[Michael Cree]

On 03/05/11 12:32, Alan Modra wrote:
> On Mon, May 02, 2011 at 12:26:22PM -0700, Richard Henderson wrote:
>> That plugin test, as far as I know, isn't system specific and fails
>> for all targets.
> 
> Passes as of 2011-04-18

Fails on Alpha at 2011-05-28.  In particular the following tests fail:

FAIL: plugin claimfile lost symbol
FAIL: plugin claimfile replace symbol
FAIL: plugin claimfile resolve symbol

Going back to the first one the ld.log file contains:

Hello from testplugin.
tv[0]: LDPT_MESSAGE func@0x0x120028690
tv[1]: LDPT_API_VERSION value        0x1 (1)
tv[2]: LDPT_GNU_LD_VERSION value       0xdd (221)
tv[3]: LDPT_LINKER_OUTPUT value        0x1 (1)
tv[4]: LDPT_OUTPUT_NAME 'tmpdir/main.x'
tv[5]: LDPT_REGISTER_CLAIM_FILE_HOOK func@0x0x120027ce0
tv[6]: LDPT_REGISTER_ALL_SYMBOLS_READ_HOOK func@0x0x120027c50
tv[7]: LDPT_REGISTER_CLEANUP_HOOK func@0x0x120027bc0
tv[8]: LDPT_ADD_SYMBOLS func@0x0x120028330
tv[9]: LDPT_GET_INPUT_FILE func@0x0x120027b60
tv[10]: LDPT_RELEASE_INPUT_FILE func@0x0x120027b00
tv[11]: LDPT_GET_SYMBOLS func@0x0x120027f20
tv[12]: LDPT_ADD_INPUT_FILE func@0x0x120027e90
tv[13]: LDPT_ADD_INPUT_LIBRARY func@0x0x120027e00
tv[14]: LDPT_SET_EXTRA_LIBRARY_PATH func@0x0x120027d70
tv[15]: LDPT_OPTION 'registerclaimfile'
tv[16]: LDPT_OPTION 'registerallsymbolsread'
tv[17]: LDPT_OPTION 'registercleanup'
tv[18]: LDPT_OPTION 'claim:tmpdir/func.o'
tv[19]: LDPT_NULL value        0x0 (0)
hook called: claim_file tmpdir/main.o [@0/4320] not claimed
hook called: claim_file tmpdir/func.o [@0/3288] CLAIMED
hook called: claim_file tmpdir/text.o [@0/2472] not claimed
hook called: all symbols read.
/home/mjc/toolchain/binutils.git/ld/ld-new: warning: cannot find entry
symbol _start; defaulting to 00
000001200000f0
tmpdir/main.o: In function `main':
/home/mjc/toolchain/binutils.git/ld/testsuite/ld-plugin/main.c:12:
undefined reference to `func'
/home/mjc/toolchain/binutils.git/ld/testsuite/ld-plugin/main.c:12:
undefined reference to `func'
hook called: cleanup.
regexp_diff match failure
regexp "^hook called: cleanup.$"
line
"/home/mjc/toolchain/binutils.git/ld/testsuite/ld-plugin/main.c:12:
undefined reference to `fun
c'"


The regular expression in testsuite/ld-plugin/plugin-6.d only expects
one line with the "undefined reference to `func'" but on Alpha two such
(identical) lines are generated.

Should two such lines really be printed (i.e. is this a bug in the Alpha
linker) or should the regexp be updated to cope with the possibility of
the undefined reference line being printed twice?

Cheers
Michael.

Re: Problems with linker on Alpha

[Michael Cree]

[-- Attachment #1: Type: text/plain, Size: 757 bytes --]

On 07/05/11 02:08, Richard Henderson wrote:
> On 05/06/2011 03:25 AM, Michael Cree wrote:
>> So my question is, what is this "[<other>: 80]"?  Does it matter?  Is this failure a false report?
> 
> It's these:
> 
> /* Legal values for st_other field of Elf64_Sym.  */
> #define STO_ALPHA_NOPV          0x80    /* No PV required.  */
> #define STO_ALPHA_STD_GPLOAD    0x88    /* PV only used for initial ldgp.  */
> 
> They're used for relaxation, and they don't matter for the purposes of this test.
> 
> I think the regexp can be equivalently written
> 
>  +[0-9]+: +[0-9a-f]+ +[0-9a-f]+ +FUNC +LOCAL +DEFAULT .+ _?foo 
> 
> I.e. accept whatever in between DEFAULT and foo.

Patch attached to fix these falsely reported testsuite failures.

Cheers
Michael.

[-- Attachment #2: 0001-ld-Tweak-regexps-in-testsuite-to-fix-false-FAILs-on-.patch --]
[-- Type: text/x-patch, Size: 3951 bytes --]

From 3a0618a1bae443368363ed6d0f83b68469bc5a2a Mon Sep 17 00:00:00 2001
From: Michael Cree <mcree@orcon.net.nz>
Date: Sun, 29 May 2011 15:06:56 +1200
Subject: [PATCH] ld: Tweak regexps in testsuite to fix false FAILs on Alpha

Objdump with the Alpha target prints some extra information out
which certain regexps in the ld testsuite do not cater for. This
patch generalises the regexps for the tests listed below as
suggested by Richard Henderson.

ld-elf/pr9676.rd
ld-elf/pr9679.rd
ld-elfvers/vers24.rd
ld-elfvers/vers30.dsym
ld-elfvers/vers31.dsym

Signed-off-by: Michael Cree <mcree@orcon.net.nz>
---
 ld/testsuite/ld-elf/pr9676.rd       |    2 +-
 ld/testsuite/ld-elf/pr9679.rd       |    2 +-
 ld/testsuite/ld-elfvers/vers24.rd   |    4 ++--
 ld/testsuite/ld-elfvers/vers30.dsym |    8 ++++----
 ld/testsuite/ld-elfvers/vers31.dsym |    2 +-
 5 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/ld/testsuite/ld-elf/pr9676.rd b/ld/testsuite/ld-elf/pr9676.rd
index 2d832db..d08fd86 100644
--- a/ld/testsuite/ld-elf/pr9676.rd
+++ b/ld/testsuite/ld-elf/pr9676.rd
@@ -1,5 +1,5 @@
 Symbol table '\.dynsym' contains [0-9]+ entries:
  +Num: +Value +Size Type +Bind +Vis +Ndx Name
 #...
- +[0-9]+: +[0-9a-f]+ +[0-9a-f]+ +FUNC +LOCAL +DEFAULT +[0-9]+ +_?foo
+ +[0-9]+: +[0-9a-f]+ +[0-9a-f]+ +FUNC +LOCAL +DEFAULT .+ +_?foo
 #...
diff --git a/ld/testsuite/ld-elf/pr9679.rd b/ld/testsuite/ld-elf/pr9679.rd
index 2d832db..d08fd86 100644
--- a/ld/testsuite/ld-elf/pr9679.rd
+++ b/ld/testsuite/ld-elf/pr9679.rd
@@ -1,5 +1,5 @@
 Symbol table '\.dynsym' contains [0-9]+ entries:
  +Num: +Value +Size Type +Bind +Vis +Ndx Name
 #...
- +[0-9]+: +[0-9a-f]+ +[0-9a-f]+ +FUNC +LOCAL +DEFAULT +[0-9]+ +_?foo
+ +[0-9]+: +[0-9a-f]+ +[0-9a-f]+ +FUNC +LOCAL +DEFAULT .+ +_?foo
 #...
diff --git a/ld/testsuite/ld-elfvers/vers24.rd b/ld/testsuite/ld-elfvers/vers24.rd
index 42e81e4..dfeea95 100644
--- a/ld/testsuite/ld-elfvers/vers24.rd
+++ b/ld/testsuite/ld-elfvers/vers24.rd
@@ -7,9 +7,9 @@ Symbol table '.dynsym' contains [0-9]+ entries:
 # And ensure the dynamic symbol table contains at least x@VERS.0
 # and foo@@VERS.0 symbols
 #...
- +[0-9]+: [0-9a-f]+ +(4 +OBJECT +GLOBAL +DEFAULT +[0-9]+ _?x|[0-9]+ +FUNC +GLOBAL +DEFAULT +[0-9]+ _?foo@)@VERS\.0
+ +[0-9]+: [0-9a-f]+ +(4 +OBJECT +GLOBAL +DEFAULT +[0-9]+ _?x|[0-9]+ +FUNC +GLOBAL +DEFAULT .+ _?foo@)@VERS\.0
 #...
- +[0-9]+: [0-9a-f]+ +(4 +OBJECT +GLOBAL +DEFAULT +[0-9]+ _?x|[0-9]+ +FUNC +GLOBAL +DEFAULT +[0-9]+ _?foo@)@VERS\.0
+ +[0-9]+: [0-9a-f]+ +(4 +OBJECT +GLOBAL +DEFAULT +[0-9]+ _?x|[0-9]+ +FUNC +GLOBAL +DEFAULT .+ _?foo@)@VERS\.0
 #...
 Symbol table '.symtab' contains [0-9]+ entries:
 #pass
diff --git a/ld/testsuite/ld-elfvers/vers30.dsym b/ld/testsuite/ld-elfvers/vers30.dsym
index 5762f01..d80d7f3 100644
--- a/ld/testsuite/ld-elfvers/vers30.dsym
+++ b/ld/testsuite/ld-elfvers/vers30.dsym
@@ -1,5 +1,5 @@
 0+ g    DO \*ABS\*	0+  VERS_30\.0   VERS_30\.0
-[0-9a-f]+ g    DF (\.text|\.opd|\*ABS\*)	[0-9a-f]+  VERS_30\.0   _?global
-[0-9a-f]+ g    DF (\.text|\.opd|\*ABS\*)	[0-9a-f]+  VERS_30\.0   _?foo
-[0-9a-f]+ g    DF (\.text|\.opd|\*ABS\*)	[0-9a-f]+  VERS_30\.0   _?info
-[0-9a-f]+ g    DF (\.text|\.opd|\*ABS\*)	[0-9a-f]+  VERS_30\.0   _?extern
+[0-9a-f]+ g    DF (\.text|\.opd|\*ABS\*)	[0-9a-f]+  VERS_30\.0 .* _?global
+[0-9a-f]+ g    DF (\.text|\.opd|\*ABS\*)	[0-9a-f]+  VERS_30\.0 .* _?foo
+[0-9a-f]+ g    DF (\.text|\.opd|\*ABS\*)	[0-9a-f]+  VERS_30\.0 .* _?info
+[0-9a-f]+ g    DF (\.text|\.opd|\*ABS\*)	[0-9a-f]+  VERS_30\.0 .* _?extern
diff --git a/ld/testsuite/ld-elfvers/vers31.dsym b/ld/testsuite/ld-elfvers/vers31.dsym
index fb22f5b..e9f6ff6 100644
--- a/ld/testsuite/ld-elfvers/vers31.dsym
+++ b/ld/testsuite/ld-elfvers/vers31.dsym
@@ -1,2 +1,2 @@
 0+ g +DO \*ABS\*	0+ +VERS_31\.0 +VERS_31\.0
-[0-9a-f]+ g +DF (\.text|\.opd|\*ABS\*)	[0-9a-f]+ +VERS_31\.0 +_?_Z1fIA3_icEvPT_T0
+[0-9a-f]+ g +DF (\.text|\.opd|\*ABS\*)	[0-9a-f]+ +VERS_31\.0.+ +_?_Z1fIA3_icEvPT_T0
-- 
1.7.4.1

Re: Problems with linker on Alpha

[Alan Modra]

On Sun, May 29, 2011 at 03:36:52PM +1200, Michael Cree wrote:
> The regular expression in testsuite/ld-plugin/plugin-6.d only expects
> one line with the "undefined reference to `func'" but on Alpha two such
> (identical) lines are generated.
> 
> Should two such lines really be printed (i.e. is this a bug in the Alpha
> linker) or should the regexp be updated to cope with the possibility of
> the undefined reference line being printed twice?

I don't have anything like an up to date alpha compiler handy, so
can't give a definitive answer.  You should only get one message if
there was only one relocation reference to "func" from main.c, but be
aware that testsuite log files often duplicate output.

-- 
Alan Modra
Australia Development Lab, IBM

Re: Problems with linker on Alpha

[Richard Henderson]

On 05/29/2011 05:39 PM, Alan Modra wrote:
> On Sun, May 29, 2011 at 03:36:52PM +1200, Michael Cree wrote:
>> The regular expression in testsuite/ld-plugin/plugin-6.d only expects
>> one line with the "undefined reference to `func'" but on Alpha two such
>> (identical) lines are generated.
>>
>> Should two such lines really be printed (i.e. is this a bug in the Alpha
>> linker) or should the regexp be updated to cope with the possibility of
>> the undefined reference line being printed twice?
> 
> I don't have anything like an up to date alpha compiler handy, so
> can't give a definitive answer.  You should only get one message if
> there was only one relocation reference to "func" from main.c, but be
> aware that testsuite log files often duplicate output.
> 

There are probably two references: the first is the LITERAL that 
loads the address from the .got, the second is the LITUSE that
annotates the jsr insn for relaxation.


r~