[Bug gas/28699] New: Bad interaction between .loc, .byte causes incorrect DWARF line table, causes corruption under gdb
https://sourceware.org/bugzilla/show_bug.cgi?id=28699
Bug ID: 28699
Summary: Bad interaction between .loc, .byte causes incorrect
DWARF line table, causes corruption under gdb
Product: binutils
Version: 2.38 (HEAD)
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: gas
Assignee: unassigned at sourceware dot org
Reporter: keno at juliacomputing dot com
Target Milestone: ---
Consider the following code which is reduced from wine:
minimal.c
```
void *wine_ntdll_get_thread_data() {
void *teb;
__asm__(".byte 0x65\n\tmovq (0x30),%0" : "=r" (teb));
return teb;
}
```
gcc -g3 -S -o minimal.S minimal.c
```
[snip]
.loc 1 3 5
#APP
# 3 "minimal.c" 1
.byte 0x65
movq (0x30),%rax
# 0 "" 2
#NO_APP
[snip]
```
$ as minimal.S -o minimal.o
objdump -d minimal.o
```
Disassembly of section .text:
:
0: f3 0f 1e fa endbr64
4: 55 push %rbp
5: 48 89 e5mov%rsp,%rbp
8: 65 48 8b 04 25 30 00mov%gs:0x30,%rax
f: 00 00
11: 48 89 45 f8 mov%rax,-0x8(%rbp)
15: 48 8b 45 f8 mov-0x8(%rbp),%rax
19: 5d pop%rbp
1a: c3 retq
```
objdump --dwarf=line minimal.o
```
Line Number Statements:
[0x0048] Set column to 36
[0x004a] Extended opcode 2: set Address to 0x0
[0x0055] Copy
[0x0056] Set column to 5
[0x0058] Special opcode 133: advance Address by 9 to 0x9 and Line by 2
to 3
[0x0059] Set column to 12
[0x005b] Special opcode 174: advance Address by 12 to 0x15 and Line by 1
to 4
[0x005c] Set column to 1
[0x005e] Special opcode 62: advance Address by 4 to 0x19 and Line by 1
to 5
[0x005f] Advance PC by 2 to 0x1b
[0x0061] Extended opcode 1: End of Sequence
```
Note that the line table has an entry at address `0x9` which is
in the middle of the instruction at `0x8`. Because of this,
GDB will set a breakpoint there and subsequently execute
the instruction without the gs prefix causing crashes.
I believe GAS is wrong here to have put 0x9 as the line
table entry and instead should have put it before the `.byte`
at 0x8.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug binutils/28687] Undefined behavior in bfd/dwarf1.c
https://sourceware.org/bugzilla/show_bug.cgi?id=28687 Nikita Popov changed: What|Removed |Added CC||npv1310 at gmail dot com --- Comment #2 from Nikita Popov --- Created attachment 13857 --> https://sourceware.org/bugzilla/attachment.cgi?id=13857&action=edit PATCH: Switch to a pointer difference in comparisons I'm submitting a proposed patch to prevent that case. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26391] Question regarding duplicate symbols
https://sourceware.org/bugzilla/show_bug.cgi?id=26391 John Paul Adrian Glaubitz changed: What|Removed |Added CC||glaubitz at physik dot fu-berlin.d ||e --- Comment #10 from John Paul Adrian Glaubitz --- It seems that this test is failing on sparc64: FAIL: Run pr26391-5 FAIL: Run pr26391-6 See: https://buildd.debian.org/status/fetch.php?pkg=binutils&arch=sparc64&ver=2.37-10&stamp=1637614637&raw=0 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28691] `nm-new -l` output changes per run
https://sourceware.org/bugzilla/show_bug.cgi?id=28691 Alan Modra changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at sourceware dot org |amodra at gmail dot com Ever confirmed|0 |1 Last reconfirmed||2021-12-15 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/28699] Bad interaction between .loc, .byte causes incorrect DWARF line table, causes corruption under gdb
https://sourceware.org/bugzilla/show_bug.cgi?id=28699 Alan Modra changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #1 from Alan Modra --- ".byte xx" is not an instruction as far as gas is concerned, it's just data. The instruction gas saw was "movq (0x30),%rax" and I believe it is quite correct to emit dwarf line info for that instruction. Write "movq gs:0x30,%0" if you want this to work. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/28603] Incorrect branch offset from the start of a function after enable LTO
https://sourceware.org/bugzilla/show_bug.cgi?id=28603 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #3 from Nick Clifton --- (In reply to Eason Lai from comment #1) > I have tried to reproduce the issue by creating a simple code for reference, > but no lucky. If anyone else could give me hint which part of linker may > causes this problem, I will try deep dive the source code and find I can > help or not. Thank you. Is this ARM/AArch64 code that you are talking about ? If so then the code you will want to look at is in the bfd/ directory, specifically the elf32-arm.c and/or elfxx-aarch64.c files. Look for the functions which are used to resolve relocations. It is strange that LTO is causing this problem. I am not sure why this would cause the effect that you are seeing. Is it possible that the bad code still has a relocation associated with it which would put the correct address into place when the program is loaded ? Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28690] `nm-new -a -l -D` produces inconsistent outputs.
https://sourceware.org/bugzilla/show_bug.cgi?id=28690 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #1 from Nick Clifton --- (In reply to Shaohua Li from comment #0) Hi Shaohua, > $ diff out_gcc11 out_clang13 > < /nm-new/bin/ DWARF error: could not find abbrev number 93 > 18c17,18 > < N .debug_info > --- > > N .debug_info/nm-new/bin/ DWARF error: could not find abbrev > > number 93 I think that this might actually be a "feature" rather than a bug. What appears to be happening is that the "DWARF error" message is being printed to stderr, whilst the " N .debug_info" message is being printed to stdout. But somehow you are collecting both streams into your output file (which should not be happening with just the ">" operator...) and the order in which the messages are printed out is different bewteen the two compilers. This suggests that the code sequences have been compiled slightly differently. But basically both versions are doing the same thing and producing the same output. It is just the synchronization between stdout and stderr that is different. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28687] Undefined behavior in bfd/dwarf1.c
https://sourceware.org/bugzilla/show_bug.cgi?id=28687 --- Comment #3 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Nick Clifton : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=4d3605c8ca92bcde848581a8ec031827c798501b commit 4d3605c8ca92bcde848581a8ec031827c798501b Author: Nikita Popov Date: Wed Dec 15 17:49:06 2021 + Fix an undefined behaviour in the BFD library's DWARF parser. PR 28687 * dwarf1.c (parse_die): Fix undefined behaviour in range tests. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28687] Undefined behavior in bfd/dwarf1.c
https://sourceware.org/bugzilla/show_bug.cgi?id=28687 Nick Clifton changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED CC||nickc at redhat dot com --- Comment #4 from Nick Clifton --- Hi Nikita, Thanks for reporting this problem - and providing a fix! I have now checked in your patch. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28691] `nm-new -l` output changes per run
https://sourceware.org/bugzilla/show_bug.cgi?id=28691 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #1 from Nick Clifton --- I think that this PR might be a duplicate of 28960... -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26391] Question regarding duplicate symbols
https://sourceware.org/bugzilla/show_bug.cgi?id=26391 --- Comment #11 from John Paul Adrian Glaubitz --- (In reply to John Paul Adrian Glaubitz from comment #10) > It seems that this test is failing on sparc64: > > FAIL: Run pr26391-5 > FAIL: Run pr26391-6 > > See: > https://buildd.debian.org/status/fetch.php?pkg=binutils&arch=sparc64&ver=2. > 37-10&stamp=1637614637&raw=0 I have verified that this commit introduced the regression on sparc64: 496afd17055aeb7d8f45e01715c475664f2b73bd is the first bad commit commit 496afd17055aeb7d8f45e01715c475664f2b73bd Author: H.J. Lu Date: Sat Sep 12 05:37:30 2020 -0700 elf: Add -z unique-symbol to avoid duplicated local symbol names The symbol string table in the .symtab section is optional and cosmetic. The contents of the .symtab section have no impact on run-time execution. The symbol names in the symbol string table help distinguish addresses at different locations. Add a linker option, -z unique-symbol, to avoid duplicated local symbol names in the symbol string table. This feature was well received by the livepatch maintainers. It not only solves the duplicated local symbol name problem, but also would allow livepatch to more precisely locate duplicate symbols in general for patching. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28691] `nm-new -l` output changes per run
https://sourceware.org/bugzilla/show_bug.cgi?id=28691 --- Comment #2 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Alan Modra : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=161cdabc3927b144ffcff9bf7b1daf5fe32a193c commit 161cdabc3927b144ffcff9bf7b1daf5fe32a193c Author: Alan Modra Date: Wed Dec 15 15:06:26 2021 +1030 PR28691, validate dwarf attribute form PR28691 is a fuzzing PR that triggers a non-problem of "output changes per run" with PIEs and/or different compilers. I've closed similar PRs before as wontfix, but I guess there will be no end of this type of PR. The trigger is an attribute that usually takes one of the offset/constant reference DW_FORMs being given an indexed string DW_FORM. The bfd reader doesn't support indexed strings and returns an error string instead. The address of the string varies with PIE runs and/or compiler, and we allow that address to appear in output. Fix this by validating integer attribute forms, as we do for string form attributes. PR 28691 * dwarf2.c (is_str_attr): Rename to.. (is_str_form): ..this. Change param type. Update calls. (is_int_form): New function. (read_attribute_value): Handle DW_FORM_addrx2. (find_abstract_instance): Validate form when using attr.u.val. (scan_unit_for_symbols, parse_comp_unit): Likewise. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28691] `nm-new -l` output changes per run
https://sourceware.org/bugzilla/show_bug.cgi?id=28691 Alan Modra changed: What|Removed |Added Target Milestone|--- |2.38 Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Alan Modra --- Fixed -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28697] objdump often doesn't look for separate debug files when using "build-id" style
https://sourceware.org/bugzilla/show_bug.cgi?id=28697 Travis Downs changed: What|Removed |Added Summary|objdump doesn't look for|objdump often doesn't look |separate debug styles using |for separate debug files |"build-id" style|when using "build-id" style -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28687] Undefined behavior in bfd/dwarf1.c
https://sourceware.org/bugzilla/show_bug.cgi?id=28687 --- Comment #5 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Alan Modra : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=05f62e0c9a0b14e211c6b2b6234095b50794b20b commit 05f62e0c9a0b14e211c6b2b6234095b50794b20b Author: Alan Modra Date: Thu Dec 16 10:50:58 2021 +1030 Re: Fix an undefined behaviour in the BFD library's DWARF parser Using an unsigned int cast (to 32 bits) on a pointer difference (of possibly 64 bits) is wrong. Even though it will work on all real object files, the fuzzers will eventually find this hole. PR 28687 * dwarf1.c (parse_die): Cast pointer difference to size_t. Catch another possible pointer overflow. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26391] Question regarding duplicate symbols
https://sourceware.org/bugzilla/show_bug.cgi?id=26391 --- Comment #12 from H.J. Lu --- I don't know why "ld -r -z unique-symbol" generates incorrect output on sparc64. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28694] stabs.c: Out-of-bounds write in stab_xcoff_builtin_type
https://sourceware.org/bugzilla/show_bug.cgi?id=28694 --- Comment #3 from Pavel Mayorov --- CVE-2021-45078 -- You are receiving this mail because: You are on the CC list for the bug.
