[Bug gas/32624] broken heuristics in R_386_GOT32{,X} handling
https://sourceware.org/bugzilla/show_bug.cgi?id=32624 --- Comment #5 from H.J. Lu --- (In reply to Jan Beulich from comment #4) > Created attachment 15909 [details] > annotated source file > > See commentary in there. Is there anything else you need? This is what I got: [hjl@gnu-tgl-3 pr32624]$ cat x.s .text .global _start .allow_index_reg _start: lea got32@got, %eax lea got32@got(,%eiz), %eax add got32@got, %eax add got32@got(,%eiz), %eax btl $31, got32@got btl $31, got32@got(,%eiz) vpermb got32@got, %zmm1, %zmm0 vpermb got32@got(,%eiz), %zmm1, %zmm0 ret .data .p2align 4 got32: .long 0x058d058d, got32@got .long 0x058c058c, got32@got .long got32+0x0500, got32@got [hjl@gnu-tgl-3 pr32624]$ make x.o as -mx86-used-note=no -mrelax-relocations=yes --32 -o x.o x.s [hjl@gnu-tgl-3 pr32624]$ readelf -r x.o Relocation section '.rel.text' at offset 0x104 contains 8 entries: Offset InfoTypeSym.Value Sym. Name 0002 0203 R_386_GOT32 got32 0009 0203 R_386_GOT32 got32 000f 022b R_386_GOT32X got32 0016 0203 R_386_GOT32 got32 001d 0203 R_386_GOT32 got32 0026 0203 R_386_GOT32 got32 0031 0203 R_386_GOT32 got32 003c 0203 R_386_GOT32 got32 Relocation section '.rel.data' at offset 0x144 contains 4 entries: Offset InfoTypeSym.Value Sym. Name 0004 0203 R_386_GOT32 got32 000c 0203 R_386_GOT32 got32 0010 0101 R_386_32 .data 0014 0203 R_386_GOT32 got32 [hjl@gnu-tgl-3 pr32624]$ objdump -dwr x.o x.o: file format elf32-i386 Disassembly of section .text: <_start>: 0: 8d 05 00 00 00 00 lea0x0,%eax 2: R_386_GOT32 got32 6: 8d 04 25 00 00 00 00lea0x0(,%eiz,1),%eax9: R_386_GOT32 got32 d: 03 05 00 00 00 00 add0x0,%eax f: R_386_GOT32X got32 13: 03 04 25 00 00 00 00add0x0(,%eiz,1),%eax16: R_386_GOT32got32 1a: 0f ba 25 00 00 00 00 1f btl$0x1f,0x01d: R_386_GOT32got32 22: 0f ba 24 25 00 00 00 00 1f btl$0x1f,0x0(,%eiz,1) 26: R_386_GOT32 got32 2b: 62 f2 75 48 8d 05 00 00 00 00 vpermb 0x0,%zmm1,%zmm0 31: R_386_GOT32got32 35: 62 f2 75 48 8d 04 25 00 00 00 00vpermb 0x0(,%eiz,1),%zmm1,%zmm03c: R_386_GOT32 got32 40: c3 ret [hjl@gnu-tgl-3 pr32624]$ make ./ld -m elf_i386 -z norelro -z nomemory-seal -o x x.o objdump -dw x x: file format elf32-i386 Disassembly of section .text: 08048074 <_start>: 8048074: 8d 05 fc ff ff ff lea0xfffc,%eax 804807a: 8d 04 25 00 90 04 08lea0x8049000(,%eiz,1),%eax 8048081: 81 c0 10 90 04 08 add$0x8049010,%eax 8048087: 03 04 25 00 90 04 08add0x8049000(,%eiz,1),%eax 804808e: 0f ba 25 00 90 04 08 1f btl$0x1f,0x8049000 8048096: 0f ba 24 25 00 90 04 08 1f btl$0x1f,0x8049000(,%eiz,1) 804809f: 62 f2 75 48 8d 05 fc ff ff ff vpermb 0xfffc,%zmm1,%zmm0 80480a9: 62 f2 75 48 8d 04 25 00 90 04 08vpermb 0x8049000(,%eiz,1),%zmm1,%zmm0 80480b4: c3 ret [hjl@gnu-tgl-3 pr32624]$ Where are the errors? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/32591] undue GOTPCREL relaxation attempts
https://sourceware.org/bugzilla/show_bug.cgi?id=32591 --- Comment #15 from H.J. Lu --- (In reply to Jan Beulich from comment #14) > (In reply to H.J. Lu from comment #13) > > I created a testcase which generates a linker error > > > > failed to convert GOTPCREL relocation against '__stack_chk_guard'; relink > > with --no-relax > > > > similar to > > > > https://lists.xenproject.org/archives/html/xen-devel/2024-12/msg00630.html > > > > based on the xen linker script, xen/arch/x86/xen.lds. My patch works. > > It doesn't on full Xen. As expected I see > > ASSERT(!SIZEOF(.got), ".got non-empty") GOT is used to access local symbol beyond 4GB. Xen can disallow run-time relocations in GOT. But GOT won't be empty. Xen needs to deal with it if it wants to access the local stack protector symbol. > triggering. I wonder whether you actually copied that when deriving the > linker script from Xen's. I used section layout in Xen's linker script to have local symbol beyond 4GB. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/32624] broken heuristics in R_386_GOT32{,X} handling
https://sourceware.org/bugzilla/show_bug.cgi?id=32624 --- Comment #3 from Jan Beulich --- (In reply to H.J. Lu from comment #2) > If you google "i386 psABI", you should find an entry: > > x86 psABIs > > System V Application Binary Interface Processor Supplements for i386 and > x86-64. I did find this. Under https://gitlab.com/x86-psABIs/i386-ABI both abi.tex and object-files.tex pretty clearly describe the x86-64 ABI, though (an older version thereof, maybe). README.md looks to confirm this, too. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/32624] broken heuristics in R_386_GOT32{,X} handling
https://sourceware.org/bugzilla/show_bug.cgi?id=32624 --- Comment #4 from Jan Beulich --- Created attachment 15909 --> https://sourceware.org/bugzilla/attachment.cgi?id=15909&action=edit annotated source file See commentary in there. Is there anything else you need? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/32591] undue GOTPCREL relaxation attempts
https://sourceware.org/bugzilla/show_bug.cgi?id=32591 Jan Beulich changed: What|Removed |Added Status|WAITING |NEW --- Comment #14 from Jan Beulich --- (In reply to H.J. Lu from comment #13) > I created a testcase which generates a linker error > > failed to convert GOTPCREL relocation against '__stack_chk_guard'; relink > with --no-relax > > similar to > > https://lists.xenproject.org/archives/html/xen-devel/2024-12/msg00630.html > > based on the xen linker script, xen/arch/x86/xen.lds. My patch works. It doesn't on full Xen. As expected I see ASSERT(!SIZEOF(.got), ".got non-empty") triggering. I wonder whether you actually copied that when deriving the linker script from Xen's. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/29004] various bugs in RISCV version of as
https://sourceware.org/bugzilla/show_bug.cgi?id=29004 --- Comment #4 from Andreas Schwab --- .macro HEADER name, code _header_\name: .set link\@, link .int link\@ # the header has a pointer to the preceding entry .set link, _header_\name .ascii "\name" # and the name of the word .int \code # and a pointer to its function body .endm -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/29004] various bugs in RISCV version of as
https://sourceware.org/bugzilla/show_bug.cgi?id=29004 remuladgryta changed: What|Removed |Added CC||foss at remuladgryta dot se --- Comment #3 from remuladgryta --- (In reply to Nelson Chu from comment #2) > > Not sure what's . fails mean. I can get the same symbol value 8 for > _thread, when using . and 9f: > > % cat tmp.s > .macro _header_ name, cfa > .section .data# assemble into head space > .quad _thread > .set _thread, . > 8: # address to link next word header against > .string "\name" > .set lex, 0 > .quad \cfa# point header at new words cfa > .previous # assemble into list space > .endm > > _header_ A, B > % riscv64-unknown-elf-as -mno-arch-attr tmp.s -o tmp.o > % riscv64-unknown-elf-readelf -Ws tmp.o > > Symbol table '.symtab' contains 7 entries: >Num:Value Size TypeBind Vis Ndx Name > 0: 0 NOTYPE LOCAL DEFAULT UND > 1: 0 SECTION LOCAL DEFAULT1 .text > 2: 0 SECTION LOCAL DEFAULT2 .data > 3: 0 SECTION LOCAL DEFAULT4 .bss > 4: 0008 0 NOTYPE LOCAL DEFAULT2 _thread > 5: 0 NOTYPE LOCAL DEFAULT ABS lex > 6: 0 NOTYPE GLOBAL DEFAULT UND B > I recently ran into this issue while porting a FORTH implementation to RISC-V (it looks like OP was doing the same, cfa is a FORTH acronym for code field address). The first invocation of the macro is fine, but it blows up on subsequent invocations: % cat tmp.s # In FORTH, functions (words) are stored in a linked-list dictionary. # A dictionary entry is typically a header followed by the function body. # The FORTH VM keeps track of the most recently defined word so that words # can be looked up by name at runtime by walking the dictionary. .set link, 0 .macro HEADER name, code _header_\name: .int link # the header has a pointer to the preceding entry .set link, _header_\name .ascii "\name" # and the name of the word .int \code # and a pointer to its function body .endm HEADER FOO, code_FOO code_FOO: nop # code body of the word FOO HEADER BAR, code_BAR code_BAR: nop # code body of the word BAR # some words are aliases or have other special semantics, # so machine code doesn't always follow the header HEADER BAZ, code_BAR % riscv64-unknown-elf-as tmp.s -o tmp.o tmp.s: Assembler messages: tmp.s:19: Error: redefined symbol cannot be used on reloc tmp.s:25: Error: redefined symbol cannot be used on reloc The same file does assemble using, say, x86_64-linux-gnu-as: % x86_64-linux-gnu-readelf -Ws tmp.o Symbol table '.symtab' contains 8 entries: Num:Value Size TypeBind Vis Ndx Name 0: 0 NOTYPE LOCAL DEFAULT UND 1: 0 SECTION LOCAL DEFAULT1 .text 2: 0018 0 NOTYPE LOCAL DEFAULT1 link 3: 0 NOTYPE LOCAL DEFAULT1 _header_FOO 4: 000b 0 NOTYPE LOCAL DEFAULT1 code_FOO 5: 000c 0 NOTYPE LOCAL DEFAULT1 _header_BAR 6: 0017 0 NOTYPE LOCAL DEFAULT1 code_BAR 7: 0018 0 NOTYPE LOCAL DEFAULT1 _header_BAZ A workaround is possible, but cumbersome and error prone: % cat workaround.s # In FORTH, functions (words) are stored in a linked-list dictionary. # A dictionary entry is typically a header followed by the function body. # The FORTH VM keeps track of the most recently defined word so that words # can be looked up by name at runtime by walking the dictionary. .macro HEADER name, code, backlink _header_\name: .int backlink # the header has a pointer to the preceding entry .ascii "\name" # and the name of the word .int \code # and a pointer to its function body .endm HEADER FOO, code_FOO code_FOO: nop # code body of the word FOO HEADER BAR, code_BAR, name_FOO code_BAR: nop # code body of the word BAR # some words are aliases or have other special semantics, # so machine code doesn't always follow the header HEADER BAZ, code_BAR, name_BAR % riscv64-unknown-elf-as workaround.s -o workaround.o % riscv64-unknown-elf-readelf -Ws workaround.o Symbol table '.symtab' contains 17 entries: Num:Value Size TypeBind Vis Ndx Name 0: 0 NOTYPE LOCAL DEFAULT UND 1: 0 SECTION LOCAL DEFAULT1 .text 2: 0 SECTION LOCAL DEFAULT3 .data 3: 0 SECTION LOCAL DEFAULT4 .bss
