problem with 64 bit binutils (32bit seems ok)
The following two-liner ie # .int gdt gdt: # assembled with "as test.s; objcopy -O binary a.out a.com; hte a.com" gives " 00 00 00 00" on my phenom X3 under both Crunchbang linux 64bit (binutils both downloaded as package and also compiled from gnu sources) and Desktopbsd 64bit (binutils included with distro) Under puppy linux and fedora 9 (both 32bit) on the same phenom x3 I got " 04 00 00 00" which looks right. I also checked on my PIII running antix linux (32bit) and it also gives " 04 00 00 00" The 64bit version of binutils seems to not do forward referencing. Can someone please advice on this inconsistency/confirm this seeming bug. Thx ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: problem with 64 bit binutils (32bit seems ok)
Re Not a bug. objcopy -O binary on a relocatable file loses the relocs. X86_64 uses rela style relocs where the addend is in the reloc, x86 uses rel where the addend is in the section. So in the latter case you get the "+4" from .text+4, in the former you don't. Phew! Thanks very much Alan! Does anyone know what I should use instead of "objcopy -O binary a.out a.com" to stop losing the relocs? ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: problem with 64 bit binutils (32bit seems ok)
Alan I'm a complete beginner re asm & binutils it would've taken me a very long time to work this out so thanks very much for coming back! ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
still struggling to produce the same flat binary with both 32 and 64bit binutils tool chains
I posted http://www.mail-archive.com/bug-binutils@gnu.org/msg08677.html on Wed, 09 Dec 2009 14:12:16 -0800 and Alan Modra very kindly advised that I needed to final link the file. Since that time I have been unable to reproduce the output with 64bit binutils. I've also tried a couple of forums. The nearest I've got is this i.e. .text _start: .global _start #keeps ld happy .int blob blob: as --32 -o test.o test.s ld -melf_i386 test.o objcopy -O binary a.out a.com hte a.com produces | 58 80 04 08 wich I think is a problem 'cos I was hoping for | 04 00 00 00 The reason for this is that the actual code I want to build, rather than this tiny example, is a standalone forth image. Once the bootloader has executed from 0x7c00 and loaded everything into memory it relocates the whole lot so that it starts at memory address 0x0. As such I can't help feeling that all addresses should be based on the presumption that the start of the file is address 0. If someone could please demonstrate how to get the same 32 bit result or a commensurate result (a 64bit ,com) that would jump to the right places from address 0x0 in memory I'd really appreciate it. On the other hand perhaps 58 80 04 08 is the right result and I'm just not interpreting it correctly. As always any help much appreciated. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/5990] New: running out of file descriptors when linking >1024 files
When trying to link a binary which takes a large number of files, I get many errors like this: ld-new: cannot open ../driver/ic/via/sinai/mlxhh/obj/1/mcgm.o: Too many open files This is coming from Read_symbols::do_read_symbols. I can obviously work around the problem by increasing the number of allowed open file desriptors. -- Summary: running out of file descriptors when linking >1024 files Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: gold AssignedTo: ian at airs dot com ReportedBy: me at cgf dot cx CC: bug-binutils at gnu dot org http://sourceware.org/bugzilla/show_bug.cgi?id=5990 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/11337] windres compiles menus and dialogs to UNICODE not ANSI
http://sourceware.org/bugzilla/show_bug.cgi?id=11337 Max Howell changed: What|Removed |Added CC||mxcl at me dot com --- Comment #8 from Max Howell --- Confirmed this bug still occurs with `GNU windres (GNU Binutils) 2.23.2` on OS X 10.8. Bug is now three years old, happy to help fix it if someone would give me a pointer. I fixed it by adding L in front of all my strings in the RC, however I am loath to do this because it means when compiling from Windows MingW it won't work or will require additional flags (don't know which yet). -- 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/11337] windres compiles menus and dialogs to UNICODE not ANSI
http://sourceware.org/bugzilla/show_bug.cgi?id=11337 --- Comment #9 from Max Howell --- For others who may come here, a better solution would be to use MingW64. MingW32—dare I saw—is a little unmaintained nowadays. -- 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/16452] ELF executable with weak reference linked with ld causes assertion in ld.so
http://sourceware.org/bugzilla/show_bug.cgi?id=16452
--- Comment #2 from roseandrew at me dot com ---
Good day, I would like to clarify :
I'm trying to compile openssh , using own compiled toolchan. at compile tim
e I
come across such an error
openbsd-compat / / libopenbsd-compat.a (bsd-misc.o): (. pdr +0 x20): undefi
ned
reference to `setlogin @ @ GLIBC_2.0 '
/ home / andrew / Desktop / mips-toolchan / bin /.. /.. / mips-toolchan / /
root/lib/libc.so.6: undefined reference to `setlogin @ @ GLIBC_2.0
I checked
Content libraries connected during linking:
libc_pic.a: setlogin.os: U __ divdi3_internal
libc_pic.a: setlogin.os: n __ evoke_link_warning_setlogin
libc_pic.a: setlogin.os: U __ GI_memmove
libc_pic.a: setlogin.os: U __ GI_memset
libc_pic.a: setlogin.os: U _gp_disp
libc_pic.a: setlogin.os: U __ libc_errno
libc_pic.a: setlogin.os: U __ moddi3_internal
libc_pic.a: setlogin.os: T setlogin
libc_pic.a: setlogin.os: U __ udivdi3_internal
libc_pic.a: setlogin.os: U __ umoddi3_internal
This may be due to an error upomyanotoy (regression in ld)?15 ян
в. 2014 г.
> http://sourceware.org/bugzilla/show_bug.cgi?id=16452
>
>Bug ID: 16452
> Summary: ELF executable with weak reference linked with ld
>causes assertion in ld.so
> Product: binutils
> Version: 2.25 (HEAD)
>Status: NEW
> Severity: normal
> Priority: P2
> Component: ld
> Assignee: unassigned at sourceware dot org
> Reporter: brnguyen at nvidia dot com
>
> Created attachment 7357
> --> http://sourceware.org/bugzilla/attachment.cgi?id=7357&action=edit
> Reproduction test case
>
> The attached reproduction test case builds two DSOs, one linked against
> pthreads, and one not linked against pthreads, which implement the same
> interface. It also builds a test application which is linked against the
DSO
> that uses pthreads. To reproduce the bug, the DSO that does not use pthr
eads
> is copied over the DSO that uses pthreads, and the test application is ru
n.
>
> Using an ld built from commit 08d0cad39e31083cb8a885703604f7b20d359849, t
his
> triggers the following assertion on ld.so built from commit
> 2f10c4d6901e7a4c4ad294cc5bb8ece6547f4f62 as well as ld.so from glibc
> 2.15-0ubuntu10.5-ppa1 on my Ubuntu 12.04 LTS system:
>
> Inconsistency detected by ld.so: dl-version.c: 224: _dl_check_map_version
s:
> Assertion `needed != ((void *)0)' failed!
>
> This may be related to bugs #15149 and #12549. Also relevant is Debian bug
> #728529.
>
> This appears to be a regression in ld (though there may be a bug in ld.so
as
> well). I bisected binutils using this reproduction test case to try to na
rrow
> down the commit(s) responsible for this regression. Interestingly, ld fai
ls to
> link the test executable in a commit range between ToT master and
> binutils_2.22, with the following error messages:
>
> /home/brnguyen/build/binutils//ld/ld: /tmp/cc3K1rHK.o: undefined referenc
e to
> symbol 'pthread_create@@GLIBC_2.2.5'
> /home/brnguyen/build/binutils//ld/ld: note: 'pthread_create@@GLIBC_2.2.5'
is
> defined in DSO //lib/x86_64-linux-gnu/libpthread.so.0 so try adding it to
the
> linker command line
>
> It appears this link error was introduced by commit
> b64fb44af4f416fbbbda3de03fcfff61d80c841c ("Also track weak references") a
nd
> later removed by commit 879707c642925947e156b7ae2169b89f844532cd ("Exclud
e weak
> refs when considering whether an --as-needed library is needed"), at which
> point ld produces an executable which triggers the assertion.
>
> --
> 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
--
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/11401] GNU debuglink section is not described in DEBUG entry in data directory in PE's optional header
http://sourceware.org/bugzilla/show_bug.cgi?id=11401 Dan Iparraguirre changed: What|Removed |Added CC||danielux at me dot com --- Comment #1 from Dan Iparraguirre --- I have a similar problem. Has anybody taken care of the matter? -- 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/18581] New: (ARM): issue with function names with a dash inside
https://sourceware.org/bugzilla/show_bug.cgi?id=18581 Bug ID: 18581 Summary: (ARM): issue with function names with a dash inside Product: binutils Version: 2.25 Status: NEW Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: adrien at guinet dot me Target Milestone: 2.25 Created attachment 8384 --> https://sourceware.org/bugzilla/attachment.cgi?id=8384&action=edit failing test case here is an issue when assembling an ARM assembly file which has one or multiple functions which have a dash in their name. For instance, the file bug-arm.s in the attached archive contains a "test-a" function, and fails to assemble use GNU as: I've used binutils-arm-linux-gnueabi debian package that includes binutils 2.25. The ARM toolchain from the android NDK has the same issue (binutils 2.24.90, see https://code.google.com/p/android/issues/detail?id=177830 for the original issue from which this one is derived). $ arm-linux-gnueabi-as bug-arm.s -o bug-arm.o bug-arm.s: Assembler messages: bug-arm.s:23: Error: Missing symbol name in directive bug-arm.s:23: Error: unrecognized symbol type "test" bug-arm.s:23: Error: junk at end of line, first unrecognized character is `-' bug-arm.s:26: Error: junk at end of line, first unrecognized character is `"' bug-arm.s:39: Error: expected comma after name `' in .size directive bug-arm.s:62: Error: bad expression -- `bl "test-a"(PLT)' If "test-a" is replaced by "test_a" (cf. the file work-arm.s), then GNU as manages to correctly assemble the object. Note: even if the C language forbids dash in function names, some compilers like LLVM can create functions with dash inside their name after some optimisations. Note bis: this works fines with the x86 GNU AS from binutils 2.25 (you can try with the file bug-x86.s). Thanks for any help/feedbacks/thoughts about this issue! -- 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/19063] New: objcopy does not set Time/Date field for created pei-x86-64 file
https://sourceware.org/bugzilla/show_bug.cgi?id=19063 Bug ID: 19063 Summary: objcopy does not set Time/Date field for created pei-x86-64 file Product: binutils Version: unspecified Status: NEW Severity: minor Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: tsoome at me dot com Target Milestone: --- GNU objdump (GNU Binutils) 2.25.51.20151004 GNU objcopy (GNU Binutils) 2.25.51.20151004 do create and handle pei files: /home/tsoome/loader.efi: file format pei-x86-64 /home/tsoome/loader.efi architecture: i386:x86-64, flags 0x0133: HAS_RELOC, EXEC_P, HAS_SYMS, HAS_LOCALS, D_PAGED start address 0xcd80 Characteristics 0x206 executable line numbers stripped debugging information removed Time/Date Thu Jan 1 03:00:00 1970 Magic 020b(PE32+) MajorLinkerVersion 2 MinorLinkerVersion 25 there is one minor issue tho (it is there in 2.25.1 at least), this pei-x86-64 file is created with objcopy from elf file and as you see the Time/Date is not set. Not a big issue, but at least GNU objcopy 2.17.50 [FreeBSD] 2007-07-03 seems to set time/date properly - it may be freebsd own patch of course. -- 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/19063] objcopy does not set Time/Date field for created pei-x86-64 file
https://sourceware.org/bugzilla/show_bug.cgi?id=19063 --- Comment #3 from Toomas Soome --- -p does not change the result. same Thu Jan 1 03:00:00 1970 at time/date field. -- 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/21677] New: ld 2.27 has unexplained 10x performance improvement in some cases
https://sourceware.org/bugzilla/show_bug.cgi?id=21677 Bug ID: 21677 Summary: ld 2.27 has unexplained 10x performance improvement in some cases Product: binutils Version: 2.26 Status: UNCONFIRMED Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: mail at nh2 dot me Target Milestone: --- Hi, the GHC Haskell compiler uses ld to link its binaries. There is currently a performance regression in GHC 8.2 that makes linking with ld 40x slower than it was in GHC 8.0. But we found that ld 2.27 made this regression 10x less bad than ld 2.26: https://ghc.haskell.org/trac/ghc/ticket/13739#comment:21 https://ghc.haskell.org/trac/ghc/attachment/ticket/13739/T13739-check-ld-output My question: Are you aware of any performance improvement in the 2.27 release that would explain the 10x speedup? I read through https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob_plain;f=ld/NEWS;hb=refs/tags/binutils-2_27 but couldn't find any. While it's great that ld 2.27 got faster, we would really like to know what made it faster. That might help us figure out our bug, and other users of ld would probably also benefit from knowing about it. Thanks! -- 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/21677] ld 2.27 has unexplained 10x performance improvement in some cases
https://sourceware.org/bugzilla/show_bug.cgi?id=21677 mail at nh2 dot me changed: What|Removed |Added CC||mail at nh2 dot me -- 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/22009] New: Excessive memory allocation resulting from memory leakge due to incorrect handling of input file
https://sourceware.org/bugzilla/show_bug.cgi?id=22009 Bug ID: 22009 Summary: Excessive memory allocation resulting from memory leakge due to incorrect handling of input file Product: binutils Version: 2.29 Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: me at adhokshajmishraonline dot in Target Milestone: --- Created attachment 10367 --> https://sourceware.org/bugzilla/attachment.cgi?id=10367&action=edit Payload file which was passed to objdump When objdump is invoked with a specially crafted file, it goes on memeory allocation spree until it cannot allocate it anymore, and then it crashes. Command ./objdump -x -C ./payload Backtrace (soon after issue starts) #0 0x7f929418a015 in __strstr_sse2_unaligned () from /usr/lib/libc.so.6 #1 0x5570a1b1 in arm_pt (work=0x7fffdae0, mangled=0x55ae32a5 "A__", 'w' ..., n=0x15558, anchor=0x7fffd5a8, args=0x7fffd5b0) at ./cplus-dem.c:2392 #2 0x5570a623 in demangle_arm_hp_template (work=0x7fffdae0, mangled=0x7fffd828, n=0x15558, declp=0x7fffd6a0) at ./cplus-dem.c:2507 #3 0x5570aa00 in demangle_class_name (work=0x7fffdae0, mangled=0x7fffd828, declp=0x7fffd6a0) at ./cplus-dem.c:2614 #4 0x5570dc4b in demangle_fund_type (work=0x7fffdae0, mangled=0x7fffd828, result=0x55a67240) at ./cplus-dem.c:4118 #5 0x5570d240 in do_type (work=0x7fffdae0, mangled=0x7fffd828, result=0x55a67240) at ./cplus-dem.c:3907 #6 0x5570e2db in do_arg (work=0x7fffdae0, mangled=0x7fffd828, result=0x7fffd830) at ./cplus-dem.c:4332 #7 0x5570ebd4 in demangle_args (work=0x7fffdae0, mangled=0x7fffda60, declp=0x7fffda90) at ./cplus-dem.c:4641 #8 0x55708a7c in demangle_signature (work=0x7fffdae0, mangled=0x7fffda60, declp=0x7fffda90) at ./cplus-dem.c:1732 #9 0x5570adb2 in iterate_demangle_function (work=0x7fffdae0, mangled=0x7fffda60, declp=0x7fffda90, scan=0x55a8bc21 "__87384A__", 'w' ...) at ./cplus-dem.c:2743 #10 0x5570b619 in demangle_prefix (work=0x7fffdae0, mangled=0x7fffda60, declp=0x7fffda90) at ./cplus-dem.c:2971 #11 0x5570793b in internal_cplus_demangle (work=0x7fffdae0, mangled=0x55aa11a7 "20A__K\377\060\060\060#\344\300") at ./cplus-dem.c:1253 #12 0x55706ea7 in cplus_demangle (mangled=0x55a8bc20 "\236__87384A__", 'w' ..., options=0x3) at ./cplus-dem.c:918 #13 0x55617a6c in bfd_demangle (abfd=0x55a67000, name=0x55a8bc20 "\236__87384A__", 'w' ..., options=0x3) at bfd.c:1961 #14 0x555b9355 in dump_symbols (abfd=0x55a67000, dynamic=0x0) at ./objdump.c:3163 #15 0x555ba0df in dump_bfd (abfd=0x55a67000) at ./objdump.c:3532 #16 0x555ba342 in display_object_bfd (abfd=0x55a67000) at ./objdump.c:3603 #17 0x555ba596 in display_any_bfd (file=0x55a67000, level=0x0) at ./objdump.c:3692 #18 0x555ba60b in display_file (filename=0x7fffe248 "../../test/payload", target=0x0, last_file=0x1) at ./objdump.c:3713 #19 0x555baf36 in main (argc=0x4, argv=0x7fffde88) at ./objdump.c:4015 #20 0x7f929410f4ca in __libc_start_main () from /usr/lib/libc.so.6 #21 0x555b24da in _start () Input file: attached herewith NOTE: I am still investigating it in depth, and will share more details as soon as I get something. -- 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/22009] Excessive memory allocation resulting from memory leakge due to incorrect handling of input file
https://sourceware.org/bugzilla/show_bug.cgi?id=22009 --- Comment #1 from Adhokshaj Mishra --- Created attachment 10368 --> https://sourceware.org/bugzilla/attachment.cgi?id=10368&action=edit Partial trace from ltrace This partial trace output from ltrace ltrace -o trace.txt ./objdump -x -C ./payload 2>&1 > /dev/null -- 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/22009] Excessive memory allocation resulting from memory leakge due to incorrect handling of input file
https://sourceware.org/bugzilla/show_bug.cgi?id=22009 --- Comment #2 from Adhokshaj Mishra --- Created attachment 10369 --> https://sourceware.org/bugzilla/attachment.cgi?id=10369&action=edit Massif output Output from valgrind massif for 30s run. valgrind --tool=massif ./objdump -x -C ./payload -- 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/22009] Excessive memory allocation resulting from memory leakge due to incorrect handling of input file
https://sourceware.org/bugzilla/show_bug.cgi?id=22009 --- Comment #4 from Adhokshaj Mishra --- Sure. Will do that. -- 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/28926] New: objcopy --weaken-symbol does not weaken STB_GNU_UNIQUE symbols
https://sourceware.org/bugzilla/show_bug.cgi?id=28926 Bug ID: 28926 Summary: objcopy --weaken-symbol does not weaken STB_GNU_UNIQUE symbols Product: binutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: i at maskray dot me Target Milestone: --- echo '.data; .type x, @gnu_unique_object; x:' | as - -o a.o objcopy -W x a.o readelf -Ws a.o The symbol 'x' remains STB_GNU_UNIQUE: Symbol table '.symtab' contains 2 entries: Num:Value Size TypeBind Vis Ndx Name 0: 0 NOTYPE LOCAL DEFAULT UND 1: 0 OBJECT UNIQUE DEFAULT2 x I think with the explicit request, it makes sense to weaken 'x'. The documentation for --weaken is: --weaken Change all global symbols in the file to be weak. This can be useful when building an object which will be linked against other objects using the -R option to the linker. This option is only effective when using an object file format which supports weak symbols. If we consider STB_GNU_UNIQUE "global", then --weaken probably should weaken STB_GNU_UNIQUE, too. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28926] objcopy --weaken-symbol does not weaken STB_GNU_UNIQUE symbols
https://sourceware.org/bugzilla/show_bug.cgi?id=28926 --- Comment #1 from Fangrui Song --- Patch: https://sourceware.org/pipermail/binutils/2022-March/119916.html -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/28902] ld: `not found for insert` error has a weird ordering
https://sourceware.org/bugzilla/show_bug.cgi?id=28902 --- Comment #3 from Fangrui Song --- Hi Nick, sorry for my belated reply. I was on a trip. > > ld.bfd a.o -T insert-data.lds -T a.lds # ok > > ld.bfd a.o -T a.lds -T insert-data.lds # .data not found for insert > > > > # Remark: The order is puzzling. If ld processes -T in order, one will > > expect that `-T a.lds -T insert-data.lds` works and the other order fails. > > > I have not dug deeply into this, but I would guess that this happens because > the script parser is stack based, so it pulls out and processes > insert-data.lds before a.lds. But because semantic processing happens > before syntactic processing the INSERT in insert-data.lds has already stopped > the default linker script from being parsed, so the only possible definition > of .data comes from a.lds. > > I expect that using multiple -T options combined with INSERT directives is a > rare thing, which is why no-one has noticed this odd behaviour before. > Personally I think that the safest thing to do would be to just document the > behaviour, but not make any changes to the code. The order issue can be fixed by postponing the effects of INSERT after regular SECTIONS. Is it feasible? > > > ld.bfd a.o -T insert-note.lds --build-id # ok > > ld.bfd a.o -T a.lds -T insert-note.lds --build-id # .note.gnu.build-id not > > found for insert > > > This makes sense. The a.lds script does not define a .note.gnu.build-id > section, so there is nowhere for the INSERT AFTER in insert-note.lds to > attach to. > > When a.lds is omitted the default linker script is used instead and this does > define a .note.gnu.build-id section, which is why the INSERT AFTER works. > > > > ld.bfd a.o -T a.lds -dT insert-note.lds --build-id # ok > > > > # Remark: Why -T fails while -dT works is puzzling. If you specify > > --verbose, the used linker script is exactly the same. > > > It seems that -T and -dT are incompatible. In my tests it appears that the > -dT option is entirely ignored if -T is also used. This is a bug, but I am > concerned that fixing it might break scripts which unknowingly rely upon this > behaviour. So maybe it should be considered a documentation bug that the > incompatibility is not mentioned. >From Debian Code Search, https://codesearch.debian.net/search?q=%5B-%5DdT&literal=0 (-dT) has no result. --default-script seems unused as well, so I think changing the behavior of -dT probably does not matter. Making -dT work in the presence of -T probably makes more sense. > So overall I am inclined to think that these are both documentation bugs. Do > you agree ? -dT/--default-script seems unused (except the recent .note.package) and INSERT is super rare as well. I think there are some changes which may be worth making to make the behavior more reasonable and make the documentation more explainable to a reader. The current behaviors may be a bit difficult to describe in the documentation... -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28926] objcopy --weaken-symbol does not weaken STB_GNU_UNIQUE symbols
https://sourceware.org/bugzilla/show_bug.cgi?id=28926 Fangrui Song changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Fangrui Song --- Fixed for 2.39 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/29012] New: gas: .set should copy st_size only if src's st_size is unset
https://sourceware.org/bugzilla/show_bug.cgi?id=29012 Bug ID: 29012 Summary: gas: .set should copy st_size only if src's st_size is unset Product: binutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: i at maskray dot me Target Milestone: --- For ``` .size foo1, 1 foo1: .set bar1, foo1 .size bar1, 2 .size bar2, 2 .set bar2, foo1 .set bar3, foo2 .size bar3, 2 .size bar4, 2 .set bar4, foo2 .size foo2, 1 foo2: ``` bar1's size is 2 while bar2, bar3, bar4's is 1. The behavior of bar1 makes sense (generally directives on the new symbol should win) and is relied upon by glibc stdio-common/errlist.c: ``` .hidden _sys_errlist_internal .globl _sys_errlist_internal .type _sys_errlist_internal, @object .size _sys_errlist_internal, 1072 _sys_errlist_internal: .globl __GLIBC_2_1_sys_errlist .set __GLIBC_2_1_sys_errlist, _sys_errlist_internal .type __GLIBC_2_1_sys_errlist, %object .size __GLIBC_2_1_sys_errlist, 125 * (64 / 8) // glibc expects that .size __GLIBC_2_1_sys_errlist, 125 * (64 / 8) wins. ``` The behavior of bar2/bar3/bar4 seems brittle. To avoid the reordering of the two code blocks which will result in the bar3 situation, glibc compiles errlist.c with gcc -fno-toplevel-reorder (previously -fno-unit-at-a-time). To fix the inconsistency and improve robustness, I think we should make bar2/bar3/bar4 match bar1, removing the directive order sensitivity. There is a pity that `.size dest, 0` is indistinguishable from the case where dest is unset, but it should be fine. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/29012] gas: .set should copy st_size only if src's st_size is unset
https://sourceware.org/bugzilla/show_bug.cgi?id=29012 --- Comment #1 from Fangrui Song --- PATCH: https://sourceware.org/pipermail/binutils/2022-March/120299.html LLVM integrated assembler has had a similar behavior since 2014-03: https://github.com/llvm/llvm-project/commit/a041ef1bd8905f0d58e301c6830b183002ff1847#diff-5f22c59676e12f7ca563d9e9324c35c9e66523e9b21a91c91fe5c73ddd09fe6aR642 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/29012] gas: .set should copy st_size only if src's st_size is unset
https://sourceware.org/bugzilla/show_bug.cgi?id=29012 Fangrui Song changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #3 from Fangrui Song --- Target milestone: 2.39 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/29067] New: gas: -gsomething-not-already-a-long-option does not get a diagnostic
https://sourceware.org/bugzilla/show_bug.cgi?id=29067 Bug ID: 29067 Summary: gas: -gsomething-not-already-a-long-option does not get a diagnostic Product: binutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: i at maskray dot me Target Milestone: --- https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=4a5700b62f767ed08c97122bad182244700bb4e3 added a diagnostic: % ~/Dev/binutils-gdb/out/debug/gas/as-new -gdwarf-6 a.s Assembler messages: Fatal error: unknown DWARF option -gdwarf-6 I think it makes sense to extend it for other unrecognized strings not starting with "dwarf" % ~/Dev/binutils-gdb/out/debug/gas/as-new -gsomething-not-already-a-long-option a.s # no diagnostic -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29072] ld silently make the program stack area executable if nested function is used
https://sourceware.org/bugzilla/show_bug.cgi?id=29072 Fangrui Song changed: What|Removed |Added CC||i at maskray dot me --- Comment #9 from Fangrui Song --- I think in 2022 we should consider this https://www.airs.com/blog/archives/518 > These days we could probably change the default: we could probably say that > if an object file does not have a .note.GNU-stack section, then it does not > require an executable stack. Only give an executable stack if -z execstack is specified. This is ld.lld's choice and (until one day ago mold's choice). Taking the address of a nested function is so rare that I am unsure having an on-demand state is useful. FWIW Clang doesn't supported GCC nested functions. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29135] New: nm: add --no-weak
https://sourceware.org/bugzilla/show_bug.cgi?id=29135 Bug ID: 29135 Summary: nm: add --no-weak Product: binutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: i at maskray dot me Target Milestone: --- Since 2018-07 (https://reviews.llvm.org/D48751), https://llvm.org/docs/CommandGuide/llvm-nm.html supports --no-weak for listing non-weak symbols. The short option -W is added as an alias. I think the option is mildly useful and perhaps binutils can consider adding it as well. llvm-nm aims for being compatible with GNU nm, so taking -W without asking for binutils opinions was not great. (Due to the recent -U conflict, llvm-nm folks should be more aware of using short options and will handle such issues better.) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29136] New: ld: ENTRY(no_such_symbol) in -shared mode does not report a warning
https://sourceware.org/bugzilla/show_bug.cgi?id=29136 Bug ID: 29136 Summary: ld: ENTRY(no_such_symbol) in -shared mode does not report a warning Product: binutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: i at maskray dot me Target Milestone: --- as /dev/null -o a.o echo 'ENTRY(no_such_symbol)' > a.t ld.bfd -T a.t -shared a.o Both `ld.bfd -e no_such_symbol -shared a.o` and (executable link) `ld.bfd -T a.t a.o` have a warning: `cannot find entry symbol ...; defaulting to ...` -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/28824] relro security issues
https://sourceware.org/bugzilla/show_bug.cgi?id=28824 Fangrui Song changed: What|Removed |Added CC||i at maskray dot me --- Comment #8 from Fangrui Song --- x86 has switched the end of PT_GNU_RELRO to max-page-size as well by H.J. in https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=3c4c0a18c8f0af039e65458da5f53811e9e43754 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/27451] ld: Provide a way to make C identifier name sections GCable under __start_/__stop_ references
https://sourceware.org/bugzilla/show_bug.cgi?id=27451 Fangrui Song changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Target Milestone|--- |2.37 Resolution|--- |FIXED --- Comment #5 from Fangrui Song --- GNU ld 2.37 has -z start-stop-gc. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29310] [2.39 Regression] copy relocation against non-copyable protected symbol `__cxa_ pure_virtual' on aarch64-linux-gnu
https://sourceware.org/bugzilla/show_bug.cgi?id=29310 Fangrui Song changed: What|Removed |Added CC||i at maskray dot me --- Comment #5 from Fangrui Song --- (In reply to Matthias Klose from comment #4) > it depends which *1 executable is built first. > > https://launchpadlibrarian.net/610456289/buildlog_ubuntu-kinetic-arm64.gcc- > 11_11.3.0-4ubuntu1_BUILDING.txt.gz > has failures in f951 and go1, > > https://launchpadlibrarian.net/610252712/buildlog_ubuntu-kinetic-arm64.gcc- > 12_12.1.0-5ubuntu1_BUILDING.txt.gz > has a failure in dm21 > > I'm sure I saw a failure on lto1 too, but it looks there's some randomness > which of these is built first. As nsz' commention suggests, -Wl,-y,__cxa_pure_virtual information (and then run `readelf -sW` on the defining archive/object) is needed. The logs are not useful. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29377] non-canonical reference to canonical protected function
https://sourceware.org/bugzilla/show_bug.cgi?id=29377
Fangrui Song changed:
What|Removed |Added
CC||i at maskray dot me
--- Comment #3 from Fangrui Song ---
This patch looks good to me.
__attribute__((visibility("protected"))) void *foo() {
return (void *)foo;
}
% gcc -m32 -fpic -shared -fuse-ld=bfd b.c
/usr/bin/ld.bfd: /tmp/cc3Ay0Gh.o: relocation R_X86_64_PC32 against protected
symbol `foo' can not be used when making a shared object
/usr/bin/ld.bfd: final link failed: bad value
collect2: error: ld returned 1 exit status
I'd still with that the x86 port considers
https://sourceware.org/pipermail/binutils/2022-June/121423.html
I have fixed GNU ld's aarch64/arm ports to match other ports and lld. This
addresses all issues reported on
https://maskray.me/blog/2021-01-09-copy-relocations-canonical-plt-entries-and-protected
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug ld/29376] multiple definition of weak symbols on MinGW toolchain
https://sourceware.org/bugzilla/show_bug.cgi?id=29376 Fangrui Song changed: What|Removed |Added CC||i at maskray dot me --- Comment #1 from Fangrui Song --- This is a limitation of the PE/COFF format: https://maskray.me/blog/2021-04-25-weak-symbol#pe-coff You can work around the limitation by adding a suitable non-comdat strong definition. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29397] New: binutils: support zstd
https://sourceware.org/bugzilla/show_bug.cgi?id=29397
Bug ID: 29397
Summary: binutils: support zstd
Product: binutils
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: i at maskray dot me
Target Milestone: ---
Zstandard is a "universal" compression algorithm which scales from
low-ratio-very-fast to high-ratio-pretty-slow.
The generic-abi proposal https://groups.google.com/g/generic-abi/c/satyPkuMisk
("Add new ch_type value: ELFCOMPRESS_ZSTD") has been approved.
The default zstd -3 is easily 7x as fast as zlib level 1 while having a higher
compression ratio.
See also https://sourceware.org/pipermail/gnu-gabi/2022q2/000498.html
binutils may need to:
* optional: import zstd/ as a toplevel directory like zlib/
* add configure.ac option --with-system-zstd
* gas: add --compress-debug-sections=zstd
* objcopy: add --compress-debug-sections=zstd
* ld: support ELFCOMPRESS_ZSTD input, add --compress-debug-sections=zstd
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug binutils/29397] binutils: support zstd
https://sourceware.org/bugzilla/show_bug.cgi?id=29397 Fangrui Song changed: What|Removed |Added CC||hjl.tools at gmail dot com, ||nick.alcock at oracle dot com, ||nickc at redhat dot com -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29397] binutils: support zstd for SHF_COMPRESSED debug sections
https://sourceware.org/bugzilla/show_bug.cgi?id=29397 Fangrui Song changed: What|Removed |Added Summary|binutils: support zstd |binutils: support zstd for ||SHF_COMPRESSED debug ||sections -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29397] binutils: support zstd for SHF_COMPRESSED debug sections
https://sourceware.org/bugzilla/show_bug.cgi?id=29397 --- Comment #1 from Fangrui Song --- Add more tools to the list: * nm * addr2line For objcopy --compress-debug-sections=zstd , I think it should apply only to uncompressed .debug_* sections. If a section is compressed by zlib, the format should not change. If a user wants to ensure zlib sections are converted to zstd, run --decompress-debug-sections first. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29540] New: ld ppc64: unneeded R_PPC64_NONE in .rela.dyn when linking Linux vdso
https://sourceware.org/bugzilla/show_bug.cgi?id=29540 Bug ID: 29540 Summary: ld ppc64: unneeded R_PPC64_NONE in .rela.dyn when linking Linux vdso Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: i at maskray dot me Target Milestone: --- This should be reproducible with many Linux versions, but I have just checked some recent commits, e.g. dcf8e5633e2e69ad60b730ab5905608b756a032f today % git remote -v | grep origin origin https://github.com/torvalds/linux (fetch) origin https://github.com/torvalds/linux (push) % make O=/tmp/linux/ppc64le ARCH=powerpc CROSS_COMPILE=powerpc64le-linux-gnu- -j60 defconfig all % readelf -Wr /tmp/linux/ppc64le/arch/powerpc/kernel/vdso/vdso64.so.dbg Relocation section '.rela.dyn' at offset 0x14f0 contains 4 entries: Offset Info Type Symbol's Value Symbol's Name + Addend R_PPC64_NONE 0 R_PPC64_NONE 0 R_PPC64_NONE 0 R_PPC64_NONE 0 The linker script is innocent. I don't reproduce the problem with other ports (though I know that the riscv port produces R_RISCV_NONE in certain scenarios) make O=/tmp/linux/x86_64 -j60 defconfig all && readelf -Wr /tmp/linux/x86_64/arch/x86/entry/vdso/vdso64.so make O=/tmp/linux/aarch64 ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- LLVM=1 -j60 all && readelf -Wr /tmp/linux/aarch64/arch/arm64/kernel/vdso/vdso.so make O=/tmp/linux/riscv64 ARCH=riscv CROSS_COMPILE=riscv64-linux-gnu- -j60 defconfig all && readelf -Wr /tmp/linux/riscv64/arch/riscv/kernel/vdso/vdso.so make O=/tmp/linux/s390x ARCH=s390 CROSS_COMPILE=s390x-linux-gnu- -j60 defconfig all && readelf -Wr /tmp/linux/s390x/arch/s390/kernel/vdso64/vdso64.so -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/25968] plugin_test_1 fails when --gc-sections is on by default
https://sourceware.org/bugzilla/show_bug.cgi?id=25968
Fangrui Song changed:
What|Removed |Added
CC||i at maskray dot me
--- Comment #1 from Fangrui Song ---
--emit-relocs + (--gc-sections || --icf) triggers an assertion failure.
--emit-relocs --icf failure is reported as PR18845.
% echo 'void foo(){}' | gcc -xc - -c -o a.o
% gold --emit-relocs --gc-sections a.o
gold: internal error in do_layout, at ../../gold/object.cc:1939
Simply commenting out the assert will lead to a segfault along the road.
diff --git i/gold/object.cc w/gold/object.cc
index fe2494d3c41..9ba444f79d0 100644
--- i/gold/object.cc
+++ w/gold/object.cc
@@ -1936,7 +1936,7 @@ Sized_relobj_file::do_layout(Symbol_table* symtab,
if (emit_relocs)
this->size_relocatable_relocs();
- gold_assert(!is_two_pass || reloc_sections.empty());
+ //gold_assert(!is_two_pass || reloc_sections.empty());
for (std::vector::const_iterator p = reloc_sections.begin();
p != reloc_sections.end();
(gdb) up
#1 0x55b7c8bd in gold::Layout::layout_reloc<64, false>
(this=0x7fff32d0, shdr=..., data_section=0x1, rr=0x55d80630) at
../../../gold/layout.cc:1341
1341 name += data_section->name();
(gdb) p data_section
$1 = (gold::Output_section *) 0x1
(gdb) bt
#0 0x55965b78 in gold::Output_section::name (this=0x1) at
../../../gold/output.h:3258
#1 0x55b7c8bd in gold::Layout::layout_reloc<64, false>
(this=0x7fff32d0, shdr=..., data_section=0x1, rr=0x55d80630) at
../../../gold/layout.cc:1341
#2 0x55bb9236 in gold::Sized_relobj_file<64, false>::do_layout
(this=0x55d90490, symtab=0x7fff37b0, layout=0x7fff32d0,
sd=0x55d906c0) at ../../../gold/object.cc:1982
#3 0x55ab58bc in gold::Object::layout (this=0x55d90490,
symtab=0x7fff37b0, layout=0x7fff32d0, sd=0x55d906c0) at
../../../gold/object.h:696
#4 0x55c5d3c8 in gold::Add_symbols::run (this=0x55d7ffe0) at
../../../gold/readsyms.cc:634
#5 0x55ceb27b in gold::Workqueue::find_and_run_task
(this=0x7fff3cb0, thread_number=0) at ../../../gold/workqueue.cc:319
#6 0x55ceb8b1 in gold::Workqueue::process (this=0x7fff3cb0,
thread_number=0) at ../../../gold/workqueue.cc:495
#7 0x557e6a80 in main (argc=4, argv=0x7fffd5d8) at
../../../gold/main.cc:252
(gdb)
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug gold/25968] gold: --emit-relocs --gc-sections => internal error in do_layout, at ../../gold/object.cc
https://sourceware.org/bugzilla/show_bug.cgi?id=25968 Fangrui Song changed: What|Removed |Added Summary|plugin_test_1 fails when|gold: --emit-relocs |--gc-sections is on by |--gc-sections => internal |default |error in do_layout, at ||../../gold/object.cc -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/27741] Using --emit-relocs with --gc-sections or -flto ends in failure
https://sourceware.org/bugzilla/show_bug.cgi?id=27741 Fangrui Song changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED CC||i at maskray dot me --- Comment #1 from Fangrui Song --- Duplicate of PR25968 *** This bug has been marked as a duplicate of bug 25968 *** -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/25968] gold: --emit-relocs --gc-sections => internal error in do_layout, at ../../gold/object.cc
https://sourceware.org/bugzilla/show_bug.cgi?id=25968 Fangrui Song changed: What|Removed |Added CC||806251055 at qq dot com --- Comment #2 from Fangrui Song --- *** Bug 27741 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/25968] gold: --emit-relocs --gc-sections => internal error in do_layout, at ../../gold/object.cc
https://sourceware.org/bugzilla/show_bug.cgi?id=25968 --- Comment #3 from Fangrui Song --- See https://github.com/llvm/llvm-project/issues/57545 for a llvm-project/bolt --emit-relocs link issue due to this gold bug. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/25968] gold: --emit-relocs --gc-sections on .eh_frame => internal error in do_layout, at ../../gold/object.cc
https://sourceware.org/bugzilla/show_bug.cgi?id=25968 Fangrui Song changed: What|Removed |Added Summary|gold: --emit-relocs |gold: --emit-relocs |--gc-sections => internal |--gc-sections on .eh_frame |error in do_layout, at |=> internal error in |../../gold/object.cc|do_layout, at ||../../gold/object.cc -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29566] New: objdump -p considers an empty .gnu.version_r invalid
https://sourceware.org/bugzilla/show_bug.cgi?id=29566 Bug ID: 29566 Summary: objdump -p considers an empty .gnu.version_r invalid Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: i at maskray dot me Target Milestone: --- % cat a.yaml --- !ELF FileHeader: Class: ELFCLASS64 Data:ELFDATA2LSB Type:ET_EXEC Machine: EM_X86_64 Sections: - Name:.gnu.version_r Type:SHT_GNU_verneed Flags: [ SHF_ALLOC ] DynamicSymbols: - Name:f1 Binding: STB_GLOBAL % yaml2obj a.yaml -o a.o# a utility from llvm-project . On Debian, the package "llvm" contains it. % objdump -p a.o a.o: file format elf64-x86-64 objdump: a.o: .gnu.version_r invalid entry objdump: warning: private headers incomplete: bad value % readelf -V a.o Version needs section '.gnu.version_r' contains 0 entries: Addr: 0x Offset: 0x40 Link: 3 (.dynstr) --- objdump -p gives a warning while readelf -V doesn't. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/19109] Cannot configure default flag_compress_debug
https://sourceware.org/bugzilla/show_bug.cgi?id=19109 Fangrui Song changed: What|Removed |Added CC||i at maskray dot me --- Comment #40 from Fangrui Song --- If binutils adds zstd (PR29397), the option --enable-compressed-debug-sections= needs to be adjusted:) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29397] binutils: support zstd for SHF_COMPRESSED debug sections
https://sourceware.org/bugzilla/show_bug.cgi?id=29397 Fangrui Song changed: What|Removed |Added Assignee|unassigned at sourceware dot org |i at maskray dot me -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29397] binutils: support zstd for SHF_COMPRESSED debug sections
https://sourceware.org/bugzilla/show_bug.cgi?id=29397 --- Comment #2 from Fangrui Song --- https://sourceware.org/pipermail/gdb-patches/2022-September/191915.html [PATCH] binutils, gdb: support zstd compressed debug sections -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29566] objdump -p considers an empty .gnu.version_r invalid
https://sourceware.org/bugzilla/show_bug.cgi?id=29566 --- Comment #2 from Fangrui Song --- The spec (https://sourceware.org/gnu-gabi/program-loading-and-dynamic-linking.txt) doesn't reject it. For a section whose content is a concatenated N items, the ELF spirits typically allows N==0, as otherwise it needs an additional sentence to disallow the case, which is unnecessary. It seems that the reference implementation of Go may generate .gnu.version_r at least in some cases: https://github.com/llvm/llvm-project/issues/57707 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29397] binutils: support zstd for SHF_COMPRESSED debug sections
https://sourceware.org/bugzilla/show_bug.cgi?id=29397 --- Comment #3 from Fangrui Song --- (In reply to Fangrui Song from comment #2) > https://sourceware.org/pipermail/gdb-patches/2022-September/191915.html > [PATCH] binutils, gdb: support zstd compressed debug sections The latest version is at https://sourceware.org/pipermail/binutils/2022-September/123085.html . The gdb part has been approved. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29640] readelf: support zstd for SHF_COMPRESSED debug sections
https://sourceware.org/bugzilla/show_bug.cgi?id=29640 --- Comment #1 from Fangrui Song --- Also, the --decompress option decompresses section content. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/29641] gold, dwp: support zstd for SHF_COMPRESSED debug sections
https://sourceware.org/bugzilla/show_bug.cgi?id=29641 Fangrui Song changed: What|Removed |Added See Also||https://sourceware.org/bugz ||illa/show_bug.cgi?id=29397 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/29641] New: gold, dwp: support zstd for SHF_COMPRESSED debug sections
https://sourceware.org/bugzilla/show_bug.cgi?id=29641 Bug ID: 29641 Summary: gold, dwp: support zstd for SHF_COMPRESSED debug sections Product: binutils Version: 2.40 (HEAD) Status: NEW Severity: normal Priority: P2 Component: gold Assignee: ccoutant at gmail dot com Reporter: i at maskray dot me CC: ian at airs dot com Target Milestone: --- dwp needs to decompress compressed .dwo . gold needs to decompress compressed input sections and compress output debug sections. I can take a stab on this feature request. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29397] binutils: support zstd for SHF_COMPRESSED debug sections
https://sourceware.org/bugzilla/show_bug.cgi?id=29397 Fangrui Song changed: What|Removed |Added See Also||https://sourceware.org/bugz ||illa/show_bug.cgi?id=29641 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/29641] gold, dwp: support zstd for SHF_COMPRESSED debug sections
https://sourceware.org/bugzilla/show_bug.cgi?id=29641 --- Comment #2 from Fangrui Song --- bfd/compress.c is used by many utilities (objcopy/addr2line/objdump/etc), but gas/readelf need to implement their own. gold/dwp share code and need separate support as well. https://sourceware.org/pipermail/binutils/2022-October/123232.html [PATCH] gold, dwp: support zstd compressed input debug sections [PR 29641] -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29640] readelf: support zstd for SHF_COMPRESSED debug sections
https://sourceware.org/bugzilla/show_bug.cgi?id=29640 --- Comment #2 from Fangrui Song --- https://sourceware.org/pipermail/binutils/2022-October/123240.html [PATCH] readelf: support zstd compressed debug sections [PR 29640] -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29654] New: ld: add -w to suppress warnings
https://sourceware.org/bugzilla/show_bug.cgi?id=29654 Bug ID: 29654 Summary: ld: add -w to suppress warnings Product: binutils Version: 2.40 (HEAD) Status: NEW Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: i at maskray dot me Target Milestone: --- Apple ld64 and llvm-project ld64.lld support -w to suppress warnings. -w was picked likely because compiler drivers use -w to suppress warnings. I think -w mildly benefits GNU ld/gold as well. With --noinhibit-exec, we downgrade errors to warnings. When analyzing a large executable with relocation overflow issues, we may use --noinhibit-exec --emit-relocs to get relocations and an output file despite relocation overflow issues. Since we know the output otherwise does not link, the warnings are not useful. If we have -w, we can add -w to not see the unuseful warnings. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29654] ld: add -w to suppress warnings
https://sourceware.org/bugzilla/show_bug.cgi?id=29654 --- Comment #2 from Fangrui Song --- (In reply to Nick Clifton from comment #1) > Created attachment 14403 [details] > Proposed patch > > Hi Fanguri, > > Is this patch the kind of thing that you had in mind ? > > Cheers > Nick Hi Nick, thanks for sending a patch! This looks good with just one thought: `config.fatal_warnings = false;` makes me wonder how -w interacts with --fatal-warnings. It seems that -w --fatal-warnings and --fatal-warnings -w have the same effect (-w wins, which makes sense IMO), so I guess `config.fatal_warnings = false;` can be omitted. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29640] readelf: support zstd for SHF_COMPRESSED debug sections
https://sourceware.org/bugzilla/show_bug.cgi?id=29640 --- Comment #3 from Fangrui Song --- (In reply to Fangrui Song from comment #2) > https://sourceware.org/pipermail/binutils/2022-October/123240.html [PATCH] > readelf: support zstd compressed debug sections [PR 29640] The patch is stilling waiting for a review:) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29640] readelf: support zstd for SHF_COMPRESSED debug sections
https://sourceware.org/bugzilla/show_bug.cgi?id=29640 Fangrui Song changed: What|Removed |Added Assignee|unassigned at sourceware dot org |i at maskray dot me Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Fangrui Song --- Implemented in https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=1f5a3546126b47fd3b7a5fbc4ec5fad1397b726b (readelf: support zstd compressed debug sections [PR 29640]) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/29641] gold, dwp: support zstd for SHF_COMPRESSED debug sections
https://sourceware.org/bugzilla/show_bug.cgi?id=29641 Fangrui Song changed: What|Removed |Added Status|NEW |RESOLVED Assignee|ccoutant at gmail dot com |i at maskray dot me Target Milestone|--- |2.40 Resolution|--- |FIXED --- Comment #3 from Fangrui Song --- Closed by https://sourceware.org/git?p=binutils-gdb.git;a=commit;h=332a4eeaea69034b8ee6f50b931ce6734b55bf08 https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=8b2d02cbb924f1f3718dc5a20f7a9dcf07739d23 Milestone: 2.40 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29820] New: ld x86: -r should not define _TLS_MODULE_BASE_
https://sourceware.org/bugzilla/show_bug.cgi?id=29820 Bug ID: 29820 Summary: ld x86: -r should not define _TLS_MODULE_BASE_ Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: i at maskray dot me Target Milestone: --- cat > a.s <: 401000: 48 c7 c0 e0 ff ff ff movq$-0x20, %rax # should be $0x0 401007: 66 90 nop 401009: 64 8b 90 e8 ff ff ff movl%fs:-0x18(%rax), %edx 401010: 64 03 90 ec ff ff ff addl%fs:-0x14(%rax), %edx 401017: 48 c7 c0 e0 ff ff ff movq$-0x20, %rax # should be $0x0 40101e: 66 90 nop 401020: 64 8b 90 f8 ff ff ff movl%fs:-0x8(%rax), %edx 401027: 64 03 90 fc ff ff ff addl%fs:-0x4(%rax), %edx -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29823] New: ld riscv: undefined elf_backend_obj_attrs_handle_unknown causes segfault when merging .riscv.attributes
https://sourceware.org/bugzilla/show_bug.cgi?id=29823 Bug ID: 29823 Summary: ld riscv: undefined elf_backend_obj_attrs_handle_unknown causes segfault when merging .riscv.attributes Product: binutils Version: 2.40 (HEAD) Status: NEW Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: i at maskray dot me Target Milestone: --- % cat a.s .attribute 9, "0" % riscv64-linux-gnu-gcc -c a.s % ~/Dev/binutils-gdb/out/riscv64/ld/ld-new a.o a.o [1]3982286 segmentation fault ~/Dev/binutils-gdb/out/riscv64/ld/ld-new a.o a.o lang_check=>_bfd_riscv_elf_merge_private_bfd_data=>riscv_merge_attributes => `result &= _bfd_elf_merge_unknown_attribute_low (ibfd, obfd, i);` => `get_elf_backend_data (err_bfd)->obj_attrs_handle_unknown (err_bfd, tag);` => null pointer dereference -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29823] ld riscv: undefined elf_backend_obj_attrs_handle_unknown causes segfault when merging .riscv.attributes
https://sourceware.org/bugzilla/show_bug.cgi?id=29823 Fangrui Song changed: What|Removed |Added CC||kito.cheng at gmail dot com, ||nelson.chu at sifive dot com -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29847] New: objdump: add --show-all-symbols
https://sourceware.org/bugzilla/show_bug.cgi?id=29847 Bug ID: 29847 Summary: objdump: add --show-all-symbols Product: binutils Version: 2.40 (HEAD) Status: NEW Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: i at maskray dot me Target Milestone: --- llvm-objdump 16 will have a new option --show-all-symbols (https://reviews.llvm.org/D131589) which prints all symbols during disassembly. This is useful to know all symbols defined at a location. https://github.com/llvm/llvm-project/blob/main/llvm/test/tools/llvm-objdump/multiple-symbols.s and https://github.com/llvm/llvm-project/blob/main/llvm/test/tools/llvm-objdump/multiple-symbols-mangling.s demonstrate the behavior. Here is some dump for your convenience. You can reproduce by yourself if you have installed llvm-mc and yaml2obj and have cloned llvm-project. cd llvm-project/llvm/test/tools/llvm-objdump llvm-mc -triple armv8a-unknown-linux -filetype=obj multiple-symbols.s -o a.o % fllvm-objdump --triple armv8a -d a.o a.o:file format elf32-littlearm Disassembly of section .text: : 0: e0800080 add r0, r0, r0, lsl #1 4: e12fff1e bx lr 0008 : 8: eb00 0080 add.w r0, r0, r0, lsl #2 c: 4770 bx lr % fllvm-objdump --triple armv8a --show-all-symbols -d a.o a.o:file format elf32-littlearm Disassembly of section .text: <$a.0>: : : 0: e0800080 add r0, r0, r0, lsl #1 4: e12fff1e bx lr 0008 <$t.1>: 0008 : 0008 : 8: eb00 0080 add.w r0, r0, r0, lsl #2 c: 4770 bx lr % fllvm-objdump --triple armv8a --disassemble-symbols= -d a.o a.o:file format elf32-littlearm Disassembly of section .text: : 0: e0800080 add r0, r0, r0, lsl #1 4: e12fff1e bx lr (llvm-objdump doesn't have --disassemble[=symbol]. It uses --disassemble-symbols=) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29939] New: -z pack-relative-relocs --no-keep-memory -pie tries to write a yet-to-be-loaded section content
https://sourceware.org/bugzilla/show_bug.cgi?id=29939
Bug ID: 29939
Summary: -z pack-relative-relocs --no-keep-memory -pie tries to
write a yet-to-be-loaded section content
Product: binutils
Version: 2.40 (HEAD)
Status: NEW
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: arsen at aarsen dot me
Target Milestone: ---
GCC: gcc-12 (Gentoo 12.2.1_p20221217 p6) 12.2.1 20221217
LD: GNU ld (Gentoo 2.39 p5) 2.39.0, and GNU ld (GNU Binutils) 2.39.50.20221218
Binutils patches for the former:
https://dev.gentoo.org/~dilfridge/distfiles/binutils-2.39-patches-5.tar.xz
(though they should not be relevant, since they're mostly build issue related
things)
The latter is a clean build of 20d8836e4ac6e416fda53152d453328934a2ea46
(Most of the) relevant files: https://www.aarsen.me/~arsen/bfdbug.tar.xz
The above is missing some parts of the GCC distribution, but removing the LTO
and linker plugin bits suffices to work around that AFAICT (and I can still
reproduce after doing that)
Running cmdline from within
var/tmp/portage/net-libs/webkit-gtk-2.38.3-r500/work/webkitgtk-2.38.3_build/:
Program terminated with signal SIGSEGV, Segmentation fault.
#0 bfd_putl64 (data=41888, p=0x0) at
/usr/src/debug/sys-devel/binutils-2.39-r4/binutils-2.39/bfd/libbfd.c:877
877 addr[0] = (data >> (0*8)) & 0xff;
(gdb) bt
#0 bfd_putl64 (data=41888, p=0x0) at
/usr/src/debug/sys-devel/binutils-2.39-r4/binutils-2.39/bfd/libbfd.c:877
#1 0x7f8149508f38 in elf_x86_size_or_finish_relative_reloc
(is_x86_64=is_x86_64@entry=true, info=info@entry=0x557de9d62e20 ,
htab=htab@entry=0x557dea2eb5d0, unaligned=unaligned@entry=false,
outrel=outrel@entry=0x7ffd284ac870)
at
/usr/src/debug/sys-devel/binutils-2.39-r4/binutils-2.39/bfd/elfxx-x86.c:1546
#2 0x7f8149509381 in _bfd_elf_x86_finish_relative_relocs
(info=0x557de9d62e20 )
at
/usr/src/debug/sys-devel/binutils-2.39-r4/binutils-2.39/bfd/elfxx-x86.c:1912
#3 0x7f8149538e80 in bfd_elf_final_link (abfd=0x557dea2e9490,
info=0x557de9d62e20 )
at
/usr/src/debug/sys-devel/binutils-2.39-r4/binutils-2.39/bfd/elflink.c:12737
... on this fairly complex link. That block is:
(gdb) list
/usr/src/debug/sys-devel/binutils-2.39-r4/binutils-2.39/bfd/elfxx-x86.c:1546
1541 }
1542 else
1543 {
1544 if (rel.r_offset >= sec->size)
1545abort ();
1546 htab->elf_write_addend
1547(info->output_bfd, outrel->r_addend,
1548(elf_section_data (sec)->this_hdr.contents
1549 + rel.r_offset));
1550 }
(gdb)
I ran a bisect for this error, and it'd appear to have been here since DT_RELR
was added in 5af6f000d88622107e7382d337af2884fd211da2
---
This combination of flags fails even for simple programs; a hello world
crashed, and so did even less:
[i] ~/gcc/binutils-bld/ld $ ld -z pack-relative-relocs --no-keep-memory -pie
/usr/lib/gcc/x86_64-pc-linux-gnu/12/crtbeginS.o
ld: warning: cannot find entry symbol _start; defaulting to 1020
Segmentation fault (core dumped)
... in the same place as the above.
I wrote a patch that does fix the simple case:
https://www.aarsen.me/~arsen/0001-ld.bfd-Fix-no-keep-memory-z-pack-relative-relocs-seg.patch
[i] ~/gcc/binutils-bld/ld 139 $ ./ld-new -z pack-relative-relocs
--no-keep-memory -pie /usr/lib/gcc/x86_64-pc-linux-gnu/12/crtbeginS.o
./ld-new: warning: cannot find entry symbol _start; defaulting to
1020
./ld-new: /usr/lib/gcc/x86_64-pc-linux-gnu/12/crtbeginS.o:(.text+0xa):
undefined reference to `__TMC_END__'
./ld-new: /usr/lib/gcc/x86_64-pc-linux-gnu/12/crtbeginS.o:(.text+0x3a):
undefined reference to `__TMC_END__'
./ld-new: a.out: hidden symbol `__TMC_END__' isn't defined
./ld-new: final link failed: bad value
[i] ~/gcc/binutils-bld/ld 1 $
... but it causes a file truncation error with the complex case:
[c] ~/.../webkit-gtk-2.38.3-r500/work/webkitgtk-2.38.3_build$ sh -x
../../../../../../../../binutils-bld/ld/cmdline
+ .../binutils-bld/ld/ld-new -plugin ...
../../../../../../../../binutils-bld/ld/ld-new: error:
bin/LLIntSettingsExtractor(.data.rel.ro.local) is too large (0x28 bytes)
../../../../../../../../binutils-bld/ld/ld-new: BFD (GNU Binutils)
2.39.50.20221218 internal error, aborting at
../../binutils-gdb/bfd/elfxx-x86.c:1566 in
elf_x86_size_or_finish_relative_reloc
../../../../../../../../binutils-bld/ld/ld-new: Please report this bug.
/home/arsen/gcc/binutils-bld/ld/ld-new: error:
bin/LLIntSettingsExtractor(.data.rel.ro.local) is too large (0x28 bytes)
In GDB:
Breakpoint 1, _bfd_abort (file=file@entry=0x55753410
"../../binutils-gdb/bfd
[Bug ld/29939] -z pack-relative-relocs --no-keep-memory -pie tries to write a yet-to-be-loaded section content
https://sourceware.org/bugzilla/show_bug.cgi?id=29939 --- Comment #2 from Arsen Arsenović --- Builds the original reproducer (webkitgtk), thanks! -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29947] New: libbfd real_fopen & libiberty unlink_if_ordinary functions are not handling Windows nul device correctly
https://sourceware.org/bugzilla/show_bug.cgi?id=29947 Bug ID: 29947 Summary: libbfd real_fopen & libiberty unlink_if_ordinary functions are not handling Windows nul device correctly Product: binutils Version: 2.39 Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: himalr at proton dot me Target Milestone: --- Created attachment 14541 --> https://sourceware.org/bugzilla/attachment.cgi?id=14541&action=edit Handle Windows nul device correctly. This bug affects gas when used as "as.exe -v -o nul" (or -o /dev/null) under msys2-mingw. Error message, Assembler messages: Fatal error: can't create nul: Invalid argument gcc.exe: error: nul: Permission denied I originally reported this to [MINGW-packages](https://github.com/msys2/MINGW-packages/issues/14725 and they asked me to report this here as well. This is my pull request https://github.com/msys2/MINGW-packages/pull/14775 I'm attaching those two patches here as well. The second one is for unlink_if_ordinary at libiberty/unlink-if-ordinary.c because under Windows/MINGW, S_ISREG returns true for null device. Please note that I'm not a C programmer so let me know if there are any issues with these patches. Thanks. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29947] libbfd real_fopen & libiberty unlink_if_ordinary functions are not handling Windows nul device correctly
https://sourceware.org/bugzilla/show_bug.cgi?id=29947 --- Comment #3 from Himal --- Hello Nick, Thanks for applying the patch. Sure, I'll submit the libiberty patch proposal to the GCC project as well. Regards, Himal -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29947] libbfd real_fopen & libiberty unlink_if_ordinary functions are not handling Windows nul device correctly
https://sourceware.org/bugzilla/show_bug.cgi?id=29947 --- Comment #4 from Himal --- I've reported the libiberty bug to [GCC](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108276) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/24784] elf_x86_64_check_tls_transition should allow R_X86_64_GOTPCREL (-fno-plt)
https://sourceware.org/bugzilla/show_bug.cgi?id=24784 --- Comment #9 from Fangrui Song --- rustc runs into this problem as well as it currently somehow defaults to disable R_X86_64_*GOTPCRELX/R_386_GOT32X. Since the fix is so trivial, I sent https://sourceware.org/pipermail/binutils/2023-January/125506.html https://sourceware.org/pipermail/binutils/2023-January/125507.html -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/28824] relro security issues
https://sourceware.org/bugzilla/show_bug.cgi?id=28824 --- Comment #22 from Fangrui Song --- > [...] (psykose/alice confirmed lld does not have the problem on alpine, but I > am not sure if they do the correct thing™ here security-wise -- it's good to > have a concrete idea here) lld does the correct thing. I changed lld to adopt the two-RW-PT_LOAD approach in 2019. I have some notes about different linkers' behaviors: https://maskray.me/blog/2020-11-15-explain-gnu-linker-options#z-noseparate-code and https://maskray.me/blog/2021-08-22-freebsd-src-browsing-on-linux-and-my-rtld-contribution#p_memsz-of-pt_gnu_relro (where I fixed FreeBSD rtld to do similarly to glibc/musl . Without this, I'd be very careful changing lld's common-page-size padding behavior). lld still pads p_memsz of PT_GNU_RELRO (the first RW PT_LOAD) to a common-page-size boundary instead of a max-page-size boundary. If GNU ld now uses max-page-size boundary for all ports but x86, I think https://sourceware.org/binutils/docs/ld/Builtin-Functions.html "DATA_SEGMENT_ALIGN(maxpagesize, commonpagesize)" needs a clarification: it seels that commonpagesize is ignored for most ports? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30091] Bundle all artifacts and command line invocation to quickly reproduce linker errors
https://sourceware.org/bugzilla/show_bug.cgi?id=30091 Fangrui Song changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE CC||i at maskray dot me --- Comment #1 from Fangrui Song --- Thanks for +1 on this feature request. I reported it on https://sourceware.org/bugzilla/show_bug.cgi?id=26119 as well :) In lld, the feature is also activated with an environment variable. LLD_REPRODUCE=/tmp/rep.tar gcc -fuse-ld=lld ... *** This bug has been marked as a duplicate of bug 26119 *** -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26119] ld: Support --reproduce
https://sourceware.org/bugzilla/show_bug.cgi?id=26119 Fangrui Song changed: What|Removed |Added CC||hiraditya at msn dot com --- Comment #1 from Fangrui Song --- *** Bug 30091 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/27565] ld: Support input section description keyword: REVERSE
https://sourceware.org/bugzilla/show_bug.cgi?id=27565 --- Comment #1 from Fangrui Song --- Justin Cady wants to add REVERSE to ld.lld in https://reviews.llvm.org/D145381 The semantics seem pretty clear, so ld.lld adopting the feature first may be fine :) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/24784] elf_x86_64_check_tls_transition should allow R_X86_64_GOTPCREL (-fno-plt)
https://sourceware.org/bugzilla/show_bug.cgi?id=24784 Fangrui Song changed: What|Removed |Added Resolution|INVALID |FIXED --- Comment #13 from Fangrui Song --- Fixed for 2.41 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/27565] ld: Support input section description keyword: REVERSE
https://sourceware.org/bugzilla/show_bug.cgi?id=27565
--- Comment #3 from Fangrui Song ---
(In reply to Nick Clifton from comment #2)
> Created attachment 14772 [details]
> Proposed patch
>
> Hi Fanguri,
>
> What do you think of this patch ? Does it do what you need ?
>
> Cheers
> Nick
Hi Nick, thanks for working on this feature! Do you have some examples how this
keyword can be used? If I try
(https://github.com/llvm/llvm-project/blob/main/lld/test/ELF/linkerscript/sort-init.s#L53):
SECTIONS {
.init_array : {
*(REVERSE(SORT_BY_INIT_PRIORITY(.init_array.* .ctors.*))
SORT_BY_INIT_PRIORITY(foo*))
*(REVERSE(.init_array .ctors))
}
}
ld reports `syntax error`.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug ld/30374] New: ld: Add --remap-inputs-file= to remap input files
https://sourceware.org/bugzilla/show_bug.cgi?id=30374 Bug ID: 30374 Summary: ld: Add --remap-inputs-file= to remap input files Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: i at maskray dot me Target Milestone: --- Hello! I'm considering an option in ld.lld to replace or remove input files with glob patterns. https://reviews.llvm.org/D148859 --remap-inputs-file= can be specified multiple times, each naming a remap file that contains from-globto-file lines or #-led comments, e.g. aa.oa.o b?.[b]c b.o cc.ac.a d*.so d.so ## Use /dev/null to indicate an input file which should be ignored. /dev/null is treated as an empty linker script. empty /dev/null This option can be used to: * replace an input file. E.g. "*/libz.so\texp/libz.so" can replace a resolved -lz without updating the input file list or (if used) a response file. When debugging an application where a bug is isolated to one single input file, this option gives an convenient way to test fixes. * remove an input file with /dev/null (changed to NUL on Windows), e.g. "a.o\t/dev/null". A build system may add unneeded dependencies. This option gives an convenient way to test the result removing some inputs. bash/zsh process substitution is handy for specifying a pattern without using a remap file, e.g. --remap-inputs-file=<(printf 'a.o\taa.o') -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30374] ld: Add --remap-inputs-file= to remap input files
https://sourceware.org/bugzilla/show_bug.cgi?id=30374 --- Comment #1 from Fangrui Song --- I have picked `=` as a separator a la -fdebug-prefix-map=. --remap-inputs= may be handy to specify just one pattern. Here is an example: --remap-inputs-file=1.map --remap-inputs-file=2.map --remap-inputs='d*.so=d.so' where 1.map contains aa.o=a.o b?.[b]c=b.o and 2.map contains cc.a=c.a ## Use /dev/null to indicate an input file which should be ignored. empty=/dev/null -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30426] New: gas x86: reject {call,jmp} [offset func] in Intel syntax
https://sourceware.org/bugzilla/show_bug.cgi?id=30426
Bug ID: 30426
Summary: gas x86: reject {call,jmp} [offset func] in Intel
syntax
Product: binutils
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: i at maskray dot me
Target Milestone: ---
% cat a.s
call [offset func]
jmp [offset func]
% as -msyntax=intel a.s -o a.o
% objdump -M intel -dr a.o
a.o: file format elf64-x86-64
Disassembly of section .text:
<.text>:
0: e8 00 00 00 00 call 0x5
1: R_X86_64_PLT32 func-0x4
5: e9 00 00 00 00 jmp0xa
6: R_X86_64_PLT32 func-0x4
MSVC ml64.exe reports "error A2023:instruction operand must have size"
for the following assembly listing
extrn k:proc
_text segment
call [offset k]
; call qword ptr [offset k] ; this is somehow accepted
_text ends
end
This is a patch for LLVM integrated assembler (used by `clang -c -masm=intel`,
llvm-mc, etc) to reject call [offset k] and jmp [offset k]:
https://reviews.llvm.org/D150048
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug binutils/30426] gas x86: reject {call,jmp} [offset func] in Intel syntax
https://sourceware.org/bugzilla/show_bug.cgi?id=30426 Fangrui Song changed: What|Removed |Added Target||i686* x86_64* -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/30449] New: gas riscv: support pseudo-instruction "lga"
https://sourceware.org/bugzilla/show_bug.cgi?id=30449 Bug ID: 30449 Summary: gas riscv: support pseudo-instruction "lga" Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: i at maskray dot me Target Milestone: --- "lga" has been in riscv-asm-manual since the resolution to https://github.com/riscv-non-isa/riscv-asm-manual/issues/50 In LLVM 17, LLVM integrated assembler will support "lga". -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/30449] gas riscv: support pseudo-instruction "lga"
https://sourceware.org/bugzilla/show_bug.cgi?id=30449 Fangrui Song changed: What|Removed |Added Target||riscv*-*-* -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30237] strip fails on riscv with 'not enough room for program headers, stgnjAlO[.interp]: bad value'
https://sourceware.org/bugzilla/show_bug.cgi?id=30237 Fangrui Song changed: What|Removed |Added CC||i at maskray dot me --- Comment #5 from Fangrui Song --- (In reply to alice from comment #4) > forwarded upstream too, then: > https://github.com/llvm/llvm-project/issues/63084 riscv-non-isa/riscv-elf-psabi-doc#71 (2021-06) added PT_RISCV_ATTRIBUTES, but no dynamic loader uses this yet. I created https://reviews.llvm.org/D152065 to add PT_RISCV_ATTRIBUTES to ld.lld. > psykose-edge-riscv64:~$ strip somebin > strip: stgnjAlO: not enough room for program headers, try linking with -N > strip: stgnjAlO[.interp]: bad value This looks like a GNU objcopy/strip bug. The tool should work regardless of whether the linker creates PT_RISCV_ATTRIBUTES. AArch32 doesn't have PT_ARM_ATTRIBUTES and I believe objcopy/strip can process such a trivial program. The RISC-V port should be fixed. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30237] strip fails on riscv with 'not enough room for program headers, stgnjAlO[.interp]: bad value'
https://sourceware.org/bugzilla/show_bug.cgi?id=30237 --- Comment #7 from Fangrui Song --- (In reply to Andreas Schwab from comment #6) > Since arm32 does not have PT_ARM_ATTRIBUTES it cannot have this problem in > the first place. With the PHDRS linker script command, we can customize program headers and drop the PT_RISCV_ATTRIBUTES program header even with newer linkers that add PT_RISCV_ATTRIBUTES. At any rate, whether a non-SHF_ALLOC section like SHT_RISCV_ATTRIBUTES is covered by a PT_LOAD should not cause objcopy/strip to behave abnormally. A non-SHF_ALLOC section like SHT_RISCV_ATTRIBUTES is not commonly covered by a PT_* program header. The SHT_RISCV_ATTRIBUTES is not that different from .comment from a strip tool's viewpoint. I don't think .comment not covered by a program header allows the strip tool to behave abnormally. > If you think this program is trivial, then why does it > have .riscv.attributes? Even for the trivial program, there is some information like Attribute Section: riscv File Attributes Tag_RISCV_stack_align: 16-bytes Tag_RISCV_arch: "rv64i2p1_m2p0_a2p1_f2p2_d2p2_c2p0_zicsr2p0_zifencei2p0_zmmul1p0" I am concerned that RISC-V folks may add more not-so-useful attributes in the future, but this is unrelated to this bug report. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/16523] support xz compression of debug info files
https://sourceware.org/bugzilla/show_bug.cgi?id=16523 Fangrui Song changed: What|Removed |Added CC||i at maskray dot me --- Comment #1 from Fangrui Song --- We now have --compress-debug-sections=zstd as another choice. To achieve a similar compression ratio like xz, zstd is slower to compress, but the decompression is much faster. Example: https://archlinux.org/news/now-using-zstandard-instead-of-xz-for-package-compression/ says "zstd and xz trade blows in their compression ratio. Recompressing all packages to zstd with our options yields a total ~0.8% increase in package size on all of our packages combined, but the decompression time for all packages saw a ~1300% speedup." -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/27452] ld: Support compressing arbitrary sections (generalized --compress-debug-sections=)
https://sourceware.org/bugzilla/show_bug.cgi?id=27452 --- Comment #1 from Fangrui Song --- I think we should just allow SHF_ALLOC | SHF_COMPRESSED sections. Created https://groups.google.com/g/generic-abi/c/HUVhliUrTG0 The proposed option syntax is: --compress-sections='.debug_*=zlib' . This applies to both SHF_ALLOC and non-SHF_ALLOC sections. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30592] New: objcopy --set-section-flags: support "large" for SHF_X86_64_LARGE
https://sourceware.org/bugzilla/show_bug.cgi?id=30592 Bug ID: 30592 Summary: objcopy --set-section-flags: support "large" for SHF_X86_64_LARGE Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: i at maskray dot me Target Milestone: --- Linkers may place SHF_X86_64_LARGE sections away from regular sections to alleviate relocation overflow pressure [1]. It would be nice to have the ability to add the SHF_X86_64_LARGE flag to sections in relocatable object files, especially for prebuilt object files that the user cannot control. I suggest that we allow objcopy --set-section-flags .data=alloc,large to set SHF_X86_64_LARGE. [1]: https://maskray.me/blog/2023-05-14-relocation-overflow-and-code-models -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30592] objcopy --set-section-flags: support "large" for SHF_X86_64_LARGE
https://sourceware.org/bugzilla/show_bug.cgi?id=30592 --- Comment #1 from Fangrui Song --- Patch: https://sourceware.org/pipermail/binutils/2023-June/128052.html -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30374] ld: Add --remap-inputs-file= to remap input files
https://sourceware.org/bugzilla/show_bug.cgi?id=30374 --- Comment #5 from Fangrui Song --- (In reply to Nick Clifton from comment #4) > OK, I have decided to commit my patch now, so that it gets into the next > release. If there are problems we can always reopen this PR. Thank you! I have tested the feature. It looks great. > ld foo.o --remap-inputs=foo.o=bar.o > > will not rename foo.o to bar.o, [...] I hope that this will be fine. Users can get adapted to this limitation. > One other thing: I wondered if we ought to accept the "@file" syntax in the > --remap-inputs option, as a synonym for --remap-inputs-file. What do you > think ? I think no. --remap-inputs @1.map would require extra work and the syntax is probably not conventional. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30623] New: objcopy --set-section-flags: support toggling a flag
https://sourceware.org/bugzilla/show_bug.cgi?id=30623 Bug ID: 30623 Summary: objcopy --set-section-flags: support toggling a flag Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: i at maskray dot me Target Milestone: --- It will be more convenient if --set-section-flags supports toggling a flag, instead of specifying the full set of flags, e.g. --set-section-flags .foo=-alloc --set-section-flags .foo=-readonly --set-section-flags .foo=+readonly The lack of toggling flags is currently not so cumbersome because most ELF sections only use "alloc" and "readonly". However, if we consider more flags, e.g. "exclude", "large" (https://sourceware.org/bugzilla/show_bug.cgi?id=30592), the lack of toggling flags is quite inconvenient. For example, if we want to add SHF_X86_64_LARGE to large data sections, we need to figure out whether "readonly" is set. --set-section-flags .ldata=alloc,large --set-section-flags .lrodata=alloc,readonly,large It will be more convenient if we can just use --set-section-flags .ldata=+large --set-section-flags .lrodata=+large Candidate syntax: the right hand side of `=` can use one of the two forms: * comma separated flags, e.g. alloc,large * comma separated + flags and - flags, e.g. -alloc,+readonly Other forms like -alloc,readonly probably should be rejected. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30592] objcopy --set-section-flags: support "large" for SHF_X86_64_LARGE
https://sourceware.org/bugzilla/show_bug.cgi?id=30592 Fangrui Song changed: What|Removed |Added Target||x86_64-* Assignee|unassigned at sourceware dot org |i at maskray dot me Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from Fangrui Song --- https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=5e24da908dbf6ddeb03e2b194f6b39dea3c660f3 Used PATCH v4 with a modification: https://sourceware.org/pipermail/binutils/2023-July/128334.html This is a minor feature, so I do not rush it into the upcoming binutils 2.41 release. Possible target milestone: binutils 2.42 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30684] New: readelf -s: support an option to display section names
https://sourceware.org/bugzilla/show_bug.cgi?id=30684 Bug ID: 30684 Summary: readelf -s: support an option to display section names Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: i at maskray dot me Target Milestone: --- I almost always prefer readelf -Ws to objdump -t for ELF symbol information as the former presents all information without distortion. Certain symbol types have strange output for objdump -t output, e.g. STT_SECTION=>'d', STT_NOTYPE=>no particular character. There is, however, one feature that objdump -t is better: it displays the section name for a symbol defined relative to a section. readelf -Ws just prints st_shndx, which is sometimes less readable. I wonder whether readelf can add an option to change the "Ndx" column to display section names instead. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30684] readelf -s: support an option to display section names
https://sourceware.org/bugzilla/show_bug.cgi?id=30684 --- Comment #4 from Fangrui Song --- (In reply to Nick Clifton from comment #3) > Created attachment 15016 [details] > Proposed patch > > And here is a full patch. > > After some more thought, I decided that the new behaviour needed to be gated > by a command line option, so I have added --extra-sym-info to do this. Thank you for implementing this! Yes, I think quite a few projects rely on the output of readelf -Ws. Using an opt-in option is necessary. The option name -X/--extra-sym-info looks good to me. Another long option name choice is --symbol-details to be similar to --section-details. > I have also moved the display of non-visibility related bits in the st_other > field to this new option. This means that by default the symbol table > displayed by readelf should be completely uniform. Like [: 8] in the [Other] column for ppc64 ELFv2? Looks good to me, but I'd like to hear from Alan. > I have discarded the "==>" for section symbols - it looked silly. Instead I > just filled the gap with spaces. objdump -t shows the section name twice for STT_SECTION symbols as well. I think readelf -sX displaying the section name twice should be as well, to not make STT_SECTION special. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/30788] New: gas aarch64: GOT relocations referencing a local symbol should not be changed to reference STT_SECTION
https://sourceware.org/bugzilla/show_bug.cgi?id=30788 Bug ID: 30788 Summary: gas aarch64: GOT relocations referencing a local symbol should not be changed to reference STT_SECTION Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: i at maskray dot me Target Milestone: --- Extracted from https://github.com/llvm/llvm-project/issues/63418 ``` cat > a.s <https://github.com/ARM-software/abi-aa/issues/217 is created to decide how we should create GOT entries, GDAT(S+A) vs GDAT(S). If the decision is to respect existing linker behaviors and allow the same GOT entry for :got_lo12:(.data+0) and :got_lo12:(.data+4), this assembler change is IMO a prerequisite. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/30788] gas aarch64: GOT relocations referencing a local symbol should not be changed to reference STT_SECTION
https://sourceware.org/bugzilla/show_bug.cgi?id=30788 Fangrui Song changed: What|Removed |Added Target||aarch64*-* -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30612] maxpagesize alignment after relro segment takes up space
https://sourceware.org/bugzilla/show_bug.cgi?id=30612 Fangrui Song changed: What|Removed |Added CC||i at maskray dot me --- Comment #1 from Fangrui Song --- Unfortunately, I believe this is nearly infeasible to fix, as long as the alignment still follows max-page-size, as switching to a two-RW-PT_LOAD layout in GNU ld is very difficult. I have a short summary of different design choices: https://maskray.me/blog/2020-11-15-explain-gnu-linker-options#z-relro > GNU ld uses one RW PT_LOAD program header with padding at the start. The > first half of the PT_LOAD overlaps with PT_GNU_RELRO. The padding is added so > that the end of PT_GNU_RELRO is aligned by max-page-size. (See ld.bfd > --verbose output.) Prior to GNU ld 2.39, the end was aligned by > common-page-size. GNU ld's one RW PT_LOAD layout makes the alignment increase > the file size. max-page-size can be large, such as 65536 for many systems, > causing wasted space. > > lld utilitizes two RW PT_LOAD program headers: one for RELRO sections and the > other for non-RELRO sections. Although this might appear unusual initially, > it eliminates the need for alignment padding as seen in GNU ld's layout. I > implemented the current layout in 2019 (https://reviews.llvm.org/D58892). > > The layout used by mold is similar to that of lld. In mold's case, the end of > PT_GNU_RELRO is padded to max-page-size by appending a SHT_NOBITS > .relro_padding section. This approach ensures that the last page of > PT_GNU_RELRO is protected, regardless of the system page size. However, when > the system page size is less than max-page-size, the map from the first RW > PT_LOAD is larger than needed. > > In my opinion, losing protection for the last page when the system page size > is larger than common-page-size is not at all an issue. Protecting .got.plt > is the main purpose of -z now. Protecting a small portion of .data.rel.ro > doesn't really make the program more secure, given that .data and .bss are so > huge and full of attach targets. If users are really anxious, they can set > common-page-size to match their system page size. > > I am unsure whether lld's hidden assumption about common-page-size <= system > page-size is an issue. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30844] New: ld riscv: --emit-relocs does not retain the original relocation type
https://sourceware.org/bugzilla/show_bug.cgi?id=30844
Bug ID: 30844
Summary: ld riscv: --emit-relocs does not retain the original
relocation type
Product: binutils
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: i at maskray dot me
Target Milestone: ---
From
https://maskray.me/blog/2021-03-14-the-dark-side-of-riscv-linker-relaxation#ld---emit-relocs
(with updated instructions)
For GNU ld's AArch64/PPC64/x86-64 ports, the --emit-relocs code retains the
original relocation type even if a linker optimization is applied. This is
partly to communicate more information to the analysis tool and partly because
the transformation may not be described with any existing relocation type.
However, the RISC-V port changes the relocation type, including relocation
types for relaxable instructions (e.g. R_RISCV_CALL_PLT), and markers
(R_RISCV_ALIGN and R_RISCV_RELAX). I believe this was not a deliberate decision
as there is no --emit-relocs test at all in ld/testsuite/ld-riscv-elf/. So far,
the unintentional change seems fine but certain relaxations (such as TLSDESC)
may not have relocation types associated with the relaxed instructions.
cat > aarch64.s <<'eof'
.global _start; _start:
adrpx1, :got:x
ldr x1, [x1, #:got_lo12:x]
.data; .globl x; .hidden x; x: .word 0
eof
cat > ppc64.s <<'eof'
.globl _start; _start:
addis 3, 2, .Lhidden@toc@ha
ld3, .Lhidden@toc@l(3)
lwa 3, 0(3)
.data; .globl hidden; .hidden hidden; hidden: .long 0
.section .toc,"aw",@progbits
.Lhidden: .tc hidden[TC], hidden
eof
cat > x86-64.s <<'eof'
.globl _start; _start:
movq foo@gotpcrel(%rip), %rax
foo: nop
eof
aarch64-linux-gnu-gcc -fuse-ld=lld -B/tmp/Rel/bin -nostdlib aarch64.s
-Wl,--emit-relocs -o aarch64 && aarch64-linux-gnu-objdump -dr aarch64 | sed -E
'/^\s*$/d'
powerpc64le-linux-gnu-gcc -nostdlib ppc64.s -Wl,--emit-relocs -o ppc64 &&
powerpc64le-linux-gnu-objdump -dr ppc64 | sed -E '/^\s*$/d'
gcc -nostdlib x86-64.s -Wl,--emit-relocs -o x86-64 && objdump -dr x86-64 | sed
-E '/^\s*$/d'
cat > riscv64.s <<'eof'
.global _start; _start:
call f
call f
.balign 8
f: ret
eof
riscv64-linux-gnu-gcc -nostdlib riscv64.s -Wl,--emit-relocs -o riscv64 &&
riscv64-linux-gnu-objdump -dr riscv64 | sed -E '/^\s*$/d'
Output (removed blank lines for compacter output):
```
aarch64: file format elf64-littleaarch64
Disassembly of section .text:
000102f8 <_start>:
102f8: d503201fnop
102f8: R_AARCH64_ADR_GOT_PAGE x
102fc: 10100661adr x1, 303c8
102fc: R_AARCH64_LD64_GOT_LO12_NC x
ppc64: file format elf64-powerpcle
Disassembly of section .text:
0240 <_start>:
240: 00 00 00 60 nop
240: R_PPC64_TOC16_HA hidden
244: 00 81 62 38 addir3,r2,-32512
244: R_PPC64_TOC16_LO hidden
248: 02 00 63 e8 lwa r3,0(r3)
x86-64: file format elf64-x86-64
Disassembly of section .text:
12dd <_start>:
12dd: 48 8d 05 00 00 00 00lea0x0(%rip),%rax# 12e4
12e0: R_X86_64_REX_GOTPCRELXfoo-0x4
12e4 :
12e4: 90 nop
riscv64: file format elf64-littleriscv
Disassembly of section .text:
02a0 <_start>:
2a0: 008000efjal 2a8
2a0: R_RISCV_JALf
2a4: 004000efjal 2a8
2a4: R_RISCV_NONE *ABS*+0x4
2a4: R_RISCV_JALf
02a8 :
2a8: 8082ret
2a8: R_RISCV_NONE *ABS*+0x4
2a8: R_RISCV_NONE *ABS*+0x6
```
I have a section "ld --emit-relocs" with very brief information on my website
for a while. Recently https://reviews.llvm.org/D159082 motivated me to
elaborate and bring this up:)
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug ld/30844] ld riscv: --emit-relocs does not retain the original relocation type
https://sourceware.org/bugzilla/show_bug.cgi?id=30844 Fangrui Song changed: What|Removed |Added CC||jrtc27 at jrtc27 dot com, ||kito.cheng at gmail dot com, ||nelsonc1225 at sourceware dot org -- You are receiving this mail because: You are on the CC list for the bug.
