[Bug binutils/29278] New: gdb crashes on interrupt (non-stop mode, target extended-remote)
https://sourceware.org/bugzilla/show_bug.cgi?id=29278
Bug ID: 29278
Summary: gdb crashes on interrupt (non-stop mode, target
extended-remote)
Product: binutils
Version: unspecified
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: Manfred.Steiner at gmx dot at
Target Milestone: ---
binutils-gdb Version: 13.0.50.20220615-git
When working with a AVR Stub in non-stop mode via target extended-remote, it is
possible to start without program running (stub returns an empty thread list on
qfThreadInfo request), or to detach from program.
If you execute interrupt in this situation on gdb command line, gdb crashes
with backtrace output.
inferior.c:304: internal-error: find_inferior_pid: Assertion `pid != 0' failed.
A problem internal to GDB has been detected,
...
.../binutils-gdb/gdb/inferior.c:299
...
Looking inside source code shows the cause:
file gdb/inferior.c:298:
struct inferior *
find_inferior_pid (process_stratum_target *targ, int pid)
{
/* Looking for inferior pid == 0 is always wrong, and indicative of
a bug somewhere else. There may be more than one with pid == 0,
for instance. */
gdb_assert (pid != 0);
...
I think the comment is outdated and it would be better to replace the assert
with:
if (pid == 0) {
return NULL;
}
because pid == 0 is a possible case in non-stop mode when using target
extended-remote.
Then the interrupt command would be ignored (or result in an error message when
the stub returns an error).
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug gprofng/28968] gprofng doesn't build with -Werror=format-security
https://sourceware.org/bugzilla/show_bug.cgi?id=28968 Vladimir Mezentsev changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Vladimir Mezentsev --- I also fixed for -Werror=format-truncation: for Author: Vladimir Mezentsev Date: Thu Jun 16 12:31:05 2022 -0700 gprofng: fix build with -Werror=format-truncation gprofng/ChangeLog 2022-06-16 Vladimir Mezentsev * configure.ac: Remove -Wno-format-truncation. * src/Makefile.am: Likewise. * configure: Rebuild. * src/Makefile.in: Rebuild. * common/hwctable.c: Fix -Werror=format-truncation errors. * src/ipc.cc: Likewise. * src/parse.cc: Likewise. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gprofng/29113] Build error for x86_64-w64-mingw32 host since CLOCK_MONOTONIC does not exist
https://sourceware.org/bugzilla/show_bug.cgi?id=29113 Vladimir Mezentsev changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Vladimir Mezentsev --- Update status as resolved/fixed. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gprofng/29143] gprofng fails to build on x86_64-linux-gnux32
https://sourceware.org/bugzilla/show_bug.cgi?id=29143 Vladimir Mezentsev changed: What|Removed |Added Resolution|--- |FIXED Status|WAITING |RESOLVED --- Comment #6 from Vladimir Mezentsev --- Update status as resolved/fixed. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29267] readelf..info misreports DW_FORM_loclistx, DW_FORM_rnglistx
https://sourceware.org/bugzilla/show_bug.cgi?id=29267 --- Comment #10 from Vsevolod Alekseyev --- There is a bit of parsing complication here that I don't think the current parser quite appreciates. The DWARF bitness may vary between CUs in indexed sections, and short of going through the headers, linked list style, there is no way to determine the bitness for any given section from the DIE data. The structure of debug_loclists goes like this: CU_header_0: length AKA bitness indicator (4 or 12) version (2) address_size (1) selector_size (1) offset_entry_count (4) offsets[0] (4 or 8)<-- DW_AT_loclists_base points here offsets[1] (4 or 8) ...more offsets ...the actual loclists The offsets table contain the offsets of the target loclists, relative to the offsets table start. The size of the offset (4 or 8) is determined by the length field in the header, the usual DWARF style. Now, from the value of DW_AT_loclists_base alone, it's pretty much impossible to tell whether the section is 32- or 64-bit DWARF (except for the 0th CU, where the DW_AT_loclists_base can be either 12 or 20). In subsequent CUs, you can't seek back from the offset table to the top of header, because it's variable length. If you look at the dword at DW_AT_loclists_base-20, it may be 0x by pure accident. Similar situation in debug_rnglists, debug_addr, debug_str_offsets. A proper parser should go through all CU headers in the section (you can sort of fast-forward through them by skipping by length), determine and store the bitness of each, and then recover the bitness of any particular CU by matching the DW_AT_rnglists_base against that. One *slightly* better alternative would be - reuse the bitness from the corresponding CU in the debug_info. While it is possible to compose a correct DWARF dataset where the bitness between contributions from the same compile unit in different section varies, it would be a pain in the neck for the compiler vendor. Or you can just assume 32 bits. The spec encourages the implementors not to use 64-bit DWARF unless absolutely necessary. How often does one see 4GB+ sections in a binary? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29267] readelf..info misreports DW_FORM_loclistx, DW_FORM_rnglistx
https://sourceware.org/bugzilla/show_bug.cgi?id=29267 --- Comment #9 from Vsevolod Alekseyev --- The patches are supposed to be cumulative, right? And the first one is already not in the bug? So there is no way to apply them on top of HEAD anymore, unless I've saved all three? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29267] readelf..info misreports DW_FORM_loclistx, DW_FORM_rnglistx
https://sourceware.org/bugzilla/show_bug.cgi?id=29267 --- Comment #8 from Vsevolod Alekseyev --- The warnings that "readelf --debug-dump=info" is giving on that binary are all bogus; they all have to do with readelf looking for the offset in the wrong place. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29267] readelf..info misreports DW_FORM_loclistx, DW_FORM_rnglistx
https://sourceware.org/bugzilla/show_bug.cgi?id=29267 --- Comment #7 from Vsevolod Alekseyev --- Created attachment 14162 --> https://sourceware.org/bugzilla/attachment.cgi?id=14162&action=edit Test binary Have a test binary. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29267] readelf..info misreports DW_FORM_loclistx, DW_FORM_rnglistx
https://sourceware.org/bugzilla/show_bug.cgi?id=29267 Nick Clifton changed: What|Removed |Added Attachment #14160|0 |1 is obsolete|| --- Comment #6 from Nick Clifton --- Created attachment 14161 --> https://sourceware.org/bugzilla/attachment.cgi?id=14161&action=edit Proposed Patch Ok, lets see if the third time is the charm. I am not 100% about the offset computation inside fetch_indexed_value() though, so some tweaking may still be needed. It would be helpful if there was a test case I could examine... -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29266] readelf ..info misreports DW_FORM_strxN
https://sourceware.org/bugzilla/show_bug.cgi?id=29266 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #3 from Nick Clifton --- (In reply to Alan Modra from comment #2) > Also, DW_AT_str_offsets_base doesn't appear to be handled in binutils/dwarf.c I think that this might be resolved by Kumar's recent commit. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29267] readelf..info misreports DW_FORM_loclistx, DW_FORM_rnglistx
https://sourceware.org/bugzilla/show_bug.cgi?id=29267 Nick Clifton changed: What|Removed |Added Attachment #14159|0 |1 is obsolete|| --- Comment #5 from Nick Clifton --- Created attachment 14160 --> https://sourceware.org/bugzilla/attachment.cgi?id=14160&action=edit Proposed Patch oops - I missed out a thunk... -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29267] readelf..info misreports DW_FORM_loclistx, DW_FORM_rnglistx
https://sourceware.org/bugzilla/show_bug.cgi?id=29267 --- Comment #4 from Vsevolod Alekseyev --- Even declared as "dwarf_vma index", the numbers are all wrong. Looks like fetch_indexed_value is not taking into account the DW_AT_loclists_base/DW_AT_rnglists_base attribute value, which stores the address of the offset table of the current compile unit's contribution in debug_loclists/debug_rnglists, respectively. Similar issue here: #29266. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29267] readelf..info misreports DW_FORM_loclistx, DW_FORM_rnglistx
https://sourceware.org/bugzilla/show_bug.cgi?id=29267 --- Comment #3 from Vsevolod Alekseyev --- Comment on attachment 14159 --> https://sourceware.org/bugzilla/attachment.cgi?id=14159 Proposed Patch Does not compile, "index" is not declared. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29267] readelf..info misreports DW_FORM_loclistx, DW_FORM_rnglistx
https://sourceware.org/bugzilla/show_bug.cgi?id=29267 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #2 from Nick Clifton --- Created attachment 14159 --> https://sourceware.org/bugzilla/attachment.cgi?id=14159&action=edit Proposed Patch Based upon your observation, would you mind trying out this patch and letting me know if it works ? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29270] Signed integer overflow with DW_FORM_udata
https://sourceware.org/bugzilla/show_bug.cgi?id=29270 --- Comment #3 from Vsevolod Alekseyev --- Confirmed, thank you! -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29267] readelf..info misreports DW_FORM_loclistx, DW_FORM_rnglistx
https://sourceware.org/bugzilla/show_bug.cgi?id=29267 --- Comment #1 from Vsevolod Alekseyev --- The culprit is, probably, the case statement at dwarf.c:2774, where fetch_indexed_addr() is being called both for DW_FORM_addrxN (where it belongs) and for DW_FORM_loclistx/DW_FORM_rnglistx (where it does not). For the latter, fetch_indexed_value should be used instead. The text description is off, too. The loclistx value doesn't represent an address index. -- You are receiving this mail because: You are on the CC list for the bug.
