A following patch will add a testcase that has two processes with
threads stepping over a breakpoint continuously, and then detaches
from one of the processes while threads are running. The other
process continues stepping over its breakpoint. And then the testcase
sends a SIGUSR1, expecting that GDB reports it. That would sometimes
hang against gdbserver, due to the bugs fixed here. Both bugs are
related, in that they're about remote protocol asynchronous Stop
notifications. There's a bug in GDB, and another in GDBserver.
The GDB bug:
- when we detach from a process, the remote target discards any
pending RSP notification related to that process, including the
in-flight, yet-unacked notification. Discarding the in-flight
notification is the problem. Until the in-flight notification is
acked with a vStopped packet, the server won't send another %Stop
notification. As a result, the debug session gets messed up. In
the new testcase's case, GDB would hang inside stop_all_threads,
waiting for a stop for one of the process'es threads, which never
arrived -- its stop reply was permanently stuck in the stop reply
queue, waiting for a vStopped packet that never arrived.
In summary:
1. GDBserver sends stop notification about thread X, the remote
target receives it and stores it
2. At the same time, GDB detaches thread X's inferior
3. The remote target discards the received stop notification
4. GDBserver waits forever for the ack
The GDBserver bug:
GDBserver has the opposite bug. It also discards notifications for
the process being detached. If that discards the head of the
notification queue, when gdb sends an ack, it ends up acking the
_next_ notification. Meaning, gdb loses one notification. In the
testcase, this results in a similar hang in stop_all_threads.
So we have two very similar bugs in GDB and GDBserver, both resulting
in a similar symptom. That's why I'm fixing them both at the same
time.
gdb/ChangeLog:
* remote.c (remote_notif_stop_ack): Don't error out on
TARGET_WAITKIND_IGNORE; instead, just ignore the notification.
(remote_target::discard_pending_stop_replies): Don't delete
in-flight notification; instead, clear its contents.
gdbserver/ChangeLog:
* server.cc (discard_queued_stop_replies): Don't ever discard the
notification at the head of the list.
This adds a testcase exercising attaching to a multi-threaded process,
in all combinations of:
- set non-stop on/off
- maint target non-stop off/on
- "attach" vs "attach &"
This exercises the bugs fixed in the two previous patches.
gdb/testsuite/ChangeLog:
* gdb.threads/attach-non-stop.c: New file.
* gdb.threads/attach-non-stop.exp: New file.
With "target extended-remote" + "maint set target-non-stop", attaching
hangs like so:
(gdb) attach 1244450
Attaching to process 1244450
[New Thread 1244450.1244450]
[New Thread 1244450.1244453]
[New Thread 1244450.1244454]
[New Thread 1244450.1244455]
[New Thread 1244450.1244456]
[New Thread 1244450.1244457]
[New Thread 1244450.1244458]
[New Thread 1244450.1244459]
[New Thread 1244450.1244461]
[New Thread 1244450.1244462]
[New Thread 1244450.1244463]
* hang *
Attaching to the hung GDB shows that GDB is busy in an infinite loop
in stop_all_threads:
(top-gdb) bt
#0 stop_all_threads () at /home/pedro/gdb/binutils-gdb/src/gdb/infrun.c:4755
#1 0x000055555597b424 in stop_waiting (ecs=0x7fffffffd930) at /home/pedro/gdb/binutils-gdb/src/gdb/infrun.c:7738
#2 0x0000555555976fba in handle_signal_stop (ecs=0x7fffffffd930) at /home/pedro/gdb/binutils-gdb/src/gdb/infrun.c:5868
#3 0x0000555555975f6a in handle_inferior_event (ecs=0x7fffffffd930) at /home/pedro/gdb/binutils-gdb/src/gdb/infrun.c:5527
#4 0x0000555555971da4 in fetch_inferior_event () at /home/pedro/gdb/binutils-gdb/src/gdb/infrun.c:3910
#5 0x00005555559540b2 in inferior_event_handler (event_type=INF_REG_EVENT) at /home/pedro/gdb/binutils-gdb/src/gdb/inf-loop.c:42
#6 0x000055555597e825 in infrun_async_inferior_event_handler (data=0x0) at /home/pedro/gdb/binutils-gdb/src/gdb/infrun.c:9162
#7 0x0000555555687d1d in check_async_event_handlers () at /home/pedro/gdb/binutils-gdb/src/gdb/async-event.c:328
#8 0x0000555555e48284 in gdb_do_one_event () at /home/pedro/gdb/binutils-gdb/src/gdbsupport/event-loop.cc:216
#9 0x00005555559e7512 in start_event_loop () at /home/pedro/gdb/binutils-gdb/src/gdb/main.c:347
#10 0x00005555559e765d in captured_command_loop () at /home/pedro/gdb/binutils-gdb/src/gdb/main.c:407
#11 0x00005555559e8f80 in captured_main (data=0x7fffffffdb70) at /home/pedro/gdb/binutils-gdb/src/gdb/main.c:1239
#12 0x00005555559e8ff2 in gdb_main (args=0x7fffffffdb70) at /home/pedro/gdb/binutils-gdb/src/gdb/main.c:1254
#13 0x0000555555627c86 in main (argc=12, argv=0x7fffffffdc88) at /home/pedro/gdb/binutils-gdb/src/gdb/gdb.c:32
The problem is that the remote sends stops for all the threads:
Packet received: l/home/pedro/gdb/binutils-gdb/build/gdb/testsuite/outputs/gdb.threads/attach-non-stop/attach-non-stop
Sending packet: $vStopped#55...Packet received: T0006:f06e25edec7f0000;07:f06e25edec7f0000;10:f14190ccf4550000;thread:p12fd22.12fd2f;core:15;
Sending packet: $vStopped#55...Packet received: T0006:f0dea5f0ec7f0000;07:f0dea5f0ec7f0000;10:e84190ccf4550000;thread:p12fd22.12fd27;core:4;
Sending packet: $vStopped#55...Packet received: T0006:f0ee25f1ec7f0000;07:f0ee25f1ec7f0000;10:f14190ccf4550000;thread:p12fd22.12fd26;core:5;
Sending packet: $vStopped#55...Packet received: T0006:f0bea5efec7f0000;07:f0bea5efec7f0000;10:f14190ccf4550000;thread:p12fd22.12fd29;core:1;
Sending packet: $vStopped#55...Packet received: T0006:f0ce25f0ec7f0000;07:f0ce25f0ec7f0000;10:e84190ccf4550000;thread:p12fd22.12fd28;core:a;
Sending packet: $vStopped#55...Packet received: T0006:f07ea5edec7f0000;07:f07ea5edec7f0000;10:e84190ccf4550000;thread:p12fd22.12fd2e;core:f;
Sending packet: $vStopped#55...Packet received: T0006:f0ae25efec7f0000;07:f0ae25efec7f0000;10:df4190ccf4550000;thread:p12fd22.12fd2a;core:6;
Sending packet: $vStopped#55...Packet received: T0006:0000000000000000;07:c0e8a381fe7f0000;10:bf43b4f1ec7f0000;thread:p12fd22.12fd22;core:2;
Sending packet: $vStopped#55...Packet received: T0006:f0fea5f1ec7f0000;07:f0fea5f1ec7f0000;10:df4190ccf4550000;thread:p12fd22.12fd25;core:8;
Sending packet: $vStopped#55...Packet received: T0006:f09ea5eeec7f0000;07:f09ea5eeec7f0000;10:e84190ccf4550000;thread:p12fd22.12fd2b;core:b;
Sending packet: $vStopped#55...Packet received: OK
But then wait_one never consumes them, always hitting this path:
4473 if (nfds == 0)
4474 {
4475 /* No waitable targets left. All must be stopped. */
4476 return {NULL, minus_one_ptid, {TARGET_WAITKIND_NO_RESUMED}};
4477 }
Resulting in GDB constanly calling target_stop to stop threads, but
the remote target never reporting back the stops to infrun.
That TARGET_WAITKIND_NO_RESUMED path shown above is always taken
because here, in wait_one too, just above:
4428 for (inferior *inf : all_inferiors ())
4429 {
4430 process_stratum_target *target = inf->process_target ();
4431 if (target == NULL
4432 || !target->is_async_p ()
^^^^^^^^^^^^^^^^^^^^^
4433 || !target->threads_executing)
4434 continue;
... the remote target is not async.
And in turn that happened because extended_remote_target::attach
misses enabling async in the target-non-stop path.
A testcase exercising this will be added in a following patch.
gdb/ChangeLog:
* remote.c (extended_remote_target::attach): Set target async in
the target-non-stop path too.
Attaching in non-stop mode currently misbehaves, like so:
(gdb) attach 1244450
Attaching to process 1244450
[New LWP 1244453]
[New LWP 1244454]
[New LWP 1244455]
[New LWP 1244456]
[New LWP 1244457]
[New LWP 1244458]
[New LWP 1244459]
[New LWP 1244461]
[New LWP 1244462]
[New LWP 1244463]
No unwaited-for children left.
At this point, GDB's stopped/running thread state is out of sync with
the inferior:
(gdb) info threads
Id Target Id Frame
* 1 LWP 1244450 "attach-non-stop" 0xf1b443bf in ?? ()
2 LWP 1244453 "attach-non-stop" (running)
3 LWP 1244454 "attach-non-stop" (running)
4 LWP 1244455 "attach-non-stop" (running)
5 LWP 1244456 "attach-non-stop" (running)
6 LWP 1244457 "attach-non-stop" (running)
7 LWP 1244458 "attach-non-stop" (running)
8 LWP 1244459 "attach-non-stop" (running)
9 LWP 1244461 "attach-non-stop" (running)
10 LWP 1244462 "attach-non-stop" (running)
11 LWP 1244463 "attach-non-stop" (running)
(gdb)
(gdb) interrupt -a
(gdb)
*nothing*
The problem is that attaching installs an inferior continuation,
called when the target reports the initial attach stop, here, in
inf-loop.c:inferior_event_handler:
/* Do all continuations associated with the whole inferior (not
a particular thread). */
if (inferior_ptid != null_ptid)
do_all_inferior_continuations (0);
However, currently in non-stop mode, inferior_ptid is still null_ptid
when we get here.
If you try to do "set debug infrun 1" to debug the problem, however,
then the attach completes correctly, with GDB reporting a stop for
each thread.
The bug is that we're missing a switch_to_thread/context_switch call
when handling the initial stop, here:
if (stop_soon == STOP_QUIETLY_NO_SIGSTOP
&& (ecs->event_thread->suspend.stop_signal == GDB_SIGNAL_STOP
|| ecs->event_thread->suspend.stop_signal == GDB_SIGNAL_TRAP
|| ecs->event_thread->suspend.stop_signal == GDB_SIGNAL_0))
{
stop_print_frame = true;
stop_waiting (ecs);
ecs->event_thread->suspend.stop_signal = GDB_SIGNAL_0;
return;
}
Note how the STOP_QUIETLY / STOP_QUIETLY_REMOTE case above that does
call context_switch.
And the reason "set debug infrun 1" "fixes" it, is that the debug path
has a switch_to_thread call.
This patch fixes it by moving the main context_switch call earlier.
It also removes the:
if (ecs->ptid != inferior_ptid)
check at the same time because:
#1 - that is half of what context_switch already does
#2 - deprecated_context_hook is only used in Insight, and all it does
is set an int. It won't care if we call it when the current
thread hasn't actually changed.
A testcase exercising this will be added in a following patch.
gdb/ChangeLog:
PR gdb/27055
* infrun.c (handle_signal_stop): Move main context_switch call
earlier, before STOP_QUIETLY_NO_SIGSTOP.
This patch makes the inferior command display information about the
current inferior when called with no argument. This behavior is similar
to the one of the thread command.
Before patch:
(gdb) info inferior
Num Description Connection Executable
* 1 process 19221 1 (native) /home/lsix/tmp/a.out
2 process 19239 1 (native) /home/lsix/tmp/a.out
(gdb) inferior 2
[Switching to inferior 2 [process 19239] (/home/lsix/tmp/a.out)]
[Switching to thread 2.1 (process 19239)]
#0 0x0000000000401146 in main ()
(gdb) inferior
Argument required (expression to compute).
After patch:
(gdb) info inferior
Num Description Connection Executable
* 1 process 18699 1 (native) /home/lsix/tmp/a.out
2 process 18705 1 (native) /home/lsix/tmp/a.out
(gdb) inferior 2
[Switching to inferior 2 [process 18705] (/home/lsix/tmp/a.out)]
[Switching to thread 2.1 (process 18705)]
#0 0x0000000000401146 in main ()
(gdb) inferior
[Current inferior is 2 [process 18705] (/home/lsix/tmp/a.out)]
gdb/doc/ChangeLog:
* gdb.texinfo (Inferiors Connections and Programs): Document the
inferior command when used without argument.
gdb/ChangeLog:
* NEWS: Add entry for the behavior change of the inferior command.
* inferior.c (inferior_command): When no argument is given to the
inferior command, display info about the currently selected
inferior.
gdb/testsuite/ChangeLog:
* gdb.base/inferior-noarg.c: New test.
* gdb.base/inferior-noarg.exp: New test.
It is possible for the tables in the .debug_{rng,loc}lists sections to
not have an array of offsets. In that case, the offset_entry_count
field of the header is 0. The forms DW_FORM_{rng,loc}listx (reference
by index) can't be used with that table. Instead, the
DW_FORM_sec_offset form, which references a {rng,loc}list by direct
offset in the section, must be used. From what I saw, this is what GCC
currently produces.
Add tests for this case. I didn't see any bug related to this, I just
think that it would be nice to have coverage for this. A new
`-with-offset-array` option is added to the `table` procs, used when
generating {rng,loc}lists, to decide whether to generate the offset
array.
gdb/testsuite/ChangeLog:
* lib/dwarf.exp (rnglists): Add -no-offset-array option to
table proc.
* gdb.dwarf2/rnglists-sec-offset.exp: Add test for
.debug_rnglists table without offset array.
* gdb.dwarf2/loclists-sec-offset.exp: Add test for
.debug_loclists table without offset array.
Change-Id: I8e34a7bf68c9682215ffbbf66600da5b7db91ef7
I think it's wrong that read_loclist_index and read_rnglist_index return
a CORE_ADDR. A CORE_ADDR is an address in the program. These functions
return offset in sections (.debug_loclists and .debug_rnglists). I
think sect_offset is more appropriate.
I'm wondering if struct attribute should have a "set_sect_offset"
method, that takes a sect_offset parameter, or if it's better to be
left as a simple "unsigned".
gdb/ChangeLog:
* dwarf2/read.c (read_loclist_index, read_rnglist_index): Return
a sect_offset.
(read_attribute_reprocess): Adjust.
Change-Id: I0e22e0864130fb490072b41ae099762918b8ad4d
Consider the test case added in this patch. It defines a compilation
unit with a DW_AT_rnglists_base attribute (used for attributes of form
DW_FORM_rnglistx), but also uses DW_AT_ranges of form
DW_FORM_sec_offset:
0x00000027: DW_TAG_compile_unit
DW_AT_ranges [DW_FORM_sec_offset] (0x0000004c
[0x0000000000005000, 0x0000000000006000))
DW_AT_rnglists_base [DW_FORM_sec_offset] (0x00000044)
The DW_AT_rnglists_base does not play a role in reading the DW_AT_ranges of
form DW_FORM_sec_offset, but it should also not do any harm.
This case is currently not handled correctly by GDB. This is not
something that a compiler is likely to emit, but in my opinion there's
no reason why GDB should fail reading it.
The problem is that in partial_die_info::read and a few other places
where the same logic is replicated, the cu->ranges_base value,
containing the DW_AT_rnglists_base value, is wrongfully added to the
DW_AT_ranges value.
It is quite messy how to decide whether cu->ranges_base should be added
to the attribute's value or not. But to summarize, the only time we
want to add it is when the attribute comes from a pre-DWARF 5 split unit
file (a .dwo) [1]. In this case, the DW_AT_ranges attribute from the
split unit file will have form DW_FORM_sec_offset, pointing somewhere in
the linked file's .debug_ranges section. *But* it's not a "true"
DW_FORM_sec_offset, in that it's an offset relative to the beginning of
that CU's contribution in the section, not relative to the beginning of
the section. So in that case, and only that case, do we want to add the
ranges base value, which we found from the DW_AT_GNU_ranges_base
attribute on the skeleton unit.
Almost all instances of the DW_AT_ranges attribute will be found in the
split unit (on DW_TAG_subprogram, for example), and therefore need to
have the ranges base added. However, the DW_TAG_compile_unit DIE in the
skeleton may also have a DW_AT_ranges attribute. For that one, the
ranges base must not be added. Once the DIEs have been loaded in GDB,
however, the distinction between what's coming from the skeleton and
what's coming from the split unit is not clear. It is all merged in one
big happy tree. So how do we know if a given attribute comes from the
split unit or not?
We use the fact that in pre-DWARF 5 split DWARF, DW_AT_ranges is found
on the skeleton's DW_TAG_compile_unit (in the linked file) and never in
the split unit's DW_TAG_compile_unit. This is why you have this in
partial_die_info::read:
int need_ranges_base = (tag != DW_TAG_compile_unit
&& attr.form != DW_FORM_rnglistx);
However, with the corner case described above (where we have a
DW_AT_rnglists_base attribute and a DW_AT_ranges attribute of form
DW_FORM_sec_offset) the condition gets it wrong when it encounters an
attribute like DW_TAG_subprogram with a DW_AT_ranges attribute of
DW_FORM_sec_offset form: it thinks that it is necessary to add the base,
when it reality it is not.
The problem boils down to failing to differentiate these cases:
- a DW_AT_ranges attribute of form DW_FORM_sec_offset in a
pre-DWARF 5 split unit (in which case we need to add the base)
- a DW_AT_ranges attribute of form DW_FORM_sec_offset in a DWARF 5
non-split unit (in which case we must not add the base)
What makes it unnecessarily complex is that the cu->ranges_base field is
overloaded, used to hold the pre-DWARF 5, non-standard
DW_AT_GNU_ranges_base and the DWARF 5 DW_AT_rnglists_base. In reality,
these two are called "bases" but are not the same thing. The result is
that we need twisted conditions to try to determine whether or not we
should add the base to the attribute's value.
To fix it, split the field in two distinct fields. I renamed everything
related to the "old" ranges base to "gnu_ranges_base", to make it clear
that it's about the non-standard, pre-DWARF 5 thing. And everything
related to the DWARF 5 thing gets renamed "rnglists". I think it
becomes much easier to reason this way.
The issue described above gets fixed by the fact that the
DW_AT_rnglists_base value does not end up in cu->gnu_ranges_base, so
cu->gnu_ranges_base stays 0. The condition to determine whether
gnu_ranges_base should be added can therefore be simplified back to:
tag != DW_TAG_compile_unit
... as it was before rnglistx support was added.
Extend the gdb.dwarf2/rnglists-sec-offset.exp to cover this case. I
also extended the test case for loclists similarly, just to see if there
would be some similar problem. There wasn't, but I think it's not a bad
idea to test that case for loclists as well, so I left it in the patch.
[1] https://gcc.gnu.org/wiki/DebugFission
gdb/ChangeLog:
* dwarf2/die.h (struct die_info) <ranges_base>: Split in...
<gnu_ranges_base>: ... this...
<rnglists_base>: ... and this.
* dwarf2/read.c (struct dwarf2_cu) <ranges_base>: Split in...
<gnu_ranges_base>: ... this...
<rnglists_base>: ... and this.
(read_cutu_die_from_dwo): Adjust
(dwarf2_get_pc_bounds): Adjust
(dwarf2_record_block_ranges): Adjust.
(read_full_die_1): Adjust
(partial_die_info::read): Adjust.
(read_rnglist_index): Adjust.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/rnglists-sec-offset.exp: Add test for DW_AT_ranges
of DW_FORM_sec_offset form plus DW_AT_rnglists_base attribute.
* gdb.dwarf2/loclists-sec-offset.exp: Add test for
DW_AT_location of DW_FORM_sec_offset plus DW_AT_loclists_base
attribute
Change-Id: Icd109038634b75d0e6e9d7d1dcb62fb9eb951d83
Add tests for the various issues fixed in the previous patches.
Add a new "loclists" procedure to the DWARF assembler, to allow
generating .debug_loclists sections.
gdb/testsuite/ChangeLog:
PR gdb/26813
* lib/dwarf.exp (_handle_DW_FORM): Handle DW_FORM_loclistx.
(loclists): New proc.
* gdb.dwarf2/loclists-multiple-cus.c: New.
* gdb.dwarf2/loclists-multiple-cus.exp: New.
* gdb.dwarf2/loclists-sec-offset.c: New.
* gdb.dwarf2/loclists-sec-offset.exp: New.
Change-Id: I209bcb2a9482762ae943e518998d1f7761f76928
The _location proc is used to assemble a location description. It needs
to know some contextual information:
- size of an address
- size of an offset (into another DWARF section)
- DWARF version
It currently get all this directly from global variables holding the
compilation unit information. This is fine because as of now, all
location descriptions are generated in the context of creating a
compilation unit. However, a subsequent patch will generate location
descriptions while generating a .debug_loclists section. _location
should therefore no longer rely on the current compilation unit's
properties.
Change it to accept these values as parameters instead of accessing the
values for the CU.
No functional changes intended.
gdb/testsuite/ChangeLog:
* lib/dwarf.exp (_location): Add parameters.
(_handle_DW_FORM): Adjust.
Change-Id: Ib94981979c83ffbebac838081d645ad71c221637
Add tests for the various issues fixed in the previous patches.
Add a new "rnglists" procedure to the DWARF assembler, to allow
generating .debug_rnglists sections. A trivial change is required to
support the DWARF 5 CU header layout.
gdb/testsuite/ChangeLog:
PR gdb/26813
* lib/dwarf.exp (_handle_DW_FORM): Handle DW_FORM_rnglistx.
(cu): Generate header for DWARF 5.
(rnglists): New proc.
* gdb.dwarf2/rnglists-multiple-cus.exp: New.
* gdb.dwarf2/rnglists-sec-offset.exp: New.
Change-Id: I5b297e59c370c60cf671dec19796a6c3b9a9f632
When loading the binary from PR 26813 in GDB, we get:
DW_FORM_rnglistx index pointing outside of .debug_rnglists offset array [in module /home/simark/build/binutils-gdb/gdb/MagicPurse]
... and the symbols fail to load.
In read_rnglist_index and read_loclist_index, we read the header
(documented in sections 7.28 and 7.29 of DWARF 5) of the CU's
contribution to the .debug_rnglists / .debug_loclists sections to
validate that the index we want to read makes sense. However, we always
read the header at the beginning of the section, rather than the header
for the contribution from which we want to read the index.
To illustrate, here's what the binary from PR 26813 contains. There are
two compile units:
0x0000000c: DW_TAG_compile_unit 1
DW_AT_ranges [DW_FORM_rnglistx]: 0x0
DW_AT_rnglists_base [DW_FORM_sec_offset]: 0xC
0x00003ec9: DW_TAG_compile_unit 2
DW_AT_ranges [DW_FORM_rnglistx]: 0xB
DW_AT_rnglists_base [DW_FORM_sec_offset]: 0x85
The layout of the .debug_rnglists is the following:
[0x00, 0x0B]: header for CU 1's contribution
[0x0C, 0x0F]: list of offsets for CU 1 (1 element)
[0x10, 0x78]: range lists data for CU 1
[0x79, 0x84]: header for CU 2's contribution
[0x85, 0xB4]: list of offsets for CU 2 (12 elements)
[0xB5, 0xBD7]: range lists data for CU 2
The DW_AT_rnglists_base attrbute points to the beginning of the list of
offsets for that CU, relative to the start of the .debug_rnglists
section. That's right after the header for that contribution.
When we try to read the DW_AT_ranges attribute for CU 2,
read_rnglist_index reads the header for CU 1 instead of the one for CU
2. Since there's only one element in CU 1's offset list, it believes
(wrongfully) that the index 0xB is out of range.
Fix it by reading the header just before where DW_AT_rnglists_base
points to. With this patch, I am able to load GDB built with clang-11
and -gdwarf-5 in itself, with and without -readnow.
gdb/ChangeLog:
PR gdb/26813
* dwarf2/read.c (read_loclists_rnglists_header): Add
header_offset parameter and use it.
(read_loclist_index): Read header of the current contribution,
not the one at the beginning of the section.
(read_rnglist_index): Likewise.
Change-Id: Ie53ff8251af8c1556f0a83a31aa8572044b79e3d
We hit an assertion when loading the binary from PR 26813. When fixing
it, execution goes a up bit further but then hits another assert, and
another, and another. With these fours fixes, I am able to load the
binary and get to the prompt. An error is shown (index pointing outside
of the section), because the DW_FORM_rnglistx attribute is not read
correctly, but that one is taken care of by the next patch.
The four fixes are:
- attribute::form_requires_reprocessing needs to handle forms
DW_FORM_rnglistx and DW_FORM_loclistx, because set_unsigned_reprocess
is called for them in read_attribute_value.
- read_attribute_reprocess must call set_unsigned for them, not
set_address. The parameter of set_address is a CORE_ADDR, meaning
it's for program addresses. Post-reprocess, DW_FORM_rnglistx and
DW_FORM_loclistx are offsets into their respective sections
(.debug_rnglists and .debug_loclists). set_unsigned is the current
attribute value setter that fits the best. But perhaps we should have
a setter that takes a sect_offset?
- read_attribute_process must call as_unsigned_reprocess instead of
as_unsigned to get the pre-reprocess value, otherwise we hit the
assert inside as_unsigned that makes sure the attribute doesn't need
reprocessing.
- attribute::set_unsigned needs to clear the requires_reprocessing flag,
otherwise it stays set when reprocessing DW_FORM_rnglistx and
DW_FORM_loclistx attributes.
There's another assert that we hit once the next patch is applied, but
since it's in the same vein as the changes in this patch, I included it
in this patch:
- attribute::form_is_unsigned must handle form DW_FORM_loclistx,
otherwise we hit the assert when trying to call set_unsigned for an
attribute of this form. DW_FORM_rnglistx is already handled.
gdb/ChangeLog:
PR gdb/26813
* dwarf2/attribute.h (struct attribute) <set_unsigned>: Clear
requires_reprocessing flag.
* dwarf2/attribute.c (attribute::form_is_unsigned): Handle
DW_FORM_loclistx.
(attribute::form_requires_reprocessing): Handle DW_FORM_rnglistx
and DW_FORM_loclistx.
* dwarf2/read.c (read_attribute_reprocess): Use set_unsigned
instead of set_address for DW_FORM_loclistx and
DW_FORM_rnglistx.
Change-Id: I06c156fa3913ca98e4e39085f4ef171645b4bc1e
In read_rnglist_index and read_loclist_index, we check that both the
start and end of the offset that we read from the offset table are
within the section. I think it's unecessary to do both: if the end of
the offset is within the section, then surely the start of the offset is
within it.
Remove the check for the start of the offset in both functions.
gdb/ChangeLog:
* dwarf2/read.c (read_loclist_index): Remove bound check for
start of offset.
(read_rnglist_index): Likewise.
Change-Id: I7b57ddf4f8a8a28971738f0e3f3af62108f9e19a
read_rnglist_index has a bound check to make sure that we don't go past
the end of the section while reading the offset, but read_loclist_index
doesn't. Add it to read_loclist_index.
gdb/ChangeLog:
* dwarf2/read.c (read_loclist_index): Add bound check for the end
of the offset.
Change-Id: Ic4b55c88860fdc3e007740949c78ec84cdb4da60
I think this check in read_rnglist_index is wrong:
/* Validate that reading won't go beyond the end of the section. */
if (start_offset + cu->header.offset_size > rnglist_base + section->size)
error (_("Reading DW_FORM_rnglistx index beyond end of"
".debug_rnglists section [in module %s]"),
objfile_name (objfile));
The addition `rnglist_base + section->size` doesn't make sense.
rnglist_base is an offset into `section`, so it doesn't make sense to
add it to `section`'s size. `start_offset` also is an offset into
`section`, so we should just compare it to just `section->size`.
gdb/ChangeLog:
* dwarf2/read.c (read_rnglist_index): Fix bound check.
Change-Id: If0ff7c73f4f80f79aac447518f4e8f131f2db8f2
Unlike read_rnglists_index, read_loclist_index uses complaints when it
detects an inconsistency (a DW_FORM_loclistx value without a
.debug_loclists section or an offset outside of the section). I really
think they should be errors, since there's no point in continuing if
this situation happens, we will likely segfault or read garbage.
gdb/ChangeLog:
* dwarf2/read.c (read_loclist_index): Change complaints into
errors.
Change-Id: Ic3a1cf6e682d47cb6e739dd76fd7ca5be2637e10
Add "R (retain)" and "D (mbind)" to "Key to Flags:".
PR binutils/27281
* readelf.c (process_section_headers): Add 'R' and 'D' to
"Key to Flags:".
* testsuite/binutils-all/retain1a.d: Updated.
A default versioned symbol definition in a shared library is
overridden by an unversioned definition in a regular object file, and
thus should not be reason to make an as-needed library needed.
bfd/
PR 27311
* elflink.c (_bfd_elf_add_default_symbol): Add override parameter.
Use when handling default versioned symbol. Rename existing
override variable to nondef_override and use for non-default
versioned symbol.
(elf_link_add_object_symbols): Adjust call to suit. Don't
pull in as-needed libraries when override is set.
ld/
* testsuite/ld-plugin/pr27311.d,
* testsuite/ld-plugin/pr27311.ver,
* testsuite/ld-plugin/pr27311a.c,
* testsuite/ld-plugin/pr27311b.c,
* testsuite/ld-plugin/pr27311c.c: New testcase.
* testsuite/ld-plugin/lto.exp: Run it. Correct PR14918 and
PR12982 entries.
When running test-case gdb.dwarf2/fission-reread.exp with target board
cc-with-gdb-index, we run into an abort during the generation of the gdb-index
by cc-with-tweaks.sh:
...
build/gdb/testsuite/cache/gdb.sh: line 1: 27275 Aborted (core dumped)
...
This can be reproduced on the command line like this:
...
$ gdb -batch ./outputs/gdb.dwarf2/fission-reread/fission-reread \
-ex 'save gdb-index ./outputs/gdb.dwarf2/fission-reread'
warning: Could not find DWO TU fission-reread.dwo(0x9022f1ceac7e8b19) \
referenced by TU at offset 0x0 [in module fission-reread]
warning: Could not find DWO CU fission-reread.dwo(0x807060504030201) \
referenced by CU at offset 0x561 [in module fission-reread]
Aborted (core dumped)
...
The abort is a segfault due to a using a nullptr psymtab in
write_one_signatured_type.
The problem is that we're trying to write index entries for the type unit
with signature:
...
(gdb) p /x entry->signature
$2 = 0x9022f1ceac7e8b19
...
which is a skeleton type unit:
...
Contents of the .debug_types section:
Compilation Unit @ offset 0x0:
Length: 0x4a (32-bit)
Version: 4
Abbrev Offset: 0x165
Pointer Size: 4
Signature: 0x9022f1ceac7e8b19
Type Offset: 0x0
<0><17>: Abbrev Number: 2 (DW_TAG_type_unit)
<18> DW_AT_comp_dir : /tmp/src/gdb/testsuite
<2f> DW_AT_GNU_dwo_name: fission-reread.dwo
<42> DW_AT_GNU_pubnames: 0x0
<46> DW_AT_GNU_pubtypes: 0x0
<4a> DW_AT_GNU_addr_base: 0x0
...
referring to a .dwo file, but as the warnings show, the .dwo file is not
found.
Fix this by skipping the type unit in write_one_signatured_type if
psymtab == nullptr.
Tested on x86_64-linux.
gdb/ChangeLog:
2021-02-02 Tom de Vries <tdevries@suse.de>
PR symtab/24620
* dwarf2/index-write.c (write_one_signatured_type): Skip if
psymtab == nullptr.
gdb/testsuite/ChangeLog:
2021-02-02 Tom de Vries <tdevries@suse.de>
PR symtab/24620
* gdb.dwarf2/fission-reread.exp: Add test-case.
When running test-case gdb.dwarf2/fission-reread.exp with target board
cc-with-gdb-index, we run into:
...
gdb compile failed, warning: Could not find DWO TU \
fission-reread.dwo(0x9022f1ceac7e8b19) referenced by TU at offset 0x0 \
[in module outputs/gdb.dwarf2/fission-reread/fission-reread]
...
The problem is that the .dwo file is not found.
There's code added in the .exp file to make sure the .dwo can be found:
...
# Make sure we can find the .dwo file, regardless of whether we're
# running in parallel mode.
gdb_test_no_output "set debug-file-directory [file dirname $binfile]" \
"set debug-file-directory"
...
This works normally, but not for the gdb invocation done by cc-with-tweaks.sh
for target board cc-with-gdb-index.
Fix this by finding the full path to the .dwo file and passing it
to the compilation.
Tested on x86_64-linux with native and target boards cc-with-gdb-index,
cc-with-debug-names and readnow.
gdb/testsuite/ChangeLog:
2021-02-01 Tom de Vries <tdevries@suse.de>
* gdb.dwarf2/fission-base.S: Pass -DDWO=$dwo.
* gdb.dwarf2/fission-loclists-pie.S: Same.
* gdb.dwarf2/fission-loclists.S: Same.
* gdb.dwarf2/fission-multi-cu.S: Same.
* gdb.dwarf2/fission-reread.S: Same.
* gdb.dwarf2/fission-base.exp: Use DWO.
* gdb.dwarf2/fission-loclists-pie.exp: Same.
* gdb.dwarf2/fission-loclists.exp: Same.
* gdb.dwarf2/fission-multi-cu.exp: Same.
* gdb.dwarf2/fission-reread.exp: Same.
This makes --defsym support the same expressions as assignment in a
script. For example, --defsym 'HIDDEN(foo=0)', will define a hidden
visibility foo.
* ldgram.y (defsym_expr): Use assignment rule.
* ldlex.h (ldlex_defsym): Delete.
* ldlex.l (DEFSYMEXP, ldlex_defsym): Delete.
Parsing symbol or file/section names in ld linker scripts is a little
complicated. Inside SECTIONS, a name might be the start of an
expression or an output section. Is ".foo=x-y" a fancy section name
or is it the expression ".foo = x - y"? It isn't possible for a
single lookahead parser to decide, so the answer in this case is
that it's a section name. This is the reason why everyone writes
linker script assignment expressions with lots of white-space.
However, there are many places where the parser knows for sure that an
expression is expected. Those could be written without whitespace
given the first change to ldlex.l below. Unfortunately, that runs
into a lookahead problem. Optional expressions at the end of an
output section statement require the parser to look ahead one token in
expression context. For this example from standard scripts
.interp : { *(.interp) }
.note.gnu.build-id : { *(.note.gnu.build-id) }
at the end of the .interp closing brace, the parser is looking for
a possible memspec, phdr, fill or even an optional comma. The next
token is a NAME, but in expression context that NAME now doesn't
include '-' as a valid char. So the lookahead NAME is
".note.gnu.build" with an unexpected "-id" syntax error before the
colon. The rest of the patch involving ldlex_backup arranges to
discard that NAME token so that it will be rescanned in the proper
script context.
* ldgram.y (section): Call ldlex_backup. Remove empty action.
* ldlex.h (ldlex_backup): Declare.
* ldlex.l (<EXPRESSION>NAME): Don't use NOCFILENAMECHAR set of
chars, use SYMBOLNAMECHAR.
(ldlex_backup): New function.
While reviewing the Linux and FreeBSD core dumping code within GDB for
another patch series, I noticed that the code that collects the
registers for each thread and writes these into ELF note format is
basically identical between Linux and FreeBSD.
This commit merges this code and moves it into the gcore.c file,
which seemed like the right place for generic writing a core file
code.
The function find_signalled_thread is moved from linux-tdep.c despite
not being shared. A later commit will make use of this function.
There are a couple of minor changes to the FreeBSD target after this
commit, but I believe that these are changes for the better:
(1) For FreeBSD we always used to record the thread-id in the core file by
using ptid_t.lwp (). In contrast the Linux code did this:
/* For remote targets the LWP may not be available, so use the TID. */
long lwp = ptid.lwp ();
if (lwp == 0)
lwp = ptid.tid ();
Both target now do this:
/* The LWP is often not available for bare metal target, in which case
use the tid instead. */
if (ptid.lwp_p ())
lwp = ptid.lwp ();
else
lwp = ptid.tid ();
Which is equivalent for Linux, but is a change for FreeBSD. I think
that all this means is that in some cases where GDB might have
previously recorded a thread-id of 0 for each thread, we might now get
something more useful.
(2) When collecting the registers for Linux we collected into a zero
initialised buffer. By contrast on FreeBSD the buffer is left
uninitialised. In the new code the buffer is always zero initialised.
I suspect once the registers are copied into the buffer there's
probably no gaps left so this makes no difference, but if it does then
using zeros rather than random bits of GDB's memory is probably a good
thing.
Otherwise, there should be no other user visible changes after this
commit.
Tested this on x86-64/GNU-Linux and x86-64/FreeBSD-12.2 with no
regressions.
gdb/ChangeLog:
* Makefile.in (HFILES_NO_SRCDIR): Add corefile.h.
* gcore.c (struct gcore_collect_regset_section_cb_data): Moved
here from linux-tdep.c and given a new name. Minor cleanups.
(gcore_collect_regset_section_cb): Likewise.
(gcore_collect_thread_registers): Likewise.
(gcore_build_thread_register_notes): Likewise.
(gcore_find_signalled_thread): Likewise.
* gcore.h (gcore_build_thread_register_notes): Declare.
(gcore_find_signalled_thread): Declare.
* fbsd-tdep.c: Add 'gcore.h' include.
(struct fbsd_collect_regset_section_cb_data): Delete.
(fbsd_collect_regset_section_cb): Delete.
(fbsd_collect_thread_registers): Delete.
(struct fbsd_corefile_thread_data): Delete.
(fbsd_corefile_thread): Delete.
(fbsd_make_corefile_notes): Call
gcore_build_thread_register_notes instead of the now deleted
FreeBSD code.
* linux-tdep.c: Add 'gcore.h' include.
(struct linux_collect_regset_section_cb_data): Delete.
(linux_collect_regset_section_cb): Delete.
(linux_collect_thread_registers): Delete.
(linux_corefile_thread): Call
gcore_build_thread_register_notes.
(find_signalled_thread): Delete.
(linux_make_corefile_notes): Call gcore_find_signalled_thread.
We renamed these years ago, but it looks like the cgen core missed the
TRACE_EXTRACT function, so these new ports still used the incompatible
common name. Fix those ports to use the right func.
When compiling we get the following warnings:
common/cgen-accfp.c: In function 'fixsfsi':
common/cgen-accfp.c:370:18: warning: pointer targets in passing argument 1 of 'sim_fpu_to32i' differ in signedness [-Wpointer-sign]
sim_fpu_to32i (&res, &op1, sim_fpu_round_near);
^
common/cgen-accfp.c: In function 'fixdfsi':
common/cgen-accfp.c:381:18: warning: pointer targets in passing argument 1 of 'sim_fpu_to32i' differ in signedness [-Wpointer-sign]
sim_fpu_to32i (&res, &op1, sim_fpu_round_near);
^
This port only had one minor warning left in it, so fix it and then
enable -Werror behavior by deleting the macro call. We'll use the
common default now (which is -Werror).
My recent rewrite of the nltvals generator fixed a bug where SYS_times
was not being exported for v850. But that in turn uncovered this bug
where the SYS_times codepath had a compile error.
This port only had one minor warning left in it, so fix it and then
enable -Werror behavior by deleting the macro call. We'll use the
common default now (which is -Werror).
Existing ports already have sizeof_pc set to the same size as sim_cia,
so simply make that part of the core code. We already assume this in
places by way of sim_pc_{get,set}, and this is how it's documented in
the sim-base.h API.
There is code to allow sims to pick different register word sizes from
address sizes, but most ports use the defaults for both (32-bits), and
the few that support multiple register sizes never change the address
size (so address defaults to register). I can't think of any machine
where the register hardware size would be larger than the address word
size either. We have ABIs that behave that way (e.g. x32), but the
hardware is still equivalent register sized.
When the target's PC is 64-bits, this shift expands into a range of
8 * 8 - 1 which doesn't work with 32-bit constants. Force it to be
a 64-bit value all the time and let the compiler truncate it.
This port doesn't build if these hardware modules are omitted, and
there's no reason we need to make it conditional at build time, so
always enable it. The hardware devices only get turned on if the
user requests it at runtime via hardware settings.
