Replace the global function address_in_mem_range with the member
function mem_range::contains. The implementation of the function
doesn't change.
There should be no user visible changes after this commit.
Approved-By: Tom Tromey <tom@tromey.com>
Most files including gdbcmd.h currently rely on it to access things
actually declared in cli/cli-cmds.h (setlist, showlist, etc). To make
things easy, replace all includes of gdbcmd.h with includes of
cli/cli-cmds.h. This might lead to some unused includes of
cli/cli-cmds.h, but it's harmless, and much faster than going through
the 170 or so files by hand.
Change-Id: I11f884d4d616c12c05f395c98bbc2892950fb00f
Approved-By: Tom Tromey <tom@tromey.com>
This commit introduces a new target hook, target_is_address_tagged,
which is used instead of the gdbarch_tagged_address_p gdbarch hook in
the upper layer (printcmd.c).
This change enables easy specialization of memory tagging address
check per target in the future. As target_is_address_tagged continues
to utilize the gdbarch_tagged_address_p hook, there is no change in
behavior for all the targets that use the new target hook (i.e., the
remote.c, aarch64-linux-nat.c, and corelow.c targets).
Just the gdbarch_tagged_address_p signature is changed for convenience,
since target_is_address_tagged takes the address to be checked as a
CORE_ADDR type.
Signed-off-by: Gustavo Romero <gustavo.romero@linaro.org>
Approved-By: Luis Machado <luis.machado@arm.com>
Tested-By: Luis Machado <luis.machado@arm.com>
Now that defs.h, server.h and common-defs.h are included via the
`-include` option, it is no longer necessary for source files to include
them. Remove all the inclusions of these files I could find. Update
the generation scripts where relevant.
Change-Id: Ia026cff269c1b7ae7386dd3619bc9bb6a5332837
Approved-By: Pedro Alves <pedro@palves.net>
Make the current_program_space reference bubble up one level.
Remove one unnecessary declaration of clear_solib.
Change-Id: I234e2c8c0b71713364fc7b76cee2bee2b026bd6d
Approved-By: Andrew Burgess <aburgess@redhat.com>
The core_bfd macro hides a use of current_program_space. Remove it, so
that we have the opportunity to get the program space from the context,
if possible. I guess that the macro was introduced at some point to
replace a global variable of the same name without changing all the
uses.
Change-Id: I971a65b29b5e5a5941f3cb7ea234547daa787268
Approved-By: Tom Tromey <tom@tromey.com>
This commit is the result of the following actions:
- Running gdb/copyright.py to update all of the copyright headers to
include 2024,
- Manually updating a few files the copyright.py script told me to
update, these files had copyright headers embedded within the
file,
- Regenerating gdbsupport/Makefile.in to refresh it's copyright
date,
- Using grep to find other files that still mentioned 2023. If
these files were updated last year from 2022 to 2023 then I've
updated them this year to 2024.
I'm sure I've probably missed some dates. Feel free to fix them up as
you spot them.
Remove get_current_regcache, inlining the call to get_thread_regcache in
callers. When possible, pass the right thread_info object known from
the local context. Otherwise, fall back to passing `inferior_thread ()`.
This makes the reference to global context bubble up one level, a small
step towards the long term goal of reducing the number of references to
global context (or rather, moving those references as close as possible
to the top of the call tree).
No behavior change expected.
Change-Id: Ifa6980c88825d803ea586546b6b4c633c33be8d6
Remove this typedef. I think that hiding the real type (std::vector)
behind a typedef just hinders readability.
Change-Id: I80949da3392f60a2826c56c268e0ec6f503ad79f
Approved-By: Pedro Alves <pedro@palves.net>
Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>
This function is just a wrapper around the current inferior's gdbarch.
I find that having that wrapper just obscures where the arch is coming
from, and that it's often used as "I don't know which arch to use so
I'll use this magical target_gdbarch function that gets me an arch" when
the arch should in fact come from something in the context (a thread,
objfile, symbol, etc). I think that removing it and inlining
`current_inferior ()->arch ()` everywhere will make it a bit clearer
where that arch comes from and will trigger people into reflecting
whether this is the right place to get the arch or not.
Change-Id: I79f14b4e4934c88f91ca3a3155f5fc3ea2fadf6b
Reviewed-By: John Baldwin <jhb@FreeBSD.org>
Approved-By: Andrew Burgess <aburgess@redhat.com>
Due to the nature of the AArch64 SVE/SME extensions in GDB, each thread
can potentially have distinct target descriptions/gdbarches.
When loading a gcore-generated core file, at the moment GDB gives priority
to the target description dumped to NT_GDB_TDESC. Though technically correct
for most targets, it doesn't work correctly for AArch64 with SVE or SME
support.
The correct approach for AArch64/Linux is to either have per-thread target
description notes in the corefiles or to rely on the
gdbarch_core_read_description hook, so it can figure out the proper target
description for a given thread based on the various available register notes.
The former, although more correct, doesn't address the case of existing gdb's
that only output a single target description note.
This patch goes for the latter, and adds a new gdbarch hook to conditionalize
the use of the corefile target description note. The hook is called
use_target_description_from_corefile_notes.
The hook defaults to returning true, meaning targets will use the corefile
target description note. AArch64 Linux overrides the hook to return false
when it detects any of the SVE or SME register notes in the corefile.
Otherwise it should be fine for AArch64 Linux to use the corefile target
description note.
When we support per-thread target description notes, then we can augment
the AArch64 Linux hook to rely on those notes.
Regression-tested on aarch64-linux Ubuntu 22.04/20.04.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
I noticed a comment by an include and remembered that I think these
don't really provide much value -- sometimes they are just editorial,
and sometimes they are obsolete. I think it's better to just remove
them. Tested by rebuilding.
Approved-By: Andrew Burgess <aburgess@redhat.com>
Add gdbarch_core_read_x86_xsave_layout to fetch the x86 XSAVE layout
structure from a core file.
Current OS's do not export the offsets of XSAVE state components in
core dumps, so provide an i387_guess_xsave_layout helper function to
set offsets based on known combinations of XCR0 masks and total state
sizes. Eventually when core dumps do contain this information this
function should only be used as a fall back for older core dumps.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
After the previous commit, exit_inferior_1 no longer makes use of the
silent parameter. This commit removes this parameter and cleans up
the callers.
After doing this exit_inferior_1, exit_inferior, and
exit_inferior_silent are all equivalent, so rename exit_inferior_1 to
exit_inferior and delete exit_inferior_silent, update all the callers.
Also I spotted the declaration exit_inferior_num_silent in inferior.h,
but this function is not defined anywhere, so I deleted the
declaration.
There should be no user visible changes after this commit.
The previous commit added the test gdb.arch/core-file-pid0.exp which
tests GDB's ability to load a core file containing threads with an
lwpid of 0, which is something we GDB can encounter when loading a
vmcore file -- a core file generated by the Linux kernel. The threads
with an lwpid of 0 represents idle cores.
While the previous commit added the test, which confirms GDB doesn't
crash when confronted with such a core file, there are still some
problems with GDB's handling of these core files. These problems all
originate from the fact that the core file (once opened by bfd)
contains multiple sections called .reg/0, these sections all
represents different threads (cpu cores in the original vmcore dump),
but GDB gets confused and thinks all of these .reg/0 sections are all
referencing the same thread.
Here is a GDB session on an x86-64 machine which loads the core file
from the gdb.arch/core-file-pid0.exp, this core file contains two
threads, both of which have a pid of 0:
$ ./gdb/gdb --data-directory ./gdb/data-directory/ -q
(gdb) core-file /tmp/x86_64-pid0-core.core
[New process 1]
[New process 1]
Failed to read a valid object file image from memory.
Core was generated by `./segv-mt'.
Program terminated with signal SIGSEGV, Segmentation fault.
The current thread has terminated
(gdb) info threads
Id Target Id Frame
2 process 1 0x00000000004017c2 in ?? ()
The current thread <Thread ID 1> has terminated. See `help thread'.
(gdb) maintenance info sections
Core file: `/tmp/x86_64-pid0-core.core', file type elf64-x86-64.
[0] 0x00000000->0x000012d4 at 0x00000318: note0 READONLY HAS_CONTENTS
[1] 0x00000000->0x000000d8 at 0x0000039c: .reg/0 HAS_CONTENTS
[2] 0x00000000->0x000000d8 at 0x0000039c: .reg HAS_CONTENTS
[3] 0x00000000->0x00000080 at 0x0000052c: .note.linuxcore.siginfo/0 HAS_CONTENTS
[4] 0x00000000->0x00000080 at 0x0000052c: .note.linuxcore.siginfo HAS_CONTENTS
[5] 0x00000000->0x00000140 at 0x000005c0: .auxv HAS_CONTENTS
[6] 0x00000000->0x000000a4 at 0x00000714: .note.linuxcore.file/0 HAS_CONTENTS
[7] 0x00000000->0x000000a4 at 0x00000714: .note.linuxcore.file HAS_CONTENTS
[8] 0x00000000->0x00000200 at 0x000007cc: .reg2/0 HAS_CONTENTS
[9] 0x00000000->0x00000200 at 0x000007cc: .reg2 HAS_CONTENTS
[10] 0x00000000->0x00000440 at 0x000009e0: .reg-xstate/0 HAS_CONTENTS
[11] 0x00000000->0x00000440 at 0x000009e0: .reg-xstate HAS_CONTENTS
[12] 0x00000000->0x000000d8 at 0x00000ea4: .reg/0 HAS_CONTENTS
[13] 0x00000000->0x00000200 at 0x00000f98: .reg2/0 HAS_CONTENTS
[14] 0x00000000->0x00000440 at 0x000011ac: .reg-xstate/0 HAS_CONTENTS
[15] 0x00400000->0x00401000 at 0x00002000: load1 ALLOC LOAD READONLY HAS_CONTENTS
[16] 0x00401000->0x004b9000 at 0x00003000: load2 ALLOC READONLY CODE
[17] 0x004b9000->0x004e5000 at 0x00003000: load3 ALLOC READONLY
[18] 0x004e6000->0x004ec000 at 0x00003000: load4 ALLOC LOAD HAS_CONTENTS
[19] 0x004ec000->0x004f2000 at 0x00009000: load5 ALLOC LOAD HAS_CONTENTS
[20] 0x012a8000->0x012cb000 at 0x0000f000: load6 ALLOC LOAD HAS_CONTENTS
[21] 0x7fda77736000->0x7fda77737000 at 0x00032000: load7 ALLOC READONLY
[22] 0x7fda77737000->0x7fda77f37000 at 0x00032000: load8 ALLOC LOAD HAS_CONTENTS
[23] 0x7ffd55f65000->0x7ffd55f86000 at 0x00832000: load9 ALLOC LOAD HAS_CONTENTS
[24] 0x7ffd55fc3000->0x7ffd55fc7000 at 0x00853000: load10 ALLOC LOAD READONLY HAS_CONTENTS
[25] 0x7ffd55fc7000->0x7ffd55fc9000 at 0x00857000: load11 ALLOC LOAD READONLY CODE HAS_CONTENTS
[26] 0xffffffffff600000->0xffffffffff601000 at 0x00859000: load12 ALLOC LOAD READONLY CODE HAS_CONTENTS
(gdb)
Notice when the core file is first loaded we see two lines like:
[New process 1]
And GDB reports:
The current thread has terminated
Which isn't what we'd expect from a core file -- the core file should
only contain threads that are live at the point of the crash, one of
which should be the current thread. The above message is reported
because GDB has deleted what we think is the current thread!
And in the 'info threads' output we are only seeing a single thread,
again, this is because GDB has deleted one of the threads.
Finally, the 'maintenance info sections' output shows the cause of all
our problems, two sections named .reg/0. When GDB sees the first of
these it creates a new thread. But, when we see the second .reg/0 GDB
tries to create another new thread, but this thread has the same
ptid_t as the first thread, so GDB deletes the first thread and
creates the second thread in its place.
Because both these threads are created with an lwpid of 0 GDB reports
these are 'New process NN' rather than 'New LWP NN' which is what we
would normally expect.
The previous commit includes a little more of the history of GDB
support in this area, but these problems were discussed on the mailing
list a while ago in this thread:
https://inbox.sourceware.org/gdb-patches/AANLkTi=zuEDw6qiZ1jRatkdwHO99xF2Qu+WZ7i0EQjef@mail.gmail.com/
In this commit I propose a solution to these problems.
What I propose is that GDB should spot when we have .reg/0 sections
and, when these are found, should rename these sections using some
unique non-zero lwpid.
Note in the above output we also have sections like .reg2/0 and
.reg-xstate/0, these are additional register sets, this commit also
renumbers these sections inline with their .reg section.
The user is warned that some section renumbering has been performed.
GDB takes care to ensure that the new numbers assigned are unique and
don't clash with any of the pid's that might already be in use --
remember, in a real vmcore file, 0 is used to indicate an idle core,
non-idle cores will have the pid of whichever process was running on
that core, so we don't want GDB to assign an lwpid that clashes with
an actual pid that is in use in the core file.
After this commit here's the updated GDB session output:
$ ./gdb/gdb --data-directory ./gdb/data-directory/ -q
(gdb) core-file /tmp/x86_64-pid0-core.core
warning: found threads with pid 0, assigned replacement Target Ids: LWP 1, LWP 2
[New LWP 1]
[New LWP 2]
Failed to read a valid object file image from memory.
Core was generated by `./segv-mt'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00000000004017c2 in ?? ()
[Current thread is 1 (LWP 1)]
(gdb) info threads
Id Target Id Frame
* 1 LWP 1 0x00000000004017c2 in ?? ()
2 LWP 2 0x000000000040dda5 in ?? ()
(gdb) maintenance info sections
Core file: `/tmp/x86_64-pid0-core.core', file type elf64-x86-64.
[0] 0x00000000->0x000012d4 at 0x00000318: note0 READONLY HAS_CONTENTS
[1] 0x00000000->0x000000d8 at 0x0000039c: .reg/1 HAS_CONTENTS
[2] 0x00000000->0x000000d8 at 0x0000039c: .reg HAS_CONTENTS
[3] 0x00000000->0x00000080 at 0x0000052c: .note.linuxcore.siginfo/1 HAS_CONTENTS
[4] 0x00000000->0x00000080 at 0x0000052c: .note.linuxcore.siginfo HAS_CONTENTS
[5] 0x00000000->0x00000140 at 0x000005c0: .auxv HAS_CONTENTS
[6] 0x00000000->0x000000a4 at 0x00000714: .note.linuxcore.file/1 HAS_CONTENTS
[7] 0x00000000->0x000000a4 at 0x00000714: .note.linuxcore.file HAS_CONTENTS
[8] 0x00000000->0x00000200 at 0x000007cc: .reg2/1 HAS_CONTENTS
[9] 0x00000000->0x00000200 at 0x000007cc: .reg2 HAS_CONTENTS
[10] 0x00000000->0x00000440 at 0x000009e0: .reg-xstate/1 HAS_CONTENTS
[11] 0x00000000->0x00000440 at 0x000009e0: .reg-xstate HAS_CONTENTS
[12] 0x00000000->0x000000d8 at 0x00000ea4: .reg/2 HAS_CONTENTS
[13] 0x00000000->0x00000200 at 0x00000f98: .reg2/2 HAS_CONTENTS
[14] 0x00000000->0x00000440 at 0x000011ac: .reg-xstate/2 HAS_CONTENTS
[15] 0x00400000->0x00401000 at 0x00002000: load1 ALLOC LOAD READONLY HAS_CONTENTS
[16] 0x00401000->0x004b9000 at 0x00003000: load2 ALLOC READONLY CODE
[17] 0x004b9000->0x004e5000 at 0x00003000: load3 ALLOC READONLY
[18] 0x004e6000->0x004ec000 at 0x00003000: load4 ALLOC LOAD HAS_CONTENTS
[19] 0x004ec000->0x004f2000 at 0x00009000: load5 ALLOC LOAD HAS_CONTENTS
[20] 0x012a8000->0x012cb000 at 0x0000f000: load6 ALLOC LOAD HAS_CONTENTS
[21] 0x7fda77736000->0x7fda77737000 at 0x00032000: load7 ALLOC READONLY
[22] 0x7fda77737000->0x7fda77f37000 at 0x00032000: load8 ALLOC LOAD HAS_CONTENTS
[23] 0x7ffd55f65000->0x7ffd55f86000 at 0x00832000: load9 ALLOC LOAD HAS_CONTENTS
[24] 0x7ffd55fc3000->0x7ffd55fc7000 at 0x00853000: load10 ALLOC LOAD READONLY HAS_CONTENTS
[25] 0x7ffd55fc7000->0x7ffd55fc9000 at 0x00857000: load11 ALLOC LOAD READONLY CODE HAS_CONTENTS
[26] 0xffffffffff600000->0xffffffffff601000 at 0x00859000: load12 ALLOC LOAD READONLY CODE HAS_CONTENTS
(gdb)
Notice the new warning which is issued when the core file is being
loaded. The threads are announced as '[New LWP NN]', and we see two
threads in the 'info threads' output. The 'maintenance info sections'
output shows the result of the section renaming.
The gdb.arch/core-file-pid0.exp test has been update to check for the
improved GDB output.
Reviewed-By: Kevin Buettner <kevinb@redhat.com>
I noticed that in corelow.c, when a core file is opened, both the
thread and inferior setup is done in add_to_thread_list. In this
patch I propose hoisting the inferior setup out of add_to_thread_list
into core_target_open.
The only thing about this change that gave me cause for concern is
that in add_to_thread_list, we only setup the inferior after finding
the first section with a name like ".reg/NN". If we find no such
section then the inferior will never be setup.
Is this important?
Well, I don't think so. Back in core_target_open, if there is no
current thread (which there will not be if no ".reg/NN" section was
found), then we look for a thread in the current inferior. If there
are no threads (which there will not be if no ".reg/NN" is found),
then we once again setup the current inferior.
What I think this means, is that, in all cases, the current inferior
will end up being setup. By moving the inferior setup code earlier in
core_target_open and making it non-conditional, we can remove the
later code that sets up the inferior, we now know this will always
have been done.
There should be no user visible changes after this commit.
Reviewed-By: Kevin Buettner <kevinb@redhat.com>
In the current implementation, core_target::build_file_mappings will try
to locate and open files which were mapped in the process for which the
core dump was produced. If the file cannot be found or cannot be
opened, GDB will re-try to open it once for each time it was mapped in
the process's address space.
This patch makes it so GDB recognizes that it has already failed to open
a given file once and does not re-try the process for each mapping.
Reviewed-By: John Baldwin <jhb@FreeBSD.org>
Approved-By: Andrew Burgess <aburgess@redhat.com>
When GDB opens a coredump it tries to locate and then open all files
which were mapped in the process.
If a file is found but cannot be opened with BFD (bfd_open /
bfd_check_format fails), then a warning is printed to the user. If the
same file was mapped multiple times in the process's address space, the
warning is printed once for each time the file was mapped. I find this
un-necessarily noisy.
This patch makes it so the warning message is printed only once per
file.
There was a comment in the code assuming that if the file was found on
the system, opening it (bfd_open + bfd_check_format) should always
succeed. A recent change in BFD (014a602b86 "Don't optimise bfd_seek
to same position") showed that this assumption is not valid. For
example, it is possible to have a core dump of a process which had
mmaped an IO page from a DRI render node (/dev/dri/runderD$NUM). In
such case the core dump does contain the information that portions of
this special file were mapped in the host process, but trying to seek to
position 0 will fail, making bfd_check_format fail. This patch removes
this comment.
Reviewed-By: John Baldwin <jhb@FreeBSD.org>
Approved-By: Andrew Burgess <aburgess@redhat.com>
In core_target::build_file_mappings, GDB tries to open files referenced
in the core dump.
The process goes like this:
struct bfd *bfd = bfd_map[filename];
if (bfd == nullptr)
{
bfd = bfd_map[filename]
= bfd_openr (expanded_fname.get (), "binary");
if (bfd == nullptr || !bfd_check_format (bfd, bfd_object))
{
if (bfd != nullptr)
bfd_close (bfd);
return;
}
}
asection *sec = bfd_make_section_anyway (bfd, "load");
...
The problem is that if bfd_check_format fails, we close the bfd but keep
a reference to it in the bfd_map.
If the same filename appears another time in the NT_FILE note, we enter
this code again. The second time, bfd_map[filename] is not nullptr and
we try to call bfd_make_section_anyway on an already closed BFD, which
is a use-after-free error.
This patch makes sure that the bfd is only saved in the bfd_map if it
got opened successfully.
This error got exposed by a recent change in BFD (014a602b86 "Don't
optimise bfd_seek to same position"). Since this change, opening a
coredump which contains mapping to some special files such as a DRI
render node (/dev/dri/renderD$NUM) exposes the issue. This happens for
example for processes using AMDGPU devices to offload compute tasks.
Reviewed-By: John Baldwin <jhb@FreeBSD.org>
Approved-By: Andrew Burgess <aburgess@redhat.com>
This commit is the result of running the gdb/copyright.py script,
which automated the update of the copyright year range for all
source files managed by the GDB project to be updated to include
year 2023.
Teach GDB how to dump memory tags for AArch64 when using the gcore command
and how to read memory tag data back from a core file generated by GDB
(via gcore) or by the Linux kernel.
The format is documented in the Linux Kernel documentation [1].
Each tagged memory range (listed in /proc/<pid>/smaps) gets dumped to its
own PT_AARCH64_MEMTAG_MTE segment. A section named ".memtag" is created for each
of those segments when reading the core file back.
To save a little bit of space, given MTE tags only take 4 bits, the memory tags
are stored packed as 2 tags per byte.
When reading the data back, the tags are unpacked.
I've added a new testcase to exercise the feature.
Build-tested with --enable-targets=all and regression tested on aarch64-linux
Ubuntu 20.04.
[1] Documentation/arm64/memory-tagging-extension.rst (Core Dump Support)
After loading a core file, you're supposed to be able to use "detach"
to unload the core file. That unfortunately regressed starting with
GDB 11, with these commits:
1192f124a3 - gdb: generalize commit_resume, avoid commit-resuming when threads have pending statuses
408f66864a - detach in all-stop with threads running
resulting in a GDB crash:
...
Thread 1 "gdb" received signal SIGSEGV, Segmentation fault.
0x0000555555e842bf in maybe_set_commit_resumed_all_targets () at ../../src/gdb/infrun.c:2899
2899 if (proc_target->commit_resumed_state)
(top-gdb) bt
#0 0x0000555555e842bf in maybe_set_commit_resumed_all_targets () at ../../src/gdb/infrun.c:2899
#1 0x0000555555e848bf in scoped_disable_commit_resumed::reset (this=0x7fffffffd440) at ../../src/gdb/infrun.c:3023
#2 0x0000555555e84a0c in scoped_disable_commit_resumed::reset_and_commit (this=0x7fffffffd440) at ../../src/gdb/infrun.c:3049
#3 0x0000555555e739cd in detach_command (args=0x0, from_tty=1) at ../../src/gdb/infcmd.c:2791
#4 0x0000555555c0ba46 in do_simple_func (args=0x0, from_tty=1, c=0x55555662a600) at ../../src/gdb/cli/cli-decode.c:95
#5 0x0000555555c112b0 in cmd_func (cmd=0x55555662a600, args=0x0, from_tty=1) at ../../src/gdb/cli/cli-decode.c:2514
#6 0x0000555556173b1f in execute_command (p=0x5555565c5916 "", from_tty=1) at ../../src/gdb/top.c:699
The code that crashes looks like:
static void
maybe_set_commit_resumed_all_targets ()
{
scoped_restore_current_thread restore_thread;
for (inferior *inf : all_non_exited_inferiors ())
{
process_stratum_target *proc_target = inf->process_target ();
if (proc_target->commit_resumed_state)
^^^^^^^^^^^
With 'proc_target' above being null. all_non_exited_inferiors filters
out inferiors that have pid==0. We get here at the end of
detach_command, after core_target::detach has already run, at which
point the inferior _should_ have pid==0 and no process target. It is
clear it no longer has a process target, but, it still has a pid!=0
somehow.
The reason the inferior still has pid!=0, is that core_target::detach
just unpushes, and relies on core_target::close to actually do the
getting rid of the core and exiting the inferior. The problem with
that is that detach_command grabs an extra strong reference to the
process stratum target, so the unpush_target inside
core_target::detach doesn't actually result in a call to
core_target::close.
Fix this my moving the cleaning up the core inferior to a shared
routine called by both core_target::close and core_target::detach. We
still need to cleanup the inferior from within core_file::close
because there are paths to it that want to get rid of the core without
going through detach. E.g., "core-file" -> "run".
This commit includes a new test added to gdb.base/corefile.exp to
cover the "core-file core" -> "detach" scenario.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29275
Change-Id: Ic42bdd03182166b19f598428b0dbc2ce6f67c893
I'm trying to switch these functions to use std::string instead of char
arrays, as much as possible. Some callers benefit from it (can avoid
doing a copy of the result), while others suffer (have to make one more
copy).
Change-Id: Iced49b8ee2f189744c5072a3b217aab5af17a993
Now that filtered and unfiltered output can be treated identically, we
can unify the printf family of functions. This is done under the name
"gdb_printf". Most of this patch was written by script.
Add debuginfod support to core_target::build_file_mappings and
locate_exec_from_corefile_build_id to enable the downloading of
missing executables and shared libraries referenced in core files.
Also add debuginfod support to solib_map_sections so that previously
downloaded shared libraries can be retrieved from the local debuginfod
cache.
When core file shared libraries are found locally, verify that their
build-ids match the corresponding build-ids found in the core file.
If there is a mismatch, attempt to query debuginfod for the correct
build and print a warning if unsuccessful:
warning: Build-id of /lib64/libc.so.6 does not match core file.
Also disable debuginfod when gcore invokes gdb. Debuginfo is not
needed for core file generation so debuginfod queries will slow down
gcore unnecessarily.
Since commit aa2d5a422 gdb has been able to read executable and shared
library build-ids within core files.
Expand this functionality so that each core file bfd maintains a map of
soname to build-id for each shared library referenced in the core file.
This feature may be used to verify that gdb has found the correct shared
libraries for core files and to facilitate downloading shared libaries via
debuginfod.
The cases for TARGET_OBJECT_LIBRARIES and TARGET_OBJECT_LIBRARIES_AIX
can try to fetch different data objects (such as
TARGET_OBJECT_SIGNAL_INFO) if gdbarch methods for the requested data
aren't present. Return with TARGET_XFER_E_IO if the gdbarch method
isn't present instead.
This commit brings all the changes made by running gdb/copyright.py
as per GDB's Start of New Year Procedure.
For the avoidance of doubt, all changes in this commits were
performed by the script.
Add aliases read_core_file_mappings_loop_ftype and
read_core_file_mappings_pre_loop_ftype. Intended for use with
read_core_file_mappings.
Also add build_id parameter to read_core_file_mappings_loop_ftype.
Make gdb_open_cloexec return a scoped_fd, to encourage using automatic
management of the file descriptor closing. Except in the most trivial
cases, I changed the callers to just release the fd, which retains their
existing behavior. That will allow the transition to using scoped_fd
more to go gradually, one caller at a time.
Change-Id: Ife022b403f96e71d5ebb4f1056ef6251b30fe554
With current gdb we run into:
...
$ gdb -batch '' ''
: No such file or directory.
pathstuff.cc:132: internal-error: \
gdb::unique_xmalloc_ptr<char> gdb_abspath(const char*): \
Assertion `path != NULL && path[0] != '\0'' failed.
...
Fix this by skipping the call to gdb_abspath in core_target_open in the
empty-string case, such that we have instead:
...
$ gdb -batch '' ''
: No such file or directory.
: No such file or directory.
$
...
Tested on x86_64-linux.
gdb/ChangeLog:
2021-08-30 Tom de Vries <tdevries@suse.de>
PR cli/28290
* gdb/corelow.c (core_target_open): Skip call to gdb_abspath in the
empty-string case.
gdb/testsuite/ChangeLog:
2021-08-30 Tom de Vries <tdevries@suse.de>
PR cli/28290
* gdb.base/batch-exit-status.exp: Add gdb '' and gdb '' '' tests.
While reviewing another patch, I realized that gdbarch_info_init could
easily be removed in favor of initializing gdbarch_info fields directly
in the struct declaration. The only odd part is the union. I don't
know if it's actually important for it to be zero-initialized, but I
presume it is. I added a constructor to gdbarch_info to take care of
that. A proper solution would be to use std::variant. Or, these could
also be separate fields, the little extra space required wouldn't
matter.
gdb/ChangeLog:
* gdbarch.sh (struct gdbarch_info): Initialize fields, add
constructor.
* gdbarch.h: Re-generate.
* arch-utils.h (gdbarch_info_init): Remove, delete all usages.
* arch-utils.c (gdbarch_info_init): Remove.
Change-Id: I7502e08fe0f278d84eef1667a072e8a97bda5ab5
At the moment, the core target has its own gdbarch (m_core_gdbarch), and that
gets set from the core_bfd on the core target's constructor.
That gdbarch doesn't contain a target description because it is constructed
before we get a chance to fetch the target description.
As a result, some hooks that depend on the target description being set are
not set, and that leads to problems. One of the examples is
gdbarch_report_signal_info, which is used to show AArch64 tag violation
information.
Fix this by reading the target description before fetching the core file's
gdbarch.
gdb/ChangeLog:
2021-06-25 Luis Machado <luis.machado@linaro.org>
* corelow.c (core_target::core_target) Update to read target
description.
Same as the previous patch, but for the push_target functions.
The implementation of the move variant is moved to a new overload of
inferior::push_target.
gdb/ChangeLog:
* target.h (push_target): Remove, update callers to use
inferior::push_target.
* target.c (push_target): Remove.
* inferior.h (class inferior) <push_target>: New overload.
Change-Id: I5a95496666278b8f3965e5e8aecb76f54a97c185
unpush_target unpushes the passed-in target from the current inferior's
target stack. Calling it is therefore an implicit dependency on the
current global inferior. Remove that function and make the callers use
the inferior::unpush_target method directly. This sometimes allows
using the inferior from the context rather than the global current
inferior.
target_unpusher::operator() now needs to be implemented in target.c,
otherwise target.h and inferior.h both need to include each other, and
that wouldn't work.
gdb/ChangeLog:
* target.h (unpush_target): Remove, update all callers
to use `inferior::unpush_target` instead.
(struct target_unpusher) <operator()>: Just declare.
* target.c (unpush_target): Remove.
(target_unpusher::operator()): New.
Change-Id: Ia5172dfb3f373e0a75b991885b50322ca2142a8c
When a core file is created from within GDB add the target description
into a note within the core file.
When loading a core file, if the target description note is present
then load the target description from the core file.
The benefit of this is that we can be sure that, when analysing the
core file within GDB, that we are using the exact same target
description as was in use at the time the core file was created.
GDB already supports a mechanism for figuring out the target
description from a given corefile; gdbarch_core_read_description.
This new mechanism (GDB adding the target description) is not going to
replace the old mechanism. Core files generated outside of GDB will
not include a target description, and so GDB still needs to be able to
figure out a target description for these files.
My primary motivation for adding this feature is that, in a future
commit, I will be adding support for bare metal core dumps on some
targets. For RISC-V specifically, I want to be able to dump all the
available control status registers. As different targets will present
different sets of register in their target description, including
registers that are possibly not otherwise known to GDB I wanted a way
to capture these registers in the core dump.
I therefore need a mechanism to write out an arbitrary set of
registers, and to then derive a target description from this arbitrary
set when later loading the core file. The obvious approach (I think)
is to just reuse the target description.
Once I'd decided to add support for writing out the target description
I could either choose to make this RISC-V only, or make it generic. I
figure that having the target description in the core file doesn't
hurt, and _might_ be helpful. So that's how I got here, general
support for including the target description in GDB generated core
files.
In previous versions of this patch I added the target description from
generic code (in gcore.c). However, doing this creates a dependency
between GDB's common code and bfd ELF support. As ELF support in gdb
is optional (for example the target x86_64-apple-darwin20.3.0 does not
include ELF support) then having gcore.c require ELF support would
break the GDB build in some cases.
Instead, in this version of the patch, writing the target description
note is done from each specific targets make notes function. Each of
these now calls a common function in gcore-elf.c (which is only linked
in when bfd has ELF support). And so only targets that are ELF based
will call the new function and we can therefore avoid an unconditional
dependency on ELF support.
gdb/ChangeLog:
* corelow.c: Add 'xml-tdesc.h' include.
(core_target::read_description): Load the target description from
the core file when possible.
* fbsd-tdep.c (fbsd_make_corefile_notes): Add target description
note.
* gcore-elf.c: Add 'gdbsupport/tdesc.h' include.
(gcore_elf_make_tdesc_note): New function.
* gcore-elf.h (gcore_elf_make_tdesc_note): Declare.
* linux-tdep.c (linux_make_corefile_notes): Add target description
note.
This commits the result of running gdb/copyright.py as per our Start
of New Year procedure...
gdb/ChangeLog
Update copyright year range in copyright header of all GDB files.
This adds a constructor to target_section, simplifying the code that
creates instances of this.
gdb/ChangeLog
2020-10-29 Tom Tromey <tom@tromey.com>
* target-section.h (struct target_section): Add constructor.
* exec.c (build_section_table, add_target_sections_of_objfile):
Update.
* corelow.c (core_target::build_file_mappings): Update.
The following failures started showing up after commit
bb2a67773c - "Use a std::vector in target_section_table":
FAIL: gdb.base/corefile2.exp: renamed binfile: print/x mbuf_ro[0]@4
FAIL: gdb.base/corefile2.exp: renamed binfile: print/x mbuf_ro[pagesize-4]@4
FAIL: gdb.base/corefile2.exp: renamed binfile: print/x mbuf_ro[-3]@6
FAIL: gdb.base/corefile2.exp: renamed binfile: print/x mbuf_rw[pagesize-3]@6
FAIL: gdb.base/corefile2.exp: renamed binfile: print/x mbuf_ro[pagesize-3]@6
I tracked it down to a problem in core_target::xfer_partial, at this point:
if (!m_core_file_mappings.empty ())
xfer_status = xfer_memory_via_mappings (readbuf, writebuf, offset,
len, xfered_len);
else
xfer_status = this->beneath ()->xfer_partial (object, annex, readbuf,
writebuf, offset, len,
xfered_len);
It seems commit bb2a67773c uncovered a latent bug when handling a particular
case where things are running within a Docker container using the AUFS storage
driver.
When building the file mappings for a core file, we call
gdbarch_read_core_file_mappings, which in turn passes a couple lambda
callbacks. One pre-loop and one in-loop.
The catch is that commit bb2a67773c reworked the pre-loop lambda and
made it do nothing. Before that commit, we always allocated
m_core_file_mappings in that lambda.
Now, when calling the in-loop lambda, we don't touch m_core_file_mappings
because the bfd is nullptr (given Docker leaks the host system path, and that
file doesn't exist within the container itself).
So, instead, we add an entry to the m_core_unavailable_mappings vector.
When we reach core_target::xfer_partial, we're only checking for an empty
m_core_file_mappings. Given it is now empty, we take the path of reading
the contents from the file, not the core file. This reads back unexpected
results.
The following patch fixes this by also checking for
m_core_unavailable_mappings, given core_target::xfer_memory_via_mappings
already handles the Docker/AUFS situation.
gdb/ChangeLog:
2020-10-22 Luis Machado <luis.machado@linaro.org>
* corelow.c (core_target::xfer_partial): Also check for an empty
m_core_unavailable_mappings vector.
Because target_section_table only holds a vector, and because it is
used in an "open" way, this patch makes it just be an alias for the
std::vector specialization. This makes the code less wordy. If we do
ever want to add more specialized behavior to this type, it's simple
enough to convert it back to a struct with the few needed methods
implied by this change.
gdb/ChangeLog
2020-10-12 Tom Tromey <tom@tromey.com>
* target.h (struct target_ops) <get_section_table>: Update.
(target_get_section_table): Update.
* target.c (target_get_section_table, target_section_by_addr)
(memory_xfer_partial_1): Update.
* target-section.h (target_section_table): Now an alias.
* target-delegates.c: Rebuild.
* target-debug.h (target_debug_print_target_section_table_p):
Rename from target_debug_print_struct_target_section_table_p.
* symfile.c (build_section_addr_info_from_section_table): Update.
* solib.c (solib_map_sections, solib_contains_address_p): Update.
* solib-svr4.c (scan_dyntag): Update.
* solib-dsbt.c (scan_dyntag): Update.
* remote.c (remote_target::remote_xfer_live_readonly_partial):
Update.
* record-full.c (record_full_core_target::xfer_partial): Update.
* progspace.h (struct program_space) <target_sections>: Update.
* exec.h (print_section_info): Update.
* exec.c (exec_target::close, build_section_table)
(add_target_sections, add_target_sections_of_objfile)
(remove_target_sections, exec_on_vfork)
(section_table_available_memory)
(section_table_xfer_memory_partial)
(exec_target::get_section_table, exec_target::xfer_partial)
(print_section_info, set_section_command)
(exec_set_section_address, exec_target::has_memory): Update.
* corelow.c (core_target::build_file_mappings)
(core_target::xfer_partial, core_target::info_proc_mappings)
(core_target::info_proc_mappings): Update.
* bfd-target.c (class target_bfd): Update
I noticed that build_section_table cannot fail. This patch changes it
to return a target_section_table and then removes the dead code.
gdb/ChangeLog
2020-10-12 Tom Tromey <tom@tromey.com>
* solib.c (solib_map_sections): Update.
* record-full.c (record_full_core_open_1): Update.
* exec.h (build_section_table): Return a target_section_table.
* exec.c (exec_file_attach): Update.
(build_section_table): Return a target_section_table.
* corelow.c (core_target::core_target): Update.
* bfd-target.c (target_bfd::target_bfd): Update.
This changes target_section_table to wrap a std::vector. This
simplifies some code, and also enables the simplifications coming in
the subsequent patches.
Note that for solib, I chose to have it use a pointer to a
target_section_table. This is more convoluted than would be ideal,
but I didn't want to convert solib to new/delete as a prerequisite for
this series.
gdb/ChangeLog
2020-10-12 Tom Tromey <tom@tromey.com>
* target.c (target_section_by_addr, memory_xfer_partial_1):
Update.
* target-section.h (struct target_section_table): Use
std::vector.
* symfile.h (build_section_addr_info_from_section_table): Take a
target_section_table.
* symfile.c (build_section_addr_info_from_section_table): Take a
target_section_table.
* solist.h (struct so_list) <sections>: Change type.
<sections_end>: Remove.
* solib.c (solib_map_sections, clear_so, solib_read_symbols)
(solib_contains_address_p): Update.
* solib-svr4.c (scan_dyntag): Update.
* solib-dsbt.c (scan_dyntag): Update.
* remote.c (remote_target::remote_xfer_live_readonly_partial):
Update.
* record-full.c (record_full_core_start, record_full_core_end):
Remove.
(record_full_core_sections): New global.
(record_full_core_open_1, record_full_core_target::xfer_partial):
Update.
* exec.h (build_section_table, section_table_xfer_memory_partial)
(add_target_sections): Take a target_section_table.
* exec.c (exec_file_attach, clear_section_table): Update.
(resize_section_table): Remove.
(build_section_table, add_target_sections): Take a
target_section_table.
(add_target_sections_of_objfile, remove_target_sections)
(exec_on_vfork): Update.
(section_table_available_memory): Take a target_section_table.
(section_table_read_available_memory): Update.
(section_table_xfer_memory_partial): Take a target_section_table.
(print_section_info, set_section_command)
(exec_set_section_address, exec_target::has_memory): Update.
* corelow.c (class core_target) <m_core_section_table,
m_core_file_mappings>: Remove braces.
<~core_target>: Remove.
(core_target::core_target): Update.
(core_target::~core_target): Remove.
(core_target::build_file_mappings)
(core_target::xfer_memory_via_mappings)
(core_target::xfer_partial, core_target::info_proc_mappings):
Update.
* bfd-target.c (target_bfd::xfer_partial): Update.
(target_bfd::target_bfd): Update.
(target_bfd::~target_bfd): Remove.
I noticed that non of the listeners of the inferior_created observable
used either of the arguments. Remove them. This in turn allows
removing the target parameter of post_create_inferior.
Tested only by rebuilding.
gdb/ChangeLog:
* observable.h <inferior_created>: Remove parameters. Update all
listeners.
* inferior.h (post_create_inferior): Remove target parameter.
Update all callers.
Change-Id: I8944cefdc4447ed5347dc927b75abf1e7a0e27e6
This changes core_target_open to avoid bfd_map_over_sections, in favor
of iteration.
gdb/ChangeLog
2020-09-19 Tom Tromey <tom@tromey.com>
* corelow.c (add_to_thread_list): Change parameters.
(core_target_open): Use foreach.
Luis Machado reported some regressions after I pushed recent core file
related patches fixing BZ 25631:
FAIL: gdb.base/corefile.exp: backtrace in corefile.exp
FAIL: gdb.base/corefile.exp: core-file warning-free
FAIL: gdb.base/corefile.exp: print func2::coremaker_local
FAIL: gdb.base/corefile.exp: up in corefile.exp
FAIL: gdb.base/corefile.exp: up in corefile.exp (reinit)
This commit fixes these regressions. Thanks to Luis for testing
an earlier version of the patch. (I was unable to reproduce these
regressions in various test environments that I created.)
Luis is testing in a docker container which is using the AUFS storage
driver. It turns out that the kernel is placing docker host paths in
the NT_FILE note instead of paths within the container.
I've made a similar docker environment (though apparently not similar
enough to reproduce the regressions). This is one of the paths that
I see mentioned in the warning messages printed while loading the
core file during NT_FILE note processing - note that I've shortened
the path component starting with "d07c4":
/var/lib/docker/aufs/diff/d07c4...21/lib/x86_64-linux-gnu/ld-2.27.so
This is a path on the docker host; it does not exist in the
container. In the docker container, this is the path:
/lib/x86_64-linux-gnu/ld-2.27.so
My first thought was to disable all NT_FILE mappings when any path was
found to be bad. This would have caused GDB to fall back to accessing
memory using the file stratum as it did before I added the NT_FILE
note loading code. After further consideration, I realized that we
could do better than this. For file-backed memory access, we can
still use the NT_FILE mappings when available, and then attempt to
access memory using the file stratum constrained to those address
ranges corresponding to the "broken" mappings.
In order to test it, I made some additions to corefile2.exp in which
the test case's executable is renamed. The core file is then loaded;
due to the fact that the executable has been renamed, those mappings
will be unavailable. After loading the core file, the executable is
renamed back to its original name at which point it is loaded using
GDB's "file" command. The "interesting" tests are then run. These
tests will print out values in file-backed memory regions along with
mmap'd regions placed within/over the file-backed regions. Despite
the fact that the executable could not be found during the NT_FILE
note processing, these tests still work correctly due to the fact that
memory is available from the file stratum combined with the fact that
the broken NT_FILE mappings are used to prevent file-backed access
outside of the "broken" mappings.
gdb/ChangeLog:
* corelow.c (unordered_set): Include.
(class core_target): Add field 'm_core_unavailable_mappings'.
(core_target::build_file_mappings): Print only one warning
per inaccessible file. Add unavailable/broken mappings
to m_core_unavailable_mappings.
(core_target::xfer_partial): Call...
(core_target::xfer_memory_via_mappings): New method.
gdb/testsuite/ChangeLog:
* gdb.base/corefile2.exp (renamed binfile): New tests.
While looking into the regressions reported by Luis Machado, I noticed
that null pathnames were being output in the warnings. E.g.
warning: Can't open file (null) during file-backed mapping note processing
I've changed the warning to output the pathname found in the note,
like this:
warning: Can't open file /var/lib/docker/aufs/diff/d07c...e21/lib/x86_64-linux-gnu/libc-2.27.so during file-backed mapping note processing
(I've shortened one of the path elements above.)
gdb/ChangeLog:
* corelow.c (core_target::build_file_mappings): Don't output
null pathname in warning.
