[Bug binutils/28759] ar: Add --thin to avoid 'T' conflict with X/Open System Interface
https://sourceware.org/bugzilla/show_bug.cgi?id=28759 Fangrui Song changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Fangrui Song --- Fixed for the upcoming 2.38 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28759] ar: Add --thin to avoid 'T' conflict with X/Open System Interface
https://sourceware.org/bugzilla/show_bug.cgi?id=28759 --- Comment #2 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Fangrui Song : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=d1b69c506f7855e5b90039abdadaf1d05b085c4c commit d1b69c506f7855e5b90039abdadaf1d05b085c4c Author: Fangrui Song Date: Tue Jan 11 08:59:40 2022 -0800 ar: Add --thin for creating thin archives In many ar implementations (FreeBSD, elfutils, etc), -T has the X/Open System Interface specified semantics. Therefore -T for thin archives is not recommended for portability. -T is deprecated without diagnostics. PR binutils/28759 * ar.c (long_options): Add --thin. (usage) Add --thin. Deprecate -T without diagnostics. * doc/binutils.texi: Add doc. * NEWS: Mention --thin. * binutils/testsuite/binutils-all/ar.exp: Add tests. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/28762] [z80-unknown-elf-as]: assembly fails, but fixed with a blank line
https://sourceware.org/bugzilla/show_bug.cgi?id=28762 --- Comment #4 from Sergey Belyashov --- Bug is present in current development branch. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/28762] [z80-unknown-elf-as]: assembly fails, but fixed with a blank line
https://sourceware.org/bugzilla/show_bug.cgi?id=28762 Pete Moore changed: What|Removed |Added Version|2.36.1 |2.37 --- Comment #3 from Pete Moore --- > I haven't yet tried assembling with z80-unknown-elf-as version 2.37, I can > do that too, if that is useful. Just checked binutils v2.37 - bug still present. https://github.com/spectrum4/spectrum4/runs/4776798824?check_suite_focus=true -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28763] New: SIGSEGV during processing of program headers
https://sourceware.org/bugzilla/show_bug.cgi?id=28763 Bug ID: 28763 Summary: SIGSEGV during processing of program headers Product: binutils Version: 2.37 Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: nils_b...@t-online.de Target Milestone: --- Created attachment 13899 --> https://sourceware.org/bugzilla/attachment.cgi?id=13899=edit The crashing input alongside a script to automatically reproduce the bug. SIGSEGV during processing of program headers # Description During processing of the attached elf file via ``` readelf -a $PWD/02f5bec64cda36a9941f7752571e5a41328f683542fa5b125bf03a8dd3c10fb0 ``` an out-of-bounds read is triggered, which causes a SIGSEGV. The bug appears to be located in the code responsible for parsing the program headers. This allows an attacker to perform a denial of service and possibly opens up other attack vectors if files from untrusted sources are processed. For reproduction of the crash, I attach a script called ./reproduce.sh alongside the crashing input. If you need further details, please do not hesitate to ask. # Version The input was tested on branch binutils-2_37 of git://sourceware.org/git/binutils-gdb.git commit 116a737f438d03a1bd6aa706b6ea0b4022f3b7e2. # Valgrind ``` readelf: Warning: Section 27 has an out of range sh_info value of 131072 readelf: Warning: Section 28 has an out of range sh_link value of 1096552196 readelf: Warning: Section 28 has an out of range sh_info value of 2370617481 readelf: Warning: Section 29 has an out of range sh_link value of 134344835 readelf: Warning: Section 29 has an out of range sh_info value of 3901310160 readelf: Error: Reading 1163130152494825472 bytes extends past end of file for string table Section Headers: [Nr] Name Type Address Offset Size EntSize Flags Link Info Align readelf: Warning: Size of section 0 is larger than the entire file! [ 0] 841f: LOOS+0x3244cb6 0179850f0020247c ba005cbd 00801f0f005c 0063247c80c031ed XLTCxxolxxx 2147483648 1057916 3550243881428485391 readelf: Warning: [ 2]: Expected link to another section in info field [ 2] LOUSER+0x78e9ff 80c0940f02fa8341 31452d750063247c 72bdfb7be9ed fb24840fd0890063 WAxMSILOGTColp 1157627904 2202135857 2629117855673549562 readelf: Warning: [ 3]: Unexpected value (2232352867) in info field. readelf: Warning: Size of section 3 is larger than the entire file! [ 3] 841f: LOUSER+0x40fd02 8d49272704c64305 676ce394901244c 8d4924012744c643 870fce394903244c WAXxGTxx 1224877132 108449337 10180711322849953347 readelf: Warning: [ 5]: Expected link to another section in info fieldreadelf: Warning: Size of section 5 is larger than the entire file! [ 5] 04c48349: LOUSER+0x7ffb15 91046348d5b60f40 1f0fe0ff3ec80148 0f02fa834144 8341fd78e9c0 WAXxMSILCoxxx 826654868 4253936109 10668749317231214591 [ 7] LOUSER+0x7e 4401c38348fd 5cbded3145c089 841f0f66 448d49272704c643 LTCop 2214592512 1082396608 393755151237644282 readelf: Warning: [ 8]: Expected link to another section in info fieldreadelf: Warning: Size of section 8 is larger than the entire file! [ 8] 430676c6: 0f02fa83: LOUSER+0x348fff 72ba000d bbda8eb00 fdc1e90076ba 0061ba00 WAILOxxolp 180223999 3120562176 557757969320640622 readelf: Warning: [11]: Expected link to another section in info fieldreadelf: Warning: Size of section 11 is larger than the entire file! [11] 1f0f66ff: LOUSER+0x4d8945 20bdc031 1f0ff87de900 4502fa834144 2444b60ffc16 WIOCxxolp 2484061577 3833941442 9587991139382987381 [13] LOUSER+0x40fc22 0696840f f0008247c80 f6854d073385 24548b48070f ASLGTxx 1220580367 1478786179 9516053376779226880 [14] LOUSER+0x464158 49e9582454894800 63247c80fa 854dfbb5850f 74894c03c485 WAXOGTxxoE 3531870198 822083587 1080960824299964626 readelf: Warning: [15]: Expected link to another section in info field [15] LOUSER+0x403103 27bdd6894900 f7e9e900 0063247c80001f0f 1f0f66f7cce9 WXIOxxop 4218258703 826671103 273766429165 [16] LOUSER+0x202484 4800 fffb834938244489 4418247c8b482d75 4824548b44e2 op 1210340489 608471108 4677041145485214784 readelf: Warning: [17]: Unexpected value (2267319432) in info field. readelf: Warning: Size of section 17 is larger than the entire file! [17] 0f444024: 3824648b: LOOS+0x674c085
[Bug gas/28762] [z80-unknown-elf-as]: assembly fails, but fixed with a blank line
https://sourceware.org/bugzilla/show_bug.cgi?id=28762 --- Comment #1 from Pete Moore --- Note, I didn't include all the output from all examples, but all of these actions were successful in removing the failure message: 1) Adding a blank line _anywhere_ before line 10290 2) Deleting any existing instruction from source code, before line 10290 3) Adding a new instruction anywhere before line 10290 The following things _didn't_ remove the bogus error: 1) Changing amount of whitespace on any existing line before 10290 2) Making any file changes _after_ line 10290 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/28762] [z80-unknown-elf-as]: assembly fails, but fixed with a blank line
https://sourceware.org/bugzilla/show_bug.cgi?id=28762 Pete Moore changed: What|Removed |Added Attachment #13898|0 |1 is obsolete|| CC||petemoore at gmx dot net --- Comment #2 from Pete Moore --- Created attachment 13900 --> https://sourceware.org/bugzilla/attachment.cgi?id=13900=edit rom1.s Apologies, I uploaded incorrect version before! -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/28762] New: [z80-unknown-elf-as]: assembly fails, but fixed with a blank line
https://sourceware.org/bugzilla/show_bug.cgi?id=28762 Bug ID: 28762 Summary: [z80-unknown-elf-as]: assembly fails, but fixed with a blank line Product: binutils Version: 2.36.1 Status: UNCONFIRMED Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: petemoore at gmx dot net CC: nickc at redhat dot com, sergey.belyashov at gmail dot com Target Milestone: --- Created attachment 13898 --> https://sourceware.org/bugzilla/attachment.cgi?id=13898=edit Bogus assembly failure fixed by introduction of arbitrary whitespace Attached (rom1.s) is valid assembly code that won't assemble under z80-unknown-elf-as version 2.36.1 on macOS and Linux, yet will assemble with the introduction of almost any (innocuous) change, including non-code changes such as a blank line or a .global directive, anywhere above the reported failure line (10290) of the source code. Since the bogus failure disappears if I delete lines, it is difficult to provide a smaller test case than the full file. However, since I've been able to reproduce it independently on both macOS and Linux, I assume it is nothing to do with my environment, and it should be reasonably easy to reproduce with the exact version of the attached file. To reproduce, download the attached file rom1.s, and run the following: ``` $ # Gas version $ z80-unknown-elf-as --version GNU assembler (GNU Binutils) 2.36.1 Copyright (C) 2021 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or later. This program has absolutely no warranty. This assembler was configured for a target of `z80-unknown-elf'. $ z80-unknown-elf-as rom1.s rom1.s: Assembler messages: rom1.s:10290: Error: bad instruction syntax $ # Insert blank line at top of file... $ (echo; cat rom1.s) > rom1_fixed.s $ # Assembly now passes, despite no code change! $ z80-unknown-elf-as rom1_fixed.s $ echo $? 0 $ # Show the lines around the reported failure... $ sed -n 10287,10293p rom1.s randomize: CALLfind_int2 ; routine FIND-INT2 puts parameter in BC. LD A,B ; test this OR C ; for zero. JR NZ,rand_1 ; forward to RAND-1 if not zero. $ ``` As you see above, the failure "rom1.s:10290: Error: bad instruction syntax" appears to be bogus, since the instruction "LD A,B" is valid, and as shown in the console output above, just inserting a blank line at the top of the file fixes the issue. I haven't yet tried assembling with z80-unknown-elf-as version 2.37, I can do that too, if that is useful. -- You are receiving this mail because: You are on the CC list for the bug.
Re: readelf: also dump the address contained in offset on R_386_RELATIVE relocs
Hi Andrea, I see that, when dumping R_386_RELATIVE relocs in readelf, the format is like this Offset InfoTypeSym.Value Sym. Name 3d01 0008 R_386_RELATIVE If I understand that type of relocation correctly, another information is missing: the address contained at the given offset, which ld.so adds to the load address of the module and then overwrites at the same offset. I think it is reasonable to provide that information. Some users might need it for debugging or learning purposes. It could indeed be useful, but there is a downside: adding extra information like this tends to break the binutils testsuites (since some tests wll not be expecting the extra output) - and more seriously, it tends to break user scripts that expect readelf's output to be in a certain format. This is not to say that the feature should not be added, but rather than it would probably be best to have it as an optional extra, controlled via a command line option. (Eg the --arch-specific option). Also, this looks like it might be a suitable project for someone interested in learning about the binutils. So I am hoping that you, or someone else will volunteer to have a go ... :-) Cheers Nick
