[Bug ld/30743] FAIL: ld-elf/now-3 for hppa64-*-linux* target
https://sourceware.org/bugzilla/show_bug.cgi?id=30743 --- Comment #16 from dave.anglin at bell dot net --- > --- Comment #15 from Nick Clifton --- > Patch applied. Thanks, Nick. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30743] FAIL: ld-elf/now-3 for hppa64-*-linux* target
https://sourceware.org/bugzilla/show_bug.cgi?id=30743 --- Comment #13 from dave.anglin at bell dot net --- On 2024-04-16 9:54 a.m., nickc at redhat dot com wrote: > Created attachment 15468 >-->https://sourceware.org/bugzilla/attachment.cgi?id=15468=edit > Proposed patch Tested with hppa64-unknown-linux-gnu target. There were no observed regressions. The patch is fine. Nick, will you please install. Dave -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30743] FAIL: ld-elf/now-3 for hppa64-*-linux* target
https://sourceware.org/bugzilla/show_bug.cgi?id=30743 --- Comment #12 from dave.anglin at bell dot net --- On 2024-04-16 9:54 a.m., nickc at redhat dot com wrote: > Like this ? Looks good. Will test. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30743] FAIL: ld-elf/now-3 for hppa64-*-linux* target
https://sourceware.org/bugzilla/show_bug.cgi?id=30743 --- Comment #10 from dave.anglin at bell dot net --- On 2024-04-16 7:25 a.m., nickc at redhat dot com wrote: > I dislike relying upon magic strings like "elf64-hppa", so how about this > alternative patch which checks the vector itself ? > > (I also added a comment so that readers of the code will be directed to this > PR > if they are wondering why the test is needed). This is clearly a better fix if it works. Can we do the same in elf64_hppa_object_p()? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30743] FAIL: ld-elf/now-3 for hppa64-*-linux* target
https://sourceware.org/bugzilla/show_bug.cgi?id=30743 --- Comment #4 from dave.anglin at bell dot net --- On 2024-04-12 5:58 a.m., nickc at redhat dot com wrote: > I am not sure why this is happening, but I do not see the harm in it. So I > think that the best solution is to change the now-3 test to look for the old > flags. There is this comment in include/elf/hppa.h" /* Processor specific dynamic array tags. */ /* Arggh. HP's tools define these symbols based on the old value of DT_LOOS. So we must do the same to be compatible. */ #define DT_HP_LOAD_MAP (OLD_DT_LOOS + 0x0) [...] /* Values for DT_HP_DLD_FLAGS. */ #define DT_HP_DEBUG_PRIVATE 0x1 /* Map text private */ #define DT_HP_DEBUG_CALLBACK 0x2 /* Callback */ #define DT_HP_DEBUG_CALLBACK_BOR 0x4 /* BOR callback */ #define DT_HP_NO_ENVVAR 0x8 /* No env var */ #define DT_HP_BIND_NOW 0x00010 /* Bind now */ -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31503] [hppa] Unsupported 14-bit PA 2.0 relocations for 32-bit (narrow) mode (elf32-hppa.c)
https://sourceware.org/bugzilla/show_bug.cgi?id=31503
--- Comment #11 from dave.anglin at bell dot net ---
On 2024-03-28 7:34 p.m., dave.anglin at bell dot net wrote:
> https://sourceware.org/bugzilla/show_bug.cgi?id=31503
>
> --- Comment #10 from dave.anglin at bell dot net ---
> On 2024-03-28 7:20 p.m., amodra at gmail dot com wrote:
>> https://sourceware.org/bugzilla/show_bug.cgi?id=31503
>>
>> --- Comment #9 from Alan Modra ---
>> (In reply to Andreas Schwab from comment #7)
>>> That should use ALIGN(8).
>> ALIGN inside an output section statement doesn't align the section, just the
>> current *relative* value of dot. So the effect is exacly the same as John's
>> expression. They both align zero to a multiple of eight and thus do nothing.
> Okay. I was hoping that the expression would align the value assigned to
> $global$.
>
> This change appears to successfully align .data:
>
> dave@mx3210:~/gnu/binutils/src/ld/scripttempl$ diff -u elf.sc elf32hppa.sc
> --- elf.sc 2024-03-28 21:45:32.560456976 +
> +++ elf32hppa.sc 2024-03-28 22:26:32.625611275 +
> @@ -669,7 +669,7 @@
>
> ${DATA_PLT+${PLT_BEFORE_GOT-${PLT}}}
>
> - .data ${RELOCATING-0} :
> + .data ${RELOCATING-0} ${CREATE_SHLIB-${CREATE_PIE-${RELOCATING+ALIGN(8)}}}
> :
> {
> ${RELOCATING+${DATA_START_SYMBOLS}}
> *(.data${RELOCATING+ .data.* .gnu.linkonce.d.*})
>
> But it causes two testsuite fails:
>
> PASS: Build pr23162b
> FAIL: Build libpr23161a.so
> PASS: Build pr23161a
> FAIL: Build libpr23161b.so
>
> regexp_diff match failure
> regexp "^Relocation section '\.rel(a|)\.dyn' at offset 0x[0-9a-f]+ contains
> [0-9
> ]+ entries:$"
> line "Relocation section '.rela.got' at offset 0x19c contains 3 entries:"
> output is
> Relocation section '.rela.got' at offset 0x19c contains 3 entries:
> Offset Info Type Sym. Value Symbol's Name + Addend
> 1088 0501 R_PARISC_DIR32 1094 __bss_start + 0
> 108c 0301 R_PARISC_DIR32 1094 _edata + 0
> 1090 0401 R_PARISC_DIR32 1094 _end + 0
>
> If this isn't serious, I can just modify the regexp. Otherwise, do you have
> any thoughts
> on how to work around this issue.
Found it. Need to define "GENERATE_COMBRELOC_SCRIPT=yes".
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug ld/31503] [hppa] Unsupported 14-bit PA 2.0 relocations for 32-bit (narrow) mode (elf32-hppa.c)
https://sourceware.org/bugzilla/show_bug.cgi?id=31503
--- Comment #10 from dave.anglin at bell dot net ---
On 2024-03-28 7:20 p.m., amodra at gmail dot com wrote:
> https://sourceware.org/bugzilla/show_bug.cgi?id=31503
>
> --- Comment #9 from Alan Modra ---
> (In reply to Andreas Schwab from comment #7)
>> That should use ALIGN(8).
> ALIGN inside an output section statement doesn't align the section, just the
> current *relative* value of dot. So the effect is exacly the same as John's
> expression. They both align zero to a multiple of eight and thus do nothing.
Okay. I was hoping that the expression would align the value assigned to
$global$.
This change appears to successfully align .data:
dave@mx3210:~/gnu/binutils/src/ld/scripttempl$ diff -u elf.sc elf32hppa.sc
--- elf.sc 2024-03-28 21:45:32.560456976 +
+++ elf32hppa.sc 2024-03-28 22:26:32.625611275 +
@@ -669,7 +669,7 @@
${DATA_PLT+${PLT_BEFORE_GOT-${PLT}}}
- .data ${RELOCATING-0} :
+ .data ${RELOCATING-0} ${CREATE_SHLIB-${CREATE_PIE-${RELOCATING+ALIGN(8)}}} :
{
${RELOCATING+${DATA_START_SYMBOLS}}
*(.data${RELOCATING+ .data.* .gnu.linkonce.d.*})
But it causes two testsuite fails:
PASS: Build pr23162b
FAIL: Build libpr23161a.so
PASS: Build pr23161a
FAIL: Build libpr23161b.so
regexp_diff match failure
regexp "^Relocation section '\.rel(a|)\.dyn' at offset 0x[0-9a-f]+ contains
[0-9
]+ entries:$"
line "Relocation section '.rela.got' at offset 0x19c contains 3 entries:"
output is
Relocation section '.rela.got' at offset 0x19c contains 3 entries:
Offset Info Type Sym. Value Symbol's Name + Addend
1088 0501 R_PARISC_DIR32 1094 __bss_start + 0
108c 0301 R_PARISC_DIR32 1094 _edata + 0
1090 0401 R_PARISC_DIR32 1094 _end + 0
If this isn't serious, I can just modify the regexp. Otherwise, do you have
any thoughts
on how to work around this issue.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug ld/31503] [hppa] Unsupported 14-bit PA 2.0 relocations for 32-bit (narrow) mode (elf32-hppa.c)
https://sourceware.org/bugzilla/show_bug.cgi?id=31503 --- Comment #8 from dave.anglin at bell dot net --- I already tried it. It also sometimes fails to align the $global$ address. spawn -ignore SIGHUP /home/dave/gnu/gcc/objdir/./gcc/xg++ -shared-libgcc -B/home /dave/gnu/gcc/objdir/./gcc -nostdinc++ -L/home/dave/gnu/gcc/objdir/hppa-linux-gn u/libstdc++-v3/src -L/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/src/. libs -L/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/libsupc++/.libs -B/ home/dave/opt/gnu/gcc/gcc-14/hppa-linux-gnu/bin/ -B/home/dave/opt/gnu/gcc/gcc-14 /hppa-linux-gnu/lib/ -isystem /home/dave/opt/gnu/gcc/gcc-14/hppa-linux-gnu/inclu de -isystem /home/dave/opt/gnu/gcc/gcc-14/hppa-linux-gnu/sys-include -fchecking= 1 -B/home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libstdc++-v3/src/.libs -fmessage- length=0 -fno-show-column -ffunction-sections -fdata-sections -g -O2 -D_GNU_SOUR CE -DLOCALEDIR="." -nostdinc++ -I/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstd c++-v3/include/hppa-linux-gnu -I/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc ++-v3/include -I/home/dave/gnu/gcc/gcc/libstdc++-v3/libsupc++ -I/home/dave/gnu/g cc/gcc/libstdc++-v3/include/backward -I/home/dave/gnu/gcc/gcc/libstdc++-v3/tests uite/util /home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/23_containers/vector/req uirements/exception/generation_prohibited.cc -std=gnu++17 -include bits/stdc++.h -fdiagnostics-plain-output ./libtestc++.a -Wl,--gc-sections -L/home/dave/gnu/gc c/objdir/hppa-linux-gnu/libstdc++-v3/src/filesystem/.libs -L/home/dave/gnu/gcc/o bjdir/hppa-linux-gnu/libstdc++-v3/src/experimental/.libs -lm -o ./generation_pro hibited.exe /home/dave/opt/gnu/bin/ld: /tmp/cc2Eie9V.o(.text._ZN10__gnu_test10setup_base8populateISt6vectorIN9__gnu_cxx18throw_value_randomENS3_22throw_allocator_randomIS4_EEELb1EEC2ERS7_[_ZN10__gnu_test10setup_base8populateISt6vectorIN9__gnu_cxx18throw_value_randomENS3_22throw_allocator_randomIS4_EEELb1EEC5ERS7_]+0x288): displacement 0x5cc for insn 0x51370002 is not a multiple of 8 (gp 0x161c4) /home/dave/opt/gnu/bin/ld: /tmp/cc2Eie9V.o(.text._ZN10__gnu_test10setup_base8populateISt6vectorIN9__gnu_cxx18throw_value_randomENS3_22throw_allocator_randomIS4_EEELb1EEC2ERS7_[_ZN10__gnu_test10setup_base8populateISt6vectorIN9__gnu_cxx18throw_value_randomENS3_22throw_allocator_randomIS4_EEELb1EEC5ERS7_]+0x288): cannot handle R_PARISC_DPREL14R for _ZZN9__gnu_cxx16random_condition8generateEvE9generator /home/dave/opt/gnu/bin/ld: final link failed: bad value collect2: error: ld returned 1 exit status compiler exited with status 1 FAIL: 23_containers/vector/requirements/exception/generation_prohibited.cc -std=gnu++17 (test for excess errors) Excess errors: /home/dave/opt/gnu/bin/ld: /tmp/cc2Eie9V.o(.text._ZN10__gnu_test10setup_base8populateISt6vectorIN9__gnu_cxx18throw_value_randomENS3_22throw_allocator_randomIS4_EEELb1EEC2ERS7_[_ZN10__gnu_test10setup_base8populateISt6vectorIN9__gnu_cxx18throw_value_randomENS3_22throw_allocator_randomIS4_EEELb1EEC5ERS7_]+0x288): displacement 0x5cc for insn 0x51370002 is not a multiple of 8 (gp 0x161c4) /home/dave/opt/gnu/bin/ld: /tmp/cc2Eie9V.o(.text._ZN10__gnu_test10setup_base8populateISt6vectorIN9__gnu_cxx18throw_value_randomENS3_22throw_allocator_randomIS4_EEELb1EEC2ERS7_[_ZN10__gnu_test10setup_base8populateISt6vectorIN9__gnu_cxx18throw_value_randomENS3_22throw_allocator_randomIS4_EEELb1EEC5ERS7_]+0x288): cannot handle R_PARISC_DPREL14R for _ZZN9__gnu_cxx16random_condition8generateEvE9generator /home/dave/opt/gnu/bin/ld: final link failed: bad value collect2: error: ld returned 1 exit status The gp value is 4-byte aligned (0x161c4). -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30732] ld: 'ELF weak (alias)' tests fail on hppa
https://sourceware.org/bugzilla/show_bug.cgi?id=30732 --- Comment #12 from dave.anglin at bell dot net --- On 2023-08-10 12:25 a.m., sam at gentoo dot org wrote: >> Let's leave things as they are for the moment. I will test hppa64 builds on >> linux and hpux. > I'll fix the pattern over the weekend (it's trivial ofc, just going to add > hppa1.1 and hppa2.0 explicitly for Gentoo, and restore the old hppa-* pattern) > as Alan pointed out the change in results for hppa64. You can cover both hppa1.1 and hppa2.0 with hppa[12]*. hppa1.0 is theoretically possible but never used. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30732] ld: 'ELF weak (alias)' tests fail on hppa
https://sourceware.org/bugzilla/show_bug.cgi?id=30732 --- Comment #9 from dave.anglin at bell dot net --- Let's leave things as they are for the moment. I will test hppa64 builds on linux and hpux. I started hacking on glibc to support hppa64-linux but got waylaid. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30732] ld: 'ELF weak (alias)' tests fail on hppa
https://sourceware.org/bugzilla/show_bug.cgi?id=30732 --- Comment #7 from dave.anglin at bell dot net --- On 2023-08-08 3:33 p.m., sam at gentoo dot org wrote: > Thanks Dave, I've done that last night in > https://inbox.sourceware.org/binutils/871qgdto5m@gentoo.org/T/#m0f16fd340d16e17949f2153309606b0918d0b926. I think the xfail and notarget comments were written as they were so they didn't match hppa64. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30732] ld: 'ELF weak (alias)' tests fail on hppa
https://sourceware.org/bugzilla/show_bug.cgi?id=30732 --- Comment #6 from dave.anglin at bell dot net --- On 2023-08-08 3:33 p.m., sam at gentoo dot org wrote: > Let me check if I can repeoduce the ELF weak (alias) failure. The segv appears to be in printf. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30732] ld: 'ELF weak (alias)' tests fail on hppa
https://sourceware.org/bugzilla/show_bug.cgi?id=30732 --- Comment #4 from dave.anglin at bell dot net --- On 2023-08-08 12:16 p.m., danglin at gcc dot gnu.org wrote: > I see for GNU ld (GNU Binutils) 2.41.50.20230808: > XFAIL: relocatable with script > UNSUPPORTED: SHF_GNU_RETAIN 7a The xfail and notarget comments for these tests need adjusting for hppa2.0 . -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30078] FAIL: merge4
https://sourceware.org/bugzilla/show_bug.cgi?id=30078 --- Comment #2 from dave.anglin at bell dot net --- Hi Nick, Yes, the behavior of .string on hppa is a bug/feature intended to match the behavior of HP as. Using .asciz instead of .string fixes the test on hppa. Dave -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29802] Segmentation fault in _bfd_elf_strtab_add
https://sourceware.org/bugzilla/show_bug.cgi?id=29802 --- Comment #3 from dave.anglin at bell dot net --- On 2022-11-18 4:30 p.m., dave.anglin at bell dot net wrote: > readelf: Warning: [ 4]: Link field (0) should index a symtab section. Sorry, cut this off: [ 3] .dynstr STRTAB 40001940 1940 0c41 A 0 0 1 readelf: Warning: [ 4]: Link field (0) should index a symtab section. [ 4] .hash HASH 40002588 2588 0740 A 0 0 8 0x0004 (HASH) 0x40002588 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29802] Segmentation fault in _bfd_elf_strtab_add
https://sourceware.org/bugzilla/show_bug.cgi?id=29802 --- Comment #2 from dave.anglin at bell dot net --- On 2022-11-18 3:51 p.m., amodra at gmail dot com wrote: > https://sourceware.org/bugzilla/show_bug.cgi?id=29802 > > --- Comment #1 from Alan Modra --- > What sort of local symbol are you trying to make dynamic? A section symbol? I'd have to debug more to be certain but when I dump a shared library generated using HP ld I see the following messages: Section Headers: [Nr] Name Type Address Offset Size EntSize Flags Link Info Align [ 0] NULL 0 0 0 [ 1] .dynamic DYNAMIC 41c8 01c8 01a0 0010 A 3 0 8 [ 2] .dynsym DYNSYM 4368 0368 15d8 0018 A 3 0 8 [ 3] .dynstr STRTAB 40001940 1940 0c41 A 0 0 1 readelf: Warning: [ 4]: Link field (0) should index a symtab section. ... Symbol table '.dynsym' contains 233 entries: Num: Value Size Type Bind Vis Ndx Name 0: 0 NOTYPE LOCAL DEFAULT UND readelf: Warning: local symbol 0 found at index >= .dynsym's sh_info value of 0 1: 41c8 0 SECTION LOCAL DEFAULT 1 __text_seg readelf: Warning: local symbol 1 found at index >= .dynsym's sh_info value of 0 2: 8001 0 SECTION LOCAL DEFAULT 20 __data_seg readelf: Warning: local symbol 2 found at index >= .dynsym's sh_info value of 0 3: 80013238 0 SECTION LOCAL DEFAULT 39 __thread_specific_seg readelf: Warning: local symbol 3 found at index >= .dynsym's sh_info value of 0 4: 80011910 96 FUNC GLOBAL DEFAULT 19 __lshrti3 I see these in links as well. /opt/gnu64/bin/ld: warning: /lib/pa20_64/libc.sl has a section extending past end of file /opt/gnu64/bin/ld: /lib/pa20_64/libc.sl: .dynsym local symbol at index 0 (>= sh_info of 0) /opt/gnu64/bin/ld: /lib/pa20_64/libc.sl: .dynsym local symbol at index 1 (>= sh_info of 0) /opt/gnu64/bin/ld: /lib/pa20_64/libc.sl: .dynsym local symbol at index 2 (>= sh_info of 0) /opt/gnu64/bin/ld: /lib/pa20_64/libc.sl: .dynsym local symbol at index 3 (>= sh_info of 0) /opt/gnu64/bin/ld: /usr/lib/pa20_64/libdl.1: .dynsym local symbol at index 0 (>= sh_info of 0) /opt/gnu64/bin/ld: /usr/lib/pa20_64/libdl.1: .dynsym local symbol at index 1 (>= sh_info of 0) /opt/gnu64/bin/ld: /usr/lib/pa20_64/libdl.1: .dynsym local symbol at index 2 (>= sh_info of 0) /opt/gnu64/bin/ld: /usr/lib/pa20_64/libdl.1: .dynsym local symbol at index 3 (>= sh_info of 0) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29263] /usr/bin/ld: warning: /usr/lib/gcc/hppa-linux-gnu/11/../../../hppa-linux-gnu/crtn.o: missing .note.GNU-stack section implies executable stack
https://sourceware.org/bugzilla/show_bug.cgi?id=29263 --- Comment #10 from dave.anglin at bell dot net --- On 2022-06-20 12:38 p.m., nickc at redhat dot com wrote: > https://sourceware.org/bugzilla/show_bug.cgi?id=29263 > > --- Comment #7 from Nick Clifton --- > Created attachment 14152 >--> https://sourceware.org/bugzilla/attachment.cgi?id=14152=edit > Proposed Patch > I believe the RWX warning comes from the second LOAD segment. It needs to be executable because of trampoline at the end of the PLT. Maybe second comment in patch could be adjusted. dave@mx3210:~/shmat$ readelf -a a.out Version: 0x1 Entry point address: 0x10334 Start of program headers: 52 (bytes into file) Start of section headers: 6804 (bytes into file) Flags: 0x210, PA-RISC 1.1 Size of this header: 52 (bytes) Size of program headers: 32 (bytes) Number of program headers: 7 Size of section headers: 40 (bytes) Number of section headers: 30 Section header string table index: 29 Section Headers: [Nr] Name Type Addr Off Size ES Flg Lk Inf Al [ 0] NULL 00 00 00 0 0 0 [ 1] .interp PROGBITS 00010114 000114 0d 00 A 0 0 1 [ 2] .note.gnu.bu[...] NOTE 00010124 000124 24 00 A 0 0 4 [ 3] .note.ABI-tag NOTE 00010148 000148 20 00 A 0 0 4 [ 4] .hash HASH 00010168 000168 2c 04 A 6 0 4 [ 5] .gnu.hash GNU_HASH 00010194 000194 20 04 A 6 0 4 [ 6] .dynsym DYNSYM 000101b4 0001b4 60 10 A 7 1 4 [ 7] .dynstr STRTAB 00010214 000214 82 00 A 0 0 1 [ 8] .gnu.version VERSYM 00010296 000296 0c 02 A 6 0 2 [ 9] .gnu.version_r VERNEED 000102a4 0002a4 20 00 A 7 1 4 [10] .rela.plt RELA 000102c4 0002c4 30 0c AI 6 23 4 [11] .init PROGBITS 000102f4 0002f4 2c 00 AX 0 0 4 [12] .text PROGBITS 00010320 000320 0004e0 00 AX 0 0 4 [13] .fini PROGBITS 00010800 000800 28 00 AX 0 0 4 [14] .rodata PROGBITS 00010828 000828 1c 00 A 0 0 4 [15] .PARISC.unwind PROGBITS 00010844 000844 000100 04 AI 0 12 4 [16] .eh_frame PROGBITS 00010944 000944 04 00 A 0 0 4 [17] .init_array INIT_ARRAY 00011000 001000 04 04 WA 0 0 1 [18] .ctors PROGBITS 00011004 001004 08 00 WA 0 0 4 [19] .dtors PROGBITS 0001100c 00100c 08 00 WA 0 0 4 [20] .data.rel.ro PROGBITS 00011014 001014 04 00 WA 0 0 4 [21] .dynamic DYNAMIC 00011018 001018 c8 08 WA 7 0 4 [22] .data PROGBITS 000110e0 0010e0 08 00 WA 0 0 4 [23] .plt PROGBITS 000110e8 0010e8 5c 00 WAX 0 0 8 [24] .got PROGBITS 00011144 001144 1c 04 WA 0 0 4 [25] .bss NOBITS 00011160 001160 10 00 WA 0 0 4 [26] .comment PROGBITS 001160 1e 01 MS 0 0 1 [27] .symtab SYMTAB 001180 000570 10 28 65 4 [28] .strtab STRTAB 0016f0 0002a1 00 0 0 1 [29] .shstrtab STRTAB 001991 000100 00 0 0 1 Key to Flags: W (write), A (alloc), X (execute), M (merge), S (strings), I (info), L (link order), O (extra OS processing required), G (group), T (TLS), C (compressed), x (unknown), o (OS specific), E (exclude), R (retain), D (mbind), p (processor specific) There are no section groups in this file. Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align PHDR 0x34 0x00010034 0x00010034 0x000e0 0x000e0 R 0x4 INTERP 0x000114 0x00010114 0x00010114 0xd 0xd R 0x1 [Requesting program interpreter: /lib/ld.so.1] LOAD 0x00 0x0001 0x0001 0x00948 0x00948 R E 0x1000 LOAD 0x001000 0x00011000 0x00011000 0x00160 0x00170 RWE 0x1000 DYNAMIC 0x001018 0x00011018 0x00011018 0x000c8 0x000c8 RW 0x4 NOTE 0x000124 0x00010124 0x00010124 0x00044 0x00044 R 0x4 GNU_STACK 0x00 0x 0x 0x0 0x0 RWE 0x10 Dave -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29263] /usr/bin/ld: warning: /usr/lib/gcc/hppa-linux-gnu/11/../../../hppa-linux-gnu/crtn.o: missing .note.GNU-stack section implies executable stack
https://sourceware.org/bugzilla/show_bug.cgi?id=29263 --- Comment #9 from dave.anglin at bell dot net --- On 2022-06-20 12:37 p.m., nickc at redhat dot com wrote: >> What is best way to transition without causing a lot of disruption? > How about a patch like the one I am about to upload ? It sets the defaults > for > these two warnings to 'ignore' for HPPA targets. (I do not know if it is > possible to determine the kernel version from the configuration string, so the > patch changes the default for all HPPA variants). Sounds like the best option for now. Thanks, Dave -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29263] /usr/bin/ld: warning: /usr/lib/gcc/hppa-linux-gnu/11/../../../hppa-linux-gnu/crtn.o: missing .note.GNU-stack section implies executable stack
https://sourceware.org/bugzilla/show_bug.cgi?id=29263 --- Comment #8 from dave.anglin at bell dot net --- On 2022-06-20 11:42 a.m., hp at sourceware dot org wrote: > But I should add: I'd suggest to inspect whatever goes on with the linker > script; a "hosted" target reasonably shouldn't get data and code segments > mixed. Maybe there's something to adjust there to make the warning go away > for > the "right" reason. Thanks H.P. for the hint. The problem is the .plt and the implementation of dynamic binding. For that, the PLT needs to be executable. Dave -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29263] /usr/bin/ld: warning: /usr/lib/gcc/hppa-linux-gnu/11/../../../hppa-linux-gnu/crtn.o: missing .note.GNU-stack section implies executable stack
https://sourceware.org/bugzilla/show_bug.cgi?id=29263 --- Comment #3 from dave.anglin at bell dot net --- On 2022-06-20 7:13 a.m., nickc at redhat dot com wrote: >> On hppa-linux with kernel v5.18 and later, we don't need an executable >> stack for signal support but we still need it for gcc nested functions. > This is already handled by gcc. If an executable stack is needed in order to > support nested functions (or more probably, taking the address of a nested > function), then gcc will generate a .note.GNU-stack section with the read, > write and execute permissions set. The linker will then obligingly create an > executable stack segment. You will still get a warning message however, since > the issue of executable stacks is still present, albeit for a different > reason. Unfortunately, this doesn't happen on hppa-linux because we have: /* It's not possible to enable GNU_stack notes since the kernel needs an executable stack for signal returns and syscall restarts. */ #undef NEED_INDICATE_EXEC_STACK #define NEED_INDICATE_EXEC_STACK 0 I can't just enable the generation of GNU_stack notes since old kernels are still prevalent. > > > The linker's warnings can be suppressed however, either via a run-time command > line option: --no-warn-execstack or a build-time configure option: > --enable-warn-execstack=no. --no-warn-execstack doesn't suppress all the warnings: dave@mx3210:~/shmat$ gcc main.c -Wl,--no-warn-execstack /usr/bin/ld: warning: a.out has a LOAD segment with RWX permissions > > > Is this sufficient ? We could change the configuration option so that it > defaults to disabling the warnings if the target is the HPPA, but I would > prefer not to do that, as it means that a potential security vulnerability > will > be ignored by default. There is no way to fix the issue on hpux. On linux, I believe the warning causes issues with some debian package builds. For example, it looks like a recent build of akonadi failed due to the warning: [ 0%] Linking CXX shared library ../../bin/sqldrivers/libqsqlite3.so cd /<>/obj-hppa-linux-gnu/src/qsqlite && /usr/bin/cmake -E cmake_link_script CMakeFiles/qsqlite3.dir/link.txt --verbose=1 /usr/bin/c++ -fPIC -g -O2 -ffile-prefix-map=/<>=. -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fno-operator-names -fno-exceptions -Wall -Wextra -Wcast-align -Wchar-subscripts -Wformat-security -Wno-long-long -Wpointer-arith -Wundef -Wnon-virtual-dtor -Woverloaded-virtual -Werror=return-type -Werror=init-self -Wvla -Wdate-time -Wsuggest-override -Wlogical-op -pedantic -Wzero-as-null-pointer-constant -Wmissing-include-dirs -Wnon-virtual-dtor -Wundef -Wcast-align -Wchar-subscripts -Wall -Wextra -Wpointer-arith -Wformat-security -fno-common -pedantic -Wno-deprecated-copy -fexceptions -Wl,--no-undefined -Wl,--fatal-warnings -Wl,--enable-new-dtags -shared -Wl,-soname,libqsqlite3.so -o ../../bin/sqldrivers/libqsqlite3.so CMakeFiles/qsqlite3.dir/qsqlite3_autogen/mocs_compilation.cpp.o CMakeFiles/qsqlite3.dir/src/sqlite_blocking.cpp.o CMakeFiles/qsqlite3.dir/src/qsql_sqlite.cpp.o CMakeFiles/qsqlite3.dir/src/smain.cpp.o /usr/lib/hppa-linux-gnu/libQt5Sql.so.5.15.4 /usr/lib/hppa-linux-gnu/libsqlite3.so /usr/lib/hppa-linux-gnu/libQt5Core.so.5.15.4 /usr/bin/ld: warning: /usr/lib/gcc/hppa-linux-gnu/11/../../../hppa-linux-gnu/crtn.o: missing .note.GNU-stack section implies executable stack /usr/bin/ld: NOTE: This behaviour is deprecated and will be removed in a future version of the linker /usr/bin/ld: warning: ../../bin/sqldrivers/libqsqlite3.so has a LOAD segment with RWX permissions collect2: error: ld returned 1 exit status make[3]: *** [src/qsqlite/CMakeFiles/qsqlite3.dir/build.make:149: bin/sqldrivers/libqsqlite3.so] Error 1 What is best way to transition without causing a lot of disruption? Regards, Dave -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/27442] FAIL: Local ifunc-using executable does not contain R_*_IRELATIVE relocation
https://sourceware.org/bugzilla/show_bug.cgi?id=27442 --- Comment #1 from dave.anglin at bell dot net --- The attached patch fixes the ifunc test fails on hppa*-*-linux-gnu. 1) The regexp in contains_irelative_reloc fails to match upper case letters arising in symbol names. 2) tmpdir/static_prog doesn't contain any relocs on hppa, so I skipped test on hppa. Dave -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/25599] gas generates invalid PCREL60B relocation offset with brl.call
https://sourceware.org/bugzilla/show_bug.cgi?id=25599 --- Comment #16 from dave.anglin at bell dot net --- Thanks for adjusting the comment. It seems the person that wrote the GNU ld code was aware of the ambiguity. I suspect there will be a need to implement the brl instruction in gcc for GNU Linux at some point, so its good to know that linking with it works. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/25599] gas generates invalid PCREL60B relocation offset with brl.call
https://sourceware.org/bugzilla/show_bug.cgi?id=25599 --- Comment #13 from dave.anglin at bell dot net --- On 2021-05-21 12:15 p.m., jvb at cyberscience dot com wrote: > I will test movl, break.x and nop.x. They have operands of 64, 62 and 62 bits, > with very different layout to brl, so PCREL60 won't apply. One potential > candidate is PCREL64 against a movl, I'll see if I can generate and test this > and anything else I can find (it will be next week though). Could you test the testcase with HP assembler and compare with GAS using objdump -r? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/25599] gas generates invalid PCREL60B relocation offset with brl.call
https://sourceware.org/bugzilla/show_bug.cgi?id=25599 --- Comment #12 from dave.anglin at bell dot net --- On 2021-05-21 12:15 p.m., jvb at cyberscience dot com wrote: > Specifying a slot value for a 2 slot instruction + immediate is clearly > ambiguous without further clarification. HP interprets it one way, other > platforms differently. I'd say neither is really right or wrong, it's > unfortunate that there are differences but we're stuck with it now. I agree. On page 3:294 of the architecture, I see that the .mlx template has the X unit instruction in slot 2. However, the IP value used with the immediate is the address of the bundle which contains the current executing instruction (page 1:27). So, the immediate value doesn't depend on slot. But I still think it makes sense to apply the relocation to the X unit instruction as it determines the X3, X4 immediate encoding. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/25599] gas generates invalid PCREL60B relocation offset with brl.call
https://sourceware.org/bugzilla/show_bug.cgi?id=25599 --- Comment #10 from dave.anglin at bell dot net --- I think the test is wrong. The brl instruction is comprised of two instruction slots (L+X). For brl, the imm39 field and a 2-bit Ignored field occupy the L instruction slot. The actual branch instruction is in the second (X) slot. The PCREL relocation needs to be computed relative to this slot, so it makes sense that the relocation would be specified relative to this slot. The psABI says "P" is the address of the bundle containing the instruction. However, the brl instruction was introduced in itanium2 and it uses two instruction slots. I think the other L+X instructions (movl, break.x and nop.x) need checking with the PCREL60B and other relocations involving instruction placement. John, could you look at this? This is failing test: .text .proc foo# foo: .mlx mov r25 = r0 brl.call.sptk.many b0 = bar# .endp foo# I agree comment in the change needs an update. Even if the HP linker is wrong, it's important that we get the brl instruction working on HPUX so that current versions of gcc will build. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/25599] gas generates invalid PCREL60B relocation offset with brl.call
https://sourceware.org/bugzilla/show_bug.cgi?id=25599
--- Comment #5 from dave.anglin at bell dot net ---
Hi John,
Please send change to binutils list with install request. CC Jim Wilson and
myself. Jim is the
expert on ia64 assembly code.
There are some GNU style issues with the change as written. The declaration of
"where"
should be at the start of the block. There should be no space after "(" or
before ")". "where++"
should be on following line. Check white space.
The Debian ia64 Linux port is still active, so I don't think ia64 should be
obsoleted at this time.
After the binutils change is accepted, please submit gcc changes to the gcc
patches list. Please
test change on master if possible.
On 2021-05-17 6:07 a.m., jvb at cyberscience dot com wrote:
> https://sourceware.org/bugzilla/show_bug.cgi?id=25599
>
> John Buddery changed:
>
>What|Removed |Added
>
> CC||jvb at cyberscience dot com
>
> --- Comment #4 from John Buddery ---
> Here's the solution I used to fix the PCREL60B offset for HP:
>
> --- binutils-2.36/gas/config/tc-ia64.c 2021-01-09 10:47:33.0 +
> +++ binutils-2.36-snake/gas/config/tc-ia64.c2021-05-17 10:21:40.651307362
> +0100
> @@ -6892,7 +6892,13 @@
>for (j = 0; j < md.slot[curr].num_fixups; ++j)
> {
> ifix = md.slot[curr].fixup + j;
> - fix = fix_new_exp (frag_now, frag_now_fix () - 16 + i, 8,
> +
> + unsigned long where = frag_now_fix () - 16 + i;
> +#ifdef TE_HPUX
> + if ( ifix->code == BFD_RELOC_IA64_PCREL60B ) where++;
> +#endif
> +
> + fix = fix_new_exp (frag_now, where, 8,
> >expr, ifix->is_pcrel, ifix->code);
> fix->tc_fix_data.opnd = ifix->opnd;
> fix->fx_file = md.slot[curr].src_file;
>
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug ld/27443] FAIL: pr25355.o
https://sourceware.org/bugzilla/show_bug.cgi?id=27443 --- Comment #8 from dave.anglin at bell dot net --- Nope, it was my build setup. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/27443] FAIL: pr25355.o
https://sourceware.org/bugzilla/show_bug.cgi?id=27443 --- Comment #7 from dave.anglin at bell dot net --- It's strange that this fails with Debian gcc-10: gcc version 10.2.1 20210110 (Debian 10.2.1-6) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/27443] FAIL: pr25355.o
https://sourceware.org/bugzilla/show_bug.cgi?id=27443 --- Comment #2 from dave.anglin at bell dot net --- Hi Nick, Attached. Regards, Dave -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26350] FAIL: Multibyte symbol names
https://sourceware.org/bugzilla/show_bug.cgi?id=26350 --- Comment #2 from dave.anglin at bell dot net --- On 2020-08-17 9:23 a.m., nickc at redhat dot com wrote: > Can you investigate a bit more and find out why the regexps are > not matching ? The first problem seems to be the sed at line 1098 in binutils-common.exp is broken when GNU sed is used. Not sure why but using "/usr/bin/sed" results in tmpdir/asm.s not being empty. Then, the readelf dump contains: String dump of section '.strtab': [tx] symbol This seems same problem as in binutils/26349. Dave -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/26359] FAIL: .xstabs
https://sourceware.org/bugzilla/show_bug.cgi?id=26359 --- Comment #3 from dave.anglin at bell dot net --- On 2020-08-13 6:53 a.m., nickc at redhat dot com wrote: > Thanks for reporting this. It was a simple case of trying to create > a debug section when it already existed. Fixed with the applied patch. Thanks Nick. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25327] FAIL: Run pr20276
https://sourceware.org/bugzilla/show_bug.cgi?id=25327 --- Comment #5 from dave.anglin at bell dot net --- On 2020-01-06 5:14 a.m., nickc at redhat dot com wrote: > Is it possible that different versions of gcc are being used for the failing > and passing versions of the tests ? That's it. The fails are with gcc-10 experimental. The tests pass with Debian gcc-9. Dave -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25327] FAIL: Run pr20276
https://sourceware.org/bugzilla/show_bug.cgi?id=25327 --- Comment #3 from dave.anglin at bell dot net --- On 2020-01-04 3:56 p.m., dave.anglin at bell dot net wrote: > https://sourceware.org/bugzilla/show_bug.cgi?id=25327 > > --- Comment #2 from dave.anglin at bell dot net --- > On 2020-01-03 6:33 a.m., nickc at redhat dot com wrote: >> Please could you try out the attached patch and let me know if it works ? > Hi Nick, > > The patch resolves the fail. There's something wierd going on. I did a full build and check with patches for ld/25326 and ld/25327 and the following teats failed: FAIL: Run with libfunc1.so comm1.o FAIL: Run pr20267a FAIL: Run pr20267b I then reran the testsuite and these tests didn't fail. In my first check, I just reran testsuite with patches. Dave -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25327] FAIL: Run pr20276
https://sourceware.org/bugzilla/show_bug.cgi?id=25327 --- Comment #2 from dave.anglin at bell dot net --- On 2020-01-03 6:33 a.m., nickc at redhat dot com wrote: > Please could you try out the attached patch and let me know if it works ? Hi Nick, The patch resolves the fail. Happy New Year, Dave -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25326] FAIL: Run pr19579
https://sourceware.org/bugzilla/show_bug.cgi?id=25326 --- Comment #2 from dave.anglin at bell dot net --- On 2020-01-03 6:41 a.m., nickc at redhat dot com wrote: > Please can you try out the attached patch and let me know if it solves the > problem ? Yes, it resolves the failure. Happy New Year, Dave -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25315] `__tcf_0' referenced in section `.rodata._ZNK6common26ChainResidueAtomDescriptor3strB5cxx11Ev.cst4' of mode_query_balls_distances.o: defined in discarded section `.text.__tcf_0[_ZNK6com
https://sourceware.org/bugzilla/show_bug.cgi?id=25315 --- Comment #14 from dave.anglin at bell dot net --- On 2019-12-30 3:06 p.m., danglin at gcc dot gnu.org wrote: > It would be better if we only ignored deleted PLABEL32 relocations to > discarded > COMDAT functions. Maybe function references could go into their own .rodata and .data sections. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25315] `__tcf_0' referenced in section `.rodata._ZNK6common26ChainResidueAtomDescriptor3strB5cxx11Ev.cst4' of mode_query_balls_distances.o: defined in discarded section `.text.__tcf_0[_ZNK6com
https://sourceware.org/bugzilla/show_bug.cgi?id=25315
--- Comment #6 from dave.anglin at bell dot net ---
On 2019-12-26 8:35 p.m., amodra at gmail dot com wrote:
> https://sourceware.org/bugzilla/show_bug.cgi?id=25315
>
> --- Comment #5 from Alan Modra ---
> Oh, wait a minute. Why are there references to a local symbol in a comdat
> section? That just seems odd. The linker will keep just one of the multiple
> copies of the comdat section but there normally isn't any translation of a
> local symbol in one discarded comdat section to the equivalent local symbol in
> the kept section. Locals are local after all. This has to be a gcc problem.
>
This is how gcc sets up the decl for __tcf_0
start_cleanup_fn (void)
{
char name[32];
tree fntype;
tree fndecl;
bool use_cxa_atexit = flag_use_cxa_atexit
&& !targetm.cxx.use_atexit_for_cxa_atexit ();
push_to_top_level ();
/* No need to mangle this. */
push_lang_context (lang_name_c);
/* Build the name of the function. */
sprintf (name, "__tcf_%d", start_cleanup_cnt++);
/* Build the function declaration. */
fntype = TREE_TYPE (get_atexit_fn_ptr_type ());
fndecl = build_lang_decl (FUNCTION_DECL, get_identifier (name), fntype);
/* It's a function with internal linkage, generated by the
compiler. */
TREE_PUBLIC (fndecl) = 0;
DECL_ARTIFICIAL (fndecl) = 1;
/* Make the function `inline' so that it is only emitted if it is
actually needed. It is unlikely that it will be inlined, since
it is only called via a function pointer, but we avoid unnecessary
emissions this way. */
DECL_DECLARED_INLINE_P (fndecl) = 1;
DECL_INTERFACE_KNOWN (fndecl) = 1;
The TREE_PUBLIC line makes the symbol local but the comment says it should have
internal
linkage.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug ld/25110] FAIL: --gc-sections with __start_SECTIONNAME
https://sourceware.org/bugzilla/show_bug.cgi?id=25110
--- Comment #3 from dave.anglin at bell dot net ---
On 2019-10-16 7:33 a.m., John David Anglin wrote:
> Final executables always need to be linked against the millicode library on
> hppa to provide $$dyncall
> and various arithmetic operations that are implemented in assembly. Seems we
> have lost that in test.
There is this code in ld/testsuite/ld-selective/selective.exp:
# HPPA linux targets need libgcc.a for millicode routines ($$dyncall).
if [istarget hppa*-*-linux*] {
set libgcc [remote_exec host "$compiler -print-libgcc-file-name"]
set libgcc [lindex $libgcc 1]
regsub -all "\[\r\n\]" $libgcc "" libgcc
set objfile "$objfile $libgcc"
}
--
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/25110] FAIL: --gc-sections with __start_SECTIONNAME
https://sourceware.org/bugzilla/show_bug.cgi?id=25110 --- Comment #2 from dave.anglin at bell dot net --- On 2019-10-15 10:23 p.m., amodra at gmail dot com wrote: > Works for me with hppa-linux-gcc (GCC) 8.1.1 20180502 It's probably because I recently changed the optimization of indirect calls in gcc-9 and gcc-10. Gcc no longer converts indirect calls to an inline version of $$dyncall if $$dyncall can be reached with a pc-relative or "ble" branch. Only the long PIC branch to $$dyncall is now optimized into inline versions of $$dyncall. The reason is $$dyncall is slightly shorter and the inline sequences got slightly longer in order to load the branch target before the new PIC register value. The above changes are preliminary to fixing a glibc race in lazy binding. Final executables always need to be linked against the millicode library on hppa to provide $$dyncall and various arithmetic operations that are implemented in assembly. Seems we have lost that in test. -- 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/23837] Segmentation fault in resolve_symbol_value at symbols.c:1165
https://sourceware.org/bugzilla/show_bug.cgi?id=23837 --- Comment #5 from dave.anglin at bell dot net --- On 2018-10-28 1:53 AM, amodra at gmail dot com wrote: > Patch committed fixes the segfault, which was due to setting a bogus symbol > frag in git commit 29e6f4745ec. Thanks Alan! Sorry for messing up. -- 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/23463] FAIL: PR ld/12982
https://sourceware.org/bugzilla/show_bug.cgi?id=23463 --- Comment #5 from dave.anglin at bell dot net --- Hi Nick, On 2018-08-02 4:01 AM, nickc at redhat dot com wrote: >Sorry about that.:-( Would you mind testing this alternative patch >instead please ? I won't check it in unless you say that it is OK... The patch is OK. === ld Summary === # of expected passes 1229 # of expected failures 41 # of untested testcases 1 # of unsupported tests 33 /home/dave/gnu/binutils/objdir/ld/ld-new 2.31.51.20180801 Thanks, Dave -- 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/23463] FAIL: PR ld/12982
https://sourceware.org/bugzilla/show_bug.cgi?id=23463
--- Comment #3 from dave.anglin at bell dot net ---
Hi Nick,
On 2018-08-01 5:02 AM, nickc at redhat dot com wrote:
>I have applied the obvious fix to the pr12982 test for the HPPA target.
The fix didn't work:
Executing on host: sh -c {gcc
-B/home/dave/gnu/binutils/objdir/ld/tmpdir/ld/ -
L=/home/dave/opt/gnu/hppa-unknown-linux-gnu/lib
-L=/home/dave/opt/gnu/lib -L=/us
r/local/lib -L=/lib -L=/usr/lib -o tmpdir/pr12982.exe
-L/home/dave/gnu/binutil
s/src/ld/testsuite/ld-plugin -O2 -flto -fuse-linker-plugin
tmpdir/pr12982.o 2>&1
} /dev/null ld.tmp (timeout = 300)
spawn [open ...]
/home/dave/gnu/binutils/objdir/ld/../binutils/readelf -l --wide
tmpdir/pr12982.e
xe > dump.out
fail if no difference
FAIL: PR ld/12982
Dave
--
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/22758] FAIL: Run pr22393-2
https://sourceware.org/bugzilla/show_bug.cgi?id=22758 --- Comment #2 from dave.anglin at bell dot net --- Hi Nick, On 2018-01-29 9:18 AM, nickc at redhat dot com wrote: >Please could you narrow this down to the linker command line and a tarball >of the object files & libraries involved ? (I do not have easy access to >an hppa based build system). I'll try to look at this as soon as I can. Alan has an account on a hppa-linux system. Dave -- 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/22300] Abort in elf32_hppa_relocate_section at elf32-hppa.c:4055 building debian polyml
https://sourceware.org/bugzilla/show_bug.cgi?id=22300 --- Comment #6 from dave.anglin at bell dot net --- Thanks Alan. That was an excellent bit of debugging. I created a debian bug report for the polyml bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=880023 -- John David Anglin dave.ang...@bell.net -- 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/22300] Abort in elf32_hppa_relocate_section at elf32-hppa.c:4055 building debian polyml
https://sourceware.org/bugzilla/show_bug.cgi?id=22300 --- Comment #3 from dave.anglin at bell dot net --- On 2017-10-15, at 7:57 PM, amodra at gmail dot com wrote: > Have you tried with current HEAD? Same error occurs with current head. Starting program: /home/dave/gnu/binutils/objdir/ld/.libs/ld-new -plugin /usr/lib/gcc/hppa-linux-gnu/7/liblto_plugin.so -plugin-opt=/usr/lib/gcc/hppa-linux-gnu/7/lto-wrapper -plugin-opt=-fresolution=-debug.res -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --sysroot=/ --build-id --eh-frame-hdr -dynamic-linker /lib/ld.so.1 -o .libs/poly /usr/lib/gcc/hppa-linux-gnu/7/../../../hppa-linux-gnu/crt1.o /usr/lib/gcc/hppa-linux-gnu/7/../../../hppa-linux-gnu/crti.o /usr/lib/gcc/hppa-linux-gnu/7/crtbegin.o -L/usr/lib/gcc/hppa-linux-gnu/7 -L/usr/lib/gcc/hppa-linux-gnu/7/../../../hppa-linux-gnu -L/usr/lib/gcc/hppa-linux-gnu/7/../../.. -L/lib/hppa-linux-gnu -L/usr/lib/hppa-linux-gnu --as-needed polyexport.o libpolymain/.libs/libpolymain.a libpolyml/.libs/libpolyml.so -lpthread -lffi -lm -ldl -lstdc++ -lgcc_s -lgcc -v -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/hppa-linux-gnu/7/crtend.o /usr/lib/gcc/hppa-linux-gnu/7/../../../hppa-linux-gnu/crtn.o GNU ld (GNU Binutils) 2.29.51.20171016 /home/dave/gnu/binutils/objdir/ld/.libs/ld-new: BFD (GNU Binutils) 2.29.51.20171016 internal error, aborting at ../../src/bfd/elf32-hppa.c:3937 in elf32_hppa_relocate_section -- John David Anglin dave.ang...@bell.net -- 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/22300] Abort in elf32_hppa_relocate_section at elf32-hppa.c:4055 building debian polyml
https://sourceware.org/bugzilla/show_bug.cgi?id=22300 --- Comment #2 from dave.anglin at bell dot net --- Will check. I thought the debug info that I posted was for the trunk but I see it was for "GNU ld (GNU Binutils) 2.29.51.20170819". -- 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/21132] [hppa-linux] pie support doesn't work
https://sourceware.org/bugzilla/show_bug.cgi?id=21132 --- Comment #13 from dave.anglin at bell dot net --- Excellent. The patch fixes the ffmpeg build which started this excursion. Thus I believe the patch can be committed to trunk and active branches. -- John David Anglin dave.ang...@bell.net -- 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/21132] [hppa-linux] pie support doesn't work
https://sourceware.org/bugzilla/show_bug.cgi?id=21132 --- Comment #4 from dave.anglin at bell dot net --- On 2017-02-14, at 9:41 PM, amodra at gmail dot com wrote: > Now that we do define $global$ in elf32_hppa_set_gp, the DATA_START_SYMBOLS > define should disappear, probably. I'll leave that patch to you, Dave. Okay, I'll test removing it. In the main description, you will see that _start is 0x41000528. It appears that "DATA_ADDR=0x4000" in scripttempl/hppaelf.sc is influencing the position of pie executables. I suspect we need a different value/define for pie. Dave -- John David Anglin dave.ang...@bell.net -- 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/21000] hppa-linux does not support -z relro
https://sourceware.org/bugzilla/show_bug.cgi?id=21000 --- Comment #18 from dave.anglin at bell dot net --- On 2017-02-14, at 1:03 AM, amodra at gmail dot com wrote: > Created attachment 9820 > --> https://sourceware.org/bugzilla/attachment.cgi?id=9820=edit > Implement no_page_alias Thanks Alan. Will test tonight. Dave -- John David Anglin dave.ang...@bell.net -- 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/21000] hppa-linux does not support -z relro
https://sourceware.org/bugzilla/show_bug.cgi?id=21000 --- Comment #16 from dave.anglin at bell dot net --- On 2017-02-12, at 8:34 PM, amodra at gmail dot com wrote: > I obviously didn't understand the alias problem.. If I am grasping it > correctly now, is the complaint about INEQUIVALENT ALIASES really that in the > following load map from a trivial -z relro main.c we have file offsets in the > same page? > > LOAD 0x00 0x0001 0x0001 0x00898 0x00898 R E 0x1000 > LOAD 0x000f20 0x00011f20 0x00011f20 0x0014c 0x0015c RWE 0x1000 I think the issue is easiest to understand by looking at the maps file for the process. For the trivial -z relro main we have dave@mx3210:/proc/19876$ cat maps 0001-00011000 r-xp 08:11 11799480 /home/dave/ffmpeg/main 00011000-00012000 r--p 08:11 11799480 /home/dave/ffmpeg/main 00012000-00013000 rwxp 1000 08:11 11799480 /home/dave/ffmpeg/main f9ffb000-fa167000 r-xp 08:25 33770753 /lib/hppa-linux-gnu/libc-2.24.so fa167000-fa16e000 rwxp 0016c000 08:25 33770753 /lib/hppa-linux-gnu/libc-2.24.so fa16e000-fa17 rwxp 00:00 0 fa3f8000-fa41b000 r-xp 08:25 33710119 /lib/hppa-linux-gnu/ld-2.24.so fa41b000-fa41f000 rwxp 00023000 08:25 33710119 /lib/hppa-linux-gnu/ld-2.24.so fa4fc000-fa501000 rw-p 00:00 0 fa501000-fa523000 rwxp 00:00 0 [stack] Without -z relro, we have dave@mx3210:/proc/25080$ cat maps 0001-00011000 r-xp 08:11 11799480 /home/dave/ffmpeg/main 00011000-00012000 rwxp 1000 08:11 11799480 /home/dave/ffmpeg/main f9ffb000-fa167000 r-xp 08:25 33770753 /lib/hppa-linux-gnu/libc-2.24.so fa167000-fa16e000 rwxp 0016c000 08:25 33770753 /lib/hppa-linux-gnu/libc-2.24.so fa16e000-fa17 rwxp 00:00 0 fa3f8000-fa41b000 r-xp 08:25 33710119 /lib/hppa-linux-gnu/ld-2.24.so fa41b000-fa41f000 rwxp 00023000 08:25 33710119 /lib/hppa-linux-gnu/ld-2.24.so fa4fc000-fa501000 rw-p 00:00 0 fa501000-fa523000 rwxp 00:00 0 [stack] -- John David Anglin dave.ang...@bell.net -- 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/21000] hppa-linux does not support -z relro
https://sourceware.org/bugzilla/show_bug.cgi?id=21000 --- Comment #15 from dave.anglin at bell dot net --- On 2017-02-12, at 8:34 PM, amodra at gmail dot com wrote: > https://sourceware.org/bugzilla/show_bug.cgi?id=21000 > > --- Comment #14 from Alan Modra --- > I obviously didn't understand the alias problem.. If I am grasping it > correctly now, is the complaint about INEQUIVALENT ALIASES really that in the > following load map from a trivial -z relro main.c we have file offsets in the > same page? > > LOAD 0x00 0x0001 0x0001 0x00898 0x00898 R E 0x1000 > LOAD 0x000f20 0x00011f20 0x00011f20 0x0014c 0x0015c RWE 0x1000 Yes, I believe that is correct. I think the file offsets need to be page aligned so that the segments don't overlap when they are mapped to virtual addresses. In a general sense, we can't have two different cache lines mapping to the same location in physical memory, particularly when they are both writeable. This is what we have without the option: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align PHDR 0x34 0x00010034 0x00010034 0x000c0 0x000c0 R E 0x4 INTERP 0xf4 0x000100f4 0x000100f4 0xd 0xd R 0x1 [Requesting program interpreter: /lib/ld.so.1] LOAD 0x00 0x0001 0x0001 0x0094c 0x0094c R E 0x1000 LOAD 0x001000 0x00011000 0x00011000 0x00188 0x00198 RWE 0x1000 DYNAMIC0x001028 0x00011028 0x00011028 0x000d8 0x000d8 RW 0x4 > > In which case the fix for this will involve changing > assign_file_positions_for_load_sections -- John David Anglin dave.ang...@bell.net -- 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/21131] *** Error in `/usr/bin/ld': corrupted double-linked list: 0x00239b48 ***
https://sourceware.org/bugzilla/show_bug.cgi?id=21131 --- Comment #3 from dave.anglin at bell dot net --- On 2017-02-12, at 7:46 PM, amodra at gmail dot com wrote: > I can't build current glibc. I configure with Attached is my current command. I have been configuring with the following: --host=hppa-linux-gnu --build=hppa-linux-gnu --prefix=/usr --without-cvs --enable-add-ons=libidn --without-selinux --enable-stackguard-randomization --enable-obsolete-rpc --enable-pt_chown --with-headers=/usr/include --enable-kernel=2.6.32 --disable-sanity-checks I think the above is more or less how Debian glibc is built. Haven't checked recently however. Had a successful build and check with previous Debian binutils. -- John David Anglin dave.ang...@bell.net -- 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/21131] *** Error in `/usr/bin/ld': corrupted double-linked list: 0x00239b48 ***
https://sourceware.org/bugzilla/show_bug.cgi?id=21131 --- Comment #1 from dave.anglin at bell dot net --- On 2017-02-11, at 5:49 PM, danglin at gcc dot gnu.org wrote: > This is with "GNU ld (GNU Binutils for Debian) 2.27.90.20170205". 2.27.90.20170124-2 was okay. -- John David Anglin dave.ang...@bell.net -- 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/21000] hppa-linux does not support -z relro
https://sourceware.org/bugzilla/show_bug.cgi?id=21000 --- Comment #10 from dave.anglin at bell dot net --- On 2017-01-02, at 8:56 AM, amodra at gmail dot com wrote: > Some of the fails should now be fixed. I trust there were no regressions on a > native build? Incidentally, latest glibc doesn't build on hppa-linux due to > https://sourceware.org/ml/libc-alpha/2016-05/msg00605.html I don't believe there were any regressions. Will retest , I believe the glibc issue must be fixed as I had successful builds in the latter part of last October when I was hacking on it. Happy New Years, Dave -- John David Anglin dave.ang...@bell.net -- 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/21000] hppa-linux does not support -z relro
https://sourceware.org/bugzilla/show_bug.cgi?id=21000 --- Comment #7 from dave.anglin at bell dot net --- On 2016-12-29, at 7:21 PM, John David Anglin wrote: > I'll give your fix a whirl. I should have mentioned that there were no unexpected errors in binutils and gas suites: === binutils Summary === # of expected passes148 # of expected failures 2 # of unsupported tests 4 Dave -- John David Anglin dave.ang...@bell.net -- 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/21000] hppa-linux does not support -z relro
https://sourceware.org/bugzilla/show_bug.cgi?id=21000
--- Comment #6 from dave.anglin at bell dot net ---
On 2016-12-29, at 7:22 PM, dave.anglin at bell dot net wrote:
> I'll give your fix a whirl.
With trunk and your fix, I see the following fails in the ld suite:
FAIL: PIE PR ld/14525
FAIL: Run with libpr18720c.so 1
FAIL: Run with libpr18720c.so 2
FAIL: Run with libpr18720c.so 3
FAIL: Run with libpr18720c.so 4
FAIL: Run with libpr18720c.so 5
FAIL: Build warn libbar.so
FAIL: Run pr2404 with PIE
FAIL: Run pr18718
FAIL: Run pr18718 with PIE (1)
FAIL: Run pr18718 with PIE (2)
FAIL: Run pr18718 with PIC (1)
FAIL: Run pr18718 with PIC (2)
FAIL: Object NOT containing unique does not have an OS/ABI field of System V
FAIL: Executable NOT containing unique does not have an OS/ABI field of System
V
Running: tmpdir/pr14525 > tmpdir/pr14525.out
tmpdir/pr14525: symbol lookup error: tmpdir/pr14525: undefined symbol:
__executable_start
FAIL: PIE PR ld/14525
Running: tmpdir/pr18720a > tmpdir/pr18720a.out
child killed: SIGABRT
FAIL: Run with libpr18720c.so 1
/home/dave/gnu/binutils/objdir/ld/../binutils/readelf -S --wide
tmpdir/libbarw.so > dump.out
readelf: Warning: [14]: Unexpected value (10) in info field.
FAIL: Build warn libbar.so
Running: tmpdir/pr2404pie > tmpdir/pr2404pie.out
child killed: illegal instruction
FAIL: Run pr2404 with PIE
Running: tmpdir/pr18718 > tmpdir/pr18718.out
child killed: SIGABRT
FAIL: Run pr18718
Executing on host: sh -c {/home/dave/gnu/binutils/objdir/ld/ld-new -o
tmpdir/l
ibunique_shared_ref.so -shared tmpdir/unique_shared.o tmpdir/unique_empty.o
2>&1} /dev/null ld.tmp (timeout = 300)
spawn [open ...]
PASS: Checking unique objectPASS: Checking unique executable
FAIL: Object NOT containing unique does not have an OS/ABI field of System V
FAIL: Executable NOT containing unique does not have an OS/ABI field of System
Vtestcase /home/dave/gnu/binutils/src/ld/testsuite/ld-unique/unique.exp
completed
in 4 seconds
Dave
--
John David Anglin dave.ang...@bell.net
--
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/21000] hppa-linux does not support -z relro
https://sourceware.org/bugzilla/show_bug.cgi?id=21000 --- Comment #5 from dave.anglin at bell dot net --- On 2016-12-29, at 7:03 PM, amodra at gmail dot com wrote: > I > gave away my hppa hardware a long time ago. Helge has been testing a user-only target of hppa to qemu being developed by Richard Henderson. It's here: git://github.com/rth7680/qemu.git tgt-hppa Dave -- John David Anglin dave.ang...@bell.net -- 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/21000] hppa-linux does not support -z relro
https://sourceware.org/bugzilla/show_bug.cgi?id=21000
--- Comment #4 from dave.anglin at bell dot net ---
On 2016-12-29, at 6:00 PM, amodra at gmail dot com wrote:
> As far as a fix for this goes, if you're sure that pr12376 isn't really just a
> kernel issue (see https://sourceware.org/bugzilla/show_bug.cgi?id=12376#c8)
> then hppa can still support relro by page aligning data then following that
> with DATA_SEGMENT_ALIGN (${MAXPAGESIZE}, ${COMMONPAGESIZE}). This will waste
> up to 2*MAXPAGESIZE-2 bytes of memory before the start of the relro area, the
> first page for the hardware/kernel issue, the second to align the end of the
> relro area to a page.
The fine print on the aliasing restrictions is described in the PA-RISC 2.0
Architecture manual
starting on page F-5. In practice, this is only a limitation on machines with
PA8800 and PA8900
processors. There is code in pacache.S where we use equivalently mapped pages
in the kernel
for certain operations.
I'll give your fix a whirl.
Dave
--
John David Anglin dave.ang...@bell.net
--
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/21000] hppa-linux does not support -z relro
https://sourceware.org/bugzilla/show_bug.cgi?id=21000 --- Comment #1 from dave.anglin at bell dot net --- Is there a testcase? It seems to me we need to either pad the text or align data to a page boundary to avoid non equivalent aliases. We continue to struggle with this issue on SMP machines in the Linux kernel, so I would be very hesitant to not align data to a page boundary. Happy Holidays, Dave -- John David Anglin dave.ang...@bell.net -- 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 binutils/20464] hppa-linux-gnu-ranlib: libcpp.a: File format not recognized
https://sourceware.org/bugzilla/show_bug.cgi?id=20464 --- Comment #17 from dave.anglin at bell dot net --- On 2016-08-22 9:07 PM, amodra at gmail dot com wrote: > https://sourceware.org/bugzilla/show_bug.cgi?id=20464 > > --- Comment #16 from Alan Modra --- > Ah, mips64 or s390x needed to be added to the target list. > > I think the part of HJ's patch that forces SYM64 archives due to the mere > presence of mips64 or s390x in the --enable-targets list ought to be reverted. That sounds like a good idea. After further consideration, it didn't seem right to break consistency with existing code due to the presence of mips64 or s390x in the --enable-targets list. > As far as I can tell, this won't break mips64 or s390x. If any 64-bit target > actually needs a 64-bit armap due to archive size exceeding 4G, then you'll > get > that. Also, note that binutils-2.25 and binutils-2.26 created archives with > 32-bit armaps for mips64 and s390x if plugins were enabled. Wouldn't this also be possible on 32-bit targets with large file support and why can't these targets support both armaps automatically? Dave -- 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 binutils/20464] hppa-linux-gnu-ranlib: libcpp.a: File format not recognized
https://sourceware.org/bugzilla/show_bug.cgi?id=20464 --- Comment #15 from dave.anglin at bell dot net --- On 2016-08-22 6:51 AM, nickc at redhat dot com wrote: > Alternatively you could configure the non multi-arch Debian binutils with > "--enable-64-bit-archive=yes" and then all of your supported targets will be > using 64-bit archives and everyone should be happy. Well apart from people > who > care about disk usage of course. Probably this is the best alternative if 32-bit archives are still supported by ranlib, etc. Dave -- 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 binutils/20464] hppa-linux-gnu-ranlib: libcpp.a: File format not recognized
https://sourceware.org/bugzilla/show_bug.cgi?id=20464 --- Comment #13 from dave.anglin at bell dot net --- On 2016-08-22 10:54 AM, dave.anglin at bell dot net wrote: > https://sourceware.org/bugzilla/show_bug.cgi?id=20464 > > --- Comment #12 from dave.anglin at bell dot net --- > On 2016-08-22 10:34 AM, dave.anglin at bell dot net wrote: >> If this is a Debian configuration issue, please close bug. > Maybe "--enable-64-bit-bfd". Still the question remains as to why a 64-bit was created for hppa-linux-gnu. There were various mips64 targets in the --enable-targets list in the multiarch build. I could see 64-bit BFD support might be needed for these. It looks like --enable-64-bit-bfd is implicitly enabled and affects creation of 32-bit archives. Dave -- 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 binutils/20464] hppa-linux-gnu-ranlib: libcpp.a: File format not recognized
https://sourceware.org/bugzilla/show_bug.cgi?id=20464 --- Comment #12 from dave.anglin at bell dot net --- On 2016-08-22 10:34 AM, dave.anglin at bell dot net wrote: > If this is a Debian configuration issue, please close bug. Maybe "--enable-64-bit-bfd". Dave -- 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 binutils/20464] hppa-linux-gnu-ranlib: libcpp.a: File format not recognized
https://sourceware.org/bugzilla/show_bug.cgi?id=20464 --- Comment #11 from dave.anglin at bell dot net --- On 2016-08-22 6:16 AM, nickc at redhat dot com wrote: > It still seems to me that this is a Debian specific problem. Or at least I > have not found any way of reproducing this problem on my x86_64 Fedora based > host machine. Looking at the archive that I uploaded, I see with od: 000 ! < a r c h > \n / S Y M 6 4 / 020 1 4 7 1 1 8 5 3 I think the "SYM64" implies that the archive is a 64-bit archive map format (Irix 6). This is likely the cause of the incompatibility between the standard 32-bit archive used on all hppa targets and the Debian binutils-multiarch. Looked at an hppa64-hpux archive it didn't have "SYM64". If this is a Debian configuration issue, please close bug. Dave -- 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 binutils/20464] hppa-linux-gnu-ranlib: libcpp.a: File format not recognized
https://sourceware.org/bugzilla/show_bug.cgi?id=20464 --- Comment #9 from dave.anglin at bell dot net --- On 2016-08-19, at 10:05 AM, nickc at redhat dot com wrote: > I see that 834253 has now been closed, so can this PR be closed too ? Applied fix for 834253 was only a partial fix. Dave -- John David Anglin dave.ang...@bell.net -- 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 binutils/20464] hppa-linux-gnu-ranlib: libcpp.a: File format not recognized
https://sourceware.org/bugzilla/show_bug.cgi?id=20464 --- Comment #8 from dave.anglin at bell dot net --- On 2016-08-19 10:05 AM, nickc at redhat dot com wrote: > This is Debian bug #834253: >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=834253 >> The error only occurs with binutils-multiarch installed. > Does this mean that this was a Debian specific bug ? > > I see that 834253 has now been closed, so can this PR be closed too ? Probably, but I can't test until this evening and I don't fully understand why ar and hppa-linux-gnu-ar were not inter operable for native archives. Mattias probably could explain why it was necesary to divert triplet-prefixed names. Dave -- 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 binutils/20464] hppa-linux-gnu-ranlib: libcpp.a: File format not recognized
https://sourceware.org/bugzilla/show_bug.cgi?id=20464 --- Comment #6 from dave.anglin at bell dot net --- On 2016-08-14, at 7:39 PM, amodra at gmail dot com wrote: > How was the failing binutils configured? This is Debian bug #834253: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=834253 The error only occurs with binutils-multiarch installed. -- John David Anglin dave.ang...@bell.net -- 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 binutils/20464] hppa-linux-gnu-ranlib: libcpp.a: File format not recognized
https://sourceware.org/bugzilla/show_bug.cgi?id=20464 --- Comment #5 from dave.anglin at bell dot net --- > How was the failing binutils configured? Please attach an example of an > archive showing the failure. Attached example. -- John David Anglin dave.ang...@bell.net -- 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 binutils/20464] hppa-linux-gnu-ranlib: libcpp.a: File format not recognized
https://sourceware.org/bugzilla/show_bug.cgi?id=20464 --- Comment #4 from dave.anglin at bell dot net --- On 2016-08-14 7:39 PM, amodra at gmail dot com wrote: > How was the failing binutils configured? Please attach an example of an > archive showing the failure. Here is a Debian build log: https://buildd.debian.org/status/fetch.php?pkg=binutils=hppa=2.27-5=1471006182 Will attach archive when I get home this evening. I also see failure with simpler configuration. With "objdump -a", I see that the objects in the archive are all elf32-hppa as expected. Dave -- 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/19526] Using "gcc -o /dev/null" gives "ld: final link failed: File truncated" error
https://sourceware.org/bugzilla/show_bug.cgi?id=19526 --- Comment #9 from dave.anglin at bell dot net --- On 2016-01-30, at 1:14 PM, John David Anglin wrote: > It seems to me we either have to match x86 behaviour, or the linker should > not allow writing > to a non-regular file. Something like to the following can check if the output file is a regular file. Various stat errors could also be reported. I'm not sure how portable this is. Dave -- John David Anglin dave.ang...@bell.net -- 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/19526] Using "gcc -o /dev/null" gives "ld: final link failed: File truncated" error
https://sourceware.org/bugzilla/show_bug.cgi?id=19526
--- Comment #8 from dave.anglin at bell dot net ---
On 2016-01-30, at 8:51 AM, sch...@linux-m68k.org wrote:
> https://sourceware.org/bugzilla/show_bug.cgi?id=19526
>
> --- Comment #7 from Andreas Schwab <sch...@linux-m68k.org> ---
> The linker should not allow writing the output to a non-regular file in the
> first place. Changing the behaviour depending on the type of output file
> would
> be wrong.
Currently in bfd/opncls.c, there is the following code
if (abfd->direction == write_direction
&& (abfd->flags & (EXEC_P | DYNAMIC)) != 0)
{
struct stat buf;
if (stat (abfd->filename, ) == 0
/* Do not attempt to change non-regular files. This is
here especially for configure scripts and kernel builds
which run tests with "ld [...] -o /dev/null". */
&& S_ISREG(buf.st_mode))
{
unsigned int mask = umask (0);
umask (mask);
chmod (abfd->filename,
(0777
& (buf.st_mode | ((S_IXUSR | S_IXGRP | S_IXOTH) &~ mask;
}
}
to support "ld [...] -o /dev/null".
It seems to me we either have to match x86 behaviour, or the linker should not
allow writing
to a non-regular file.
Dave
--
John David Anglin dave.ang...@bell.net
--
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/19526] Using "gcc -o /dev/null" gives "ld: final link failed: File truncated" error
https://sourceware.org/bugzilla/show_bug.cgi?id=19526 --- Comment #2 from dave.anglin at bell dot net --- On 2016-01-29 4:17 PM, deller at gmx dot de wrote: > https://sourceware.org/bugzilla/show_bug.cgi?id=19526 > > --- Comment #1 from Helge Deller --- > The debian "libbsd" package fails because of the same issue: > > gcc -isystem ../include/bsd -I.. -include ../config.h > -DLIBBSD_DISABLE_DEPRECATED -D__REENTRANT -DLIBBSD_OVERLAY > headers-overlay-gen.c -o /dev/null > /usr/bin/ld: final link failed: File truncated > collect2: error: ld returned 1 exit status > FAIL headers-overlay.sh (exit status: 1) > > Full log: > https://buildd.debian.org/status/fetch.php?pkg=libbsd=hppa=0.8.2-1=1453935236 > I have built a debug version of binutils. I'll see if I can find problem this weekend. Dave -- 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/19526] Using "gcc -o /dev/null" gives "ld: final link failed: File truncated" error
https://sourceware.org/bugzilla/show_bug.cgi?id=19526
--- Comment #3 from dave.anglin at bell dot net ---
It's not necessary to use a pipe to duplicate. I created a file xxx.c with
'int main(){}' and
compiled with -save-temps and -Wl,-debug to get the actual link command. Here
is backtrace
for bfd_error_file_truncated:
Breakpoint 4, bfd_set_error (error_tag=724328) at ../../src/bfd/bfd.c:511
511 va_start (ap, error_tag);
(gdb) step
503 {
(gdb)
504 bfd_error = error_tag;
(gdb)
505 if (error_tag == bfd_error_on_input)
(gdb) p bfd_error
$3 = bfd_error_file_truncated
(gdb) bt
#0 bfd_set_error (error_tag=bfd_error_file_truncated)
at ../../src/bfd/bfd.c:505
#1 0xfd1ade30 in cache_bread_1 (abfd=0xaecb0, buf=0x257978, nbytes=256)
at ../../src/bfd/cache.c:347
#2 0xfd1adf60 in cache_bread (abfd=0xaecb0, buf=0x257978, nbytes=256)
at ../../src/bfd/cache.c:368
#3 0xfd1ac17c in bfd_bread (ptr=0x257978, size=256, abfd=0xaecb0)
at ../../src/bfd/bfdio.c:196
#4 0xfd1b6000 in _bfd_generic_get_section_contents (abfd=0xaecb0,
section=0xb0850, location=0x257978, offset=0, count=256)
at ../../src/bfd/libbfd.c:812
#5 0xfd1ca458 in bfd_get_section_contents (abfd=0xaecb0, section=0xb0850,
location=0x257978, offset=0, count=256) at ../../src/bfd/section.c:1619
#6 0xfd1af8c4 in bfd_get_full_section_contents (abfd=0xaecb0, sec=0xb0850,
ptr=0xfd7034d0) at ../../src/bfd/compress.c:253
#7 0xfd1ca4d8 in bfd_malloc_and_get_section (abfd=0xaecb0, sec=0xb0850,
buf=0xfd7034d0) at ../../src/bfd/section.c:1640
#8 0xfd1ddb4c in elf_hppa_sort_unwind (abfd=0xaecb0)
at ../../src/bfd/elf-hppa.h:1196
#9 0xfd1e6030 in elf32_hppa_final_link (abfd=0xaecb0,
info=0x9f5b0 ) at ../../src/bfd/elf32-hppa.c:3257
#10 0x00049010 in ldwrite () at ../../src/ld/ldwrite.c:581
#11 0x00043bd8 in main (argc=38, argv=0xfd70302c) at ../../src/ld/ldmain.c:430
(gdb) frame 8
#8 0xfd1ddb4c in elf_hppa_sort_unwind (abfd=0xaecb0)
at ../../src/bfd/elf-hppa.h:1196
1196 if (!bfd_malloc_and_get_section (abfd, s, ))
(gdb) p *abfd
$4 = {filename = 0xb0d58 "/dev/null",
xvec = 0xfd2d07b8 , iostream = 0xb0d68,
iovec = 0xfd2c90a0 , lru_prev = 0xc5738, lru_next = 0x118568,
where = 2228, mtime = 0, id = 0, format = bfd_object,
direction = write_direction, flags = 386, cacheable = 1,
target_defaulted = 0, opened_once = 1, mtime_set = 0, no_export = 0,
output_has_begun = 1, has_armap = 0, is_thin_archive = 0,
selective_search = 0, is_linker_output = 1, is_linker_input = 0,
plugin_format = bfd_plugin_uknown, lto_output = 0, plugin_dummy_bfd = 0x0,
origin = 0, proxy_origin = 0, section_htab = {table = 0x232490,
newfunc = @0xfd42031e: 0xfd1c8b08 ,
memory = 0xafd60, size = 61, count = 31, entsize = 184, frozen = 0},
sections = 0xafdc0, section_last = 0x232878, section_count = 27,
archive_pass = 0, start_address = 66496, outsymbols = 0x0, symcount = 93,
dynsymcount = 0, arch_info = 0xfd2d1140 , arelt_data = 0x0,
my_archive = 0x0, archive_next = 0x0, archive_head = 0x0,
nested_archives = 0x0, link = {next = 0xb0ed0, hash = 0xb0ed0}, tdata = {
aout_data = 0xaed80, aout_ar_data = 0xaed80, oasys_obj_data = 0xaed80,
oasys_ar_data = 0xaed80, coff_obj_data = 0xaed80, pe_obj_data = 0xaed80,
xcoff_obj_data = 0xaed80, ecoff_obj_data = 0xaed80, ieee_data = 0xaed80,
ieee_ar_data = 0xaed80, srec_data = 0xaed80, verilog_data = 0xaed80,
ihex_data = 0xaed80, tekhex_data = 0xaed80, elf_obj_data = 0xaed80,
nlm_obj_data = 0xaed80, bout_data = 0xaed80, mmo_data = 0xaed80,
sun_core_data = 0xaed80, sco5_core_data = 0xaed80,
trad_core_data = 0xaed80, som_data = 0xaed80, hpux_core_data = 0xaed80,
hppabsd_core_data = 0xaed80, sgi_core_data = 0xaed80,
lynx_core_data = 0xaed80, osf_core_data = 0xaed80,
cisco_core_data = 0xaed80, versados_data = 0xaed80,
netbsd_core_data = 0xaed80, mach_o_data = 0xaed80,
mach_o_fat_data = 0xaed80, plugin_data = 0xaed80, pef_data = 0xaed80,
pef_xlib_data = 0xaed80, sym_data = 0xaed80, any = 0xaed80},
usrdata = 0x0, memory = 0xaed68, build_id = 0x0}
Maybe skipping sort when filename is "/dev/null" will fix.
Is there a better test?
Dave
--
John David Anglin dave.ang...@bell.net
--
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/19526] Using "gcc -o /dev/null" gives "ld: final link failed: File truncated" error
https://sourceware.org/bugzilla/show_bug.cgi?id=19526 --- Comment #4 from dave.anglin at bell dot net --- On 2016-01-29, at 9:05 PM, John David Anglin wrote: > Maybe skipping sort when filename is "/dev/null" will fix. Untested fix. -- John David Anglin dave.ang...@bell.net -- 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/18427] GNU as slow on hppa architecture
https://sourceware.org/bugzilla/show_bug.cgi?id=18427 --- Comment #8 from dave.anglin at bell dot net --- On 6/8/2015 6:19 AM, nickc at redhat dot com wrote: Your patch is approved - please apply it when you have the time. Are there guidelines for git commits somewhere? I'll give this a try tonight. Regards, Dave -- 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/18427] GNU as slow on hppa architecture
https://sourceware.org/bugzilla/show_bug.cgi?id=18427
--- Comment #6 from dave.anglin at bell dot net ---
Hi Nick,
On 2015-06-01 4:01 AM, nickc at redhat dot com wrote:
https://sourceware.org/bugzilla/show_bug.cgi?id=18427
--- Comment #5 from Nick Clifton nickc at redhat dot com ---
Hi Dave,
Thanks for helping with this change.
I'm not sure about the option. Alpha has somewhat similar code without
an option.
As I understand it, this code is to handle a number of instructions
which require a preceding
label. It usually emitted on the previous line. It seems to me that
changing segments between
the label and its related instruction should be an error. I don't think
this feature is needed
even for the HP-UX SOM target.
I will check whether GCC needs this for SOM.
OK - thanks. If you can confirm that support for this behaviour is no
longer needed then I will be happy to go with the simpler patch. (Or
maybe the simpler one + an error message if the preceding label cannot
be found). I just did not want to break anybody's builds because of a
speed optimization,
Attached is a change to implement the above handling for the last label.
The gas testsuite for the hpux SOM target is clean. There are four
fails with 64-bit
hpux ELF target. None of these appear related to the change. Haven't
tested linux yet.
The 64-bit gas fails are:
FAIL: gas/all/none
FAIL: Multibyte symbol names
FAIL: weak and common directives
FAIL: common and weak directives
The latter two are caused by the behavior of the .comm directive. These
two would pass
with foobar label before the .comm.
We have for gas/all/none:
# ../as-new -o dump.o none.s
# /opt/gnu64/bin/objdump -r -w dump.o
dump.o: file format elf64-hppa
RELOCATION RECORDS FOR [.text]:
OFFSET TYPE VALUE
R_PARISC_PCREL64 *ABS*
We have for Multibyte symbol names:
# ../as-new -o dump.o syms.s
# /opt/gnu64/bin/readelf -S -s -p .strtab dump.o
There are 8 section headers, starting at offset 0x120:
Section Headers:
[Nr] Name Type Address Offset
Size EntSize Flags Link Info Align
[ 0] NULL
0 0 0
[ 1] .text PROGBITS 0040
AX 0 0 1
[ 2] .data PROGBITS 0040
WA 0 0 1
[ 3] .bss NOBITS 0040
WA 0 0 1
[ 4] sec▒▒tion PROGBITS 0040
0009 0 0 1
[ 5] .shstrtab STRTAB 00ea
0036 0 0 1
[ 6] .symtab SYMTAB 0050
0090 0018 7 6 8
[ 7] .strtab STRTAB 00e0
000a 0 0 1
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings)
I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown)
O (extra OS processing required) o (OS specific), p (processor specific)
Symbol table '.symtab' contains 6 entries:
Num:Value Size TypeBind Vis Ndx Name
0: 0 NOTYPE LOCAL DEFAULT UND
1: 0 SECTION LOCAL DEFAULT1
2: 0 SECTION LOCAL DEFAULT2
3: 0 SECTION LOCAL DEFAULT3
4: 0 SECTION LOCAL DEFAULT4
5: 0 NOTYPE LOCAL DEFAULT4 sy▒▒mbol
String dump of section '.strtab':
[tx] sy▒▒mbol
Dave
--
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/18427] GNU as slow on hppa architecture
https://sourceware.org/bugzilla/show_bug.cgi?id=18427 --- Comment #4 from dave.anglin at bell dot net --- On 2015-05-29 12:20 PM, nickc at redhat dot com wrote: I dislike the idea of disabling code that might actually be needed in some circumstances. So how about this alternative patch ? It extends David's patch by adding a command line option: --enable-multi-seg-support. If this option is used the old, slow, searching code is used. Otherwise the default action is to use the new, faster search code. Hi Nick, Thanks for helping with this change. I'm not sure about the option. Alpha has somewhat similar code without an option. As I understand it, this code is to handle a number of instructions which require a preceding label. It usually emitted on the previous line. It seems to me that changing segments between the label and its related instruction should be an error. I don't think this feature is needed even for the HP-UX SOM target. I will check whether GCC needs this for SOM. Dave -- 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/18427] GNU as slow on hppa architecture
https://sourceware.org/bugzilla/show_bug.cgi?id=18427 --- Comment #2 from dave.anglin at bell dot net --- On 2015-05-18, at 3:15 PM, deller at gmx dot de wrote: So, the pa_undefine_label() function seems problematic. I talked to Dave Anglin about that issue, and he came up with the attached patch. This patch seems to work and speeds up gas a lot, but it will most likely break HP-UX (which uses multiple segments). Actually, ELF targets such as Linux have multiple segments. Assembly time blows up when -ffunction-sections and -fdata-sections are used. The lists for each segment are poorly managed, so both the number of lists and their length grows. All this overhead is to find the previous label emitted in the current space/segment. In practice, GCC never plays with spaces/segments between emitting the label and its associated instruction. So, the previous label is what's needed. The tracking is for hand crafted assembly code. The patch doesn't affect 32-bit HP-UX SOM. The patch might affect 64-bit HP-UX. I haven't tried it on 64-bit HP-UX. -- John David Anglin dave.ang...@bell.net -- 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/18421] hppa/parisc ld: read-only segment has dynamic relocations
https://sourceware.org/bugzilla/show_bug.cgi?id=18421
--- Comment #4 from dave.anglin at bell dot net ---
On 2015-05-16, at 7:05 AM, deller at gmx dot de wrote:
Output of:
readelf -r conftest
Relocation section '.rela.PARISC.unwind' at offset 0x140 contains 2 entries:
Offset InfoTypeSym.Value Sym. Name + Addend
0131 R_PARISC_SEGREL32 .text + 0
0004 0131 R_PARISC_SEGREL32 .text + 18
Possibly, this has to do with following lines in emulparams/hppalinux.sh:
OTHER_READONLY_SECTIONS=
.PARISC.unwind ${RELOCATING-0} : { *(.PARISC.unwind) }
--
John David Anglin dave.ang...@bell.net
--
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 binutils/17840] [2.25 Regression] ar creates archives with incorrect LST system_id and magic
https://sourceware.org/bugzilla/show_bug.cgi?id=17840 --- Comment #3 from dave.anglin at bell dot net --- On 2015-01-13, at 7:18 PM, amodra at gmail dot com wrote: I'll bet that building with --disable-plugins cures this problem The problem is plugins.m4 sets maybe_plugins=yes based on the presence of dlfcn.h. However, this header is not applicable to 32-bit hpux targets (only 64-bit). dlopen is only available on hppa64. Dave -- John David Anglin dave.ang...@bell.net -- 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 binutils/17840] [2.25 Regression] ar creates archives with incorrect LST system_id and magic
https://sourceware.org/bugzilla/show_bug.cgi?id=17840 --- Comment #2 from dave.anglin at bell dot net --- On 2015-01-13, at 7:18 PM, amodra at gmail dot com wrote: I'll bet that building with --disable-plugins cures this problem Remind me not to play poker with you... Problem goes away with --disable-plugins. -- John David Anglindave.ang...@bell.net -- 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 binutils/14779] readelf.c:403:3: error: unknown type name 'mbstate_t'
http://sourceware.org/bugzilla/show_bug.cgi?id=14779 --- Comment #4 from dave.anglin at bell dot net 2012-10-30 18:05:55 UTC --- Hi Nick, On 10/30/2012 8:03 AM, nickc at redhat dot com wrote: Please could you try out the uploaded patch and let me know if it works for you. The patch works fine. I'm going to retest removing --disable-werror. Think there are a couple of unrelated warnings that need fixing. Thanks, Dave -- 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 binutils/14779] readelf.c:403:3: error: unknown type name 'mbstate_t'
http://sourceware.org/bugzilla/show_bug.cgi?id=14779 --- Comment #5 from dave.anglin at bell dot net 2012-10-30 22:59:15 UTC --- On 30-Oct-12, at 8:45 AM, cvs-commit at gcc dot gnu.org wrote: binutils: PR binutils/14779 * configure.in: Add checks for wchar.h and mbstate_t. * config.in: Regenerate. * configure: Regenerate. * readelf.c: Conditionally include wchar.h. (print_symbol): Conditionally use mbstate_t. Bug is also present in 2.23. -- John David Anglindave.ang...@bell.net -- 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 binutils/13476] Incorrect TLS relocations created in DSOs on hppa
http://sourceware.org/bugzilla/show_bug.cgi?id=13476 --- Comment #4 from dave.anglin at bell dot net 2011-12-08 11:54:44 UTC --- On 8-Dec-11, at 2:43 AM, skrll at netbsd dot org wrote: --- Comment #3 from Nick Hudson skrll at netbsd dot org 2011-12-08 07:43:50 UTC --- To hopefully show the bug clearer here's some more output. I believe that I have a patch. Will send when it has some testing. Dave -- John David Anglindave.ang...@bell.net -- 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 binutils/13476] Incorrect TLS relocations created in DSOs on hppa
http://sourceware.org/bugzilla/show_bug.cgi?id=13476 --- Comment #5 from dave.anglin at bell dot net 2011-12-08 15:06:37 UTC --- Could you try the attached change? The PIC TLS relocs are now only changed to dp relative when !info-shared. I looked briefly at this case this morning and it seems to work. However, there are some subtle aspects to this. Dave -- 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
