[Bug gas/12263] Compiling bfd/compress.c fails on Solaris 8 with included zlib.h
https://sourceware.org/bugzilla/show_bug.cgi?id=12263 --- Comment #3 from Rainer Orth --- > --- Comment #2 from Tom Tromey --- > Is this still a problem? > I see zlib in the binutils source tree now. I happen to have a Solaris 8/x86 VM around and gave building binutils 2.41 with gcc 4.7 (the last supported version) a try. However, that already fails compiling bfd/doc/chew.c: /vol/src/gnu/binutils/binutils-2.41/bfd/doc/chew.c: In function 'print': /vol/src/gnu/binutils/binutils-2.41/bfd/doc/chew.c:1464:60: error: expected ')' before 'PRIdPTR' TBH, Solaris 8 and 9 are such ancient history by now that I wouldn't bother with either of them. They have been obsoleted in GCC and GDB for years, and even GCC 10 is considered obsolete there. As such, I'd just close this as WONTFIX (if it even is an issue any longer). -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29512] ld non-canon ref to canon protected function check breaks Solaris/x86
https://sourceware.org/bugzilla/show_bug.cgi?id=29512 --- Comment #3 from Rainer Orth --- > --- Comment #2 from H.J. Lu --- > Created attachment 14288 > --> https://sourceware.org/bugzilla/attachment.cgi?id=14288=edit > A patch > > Try this. I've just successfully completed a i386-pc-solaris2.11 bootstrap. Looks good to go. Thanks. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29424] ld chokes on DW_FORM_rnglistx
https://sourceware.org/bugzilla/show_bug.cgi?id=29424 --- Comment #5 from Rainer Orth --- > --- Comment #4 from Rainer Orth --- > I've just spotchecked ld 2.38.90 with that patch included with my > testcase: the link worked fine (or rather failed as expected due to the > missing __atomic_* symbols, but without the DWARF error). I'm now > running a full LLVM main build with that ld on > sparc64-unknown-linux-gnu. Will take a couple of hours, though... The build just completed without any issues. Thanks again. Rainer -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29424] ld chokes on DW_FORM_rnglistx
https://sourceware.org/bugzilla/show_bug.cgi?id=29424 --- Comment #4 from Rainer Orth --- > --- Comment #2 from Nick Clifton --- Hi Nick, > Unfortunately the reproducer fails for me due to lots of missing system > libraries. Not surprising really given that I was running the test on an > x86_64 linux box... no wonder indeed. That's why I mentioned gcc202 ;-) > Please could you try out the patch I am about to upload. It does not do > much > more than ignore the form, but it may be enough in this particular case. (I > believe that the linker is only parsing the DWARF information so that it can > generate an error message about the missing symbols, so I am hoping that not > decoding the range information will not be a big problem). I've just spotchecked ld 2.38.90 with that patch included with my testcase: the link worked fine (or rather failed as expected due to the missing __atomic_* symbols, but without the DWARF error). I'm now running a full LLVM main build with that ld on sparc64-unknown-linux-gnu. Will take a couple of hours, though... Thanks. Rainer -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29411] ld warning on SPARC: LOAD segment with RWX permissions
https://sourceware.org/bugzilla/show_bug.cgi?id=29411 --- Comment #7 from Rainer Orth --- > --- Comment #6 from Rainer Orth --- >> --- Comment #5 from Nick Clifton --- >> (In reply to Rainer Orth from comment #4) >> >>> I missed this, although I saw the initial discussion about this warning >>> fly by. However, this is not a Solaris/SPARC-only issue: I first saw it >>> on Linux/sparc64. Given the SPARC and SPARC V9 psABIs, I guess it >>> affects at least all SPARC/ELF targets (if not SPARC in general). >> >> Ah - I missed this. Would you mind applying a small patch on top of mine >> then, >> that tweaks the regexp for sparc targets ? (I am just a little bit swamped >> at >> the moment. I have come back from PTO to find 19,756 emails waiting for >> me...) > > Sure. I'll check if we want this for all SPARC targets or restrict to > some subset (ELF) somehow. Patch posted: https://sourceware.org/pipermail/binutils/2022-July/122057.html -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29411] ld warning on SPARC: LOAD segment with RWX permissions
https://sourceware.org/bugzilla/show_bug.cgi?id=29411 --- Comment #6 from Rainer Orth --- > --- Comment #5 from Nick Clifton --- > (In reply to Rainer Orth from comment #4) > >> I missed this, although I saw the initial discussion about this warning >> fly by. However, this is not a Solaris/SPARC-only issue: I first saw it >> on Linux/sparc64. Given the SPARC and SPARC V9 psABIs, I guess it >> affects at least all SPARC/ELF targets (if not SPARC in general). > > Ah - I missed this. Would you mind applying a small patch on top of mine > then, > that tweaks the regexp for sparc targets ? (I am just a little bit swamped at > the moment. I have come back from PTO to find 19,756 emails waiting for > me...) Sure. I'll check if we want this for all SPARC targets or restrict to some subset (ELF) somehow. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29411] ld warning on SPARC: LOAD segment with RWX permissions
https://sourceware.org/bugzilla/show_bug.cgi?id=29411 --- Comment #4 from Rainer Orth --- > --- Comment #2 from Nick Clifton --- > Hi Rainer, > > The warning is intended to alter users to the fact that a segment has been > created with all three permission flags set - something that is very tempting > to attackers looking to inject code into a binary. > > Disabling the warning for specific target configurations is possible > however. > There is a section of code at the start of ld/configure.tgt to do this. > > I have gone ahead and added the sparc-solaris targets to the list of targets > for which the warning should be supressed by default. (It can still be > enabled > via a command line option, if the user so desires). I missed this, although I saw the initial discussion about this warning fly by. However, this is not a Solaris/SPARC-only issue: I first saw it on Linux/sparc64. Given the SPARC and SPARC V9 psABIs, I guess it affects at least all SPARC/ELF targets (if not SPARC in general). Thanks. Rainer -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27666] ar doesn't create indices on Solaris/sparcv9
https://sourceware.org/bugzilla/show_bug.cgi?id=27666
--- Comment #7 from Rainer Orth ---
> --- Comment #5 from Joel Brobecker ---
> (Thanks Nick for the patch)
Indeed, thanks a lot.
However, I think we can do better than disabling the ld sparc*tests on
Solaris. Even if we omit support for the elf32_sparc and and
elf64_sparc emulations, it should be possible to handle that with a
snippet like the following in sparc.exp (tested a very long time ago,
not sure if it still works as is):
# Solaris/SPARC ld uses elf??-sparc_sol2 emulations.
if { [istarget "*-*-solaris*"] } {
set options_regsub(ld) {-m(\\S+) -m\\1_sol2}
verbose "solaris: options_regsub(ld)"
}
Alan has also done some of the work by making the dump files accept both
elf32-sparc and elf32-sparc-sol2. The ugliest part (or one which really
requires a general solution) is that the Solaris ABI couple of
additional symbols into the output files, like
/var/gcc/binutils/sparcv9/obj/binutils/ld/../binutils/readelf -WSsrl
tmpdir/libtlssunpic32.so
regexp_diff match failure
regexp "^.* TLS +GLOBAL +DEFAULT +7 sg8$"
line " 4: 00012188 0 OBJECT LOCAL DEFAULT 11 _END_"
regexp_diff match failure
regexp "^.* TLS +GLOBAL +DEFAULT +7 sg3$"
line " 5: 1000 0 OBJECT LOCAL DEFAULT6 _START_"
[...]
One possible solution to that is to have separate copies for Solaris (as
done in gas in a few cases for x86), but that quickly becomes
unmaintainable with master dump and Solaris copy beginning to drift
apart.
What I think would be a general solution is having support for
conditionals in the dump files, something like
#cond : GLOB|PROC
set condition cond to true if GLOB matches or PROC returns true, false
otherwise, e.g.
#cond SOLARIS: *-*-solaris2*
run_dump_test calls to regexp_diff for comparisons
#if:
e.g.
#if:SOLARIS
need more:
#if:SOLARIS
#else
for individual lines, maybe also for blocks?
then we need
#if:SOLARIS
#else
#endif
no nesting for simplicity's sake
Just a general idea because this issue seems to come up on other
targets, too. I haven't even started thinking about implemented this
and probably won't for quite some time.
Rainer
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug binutils/27666] ar doesn't create indices on Solaris/sparcv9
https://sourceware.org/bugzilla/show_bug.cgi?id=27666 --- Comment #6 from Rainer Orth --- > --- Comment #5 from Joel Brobecker --- > (Thanks Nick for the patch) > > Hi Rainer, > > If I read Nick's patch correctly, I think things should be back to normal > again > in terms of behavior, thus no longer blocking the GDB 11 release. Would you be > able to double-check that it's the case? Hi Joel, that's indeed the case: thinks are now as they were before. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27666] ar doesn't create indices on Solaris/sparcv9
https://sourceware.org/bugzilla/show_bug.cgi?id=27666 --- Comment #3 from Rainer Orth --- > --- Comment #2 from Nick Clifton --- > Created attachment 13455 > --> https://sourceware.org/bugzilla/attachment.cgi?id=13455=edit > Proposed patch Hi Nick, sorry for the long delay: I've been on vacation for some time. > Would you mind trying out the uploaded patch ? > > I am working on a theory that the real bug is that > _bfd_write_archive_contents() is not creating the symbol index. As you noted > the call to bfd_check_format() fails, because there are two potential > matches. > But I do not think that this is grounds for the archiver to decide that there > are no objects in the library. > > Even with this patch applied, most of the linker tests that are failing > continue to do so, but I have not yet investigated why. I just wanted to show > you my ida, and see if you thought that it might be worth persuing. As a first step, I've tested the patch on both amd64-pc-solaris2.11 (no changes in test results) and sparcv9-sun-solaris2.11. The situation is mixed here: @@ -45 +44,0 @@ -FAIL: --export-dynamic-symbol foo archive @@ -48 +46,0 @@ -FAIL: --export-dynamic-symbol-list foo archive @@ -55 +53,2 @@ -FAIL: ld link shared library +FAIL: ld export symbols from archive spawn [open ...]^M 00100250 A _DYNAMIC 00100330 A _GLOBAL_OFFSET_TABLE_ 00100400 A _PROCEDURE_LINKAGE_TABLE_ U exclude_sym 00100338 D include_sym +FAIL: ld don't exclude symbols from archive - --exclude-libs foo:bar spawn [open ...]^M 00100250 A _DYNAMIC 00100330 A _GLOBAL_OFFSET_TABLE_ 00100400 A _PROCEDURE_LINKAGE_TABLE_ U exclude_sym 00100338 D include_sym @@ -109 +107,0 @@ -FAIL: ld-misc/defsym1 In both failing cases, exclude_common is missing. The symbol is present in exclude2.o, but missing from exclude.so. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27666] ar doesn't create indices on Solaris/sparcv9
https://sourceware.org/bugzilla/show_bug.cgi?id=27666 --- Comment #1 from Rainer Orth --- When I tried a sparcv9-sun-solaris2.11 build of gdb master in preparation for the upcoming GDB 11 release, I found that the impact of this bug is way greater than just a couple of binutils testsuite failures: it causes many hundreds of gdb testsuite failures due to the same ambiguity: (gdb) break increment Breakpoint 1 at 0x100020368: file /vol/src/gnu/gdb/hg/master/dist/gdb/testsuite/gdb.ada/O2_float_param/callee.adb, line 19. (gdb) run Starting program: /vol/obj/gnu/gdb/gdb/11.4-sparcv9-dist/gdb/testsuite/outputs/gdb.ada/O2_float_param/foo warning: Unable to find dynamic linker breakpoint function. GDB will be unable to debug shared library initializers and track explicitly loaded dynamic code. Error while mapping shared library sections: `/lib/64/libc.so.1': not in executable format: file format is ambiguous Error while mapping shared library sections: `/lib/sparcv9/ld.so.1': not in executable format: file format is ambiguous As with binutils, reverting just the bfd/config.bfd part of the patch returns gdb testresults back to normal. Unless there's a considerably better (and sufficiently safe) alternative, this is what I believe should be done. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25802] Several 64-bit SPARC tests FAIL: relocation truncated to fit
https://sourceware.org/bugzilla/show_bug.cgi?id=25802 --- Comment #3 from Rainer Orth --- > --- Comment #2 from Nick Clifton --- > Hi Rainer, > >> I wonder how best to handle this: bfd/elfxx-sparc.c >> (_bfd_sparc_elf_relocate_section) already silently ignores the overflow in a >> few select cases (like .stab sections), following the lead of Solaris ld. > > Do you know if the Solaris linker ignores overflow in other cases as well ? > IE should we be emulating the Solaris linker and ignoring more overflows ? I'd have to ask the Solaris linker engineer (Ali Bahrami, you may know him) that. I haven't found anything in the OpenSolaris linker sources, though. >> As expected, the tests do PASS if I do this unconditionally for the >> 3 affected relocs. >> >> This may or may not be a hack, though. > > It probably is a hack, modulo the answer to the question above of course. > > Are you able to examine a Solaris linked binary and find out how > those relocs were resolved ? Ie is the debug info correct or corrupt > or just uninitialised ? After linking the ld-elf/eh5 test with Solaris ld instead of ld-new, I tried the following: * Run readelf -u on the result, which comes up blank: The decoding of unwind sections for machine type Sparc v9 is not currently supported. * However, elfdump -u (the native Solaris ELF object dumping utility) produces results that seem at least well formed and possibly sensible (attached). * I've also run readelf -wf (also attached) and visually compared it to eh5.d (is there a manual way to perform a comparison between readelf etc. output and a .d file?): the first few sections seemed to match. > One possibility that occurs to me is that the Solaris linker is using > a different linker script to the bfd linker (or whatever it uses) and > so placing the sections in different places. Places which are more > amenable to resolving the relocs. The Solaris linker doesn't use explicit linker scripts (and has a different mapfile syntax compared to GNU ld). However, the internal rules (in the Solaris syntax) are documented in the Linkers and Libraries Guide: https://docs.oracle.com/cd/E37838_01/html/E36783/gjqaz.html#scrolltoc > It also occurs to me that maybe the bug is in the assembler, in that it > should be generating R_SPARC_UA64 relocs instead of R_SPARC_UA32 relocs. > Not being a Solaris expert however, I do not know if this is the case. Me neither: I'm just the messenger ;-) Unfortunately, the Solaris/SPARC assembler doesn't support the .cfi_* directives, otherwise I could have tried to use it to assemble the input and compare. Are there C sources corresponding to the eh5*.s files that I could feed through Solaris/SPARC gcc configure to use as instead of gas? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/25732] test-suite failures with i386-pc-solaris2.11
https://sourceware.org/bugzilla/show_bug.cgi?id=25732 --- Comment #14 from Rainer Orth --- > --- Comment #13 from H.J. Lu --- > (In reply to Rainer Orth from comment #11) > >> >> That leaves us with the two pr20995-2 ones... >> > >> > Does Solaris support GNU_RELRO? If not, I can skip these for Solaris. >> >> I'm pretty certain it doesn't. has this comment: >> >> /* >> * Linux specific program headers not used by Solaris >> */ >> #define PT_GNU_STACK0x6474e551 /* Indicates stack executability */ >> #define PT_GNU_RELRO0x6474e552 /* Read-only after relocation */ > > I checked in a patch to xfail them on Solaris. Can you submit a gas patch Excellent, thanks. > to adjust Solaris tests? Will do. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/25732] test-suite failures with i386-pc-solaris2.11
https://sourceware.org/bugzilla/show_bug.cgi?id=25732 --- Comment #11 from Rainer Orth --- > --- Comment #10 from H.J. Lu --- >> FAIL: ld-ifunc/ifunc-23a-x86 >> FAIL: ld-ifunc/ifunc-24a-x86 >> FAIL: ld-ifunc/ifunc-25a-x86 >> >> the last three are highly dubious: Solaris ld.so.1 doesn't support ifunc >> and never will, so I'm unsure if those tests can produce useful >> results. Certainly not if they are runtime tests. > > I checked a fix for these IFUNC tests. Great, thanks. >> That leaves us with the two pr20995-2 ones... > > Does Solaris support GNU_RELRO? If not, I can skip these for Solaris. I'm pretty certain it doesn't. has this comment: /* * Linux specific program headers not used by Solaris */ #define PT_GNU_STACK0x6474e551 /* Indicates stack executability */ #define PT_GNU_RELRO0x6474e552 /* Read-only after relocation */ -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/25732] test-suite failures with i386-pc-solaris2.11
https://sourceware.org/bugzilla/show_bug.cgi?id=25732 --- Comment #8 from Rainer Orth --- > --- Comment #6 from H.J. Lu --- > I stopped checking Solaris cross target since the result isn't clean. > If Solaris cross target test becomes clean, I will test Solaris cross I doubt I will be able to do much more than the occasional bugfix in binutils. In particular, the bfd and ld code bases remain a complete mystery to me. > target again. BTW, you can disable ld for Solaris target by default > so that ld test won't run by default. No point in that: gld is by far good enough on Solaris to bootstrap and test gcc. It's certainly good to have it for comparisons when investigating issues with the Solaris ld. Looking at your list of failing ld tests FAIL: Build pr20995-2.so FAIL: pr20995-2 FAIL: ld-ifunc/ifunc-23a-x86 FAIL: ld-ifunc/ifunc-24a-x86 FAIL: ld-ifunc/ifunc-25a-x86 the last three are highly dubious: Solaris ld.so.1 doesn't support ifunc and never will, so I'm unsure if those tests can produce useful results. Certainly not if they are runtime tests. That leaves us with the two pr20995-2 ones... -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/25732] test-suite failures with i386-pc-solaris2.11
https://sourceware.org/bugzilla/show_bug.cgi?id=25732 --- Comment #5 from Rainer Orth --- > --- Comment #4 from John Levon --- > It's only the last 5 for me (running natively, but illumos not Solaris) That's most likely because gld testing assumes a gcc configured to use gld without an explicit --with-ld. Otherwise the hardcoded linker is used instead of the newly built one. When I run make check in gas in a binutils tree as of 20200322, I get the same 5 failures. Won't bother with ld testing at the moment. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/13671] gld creates i386 relocations not supported by Solaris ld.so.1
https://sourceware.org/bugzilla/show_bug.cgi?id=13671 --- Comment #22 from Rainer Orth --- > --- Comment #21 from H.J. Lu --- [...] > I didn't see R_386_TLS_TPOFF. What happened to > > 0030 0b12 R_386_TLS_GD 0004 > __gcov_indirect_call_callee > > in input file? This: _gcov_indirect_call_profiler_v2.o has 1a: 8d 04 1d 00 00 00 00lea0x0(,%ebx,1),%eax 21: e8 fc ff ff ff call 22 <__gcov_indirect_call_profiler_v2+0x22> with the R_386_TLS_GD reloc above; the executable has 805224a: 65 a1 00 00 00 00 mov%gs:0x0,%eax 8052250: 05 fc ff ff ff add$0xfffc,%eax 8052255: 90 nop without any relocs. Btw., please note that I'll be on an extended vacation starting tomorrow, with little or no net access for a month. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/13671] gld creates i386 relocations not supported by Solaris ld.so.1
https://sourceware.org/bugzilla/show_bug.cgi?id=13671 --- Comment #20 from Rainer Orth --- > --- Comment #19 from H.J. Lu --- [...] > What doe Solaris ld generate? Here are the initial sections of with either linker: * gas-gld: 08048ff0 <__gcov_indirect_call_profiler_v2>: 8048ff0: 55 push %ebp 8048ff1: 89 e5 mov%esp,%ebp 8048ff3: 57 push %edi 8048ff4: 56 push %esi 8048ff5: 53 push %ebx 8048ff6: e8 8d ff ff ff call 8048f88 <__x86.get_pc_thunk.bx> 8048ffb: 81 c3 99 3f 00 00 add$0x3f99,%ebx 8049001: 83 ec 1csub$0x1c,%esp 8049004: 8b 7d 08mov0x8(%ebp),%edi 8049007: 8b 75 0cmov0xc(%ebp),%esi 804900a: 65 a1 00 00 00 00 mov%gs:0x0,%eax 8049010: 03 83 8c 00 00 00 add0x8c(%ebx),%eax 8049016: 8b 55 10mov0x10(%ebp),%edx 8049019: 39 10 cmp%edx,(%eax) * gas-ld: 08052230 <__gcov_indirect_call_profiler_v2>: 8052230: 55 push %ebp 8052231: 89 e5 mov%esp,%ebp 8052233: 57 push %edi 8052234: 56 push %esi 8052235: 53 push %ebx 8052236: e8 6e fb ff ff call 8051da9 <__x86.get_pc_thunk.bx> 805223b: 81 c3 4d 2b 01 00 add$0x12b4d,%ebx 8052241: 83 ec 1csub$0x1c,%esp 8052244: 8b 7d 08mov0x8(%ebp),%edi 8052247: 8b 75 0cmov0xc(%ebp),%esi 805224a: 65 a1 00 00 00 00 mov%gs:0x0,%eax 8052250: 05 fc ff ff ff add$0xfffc,%eax 8052255: 90 nop 8052256: 8b 55 10mov0x10(%ebp),%edx 8052259: 39 10 cmp%edx,(%eax) The full executable is at https://www.cebitec.uni-bielefeld.de/~ro/files/crossmodule-indircall-1-ld.tar.bz2 -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/13671] gld creates i386 relocations not supported by Solaris ld.so.1
https://sourceware.org/bugzilla/show_bug.cgi?id=13671 --- Comment #18 from Rainer Orth --- > --- Comment #17 from H.J. Lu --- > Please try users/hjl/solaris branch at > > https://github.com/hjl-tools/binutils-gdb Any reason not to keep that branch in the binutils-git repo on sourceware? That's where I looked initially, confusing the hell out of me ;-) Fortunately, a lot of failures are gone, but still a couple remain, all from g++.dg/tree-prof and gcc.dg/tree-prof tests, which SEGV, e.g. FAIL: gcc.dg/tree-prof/crossmodule-indircall-1.c execution, -fprofile-generate -D_PROFILE_GENERATE Thread 2 received signal SIGSEGV, Segmentation fault. [Switching to Thread 1 (LWP 1)] 0x080491c9 in __gcov_indirect_call_profiler_v2 (value=151663852, cur_func=0x8048f10 ) at /vol/gcc/src/hg/trunk/local/libgcc/libgcov-profiler.c:335 335 if (cur_func == __gcov_indirect_call_callee => 0x8049019 <__gcov_indirect_call_profiler_v2+41>: cmp%edx,(%eax) (gdb) p/x $eax $1 = 0x66caa44 That address is indeed unmapped and below the text segment. (gdb) where #0 0x080491c9 in __gcov_indirect_call_profiler_v2 (value=151663852, cur_func=0x8048f10 ) at /vol/gcc/src/hg/trunk/local/libgcc/libgcov-profiler.c:335 #1 0x08048f41 in add () #2 0x08048e5c in main () elfdump -r complains about the executable: crossmodule-indircall-1.x01: bad relocation entry: R_386_TLS_TPOFF: relocation requires symbol crossmodule-indircall-1.x01: bad relocation entry: R_386_TLS_TPOFF: relocation requires symbol [3] R_386_TLS_TPOFF 0x804d22c 0x4 .got [4] R_386_TLS_TPOFF 0x804d230 0 .got [11] R_386_JMP_SLOT 0x804d1c8 0x80489f6 .got___tls_get_addr It happens even when I build without -flto: $ ld -m elf_i386_sol2 -o crossmodule-indircall-1.x01 /usr/lib/crt1.o crossmodule-indircall-1.o crossmodule-indircall-1a.o -lm -lgcov -lgcc -lc /usr/lib/crtn.o Input files at https://www.cebitec.uni-bielefeld.de/~ro/files/crossmodule-indircall-1.tar.bz2 -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/13671] gld creates i386 relocations not supported by Solaris ld.so.1
https://sourceware.org/bugzilla/show_bug.cgi?id=13671 --- Comment #15 from Rainer Orth --- > --- Comment #14 from H.J. Lu --- [...] > Please provide all linker inputs so that I > can reproduce i it on Linux. Now available at https://www.cebitec.uni-bielefeld.de/~ro/files/pr13671.tar.bz2 -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/13671] gld creates i386 relocations not supported by Solaris ld.so.1
https://sourceware.org/bugzilla/show_bug.cgi?id=13671 --- Comment #12 from Rainer Orth --- While it fixes the two failing ld testcases, during a gcc mainline bootstrap I get man errors: FAIL: gcc.dg/pr47793.c (test for excess errors) Excess errors: /vol/gcc/bin/gld-2.30.51-tls: BFD (GNU Binutils) 2.30.51.20180211 internal error, aborting at /vol/src/gnu/binutils/binutils/local/bfd/elf32-i386.c:3169 in elf_i386_relocate_section The ld invocation boils down to ld -m elf_i386_sol2 -o ./pr47793.exe /usr/lib/crt1.o pr47793.o -lgcov -lgcc -lc -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/13671] gld creates i386 relocations not supported by Solaris ld.so.1
https://sourceware.org/bugzilla/show_bug.cgi?id=13671 --- Comment #10 from Rainer Orth --- As a first step, I've enabled ld-i386/tls.exp and ld-x86_64/tls.exp on Solaris/x86 and ran the respective tests. The x86_64 tests all PASS, while for i386 I see the known failure case: FAIL: TLS GD/LD -> IE transition without PLT Running: tmpdir/tls-1d > tmpdir/tls-1d.out ld.so.1: tls-1d: fatal: relocation error: R_386_UNKNOWN37: file tmpdir/tls-1d: symbol gd: offset size (0 bytes) is not supported FAIL: TLS GD/LD -> IE transition without PLT (-z now) same error -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/13671] gld creates i386 relocations not supported by Solaris ld.so.1
https://sourceware.org/bugzilla/show_bug.cgi?id=13671 --- Comment #7 from Rainer Orth --- > --- Comment #6 from H.J. Lu --- [...] > Please provide one separate testcase in assembly code for each instance > where ld creates dynamic relocs Solaris ld.so.1 cannot handle. I'm trying, but I have a hard time even for the case at hand: There's not only one, but a couple of those relocs in cc1: Relocation Section: .rel.dyn index typeoffset value section symbol [...] [189] R_386_UNKNOWN37 0x9c79cf4 0 .got __gmpfr_emin [390] R_386_UNKNOWN37 0x9c7a01c 0 .got __gmpfr_default_rounding_mode [430] R_386_UNKNOWN37 0x9c7a0bc 0 .got __gmpfr_cache_const_log2 [432] R_386_UNKNOWN37 0x9c7a0c4 0 .got __gmpfr_flags [546] R_386_UNKNOWN37 0x9c7a28c 0 .got __gmpfr_cache_const_catalan [1069] R_386_UNKNOWN37 0x9c7aab8 0 .got __gmpfr_cache_const_euler [1225] R_386_UNKNOWN37 0x9c7ad28 0 .got __gmpfr_emax [1330] R_386_UNKNOWN37 0x9c7aecc 0 .got __gmpfr_default_fp_bit_precision [1467] R_386_UNKNOWN37 0x9c7b0f0 0 .got __gmpfr_cache_const_pi The definitions are from libmpfr.a (built with --disable-shared --with-pic), e.g. [22] 0 0x4 TLS GLOB D0 .tbss __gmpfr_flags In the gld-linked cc1, I find Symbol Table Section: .dynsym [5850] 0x6c 0x4 TLS GLOB D1 .tbss __gmpfr_flags Global Offset Table Section: .got [584] 0x9c7a0c4 0 R_386_UNKNOWN37 __gmpfr_flags Relocation Section: .rel.dyn [432] R_386_UNKNOWN37 0x9c7a0c4 0 .got __gmpfr_flags while in the ld-linked cc1, there is only: Symbol Table Section: .dynsym [14735] 0x6c 0x4 TLS GLOB D1 .tbss__gmpfr_flags The toolchains are otherwise identical, both using gas 2.30 with either Solaris ld or gld 2.30, both trees configured with --enable-host-shared, no (relevant) differences in auto-host.h. In the ld-linked cc1, there are no got entries for __gmpfr_* symbols at all. So far, I've not managed to create a testcase from this. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/13671] gld creates i386 relocations not supported by Solaris ld.so.1
https://sourceware.org/bugzilla/show_bug.cgi?id=13671 --- Comment #5 from Rainer Orth --- I don't think it needs to: gcc is careful only to emit those tls relocs that the whole toolchain (assembler + linker) can handle. See TARGET_SUN_TLS, HAVE_AS_IX86_TLSLDMPLT, and HAVE_AS_IX86_TLSGDPLT. So far gcc bootstraps with gas and gld work just fine: this is one of the first cases where gld emits relocs Solaris ld.so.1 cannot handle. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/13671] gld creates i386 relocations not supported by Solaris ld.so.1
https://sourceware.org/bugzilla/show_bug.cgi?id=13671 --- Comment #3 from Rainer Orth --- > --- Comment #2 from H.J. Lu --- > These TLS transitions should be disabled for Solaris. > Does Solaris support Linux TLS relocations without > TLS transitions? The full docs on what Solaris does support wrt. relocs is here: https://docs.oracle.com/cd/E37838_01/html/E36783/chapter6-54839.html#scrolltoc And there's also a section on TLS: https://docs.oracle.com/cd/E37838_01/html/E36783/man-tlsam.html#scrolltoc -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/22727] [2.30, 2.31 regression] Thousands of EH-related execution failures on SPARC
https://sourceware.org/bugzilla/show_bug.cgi?id=22727 --- Comment #21 from Rainer Orth --- > --- Comment #20 from Eric Botcazou --- > Please give it a try on Solaris. I just tried gcc mainline with the top of the binutils 2.30 branch on Solaris 11.4: worked like a charm. Thanks. Rainer -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/22721] [2.30, 2.31 regression] Solaris/x86 TLS transition failures with linker plugin
https://sourceware.org/bugzilla/show_bug.cgi?id=22721 --- Comment #11 from Rainer Orth --- > --- Comment #10 from H.J. Lu --- > Please try: > > https://sourceware.org/ml/binutils/2018-01/msg00293.html As a quick test, I've just rebuilt binutils with that patch and ran the failing LTO test and the various tls.exp in gcc.dg: no failures anymore. Also, upon make check in ld, the new tests PASS as well. Thanks. Rainer -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/22721] [2.30, 2.31 regression] Solaris/x86 TLS transition failures with linker plugin
https://sourceware.org/bugzilla/show_bug.cgi?id=22721 --- Comment #8 from Rainer Orth --- > --- Comment #7 from H.J. Lu --- [...] > What are the commend-line options passed to ld? ld -plugin ./liblto_plugin.so -plugin-opt=./lto-wrapper \ -plugin-opt=-fresolution=-plugin-save-temps.res \ -flto \ -o gcc-dg-lto-20090210-01.exe \ /usr/lib/crt1.o \ c_lto_20090210_0.o c_lto_20090210_1.o \ -lc -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/22721] [2.30, 2.31 regression] Solaris/x86 TLS transition failures with linker plugin
https://sourceware.org/bugzilla/show_bug.cgi?id=22721
--- Comment #6 from Rainer Orth ---
> --- Comment #3 from H.J. Lu ---
[...]
> Please do
>
> 1. Get users/hjl/lto-mixed/master branch and build/install it.
> 2. Pass -v -save-temps -Wl,-plugin-save-temps to gcc
> This should save all temporary files used by ld LTO.
> 3. Create .gdbinit to set environment variables used by ld LTO with
> output from "gcc -v".
> 4. Capture the failed ld LTO command line option.
> 5. Run ld under gdb to investigate why ld fails.
I did some digging so far. That branch didn't include the culprit
patch. If I use gld build from it as is, the testcase works fine.
Next, I've applied that patch and could reproduced the failure, so the
reghunt was correct in identifying the culprit.
I find that this call to elf_i386_check_tls_transition returns FALSE
Thread 2 hit Breakpoint 2, elf_i386_check_tls_transition (sec=0x8303f48,
contents=0x82b6c78 "U\211\345\213E\b]\303U\211\345S\203\354\024\307E\364",
symtab_hdr=0x82fa2ac, sym_hashes=0x83050f4, r_type=18, rel=0x8305184,
relend=0x83051b4) at /var/gcc/reghunt/binutils-lto-mixed/bfd/elf32-i386.c:1381
here:
h = sym_hashes[r_symndx - symtab_hdr->sh_info];
if (h == NULL
|| !((struct elf_i386_link_hash_entry *) h)->tls_get_addr)
return FALSE;
(gdb) p *$33
$34 = {elf = {root = {root = {next = 0x0, string = 0x846d570
"___tls_get_addr@@SUNWprivate_1.1", hash = 624670595}, type =
bfd_link_hash_defined, non_ir_ref_regular = 0, non_ir_ref_dynamic = 0,
linker_def = 0, ldscript_def = 0, u = {undef = {next = 0x846d594, abfd =
0x82d88d4}, def = {next = 0x846d594, section = 0x82d88d4, value = 1081620}, i =
{next = 0x846d594, link = 0x82d88d4, warning = 0x108114 }, c = {next = 0x846d594, p = 0x82d88d4, size =
1081620}}}, indx = -1, dynindx = 8, got = {refcount = 0, offset = 0, glist =
0x0, plist = 0x0}, plt = {refcount = 0, offset = 0, glist = 0x0, plist = 0x0},
size = 45, type = 2, other = 0, target_internal = 0, ref_regular = 1,
def_regular = 0, ref_dynamic = 0, def_dynamic = 1, ref_regular_nonweak = 1,
dynamic_adjusted = 0, needs_copy = 0, needs_plt = 0, non_elf = 0, versioned =
versioned, forced_local = 0, dynamic = 0, mark = 0, non_got_ref = 0,
dynamic_def = 1, ref_dynamic_nonweak = 0, pointer_equality_needed = 0,
unique_global = 0, protected_def = 0, start_stop = 0, dynstr_index = 9, u =
{weakdef = 0x0, elf_hash_value = 0}, verinfo = {verdef = 0x82da720, vertree =
0x82da720}, u2 = {start_stop_section = 0x0, vtable = 0x0}}, dyn_relocs = 0x0,
tls_type = 0 '\000', gotoff_ref = 0, has_got_reloc = 0, has_non_got_reloc = 0,
no_finish_dynamic_symbol = 0, tls_get_addr = 0, func_pointer_refcount = 0,
plt_got = {refcount = -1, offset = 18446744073709551615, glist = 0x,
plist = 0x}, plt_second = {refcount = 0, offset = 0, glist = 0x0, plist
= 0x0}, tlsdesc_got = 18446744073709551615}
It's pretty obvious that this *is* ___tls_get_addr, but h->tls_get_addr
is 0 nontheless.
Rainer
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/22721] [2.30, 2.31 regression] Solaris/x86 TLS transition failures with linker plugin
https://sourceware.org/bugzilla/show_bug.cgi?id=22721
--- Comment #4 from Rainer Orth ---
> --- Comment #3 from H.J. Lu ---
[...]
>> The static tests fail because there are no libc.a and libm.a on Solaris,
>> so full-static linking just isn't possible. Testing static linking when
>> the platform doesn't support it is a testsuite bug.
>
> Please open a bug report.
Done: PR ld/22732.
>> All other failures follow the same pattern:
>>
>> regexp_diff match failure
>> regexp "^ +[a-f0-9]+: 8b 80 ([0-9a-f]{2} ){4}[]+mov
>> +-0x[a-f0-9]+\(%eax\),%eax$"
>> line " 52a: 8b 80 10 00 00 00 mov0x10(%eax),%eax"
>> regexp_diff match failure
>> regexp "^ +[a-f0-9]+: ff a0 ([0-9a-f]{2} ){4}[]+jmp
>> +\*-0x[0-9a-f]+\(%eax\)$"
>> line " 54a: ff a0 10 00 00 00 jmp*0x10(%eax)"
>> FAIL: Build libno-plt-1b.so
>>
>> where i686-pc-linux-gnu has
>>
>> 48a: 8b 80 f8 ff ff ff mov-0x8(%eax),%eax
>>
>> 4aa: ff a0 f8 ff ff ff jmp*-0x8(%eax)
>>
>> Maybe an -fno-omit-frame-pointer thing?
>
> Can you add -fomit-frame-pointer to i386.exp to see if it works?
I set CFLAGS to '-g -O2 -fomit-frame-pointer' in site.exp instead:
doesn't make a difference for test results.
Rainer
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/22727] [2.30, 2.31 regression] Thousands of EH-related execution failures on Solaris/SPARC
https://sourceware.org/bugzilla/show_bug.cgi?id=22727 --- Comment #2 from Rainer Orth --- > --- Comment #1 from H.J. Lu --- > Does Linux/Sparc work? Are there any regressions in binutils I've no idea and no way to test. > testsuite on Solaris/Sparc? That will take a bit to determine: I'll need to rebuild gcc to use the freshly-built gas and gld, otherwise testing is meaningless (often the configured as and ld are used, not the binutils ones). Rainer -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/22721] [2.30, 2.31 regression] Solaris/x86 TLS transition failures with linker plugin
https://sourceware.org/bugzilla/show_bug.cgi?id=22721
--- Comment #2 from Rainer Orth ---
> --- Comment #1 from H.J. Lu ---
> A couple questions:
>
> 1. Do all tests under ld/testsuite/ld-i386 pass on Solaris?
No, but that's a preexisting condition:
FAIL: Build libno-plt-1b.so
FAIL: No PLT (dynamic 1a)
FAIL: No PLT (dynamic 1b)
FAIL: No PLT (dynamic 1c)
FAIL: No PLT (static 1d)
FAIL: No PLT (PIE 1e)
FAIL: No PLT (PIE 1f)
FAIL: No PLT (PIE 1g)
FAIL: No PLT (static 1j)
FAIL: No PLT (static 1d)
FAIL: No PLT (static 1j)
The static tests fail because there are no libc.a and libm.a on Solaris,
so full-static linking just isn't possible. Testing static linking when
the platform doesn't support it is a testsuite bug.
All other failures follow the same pattern:
regexp_diff match failure
regexp "^ +[a-f0-9]+: 8b 80 ([0-9a-f]{2} ){4}[]+mov
+-0x[a-f0-9]+\(%eax\),%eax$"
line " 52a: 8b 80 10 00 00 00 mov0x10(%eax),%eax"
regexp_diff match failure
regexp "^ +[a-f0-9]+: ff a0 ([0-9a-f]{2} ){4}[]+jmp
+\*-0x[0-9a-f]+\(%eax\)$"
line " 54a: ff a0 10 00 00 00 jmp*0x10(%eax)"
FAIL: Build libno-plt-1b.so
where i686-pc-linux-gnu has
48a: 8b 80 f8 ff ff ff mov-0x8(%eax),%eax
4aa: ff a0 f8 ff ff ff jmp*-0x8(%eax)
Maybe an -fno-omit-frame-pointer thing?
The tls.exp tests there are only run on Linux/x86 at the moment.
> 2. Does Solaris use the same TLS code sequences as Linux?
Mostly. See HAVE_AS_IX86_TLSGDPLT and HAVE_AS_IX86_TLSLDMPLT in gcc's
i386.md. They are only used if both assembler and linker support those
relocs, which means when using as and ld only, so they are not relevant
to this bug.
For full documentation, see
https://docs.oracle.com/cd/E53394_01/html/E54813/chapter8-1.html#scrolltoc
> 3. Does GCC generate different TLS code sequences on Solaris?
Not as far as the present bug is concerned, I believe.
> 4. If GCC generate different TLS code sequences on Solaris,
>a. Did GNU ld ever support Solaris TLS code sequences?
>b. If yes, are there any linker testcases for Solaris TLS code sequences?
No to both: I think I once tried to teach gas and gld about them. gas
was reasonably easy, but I totally failed for gld, so I gave up.
Rainer
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/21251] Support $SYSROOT in ld -L and INPUT command
https://sourceware.org/bugzilla/show_bug.cgi?id=21251 --- Comment #7 from Rainer Orth --- > --- Comment #6 from Nick Clifton --- Hi Nick, >>> Hmm, I was going to say not a lot, but then I remembered that GCC uses it: >>> >>>https://gcc.gnu.org/onlinedocs/gcc/Directory-Options.html >> >> Maybe I'm blind, but where did you see that? > > Umm, do you mean "where in that web page do I see an '=' prefix being used > to indicate that a sysroot should be used ?" Then, right at the start: > > -idirafter dir > > Add the directory dir to the list of directories to be searched > for header files during preprocessing. If dir begins with ‘=’, > then the ‘=’ is replaced by the sysroot prefix; see --sysroot and > -isysroot. ah, silly me, I just thought to look at -L and friends. >> I'd have been surprised to find pure linker option descriptions repeated >> in the GCC manual, so I didn't even think to look. > > Well to be honest it is talking about the c-preprocessor include path options > rather than the linker search path, but I think that it establishes a > principle > which users will expect to be followed. IE if include paths can use a '=' > prefix > then library search paths should be able to as well. Indeed, everything else would be just confusing. This pretty much rules out deprecating '=' in either gld or gcc, obviously. I'll look into supporting $SYSROOT in gcc for symmetry, but that's about it. Thanks for your patience ;-) Rainer -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/21251] Support $SYSROOT in ld -L and INPUT command
https://sourceware.org/bugzilla/show_bug.cgi?id=21251 --- Comment #5 from Rainer Orth --- Hi Nick, > Great - I have checked the patch in. excellent, thanks. >> Btw., do you have any idea how widespread the use of '=' for the sysroot >> prefix is? > > Hmm, I was going to say not a lot, but then I remembered that GCC uses it: > > https://gcc.gnu.org/onlinedocs/gcc/Directory-Options.html Maybe I'm blind, but where did you see that? I've also looked at GCC mainline invoke.text and found nothing, neither with -L nor anywhere sysroot is described. I'd have been surprised to find pure linker option descriptions repeated in the GCC manual, so I didn't even think to look. > So maybe it is more widespread than we realise. Which would be a pity ;-) >> Besides, while were at --sysroot, did you have a chance to have a look >> at PR ld/21250. > > I looked at it, shuddered, and looked away. :-} I suspect that that PR > will turn out to be a can of worms, so I was going to treat it as low > priority unless other people notice and complain too. Understood. It took me completely off guard since gcc's --sysroot support works just the way I expected (no headers found outside of the sysroot prefix), while gld may behave otherwise. This is particularly ugly if you're cross-linking for say a different OS version where the native libraries do work, but may contain more (or less) functions than desired for the target OS version. In a real cross environment, where host and target differ, you will get an error instead of links succeeding silently when they shouldn't... Rainer -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/21251] Support $SYSROOT in ld -L and INPUT command
https://sourceware.org/bugzilla/show_bug.cgi?id=21251 --- Comment #2 from Rainer Orth --- Hi Nick, sorry for the very long delay in replying ;-( Yes, works like a charm, thanks. Btw., do you have any idea how widespread the use of '=' for the sysroot prefix is? It's kinda hard to search for -L = ... I've only noticed it very recently. There's work going on to implement --sysroot in Solaris ld, and the question poses itself if there's much point in supporting the '=' form or just going for $SYSROOT here. Besides, while were at --sysroot, did you have a chance to have a look at PR ld/21250. Thanks a lot. Rainer -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/20989] Every 64-bit Solaris 12/SPARC executable dies with SIGILL
https://sourceware.org/bugzilla/show_bug.cgi?id=20989 --- Comment #2 from Rainer Orth --- > --- Comment #1 from Alan Modra --- > How is crt1.o testing that __start_crt_compiler is undefined? I'm talking > about an "if (foo)" test used in a call to a weak function: > if (foo) > foo (); You've got this (I'm attaching both the crt1.o and empty-ld and empty-gld executables for reference) in crt1.o: crt1.o: cc __start_crt+0x4c: 2f 00 00 00 sethi %hi(0x0), %l7 d0 __start_crt+0x50: f4 74 60 00 stx %i2, [%l1] d4 __start_crt+0x54: ac 1d e0 00 xor %l7, 0x0, %l6 d8 __start_crt+0x58: ea 5c 00 16 ldx [%l0 + %l6], %l5 dc __start_crt+0x5c: 02 c5 40 09 brz,pn%l5, +0x24 <__start_crt+0x80> ^ offsets (in hex) from the beginning of .text to allow matching with the relocs below. This is the if (__start_crt_compiler) __start_crt_compiler (); part ... e0 __start_crt+0x60: 91 3e 20 00 sra %i0, 0x0, %o0 e4 __start_crt+0x64: 40 00 00 00 call +0x0 <__start_crt+0x64> ... and here are the corresponding relocs. [17] R_SPARC_GOTDATA_OP_HIX220xcc 0 0 .text __start_crt_compiler [18] R_SPARC_GOTDATA_OP_LOX100xd4 0 0 .text __start_crt_compiler [19] R_SPARC_GOTDATA_OP 0xd8 0 0 .text __start_crt_compiler [20] R_SPARC_WPLT30 0xe4 0 0 .text __start_crt_compiler When single-stepping through this part of empty-ld (ld output), I find: __start_crt+0x4c: 2f 00 00 00 sethi %hi(0x0), %l7 __start_crt+0x50: f4 74 60 00 stx %i2, [%l1] __start_crt+0x54: ac 1d e0 08 xor %l7, 0x8, %l6 __start_crt+0x58: ea 5c 00 16 ldx [%l0 + %l6], %l5 __start_crt+0x5c: 02 c5 40 09 brz,pn%l5, +0x24 <__start_crt+0x80> __start_crt+0x60: 91 3e 20 00 sra %i0, 0x0, %o0 __start_crt+0x64: 40 00 00 00 call +0x0 <__start_crt+0x64> __start_crt+0x48:brnz,pn %l2, 0x10b94 <__start_crt+0x54> (gdb) p/x $l2 $5 = 0x7b08 __start_crt+0x4c:sethi %hi(0), %l7 __start_crt+0x54:xor %l7, 8, %l6 __start_crt+0x58:ldx [ %l0 + %l6 ], %l5 __start_crt+0x5c:brz,pn %l5, 0x10bc0 <__start_crt+0x80> (gdb) p/x $l5 $4 = 0x0 I.e. __start_crt_compiler is 0 and the branch is taken, skipping the call. __start_crt+0x60:sra %i0, 0, %o0 __start_crt+0x80:sethi %hi(0x10), %i3 On the other hand, with the gld-produced executable, I get __start_crt+0x4c: 2f 00 04 02 sethi %hi(0x100800), %l7 __start_crt+0x50: f4 74 60 00 stx %i2, [%l1] __start_crt+0x54: ac 1d fd f0 xor %l7, -0x210, %l6 __start_crt+0x58: aa 04 00 16 add %l0, %l6, %l5 __start_crt+0x5c: 02 c5 40 09 brz,pn%l5, +0x24 <__start_crt+0x80> __start_crt+0x60: 91 3e 20 00 sra %i0, 0x0, %o0 __start_crt+0x64: 7f ff fe 57 call -0x6a4<0x1> __start_crt+0x48:brnz,pn %l2, 0x10694 <__start_crt+0x54> (gdb) p/x $l2 $4 = 0x79d8 __start_crt+0x4c:sethi %hi(0x100800), %l7 __start_crt+0x54:xor %l7, -528, %l6 __start_crt+0x58:add %l0, %l6, %l5 __start_crt+0x5c:brz,pn %l5, 0x106c0 <__start_crt+0x80> (gdb) p/x $l5 $6 = 0x1 __start_crt+0x60:sra %i0, 0, %o0 __start_crt+0x64:call 0x1 I.e. __start_crt_compiler is non-NULL, the call is taken, but the destination is invalid, leading to the SIGILL. Rainer -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/20427] Solaris rtld on SPARC does not allow R_SPARC_UA64 or R_SPARC_64 relocations in 32-bit executables
https://sourceware.org/bugzilla/show_bug.cgi?id=20427 --- Comment #8 from Rainer Orth --- Two more data points in addition to what Ali has discovered: * In addition to gas emitting those 64-bit relocs for 32-bit objects, I tried to build libtest32.so from Stefan's testcase with mainline gcc configured to use both gas and gld on sparc-sun-solaris2.12, which worked just fine (at least there was no error), unlike with ld, and produces Relocation Section: .rela.dyn index type offset value addend section symbol [...] [9] R_SPARC_640x107b0 0 0 .data .gomp_critical_user_ * However, according to my reading of the glibc sources, only the sparc64 runtime linker, /lib64/ld-linux.so.2, accepts the R_SPARC_64 reloc, while the sparc32 one, /lib/ld-linux.so.2 doesn't: sysdeps/sparc/sparc64/dl-machine.h (elf_machine_rela) accepts and handles it, while sysdeps/sparc/sparc32/dl-machine.h (elf_machine_rela) doesn't and errors out with _dl_reloc_bad_type printing "unexpected reloc type 0x32", just as Solaris ld.so.1 aborts with ld.so.1: main32: fatal: relocation error: file /homes/ro/rel64/libtest32.so: symbol .gomp_critical_user_: invalid relocation type for ELFCLASS32: 32 when trying to run main32. I don't have a Linux/SPARC machine around, so I cannot try this for real and may well be wrong in my reading. If that turns out to be true, though, both runtime linkers are correct (and consistent :-) while gas and gld get it wrong. Rainer -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/20118] gas should set .init_array etc. sh_entsize to word size
https://sourceware.org/bugzilla/show_bug.cgi?id=20118 --- Comment #4 from Rainer Orth --- > --- Comment #3 from Alan Modra --- > Fixed. Great, thanks for the blazingly fast fix. Rainer -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/19520] [2.26 regression] R_386_GOT32X relocation breaks gcc bootstrap with non-gld/gold linker
https://sourceware.org/bugzilla/show_bug.cgi?id=19520
--- Comment #7 from Rainer Orth ---
> --- Comment #4 from H.J. Lu ---
> Please checkout users/hjl/pr19520/master branch. I added a
> configure-time option, --enable-new-x86-relocations, and a
> run-time option, -mnew-relocations=.
I've successfully bootstrapped gcc mainline with gas 2.26 with your
patch applied and /bin/ld.
A couple of comments, though:
* As Andreas noted, today's new is tomorrow's old. The option needs a
more descriptive name.
* It needs documentation in gas/doc/c-i386.texi, perhaps together with
the new configure option.
* I wonder if the gas option should be called -mnew-relocations=(yes|no)
or -m(no-)new-relocations. There seems to be precedent for both
versions.
* There's a superfluous trailing ] in gas/configure, both for the new
option and --enable-compressed-debug-sections (copy-and-paste error,
no doubt):
@@ -1415,6 +1416,8 @@ Optional Features:
--enable-checking enable run-time checks
--enable-compressed-debug-sections={all,gas,none}
compress debug sections by default]
+ --enable-new-x86-relocations
+ generate new x86 relocations by default]
--enable-werror treat compile warnings as errors
--enable-build-warnings enable build-time compiler warnings
--disable-nls do not use Native Language Support
* Typo in gas/configure.ac:
diff --git a/gas/configure.ac b/gas/configure.ac
--- a/gas/configure.ac
+++ b/gas/configure.ac
@@ -77,6 +77,20 @@ AC_ARG_ENABLE(compressed_debug_sections,
[...]
+AC_DEFINE_UNQUOTED(DEFAULT_GENERATE_X86_NEW_RELOCATIONS,
+ $ac_default_new_x86_relocations,
+ [Define to 1 if you want generate new x86 relocations by default.])
^ to generate
* I believe --enable-new-x86-relocations should default to 0 on
i?86-*-solaris2.[0-9], i?86-*-solaris2.1[01], x86_64-*-solaris2.1[01]
and to 1 on i?86-solaris2.1[2-9], x86_64-*-solaris2.1[2-9] so this
works out of the box.
Rainer
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/19520] [2.26 regression] R_386_GOT32X relocation breaks gcc bootstrap with non-gld/gold linker
https://sourceware.org/bugzilla/show_bug.cgi?id=19520 --- Comment #2 from Rainer Orth --- > --- Comment #1 from H.J. Lu --- > Please open a Solaris linker request to support R_386_GOT32X, > R_X86_64_GOTPCRELX and R_X86_64_REX_GOTPCRELX. Then we discuss > how to address it, depending on the response. I've started just that (at least for R_386_GOT32X for now), but even if this were implemented for Solaris 12, this won't help older installations in the field. This also needs to be addressed on the binutils side. Rainer -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/16833] New: ld refuses to mix ordered and unordered sections
https://sourceware.org/bugzilla/show_bug.cgi?id=16833 Bug ID: 16833 Summary: ld refuses to mix ordered and unordered sections Product: binutils Version: 2.24 Status: NEW Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: ro at CeBiTec dot Uni-Bielefeld.DE Host: i386-pc-solaris2.11 Target: i386-pc-solaris2.11 Build: i386-pc-solaris2.11 While testing a new Solaris/x86 assembler that does support cfi directives, I ran into a link failure while bootstrapping gcc mainline with that /bin/as and gld 2.24: /vol/gcc/bin/gld-2.24: .eh_frame has both ordered [`.eh_frame' in _muldi3_s.o] and unordered [`.eh_frame' in /usr/lib/amd64/crti.o] sections /vol/gcc/bin/gld-2.24: final link failed: Bad value collect2: error: ld returned 1 exit status /bin/as sets SHF_LINK_ORDER in .eh_frame, but as you can see, the bundled crti.o lacks that flag. The question is: what's the basis for this refusal: I see nothing of the kind in the current ELF gABI: http://www.sco.com/developers/gabi/latest/ch4.sheader.html I see that this check (without the error messages) is already in the original submission: [patch] Honour SHF_LINK_ORDER https://sourceware.org/ml/binutils/2004-07/msg00197.html and https://sourceware.org/ml/binutils/2004-07/msg00200.html but no justification either. Why not just emit the sections with SHF_LINK_ORDER set in order and add in the rest behind? Rainer -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/15056] gld 2.23.1 mishandles R_SPARC_TLS_LDM_CALL
http://sourceware.org/bugzilla/show_bug.cgi?id=15056 --- Comment #22 from Rainer Orth ro at CeBiTec dot Uni-Bielefeld.DE 2013-02-01 09:31:00 UTC --- The bootstrap has now concluded without regressions, so all is certainly fine. Thanks again. Rainer -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/15056] gld 2.23.1 mishandles R_SPARC_TLS_LDM_CALL
http://sourceware.org/bugzilla/show_bug.cgi?id=15056 --- Comment #21 from Rainer Orth ro at CeBiTec dot Uni-Bielefeld.DE 2013-01-31 12:22:42 UTC --- This fixed the full libstdc++.so testcase. I'm now running a full gcc mainline bootstrap to check that no other problems turn up. Many thanks to both of you for the quick resolution. Rainer -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/15056] gld 2.23.1 mishandles R_SPARC_TLS_LDM_CALL
http://sourceware.org/bugzilla/show_bug.cgi?id=15056 --- Comment #5 from Rainer Orth ro at CeBiTec dot Uni-Bielefeld.DE 2013-01-30 09:31:13 UTC --- The reghunt identified the following patch as the culprit: 2011-12-07 Alan Modra amo...@gmail.com PR ld/12772 * elflink.c (elf_gc_sweep_symbol): Discard unmarked symbols defined in shared libraries. To verify, I've reverted just this patch in a binutils 2.23.1 tree, rebuilt gld and all the EH failure were gone in a fresh gcc mainline bootstrap. Rainer -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/15057] gld creates SHT_PROGBITS .bss section
http://sourceware.org/bugzilla/show_bug.cgi?id=15057 --- Comment #2 from Rainer Orth ro at CeBiTec dot Uni-Bielefeld.DE 2013-01-24 13:16:08 UTC --- --- Comment #1 from Alan Modra amodra at gmail dot com 2013-01-24 01:40:40 UTC --- Create a link map for one of these failing tests (-Wl,-Map,somefile). Look in somefile to see what sections (or data!) are going in to .bss. If you find data from a linker script there's your problem, otherwise look at all the input objects contributing to .bss to see whether any have a SHT_PROGBITS .bss. If no input objects, then we might have a bug in the linker when eg. the linker created .dynbss is the only section in .bss output section. Thanks, that helped a lot: with Sun as, several .bss.symbol sections in the input object files are marked SHT_PROGBITS (I keep forgetting about those), unlike Solaris/x86 with Sun as. On Solaris/x86, gcc generates .section.bss.def,aw,@nobits while on Solaris/SPARC we get this instead: .section.bss.def,#alloc,#write It turns out that Solaris 10+ as supports the necessary #nobits/#progbits syntax, while Solaris 9 does not. gcc/ config/sparc/sparc.c (sparc_solaris_elf_asm_named_section) has /* ??? Handle SECTION_BSS. */ while SECTION_BSS is handled explicitly in gcc/varasm.c (default_elf_asm_named_section). After all, a gcc issue. Thanks for your help resolving it. Rainer -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/15056] gld 2.23.1 mishandles R_SPARC_TLS_LDM_CALL
http://sourceware.org/bugzilla/show_bug.cgi?id=15056 --- Comment #4 from Rainer Orth ro at CeBiTec dot Uni-Bielefeld.DE 2013-01-24 13:25:16 UTC --- --- Comment #3 from David S. Miller davem at davemloft dot net 2013-01-23 21:34:17 UTC --- Indeed, my change is in the 2.22 release, I just double checked. Seems like I'll have to run a reghunt to find which binutils patch caused this. Rainer -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/13255] Wrong `local symbol is referenced by DSO' warnings on Solaris
http://sourceware.org/bugzilla/show_bug.cgi?id=13255 --- Comment #3 from Rainer Orth ro at CeBiTec dot Uni-Bielefeld.DE 2011-10-14 11:46:00 UTC --- --- Comment #2 from H.J. Lu hjl.tools at gmail dot com 2011-10-10 15:55:01 UTC --- Please try the current binutils 2.22 branch. Sorry for the delay: I've now re-bootstrapped gcc mainline as of 20111007 with gas/gld 2.21.90.20111007 and Alan's patch for PR ld/13254. Works just fine, with only two testsuite regressions compared to 2.21.1: FAIL: g++.dg/init/cleanup3.C scan-assembler-not _tcf FAIL: g++.old-deja/g++.other/init5.C execution test With gld 2.21.1, the cxa_atexit effective-target test fails, thus the first test above is UNSUPPORTED and the second XFAIL. With 2.21.90, the cxa_atexit test suddenly passes, although Solaris 11 doesn't have __cxa_atexit. Rainer -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/12987] gold doesn't build on Solaris 11
http://sourceware.org/bugzilla/show_bug.cgi?id=12987 --- Comment #2 from Rainer Orth ro at CeBiTec dot Uni-Bielefeld.DE 2011-07-12 18:47:23 UTC --- One issue I forgot: when build a 64-bit gold to perform 64-bit testing (which otherwise fails in many ways, e.g. due to trying to link libgold.a), I had to remove the static from the posix_fallocate replacement to avoid the following error: /vol/gnu/src/binutils/binutils/local/gold/output.cc: In function 'int posix_fallocate(int, off_t, off_t)': /vol/gnu/src/binutils/binutils/local/gold/output.cc:119:47: error: 'int posix_fallocate(int, off_t, off_t)' was declared 'extern' and later 'static' [-fpermissive] /usr/include/fcntl.h:136:12: error: previous declaration of 'int posix_fallocate(int, off_t, off_t)' [-fpermissive] Rainer -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/12525] gold SEGV linking libgcc_s.so.1 on Solaris 11/x86
http://sourceware.org/bugzilla/show_bug.cgi?id=12525 --- Comment #24 from Rainer Orth ro at CeBiTec dot Uni-Bielefeld.DE 2011-03-14 19:40:31 UTC --- I've had a look at the two remaining errors (apart from not having static system libs on newer Solaris releases): gcctestdir/ld: internal error in override_version, at /vol/gnu/src/binutils/binutils-hg/gold/resolve.cc:61 collect2: ld returned 1 exit status make[3]: *** [weak_test] Error 1 This can be reproduced with gold-2.21.51 -o weak_test /usr/lib/crt1.o weak_test.o -lc gold-2.21.51: internal error in override_version, at /vol/gnu/src/binutils/binutils-hg/gold/resolve.cc:61 In override_version, I find: this-name_ = _iob this-version_ = SUNW_0.7 version = SYSVABI_1.3 With pvs -dsvo /lib/libc.so.1, I find the following version info in libc: /lib/libc.so.1 -SUNW_0.7: _iob (960); /lib/libc.so.1 -SYSVABI_1.3: __iob (960); and elfdump reveals a bit more about those symbols: $ elfdump -s /lib/libc.so.1|grep _iob [60] 0x00151818 0x03c0 OBJT GLOB D 40 .data _iob [299] 0x00151818 0x03c0 OBJT WEAK D 41 .data __iob The other failure is gcctestdir/ld: error: read-only segment has dynamic relocations collect2: ld returned 1 exit status make[3]: *** [two_file_shared_1_nonpic.so] Error 1 Can be reproduced with gold-2.21.51 -G -z text -o two_file_shared_1_nonpic.so two_file_test_1.o two_file_test_1b.o gold-2.21.51: error: read-only segment has dynamic relocations I suspect this happens because (32-bit) Solaris 2/x86 creates non-PIC code without -fpic/-fPIC. If so, the FN_PTRS_IN_SO_WITHOUT_PIC test in gold/configure.ac would have to be updated, perhaps with a real test instead of a hardcoded target list? Strangely, gld 2.21 can link those objects, while ld can not. I'm attaching them for inspection. Rainer -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/12525] gold SEGV linking libgcc_s.so.1 on Solaris 11/x86
http://sourceware.org/bugzilla/show_bug.cgi?id=12525 --- Comment #23 from Rainer Orth ro at CeBiTec dot Uni-Bielefeld.DE 2011-03-11 15:40:46 UTC --- --- Comment #21 from Ian Lance Taylor ian at airs dot com 2011-03-09 01:56:59 UTC --- [...] I committed a patch which should fix the problem of passing too many values to readv. That fixes all related failures, thanks. I don't know what's going on with the other two errors. I'll see if I can find anything over the weekend. This also blocks a gcc bootstrap with gold. Rainer -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/12525] gold SEGV linking libgcc_s.so.1 on Solaris 11/x86
http://sourceware.org/bugzilla/show_bug.cgi?id=12525 --- Comment #22 from Rainer Orth ro at CeBiTec dot Uni-Bielefeld.DE 2011-03-09 09:49:09 UTC --- --- Comment #21 from Ian Lance Taylor ian at airs dot com 2011-03-09 01:56:59 UTC --- There's not much point to trying to use gold to build gcc until gold passes at least most of its tests. Ok. The failure on basic_static_test looks like you don't have libc.a or libm.a--that is, it looks like gcc -static is always going to fail, whether using gold or the existing linker. Is that correct? Right: starting from Solaris 10, static system libs are gone, and 64-bit static libs didn't exist ever, even when 64-bit support was introduced in Solaris 7. I committed a patch which should fix the problem of passing too many values to readv. Thanks, I'll give it a try. I don't know what's going on with the other two errors. I'll investigate as time permits. Rainer -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/12525] gold SEGV linking libgcc_s.so.1 on Solaris 11/x86
http://sourceware.org/bugzilla/show_bug.cgi?id=12525 --- Comment #14 from Rainer Orth ro at CeBiTec dot Uni-Bielefeld.DE 2011-03-08 10:18:43 UTC --- ian at airs dot com sourceware-bugzi...@sourceware.org writes: --- Comment #13 from Ian Lance Taylor ian at airs dot com 2011-03-08 05:33:07 UTC --- Created attachment 5280 -- http://sourceware.org/bugzilla/attachment.cgi?id=5280 Possible patch Please try this patch to see if it fixes the assertion failure on get_fde_pc. The key will be whether the various exception tests in the testsuite pass. That test helped me get further along in the GCC bootstrap, but I'm now failing to link the 64-bit libgomp.so: gold-2.21.51: fatal error: .libs/team.o: readv failed: Invalid argument With truss, I see that readv is called like this: 11626: readv(21, 0x080438E4, 17) Err#22 EINVAL 11626: iov_base = 0xFE809CA0 iov_len = 2807 11626: iov_base = 0x080418E4 iov_len = 33 11626: iov_base = 0xFE80B9A8 iov_len = 41 11626: iov_base = 0x080418E4 iov_len = 15 11626: iov_base = 0xFE80A7A0 iov_len = 71 11626: iov_base = 0x080418E4 iov_len = 1 11626: iov_base = 0xFE80D8E0 iov_len = 8 11626: iov_base = 0xFE80A7F0 iov_len = 14 11626: iov_base = 0x080418E4 iov_len = 2 11626: iov_base = 0xFE80D8F8 iov_len = 8 11626: iov_base = 0xFE81A858 iov_len = 4666 11626: iov_base = 0xFE824120 iov_len = 1059 11626: iov_base = 0xFE830BE8 iov_len = 5233 11626: iov_base = 0xFE83B4FE iov_len = 464 11626: iov_base = 0xFE8369D6 iov_len = 1156 11626: iov_base = 0x080418E4 iov_len = 2494 i.e. iovcnt is 17, but iov[] has only 16 members. Seems inconsistent to me, though this could be a truss artefact. Rainer -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/12525] gold SEGV linking libgcc_s.so.1 on Solaris 11/x86
http://sourceware.org/bugzilla/show_bug.cgi?id=12525 --- Comment #16 from Rainer Orth ro at CeBiTec dot Uni-Bielefeld.DE 2011-03-08 14:14:01 UTC --- --- Comment #15 from Ian Lance Taylor ian at airs dot com 2011-03-08 14:10:34 UTC --- What is the value of IOV_MAX on Solaris? The man page implies that it is defined in some header file, perhaps stdio.h or limits.h. It's 16, from limits.h. That certainly explains the failure. Rainer -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/12525] gold SEGV linking libgcc_s.so.1 on Solaris 11/x86
http://sourceware.org/bugzilla/show_bug.cgi?id=12525 --- Comment #18 from Rainer Orth ro at CeBiTec dot Uni-Bielefeld.DE 2011-03-08 14:39:08 UTC --- --- Comment #17 from Ian Lance Taylor ian at airs dot com 2011-03-08 14:28:19 UTC --- Thanks. I would also be interesting in knowing whether gold can pass its tests with the patch I sent, even before you succeed in getting gcc to build. Apart from the readv stuff, there are a couple of other errors: gcctestdir/ld: error: cannot find -lm gcctestdir/ld: error: cannot find -lc gcctestdir/ld: /usr/lib/crt1.o: in function _start:fsr.s(.text+0x11): error: undefined reference to 'atexit' gcctestdir/ld: /usr/lib/crt1.o: in function _start:fsr.s(.text+0x1e): error: undefined reference to 'atexit' gcctestdir/ld: /usr/lib/crt1.o: in function _start:fsr.s(.text+0x3f): error: undefined reference to 'atexit' gcctestdir/ld: /usr/lib/crt1.o: in function _start:fsr.s(.text+0x70): error: undefined reference to '__fpstart' gcctestdir/ld: /usr/lib/crt1.o: in function _start:fsr.s(.text+0x8b): error: undefined reference to 'exit' gcctestdir/ld: /usr/lib/crt1.o: in function _start:fsr.s(.text+0x97): error: undefined reference to '_exit' gcctestdir/ld: fatal error: basic_test.o: readv failed: Invalid argument collect2: ld returned 1 exit status make[3]: *** [basic_static_test] Error 1 gcctestdir/ld: error: read-only segment has dynamic relocations collect2: ld returned 1 exit status make[3]: *** [two_file_shared_1_nonpic.so] Error 1 gcctestdir/ld: internal error in override_version, at /vol/gnu/src/binutils/binutils-hg/gold/resolve.cc:61 collect2: ld returned 1 exit status make[3]: *** [weak_test] Error 1 gcctestdir/ld: fatal error: ver_matching_def_pic.o: readv failed: Invalid argument collect2: ld returned 1 exit status make[3]: *** [ver_matching_def.so] Error 1 Rainer -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/12525] gold SEGV linking libgcc_s.so.1 on Solaris 11/x86
http://sourceware.org/bugzilla/show_bug.cgi?id=12525 --- Comment #10 from Rainer Orth ro at CeBiTec dot Uni-Bielefeld.DE 2011-03-07 19:10:06 UTC --- --- Comment #9 from Ian Lance Taylor ian at airs dot com 2011-03-04 19:08:43 UTC --- output.cc does #include fcntl.h. gold is always compiled with -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64. Those two facts together should ensure that posix_fallocate is called with the right types. Can you suggest a way that the gold source should be changed to fix this? Not yet, since this was just a guess based on the fact that truss showed impossibly large values for a couple of the fcntl struct flock64 members. I'll have to analyse this further. In the meantime, I've tried to disable posix_fallocate in config.h, thus using ftruncate (or rather ftruncate64) instead. This works (which suggests that my guess above may be wrong), but linking libgcc_s.so.1 fails again like this: gold-2.21: internal error in get_fde_pc, at /vol/gnu/src/binutils/binutils-2.21/gold/ehframe.cc:281 According to gcc/config/i386/sol2.h (ASM_PREFERRED_EH_DATA_FORMAT), Solaris 2/x86 uses datarel encoding, which isn't handled yet in gold/ehframe.cc (Eh_frame_hdr::get_fde_pc). Rainer -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/12525] gold SEGV linking libgcc_s.so.1 on Solaris 11/x86
http://sourceware.org/bugzilla/show_bug.cgi?id=12525 --- Comment #2 from Rainer Orth ro at CeBiTec dot Uni-Bielefeld.DE 2011-03-01 14:45:36 UTC --- --- Comment #1 from Ian Lance Taylor ian at airs dot com 2011-03-01 14:29:45 UTC --- At least part of the problem is that gold does not support the -dy option. That is interpreted as the -d option followed by the -y option. The -y option takes an argument, which is the string -z. The string text is then taken to name an input file. I see. gld 2.21 does handle it though, so I suppose gold should as well to be a drop-in replacement? That does not explain the crash. The value of the parameter p is apparently incorrect, but I don't see what could cause that to happen. I'll need to be able to recreate this in the debugger somehow. I've had a look: (gdb) up #2 0x085c959d in gold::Symbol_table::sized_write_globals32, false (this=0x8046d9c, sympool=0x8046bf4, dynpool=0x8046c38, symtab_xindex=0x0, dynsym_xindex=0x0, of=0x897f3d0) at /vol/gnu/src/binutils/binutils-hg/gold/symtab.cc:2850 (gdb) p ps $1 = (unsigned char *) 0xfe51e9b4 Address 0xfe51e9b4 out of bounds (gdb) p psyms $2 = (unsigned char *) 0xfe51e874 Address 0xfe51e874 out of bounds So it seems the bad value is from symtab.cc:2706: psyms = of-get_output_view(this-offset_, oview_size); gold::Output_file::get_output_view (this=0x897f3d0, start=383092, size=2752) at /vol/gnu/src/binutils/binutils-hg/gold/output.h:4105 (gdb) p this-base_ $5 = (unsigned char *) 0xfe4c1000 Address 0xfe4c1000 out of bounds (gdb) p start $6 = 383092 (gdb) p this-base_ + start $7 = (unsigned char *) 0xfe51e874 Address 0xfe51e874 out of bounds The bad value for base_ is already in layout.cc (Write_symbols_task::run), but I cannot readily see how to trace it back further up. Rainer -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/12320] ld --as-needed links libgcc_s.so.1 unnecessarily on Solaris 11
http://sourceware.org/bugzilla/show_bug.cgi?id=12320 --- Comment #6 from Rainer Orth ro at CeBiTec dot Uni-Bielefeld.DE 2011-02-16 17:51:03 UTC --- --- Comment #5 from Alan Modra amodra at gmail dot com 2011-02-15 23:54:45 UTC --- So http://sourceware.org/ml/binutils/2010-03/msg00017.html broke --as-needed. I did ask why you wanted to follow the mistakes of the Sun linker.. Are you certain that the Solaris ABI requires these symbols to be dynamic? Yes: every versioned symbol (and this includes the base version) needs to be in .dynamic. Rainer -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/12320] ld --as-needed links libgcc_s.so.1 unnecessarily on Solaris 11
http://sourceware.org/bugzilla/show_bug.cgi?id=12320 --- Comment #4 from Rainer Orth ro at CeBiTec dot Uni-Bielefeld.DE 2011-02-15 12:44:52 UTC --- --- Comment #3 from Alan Modra amodra at gmail dot com 2011-02-15 12:01:45 UTC --- In crt1.o 15: 0 NOTYPE WEAK DEFAULT UND _DYNAMIC In libgcc_s.so 154: 00018fd0 0 OBJECT GLOBAL DEFAULT ABS _DYNAMIC libgcc_s.so provides a symbol that is undefined at the time libgcc_s.so is linked, and thus libgcc_s.so is marked as needed. So, why does your libgcc_s.so export _DYNAMIC (and _GLOBAL_OFFSET_TABLE_)? Because that's what the Solaris 2 ABI requires for shared objects, cf. ld/emultempl/solaris2.em (elf_solaris2_before_allocation). Rainer -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/12253] .eh_frame_hdr not properly sorted with mixed .eh_frame encodings
http://sourceware.org/bugzilla/show_bug.cgi?id=12253 --- Comment #6 from Rainer Orth ro at CeBiTec dot Uni-Bielefeld.DE 2010-11-25 16:31:44 UTC --- --- Comment #5 from Alan Modra amodra at gmail dot com 2010-11-24 05:34:22 UTC --- http://sourceware.org/ml/binutils/2010-11/msg00431.html http://sourceware.org/ml/binutils-cvs/2010-11/msg00150.html Excellent, thanks. It would be good to have this backported to the 2.21 branch, although I plan to work around the issue I've found in libffi for the benefit of older versions. Rainer -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/12253] .eh_frame_hdr not properly sorted with mixed .eh_frame encodings
http://sourceware.org/bugzilla/show_bug.cgi?id=12253 --- Comment #3 from Rainer Orth ro at CeBiTec dot Uni-Bielefeld.DE 2010-11-23 16:01:49 UTC --- --- Comment #2 from Alan Modra amodra at gmail dot com 2010-11-23 13:34:02 UTC --- I took a look at this today. Besides the sorting problem, elf-eh-frame.c gets DW_EH_PE_datarel wrong. datarel is quite horrible, with behaviour varying from one architecture to another, unspecified on most. For x86, datarel offsets are supposed to be relative to .got.plt rather than .got. On ia64, datarel is relative to __gp. Do you have an idea where this is specified? I've only found Table 11.6 in the LSB 4.0.0: http://refspecs.freestandards.org/LSB_4.0.0/LSB-Core-generic/LSB-Core-generic/dwarfext.html which says DW_EH_PE_datarel0x30Value is relative to the beginning of the .got or .eh_frame_hdr section. A spec which says `do A or B' with no indication when to do one or the other seems like a joke to me. I've looked into the architecture extensions for advise, but found nothing. I ran into this when trying to get the libgcc unwinder to work with dl_iterate_phdr on Solaris 11. While the function works, Sun ld interpreted DW_EH_PE_datarel relative to .eh_frame_hdr on i386 (apart from other problems). It would be good to have a spec to point to for this, rather than saying `GCC has been doing this' instead. Thanks. Rainer -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/12181] local COMDAT group names break linking libstdc++.so with Sun ld
http://sourceware.org/bugzilla/show_bug.cgi?id=12181
--- Comment #1 from Rainer Orth ro at CeBiTec dot Uni-Bielefeld.DE 2010-11-05
17:28:24 UTC ---
Parallel to filing this PR, I've contacted the Solaris linker
maintainers. Here's Ali Bahrami's analysis, cited by permission:
The error you reported in the bugzilla report
ld: fatal: file group.o: group section [1].group: invalid group symbol
D5Ev
comes from this code in groups.c:
/*
* If this group is a COMDAT group, validate the signature symbol.
*/
if ((gd.gd_data[0] GRP_COMDAT) !gnu_stt_section
((ELF_ST_BIND(sym-st_info) == STB_LOCAL) ||
(sym-st_shndx == SHN_UNDEF))) {
/* If section symbol, construct a printable name for it */
if (ELF_ST_TYPE(sym-st_info) == STT_SECTION) {
if (gisc-is_sym_name == NULL)
(void) ld_stt_section_sym_name(gisc);
if (gisc-is_sym_name != NULL)
str = gisc-is_sym_name;
}
ld_eprintf(ofl, ERR_FATAL, MSG_INTL(MSG_GRP_INVALSYM),
gifl-ifl_name, EC_WORD(gisc-is_scnndx),
gisc-is_name, str);
return (0);
}
As you deduced, it does not like the fact that the name symbol is local.
I can guess at the cause of this. The LLM says this in the documentation for
Group Section in the File Format chapter:
References to the sections comprising a group from sections outside
of the group must be made through symbol table entries with STB_GLOBAL
or STB_WEAK binding and section index SHN_UNDEF. A definition of the
same symbol in the object containing the reference must have a separate
symbol table entry from the reference. Sections outside of the group
can not reference symbols with STB_LOCAL binding for addresses that
are contained in the group's sections, including symbols with type
STT_SECTION.
As far as I can tell, the symbol that gives a group its name is not
a reference to the sections comprising a group. In fact, it seems that
we take the name for the group from this symbol and then never look
at the symbol again (at least as far as the group is concerned). As such,
I don't know why the symbol's type, scope, binding, or any other attribute
would matter. Perhaps this wording, which is clearly about how the code within
a group can be accessed by code outside the group, led us to assume that the
name symbol needs to be global.
I note in the above code that we also refuse to let the symbol be undefined,
even if it has a valid name. I don't really understand why that's not
allowed either --- as long as it has a name we can use for the group, what
does it matter? This makes me think that the entire block of code shown above
could simply come out.
If you can confirm this analysis, the issue could be fixed on the
Solaris ld side.
Additionally, it might be possible (not yet tried, just an idea) to
change the STB_GLOBAL, but use STV_HIDDEN. This would have the same
effect as making it local in the first place, but avoid the Solaris ld
problem even for current versions.
Comments?
Rainer
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
