With test-case gdb.debuginfod/solib-with-soname.exp on aarch64-linux, I ran
into:
...
(gdb) core-file solib-with-soname.core^M
Downloading 197.86 K file libfoo_1.so...^M
[New LWP 997314]^M
[Thread debugging using libthread_db enabled]^M
Using host libthread_db library "/lib64/libthread_db.so.1".^M
Core was generated by `solib-with-soname'.^M
Program terminated with signal SIGABRT, Aborted.^M
(gdb) FAIL: $exp: load core file, use debuginfod: load core file
...
The test-case doesn't expect the "197.86 K" part.
The same problem was fixed for another test-case in commit a723c56efb
("gdb/testsuite: avoid intermittent failures on a debuginfod test").
Fix this in the same way: by updating the regexp.
Tested on aarch64-linux.
PR testsuite/32354
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32354
A customer noted that there is no way to prevent the "current language
does not match this frame" warning. This patch adds a new setting to
allow this warning to be suppressed.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Andrew Burgess <aburgess@redhat.com>
I recently came across a case where a compiler would emit a CU with an
empty name. In such case, the attribute object constructed by GDB will
return nullptr when as_string is called. One place is not checking for
this possibility. As a result, loading such binary results in a GDB
crash:
$ gdb -q a.out
Reading symbols from a.out...
Fatal signal: Segmentation fault
----- Backtrace -----
[...]
0x742f4dd8afab __strcmp_avx2
../sysdeps/x86_64/multiarch/strcmp-avx2.S:283
0x58593704a0bc prepare_one_comp_unit
../../gdb/dwarf2/read.c:21842
0x585937053fd9 process_psymtab_comp_unit
../../gdb/dwarf2/read.c:4633
0x585937053fd9 _ZN23cooked_index_debug_info11process_cusEmN9__gnu_cxx17__normal_iteratorIPSt10unique_ptrI18dwarf2_per_cu_data26dwarf2_per_cu_data_deleterESt6vectorIS5_SaIS5_EEEESA_
../../gdb/dwarf2/read.c:4943
[...]
---------------------
A fatal error internal to GDB has been detected, further
debugging is not possible. GDB will now terminate.
This is a bug, please report it. For instructions, see:
<https://www.gnu.org/software/gdb/bugs/>.
Segmentation fault (core dumped)
This seems to be a regression introduced by the following commit:
commit 00105aa1c4
Date: Tue Sep 24 10:24:22 2024 +0200
[gdb/symtab] Don't expand non-Ada CUs for info exceptions
This patch fixes this issue by checking if attr->as_string returns
nullptr.
Change-Id: I78fe7a090f0bd1045b8cb2f8d088a8d6cf57fe1c
Approved-By: Andrew Burgess <aburgess@redhat.com>
Approved-By: Tom Tromey <tom@tromey.com>
Implement extension_language_ops::find_objfile_from_buildid within
GDB's Python API. Doing this allows users to write Python extensions
that can help locate missing objfiles when GDB opens a core file. A
handler might perform some project- or site-specific actions to find a
missing objfile. Or might provide some project- or site-specific
advice to the user on how they can obtain the missing objfile.
The implementation is very similar to the approach taken in:
commit 8f6c452b5a
Date: Sun Oct 15 22:48:42 2023 +0100
gdb: implement missing debug handler hook for Python
The following new commands are added as commands implemented in
Python, this is similar to how the Python missing debug and unwinder
commands are implemented:
info missing-objfile-handlers
enable missing-objfile-handler LOCUS HANDLER
disable missing-objfile-handler LOCUS HANDLER
To make use of this extension hook a user will create missing objfile
handler objects, and registers these handlers with GDB. When GDB
opens a core file and encounters a missing objfile each handler is
called in turn until one is able to help. Here is a minimal handler
that does nothing useful:
import gdb
import gdb.missing_objfile
class MyFirstHandler(gdb.missing_objfile.MissingObjfileHandler):
def __init__(self):
super().__init__("my_first_handler")
def __call__(self, pspace, build_id, filename):
# This handler does nothing useful.
return None
gdb.missing_objfile.register_handler(None, MyFirstHandler())
Returning None from the __call__ method tells GDB that this handler
was unable to find the missing objfile, and GDB should ask any other
registered handlers.
Possible return values from a handler:
- None: This means the handler couldn't help. GDB will call other
registered handlers to see if they can help instead.
- False: The handler has done all it can, but the objfile couldn't
be found. GDB will not call any other handlers, and will
continue without the objfile.
- True: The handler has installed the objfile into a location where
GDB would normally expect to find it. GDB should repeat its
normal lookup process and the objfile should now be found.
- A string: The handler can return a filename, which is the missing
objfile. GDB will load this file.
Handlers can be registered globally, or per program space. GDB checks
the handlers for the current program space first, and then all of the
global handles. The first handler that returns a value that is not
None, has "handled" the missing objfile, at which point GDB continues.
The implementation of this feature is mostly straight forward. I have
reworked some of the missing debug file related code so that it can be
shared with this feature. E.g. gdb/python/lib/gdb/missing_files.py is
mostly content moved from gdb/python/lib/gdb/missing_debug.py, but
updated to be more generic. Now gdb/python/lib/gdb/missing_debug.py
and the new file gdb/python/lib/gdb/missing_objfile.py both call into
the missing_files.py file.
For gdb/python/lib/gdb/command/missing_files.py this is even more
extreme, gdb/python/lib/gdb/command/missing_debug.py is completely
gone now and gdb/python/lib/gdb/command/missing_files.py provides all
of the new commands in a generic way.
I have made one change to the existing Python API, I renamed the
attribute Progspace.missing_debug_handlers to
Progspace.missing_file_handlers. I don't see this as too
problematic. This attribute was only used to implement the missing
debug feature and was never documented beyond the fact that it
existed. There was no reason for users to be touching this attribute.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
When opening a core-file GDB is able to use debuginfod to download the
executable that matches the core-file if GDB can find a build-id for
the executable in the core-file.
In this case GDB calls debuginfod_exec_query to download the
executable and GDB prints a message like:
Downloading executable for /path/to/core-file...
which makes sense in that case.
For a long time GDB has also had the ability to download memory-mapped
files and shared libraries when opening a core-file. However, recent
commits have made these cases more likely to trigger, which is a good
thing, but the messaging from GDB in these cases is not ideal. When
downloading a memory-mapped file GDB prints:
Downloading executable for /path/to/memory-mapped-file
And for a shared library:
Downloading executable for /path/to/libfoo.so
These last two messages could, I think, be improved.
I propose making two changes. First, I suggest instead of using
/path/to/core-file in the first case, we use the name of the
executable that GDB is fetching. This makes the messaging consistent
in that we print the name of the file we're fetching rather than the
name of the file we're fetching something for.
I further propose that we replace 'executable for' with the more
generic word 'file'. The messages will then become:
Downloading file /path/to/exec-file...
Downloading file /path/to/memory-mapped-file...
Downloading file /path/to/libfoo.so...
I think these messages are clearer than what we used to have, and they
are consistent in that we name the thing being downloaded in all
cases.
There is one tiny problem. The first case relies on GDB knowing the
name of the executable it wants to download. The only place we can
currently get that from is, I think, the memory-mapped file list.
[ ASIDE: There is `bfd_core_file_failing_command` which reports the
executable and argument list from the core file, but this
information is not ideal for this task. First, the executable and
arguments are merged into a single string, and second, the string is
a relatively short, fixed length string, so the executable name is
often truncated. For these reasons I don't consider fetching the
executable name using this bfd function as a solution. ]
We do have to consider the case that the core file does not have any
mapped file information. This shouldn't ever be the case for a Linux
target, but it's worth considering.
[ ASIDE: I mention Linux specifically because this only becomes a
problem if we try to do a lookup via debuginfod, which requires that
we have build-ids available. Linux has special support for
embedding build-ids into the core file, but I'm not sure if other
kernels do this. ]
For the unlikely edge case of a core-file that has build-ids, but
doesn't have any mapped file information then I propose that we
synthesis a filename like: 'with build-id xxxxxx'. We would then see
a message like:
Downloading file with build-id xxxxxx...
Where 'xxxxxx' would be replaced by the actual build-id.
This isn't ideal, but I think is good enough, and, as I said, I think
this case is not going to be hit very often, or maybe at all.
We already had some tests that emitted two of the above messages,
which I've updated, these cover the mapped-file and shared library
case.
The message about downloading the exec for the core-file is actually
really hard to trigger now as usually the exec will also appear in the
memory-mapped file list and GDB will download the file at this stage.
Then when GDB needs the executable for loading the symbols it'll ask
debuginfod, and debuginfod will find the file in its cache, and so no
message will be printed.
If anyone has any ideas about how to trigger this case then I'm happy
to add additional tests.
Approved-By: Tom Tromey <tom@tromey.com>
This test checks that GDB is able to load DWARF information when
.debug_aranges has a section address size that is set to 0.
This test was originally written by Jan Kratochvil to test commit
927aa2e778 from 2017, titled "DWARF-5: .debug_names index consumer".
This test was originally written using a static .S file and has
been present in the Fedora tree for a long time.
If dwarf2/aranges.c is modified to turn off the address_size check,
GDB will crash with SIGFPE when loading the executable with address
size set to zero.
I modified the DWARF assembler to make it possible to set the address
size to zero in a .debug_aranges section and used the DWARF assembler
to produce the assembly file.
Co-Authored-By: Jan Kratochvil <jan.kratochvil@redhat.com>
Approved-by: Kevin Buettner <kevinb@redhat.com>
In the recent commit:
commit 31ada87f91
Date: Wed Nov 6 22:18:55 2024 +0000
gdb: fixes and tests for the 'edit' command
the new gdb.base/basic-edit-cmd.exp was added. The Linaro CI
highlighted an issue with the test which I failed to address before
pushing the above commit.
Part of the test loads a file into GDB and then uses the 'edit'
command with no arguments to edit the default location. This default
location is expected to be the 'main' function.
On my local machine the line reported is the opening '{' of main, and
that is what the test checks for.
The Linaro CI though appears to see the first code line of main.
I think either result is fine as far as this test is concerned, so
I've expanded the test regexp to check for either line number. This
should make the CI testing happy again.
This commit was inspired by this mailing list post:
https://inbox.sourceware.org/gdb-patches/osmtfvf5xe3yx4n7oirukidym4cik7lehhy4re5mxpset2qgwt@6qlboxhqiwgm
When reviewing that patch, the first thing I wanted to do was add some
tests for the 'edit' command because, as far as I can tell, there are
no real tests right now.
The approach I've taken for testing is to override the EDITOR
environment variable, setting this to just 'echo'. Now when the
'edit' command is run, instead of entering an interactive editor, the
shell instead echos back the arguments that GDB is trying to pass to
the editor. The output might look like this:
(gdb) edit
+22 /tmp/gdb/testsuite/gdb.base/edit-cmd.c
(gdb)
We can then test this like any other normal command. I then wrote
some basic tests covering a few situations like, using 'edit' before
the inferior is started. Using 'edit' without any arguments, and
using 'edit' with a line number argument.
There are plenty of cases that are still not tested, for example, the
test program only has a single source file for example. But we can
always add more tests later.
I then used these tests to validate the fix proposed in the above
patch.
The patch above does indeed fix some cases, specifically, when GDB
stops at a location (e.g. a breakpoint location) and then the 'edit'
command without any arguments is fixed. But using the 'list' command
to show some other location, and then 'edit' to edit the just listed
location broken before and after the above patch.
I am instead proposing this alternative patch which I think fixes more
cases. When GDB stops at a location then 'edit' with no arguments
should correctly edit the current line. And using 'list XX' to list a
specific location, followed by 'edit' should also now edit the just
listed location.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17669
Co-Authored-By: Lluís Batlle i Rossell <viric@viric.name>
Approved-By: Tom Tromey <tom@tromey.com>
This commit adds support for filename options to GDB's option
sub-system (see cli/cli-option.{c,h}).
The new filename options support quoted and escaped filenames, and tab
completion is fully supported.
This commit adds the new option, and adds these options to the
'maintenance test-options' command as '-filename', along with some
tests that exercise this new option.
I've split the -filename testing into two. In gdb.base/options.exp we
use the -filename option with some arbitrary strings. This tests that
GDB can correctly extract the value from a filename option, and that
GDB can complete other options after a filename option. However,
these tests don't actually pass real filenames, nor do they test
filename completion.
In gdb.base/filename-completion.exp I have added some tests that test
the -filename option with real filenames, and exercise filename tab
completion.
This commit doesn't include any real uses of the new filename options,
that will come in the next commit.
I had reason to look at the gdb.stabs/gdb11479.exp test script and
figured it could do with a small clean up. I've:
- Made use of standard_testfile and the variables it defines.
- Made use of with_test_prefix and removed the prefix from the end
of each test name.
- Avoid overwriting the test binary when we recompile, instead use a
different name for each recompilation.
- Add '.' at the end of each comment.
There should be no changes in what is tested with this commit.
Reviewed-By: Keith Seitz <keiths@redhat.com>
This adds a new event source so that Python scripts can track whether
or not the TUI is presently enabled.
v2 of the patch renames "status" -> "enabled".
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32162
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Reviewed-by: Keith Seitz <keiths@redhat.com>
There are two useful ways to run a test-case, that are not represented by a
board file in gdb/testsuite/boards: check-read1 and check-readmore.
Consequently, they're not run either by make-check-all.sh.
Fix this by adding check-read1 and check-readmore to make-check-all.sh.
Tested on x86_64-linux. Verified with shellcheck.
Approved-By: Andrew Burgess <aburgess@redhat.com>
When compiling dw2-multiple-debug-info.c using -gdwarf-5
-fdebug-types-section, we end with two .debug_info sections in the object
file:
...
$ g++ gdb.dwarf2/dw2-multiple-debug-info.c -c -g \
-gdwarf-5 \
-fdebug-types-section
$ readelf -WS dw2-multiple-debug-info.o | grep -v RELA | grep .debug_info
[10] .debug_info PROGBITS 0 000128 0000cd 00 GC 0 0 8
[12] .debug_info PROGBITS 0 0001f8 0000ad 00 C 0 0 8
...
One of them contains the CU for dw2-multiple-debug-info.c, the other contains
the TU for the type of variable a.
When trying to print the type of variable a, we get:
...
$ gdb -q -batch dw2-multiple-debug-info.o -ex "ptype a"
'a' has unknown type; cast it to its declared type
...
because the TU hasn't been read.
Fix this by adding support for reading multiple .debug_info sections, similar
to how that is done for multiple .debug_types sections, getting us instead:
...
$ gdb -q -batch dw2-multiple-debug-info.o -ex "ptype a"
type = class sp1::A {
...
}
...
Tested on x86_64-linux.
PR symtab/32223
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32223
Before this change resolve_dynamic_array_or_string was called for
all TYPE_CODE_ARRAY and TYPE_CODE_STRING types, but, in the end,
this function always called create_array_type_with_stride, which
creates a TYPE_CODE_ARRAY type.
Suppose we have
subroutine vla_array (arr1, arr2)
character (len=*):: arr1 (:)
character (len=5):: arr2 (:)
print *, arr1 ! break-here
print *, arr2
end subroutine vla_array
The "print arr1" and "print arr2" command at the "break-here" line
gives the following output:
(gdb) print arr1
$1 = <incomplete type>
(gdb) print arr2
$2 = ('abcde', 'abcde', 'abcde')
(gdb) ptype arr1
type = Type
End Type
(gdb) ptype arr2
type = character*5 (3)
Dwarf info using Intel® Fortran Compiler for such case contains following:
<1><fd>: Abbrev Number: 12 (DW_TAG_string_type)
<fe> DW_AT_name : (indirect string, offset: 0xd2): .str.ARR1
<102> DW_AT_string_length: 3 byte block: 97 23 8 (DW_OP_push_object_address; DW_OP_plus_uconst: 8)
After this change resolve_dynamic_array_or_string now calls
create_array_type_with_stride or create_string_type, so if the
incoming dynamic type is a TYPE_CODE_STRING then we'll get back a
TYPE_CODE_STRING type. Now gdb shows following:
(gdb) p arr1
$1 = ('abddefghij', 'abddefghij', 'abddefghij', 'abddefghij', 'abddefghij')
(gdb) p arr2
$2 = ('abcde', 'abcde', 'abcde')
(gdb) ptype arr1
type = character*10 (5)
(gdb) ptype arr2
type = character*5 (3)
In case of GFortran, compiler emits DW_TAG_structure_type for string type
arguments of the subroutine and it has only DW_AT_declaration tag. This
results in <incomplete type> in gdb. So, following issue is raised in gcc
bugzilla "https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101826".
Fixing above issue introduce regression in gdb.fortran/mixed-lang-stack.exp,
i.e. the test forces the language to C/C++ and print a Fortran string value.
The string value is a dynamic type with code TYPE_CODE_STRING.
Before this commit the dynamic type resolution would always convert this to
a TYPE_CODE_ARRAY of characters, which the C value printing could handle.
But now after this commit we get a TYPE_CODE_STRING, which
neither the C value printing, or the generic value printing code can
support. And so, I've added support for TYPE_CODE_STRING to the generic
value printing, all characters of strings are printed together till the
first null character.
Lastly, in gdb.opt/fortran-string.exp and gdb.fortran/string-types.exp
tests it expects type of character array in 'character (3)' format but now
after this change we get 'character*3', so tests are updated accordingly.
Approved-By: Tom Tromey <tom@tromey.com>
This commit adds recording support for the AVX instruction vzeroupper,
which zeroes the high bits of ymm registers 0..15. In the programmer's
manual, it is explicitly states that ymm registers 16..31 won't be
affected if present, so we only need to record the first 16 registers.
We record ymm_h registers since only the higher bits are touched, and
that reduces the memory footprint of the instruction.
This instruction is tested differently as we want to confirm we're only
saving the relevant registers, and we want to ensure we're saving
all of them, so it makes use of "maint print record-instruction" to see
exactly what was recorded.
Approved-By: Tom Tromey <tom@tromey.com>
This commit adds support for the instructions VMOVDQU and VMOVDQA, used
to move values to/from 256 bit registers. Unfortunately, the
programmer's manual is very incomplete (if not wrong) about these
instructions, so the logic had to be reverse engineered from how gcc
actually encodes the instruction.
This commit also changes the memory regions from the test to store 256
bits, so its easier to test the instructions and that we're recording
ymm registers correctly.
Approved-By: Tom Tromey <tom@tromey.com>
This commit adds recording support to all AVX and AVX2 instructions
of the form vpbroadcast. GDB is not yet concerned about AVX512 in
recording mode, so for now we only support the AVX2 registers and
instructions.
This commit also updates the gdb.reverse/i386-avx-reverse.exp to test
broadcast instructions.
Approved-By: Tom Tromey <tom@tromey.com>
This commit adds support to recording instructions to unpack high
or low data from XMM registers, identified by the mnemonics in the
form: VPUNPCK [L|H] [BW|WD|DQ|QDQ].
All these instructions are encoded the exact same way, and only affect
the destination register, making them trivial to implement together.
It also updates the test gdb.reverse/i386-avx-reverse.exp to test these
new instructions. The test always uses ymm because the vpunpck
instructions overwrite the high bits, so we have to be able to record
the full ymm register, not just the output size.
Approved-By: Tom Tromey <tom@tromey.com>
This commit adds support to the x86_64 AVX instructions vmovd and vmovq.
The programmers manuals for Intel and AMD describe these 2 instructions
as being almost the same, but my local testing, using gcc 13.2 on Fedora
39, showed several differences and inconsistencies.
The instruction is supposed to always use the 3-byte VEX prefix, but I
could only find 2-byte versions. The instructions aren't differentiated
by the VEX.w bit, but by opcodes and VEX.pp.
This patch adds a test with many different uses for both vmovd and
vmovq. It also updates the test gdb.reverse/step-precsave.exp to
reference the generic "missing avx support" bug open in the bug tracker
(17346), instead of pointing to one that specifically calls out to
vmovd instructions.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=23188
Approved-By: Tom Tromey <tom@tromey.com>
This patch introduces the information needed to properly identify the
VEX prefix, used to signal an AVX and AVX2 instruction, and introduces
a helper function to handle all AVX instruction, instead of adding to
the 3000 line long recording function.
This new function will temporarily set the current thread as "not
executing" so that it can read from pseudo registers as we record, since
most AVX/AVX2 instructions would benefit from recording ymm registers.
The new helper also handles unsupported instructions so that the largest
part of the i386_process_record doesn't have to be shifted by 2 spaces,
which made an unreadably big patch file.
The only expected difference to the end user added by this patch is a
small change to the unsupported message. This patch also updates the
test gdb.reverse/step-precsave.exp, by recognizing the new output.
As a note for the future, we don't handle xmm16-31 and ymm16-31 because
those require the EVEX prefix, meaning avx512 support.
Approved-By: Tom Tromey <tom@tromey.com>
I saw a failure in gdb.debuginfod/build-id-no-debug-warning.exp which
I could only produce one time.
Normally the test output looks like this:
file /tmp/build/gdb/testsuite/outputs/gdb.debuginfod/build-id-no-debug-warning/.build-id/0c/30f589cc4f2c0fb22c8914d042ddf39c9a3885.debug
Reading symbols from /tmp/build/gdb/testsuite/outputs/gdb.debuginfod/build-id-no-debug-warning/.build-id/0c/30f589cc4f2c0fb22c8914d042ddf39c9a3885.debug...
Downloading separate debug info for /tmp/build/gdb/testsuite/outputs/gdb.debuginfod/build-id-no-debug-warning/.build-id/0c/30f589cc4f2c0fb22c8914d042ddf39c9a3885.debug...
Reading symbols from /tmp/build/gdb/testsuite/outputs/gdb.debuginfod/build-id-no-debug-warning/.client_cache/0c30f589cc4f2c0fb22c8914d042ddf39c9a3885/debuginfo...
(gdb) PASS: gdb.debuginfod/build-id-no-debug-warning.exp: local_debuginfod: debuginfod running, info downloaded, no war
But one time I saw this:
file /tmp/build/gdb/testsuite/outputs/gdb.debuginfod/build-id-no-debug-warning/.build-id/0c/30f589cc4f2c0fb22c8914d042ddf39c9a3885.debug
Reading symbols from /tmp/build/gdb/testsuite/outputs/gdb.debuginfod/build-id-no-debug-warning/.build-id/0c/30f589cc4f2c0fb22c8914d042ddf39c9a3885.debug...
Downloading 6.77 K separate debug info for /tmp/build/gdb/testsuite/outputs/gdb.debuginfod/build-id-no-debug-warning/.build-id/0c/30f589cc4f2c0fb22c8914d042ddf39c9a3885.debug...
Reading symbols from /tmp/build/gdb/testsuite/outputs/gdb.debuginfod/build-id-no-debug-warning/.client_cache/0c30f589cc4f2c0fb22c8914d042ddf39c9a3885/debuginfo...
(gdb) FAIL: gdb.debuginfod/build-id-no-debug-warning.exp: local_debuginfod: debuginfod running, info downloaded, no warnings
The difference is the "Downloading separate debug info for ..." line
has gained an extra '6.77 K' component. When I got the FAIL the
machine was under heavy load, so I suspect everything was running
pretty slow. I think the size is only added when the debuginfod
download is taking its time.
Anyway, the test in question is not expecting to see a size, which is
why it failed.
Every other debuginfod test does allow for an optional size being
printed, so lets update this test to also accept an optional size,
this should prevent failures like this in the future.
There are two test-cases that only run when the target board produces .dwp
files, gdb.dwarf2/dwp-sepdebug.exp and gdb.dwarf2/dwp-symlink.exp.
When running those test-cases with target board fission-dwp, I run into:
...
(gdb) ptype main^M
warning: Could not find DWO CU dwp-symlink0.dwo(0x496f1a7405c37a61) \
referenced by CU at offset 0xa6 [in module dwp-symlink]^M
type = <unknown return type> ()^M
(gdb) FAIL: gdb.dwarf2/dwp-symlink.exp: binary default, dwp at symlink
...
coming from:
...
# This case cannot work.
gdb_test "ptype main" {type = int \(\)} "binary default, dwp at symlink"
...
I had a bit of difficulty understanding what the test-case does/tries to do,
so to build some understanding I reproduced the behaviour outside of the
test-case:
...
$ cat start.c
void _start (void) {}
$ gcc -gsplit-dwarf start.c -nostdlib
$ gdb -q -batch a.out -ex "print _start"
$1 = {void (void)} 0x400144 <_start>
$ dwp -e a.out
$ rm start.dwo
$ gdb -q -batch a.out -ex "print _start"
$1 = {void (void)} 0x400144 <_start>
$ ln -s a.out b.out
$ gdb -q -batch b.out -ex "print _start"
$1 = {void (void)} 0x400144 <_start>
$ mv a.out.dwp b.out.dwp
$ gdb -q -batch b.out -ex "print _start"
$1 = {void (void)} 0x400144 <_start>
$ gdb -q -batch a.out -ex "print _start"
During symbol reading: Could not find DWO CU start.dwo(0x8bdfd613387aa145) \
referenced by CU at offset 0x0 [in module a.out]
warning: Could not find DWO CU start.dwo(0x8bdfd613387aa145) \
referenced by CU at offset 0x0 [in module a.out]
$1 = {<text variable, no debug info>} 0x400144 <_start>
...
and agreed, that cannot work: the DWO CU required in a.out is in b.out.dwp,
and there's no way to find b.out.dwp starting from a.out.
The fact that a FAIL is produced is incorrect, gdb does nothing wrong.
Fix this by checking for the warning text instead.
While we're at it, fix this PATH as well:
...
(gdb) cd /data/vries/gdb/leap-15-5/build/gdb/testsuite/outputs/gdb.dwarf2/dwp-symlink^M
Working directory /data/vries/gdb/leap-15-5/build/gdb/testsuite/outputs/gdb.dwarf2/dwp-symlink.^M
(gdb) PASS: gdb.dwarf2/dwp-symlink.exp: cd \
/data/vries/gdb/leap-15-5/build/gdb/testsuite/outputs/gdb.dwarf2/dwp-symlink
PATH: gdb.dwarf2/dwp-symlink.exp: cd \
/data/vries/gdb/leap-15-5/build/gdb/testsuite/outputs/gdb.dwarf2/dwp-symlink
...
While we're at it, use string_to_regexp to simplify the test-case.
Tested on x86_64-linux, with target board fission-dwp.
After commit:
commit a1ccc78ea7
Date: Fri Oct 25 06:14:03 2024 +0200
[gdb/testsuite] Fix some test-cases for check-read1 (-lbl)
I notice that gdb.base/sect-cmd.exp would sometimes fail. The problem
is that by switching to line by line matching we now need to ensure
that the gdb_test_multiple patterns match up to the end of the line,
but don't actually include the trailing \r\n (yeah, our line by line
matching is weird). We need to be especially careful anywhere '.*' is
used as this can potentially match content on a subsequent line.
I have replaced '.*' with '\[^\r\n\]*(?=\r\n)', matching everything up
to the end of the line, but not the end of line itself, and I've made
use of '(?=\r\n)' in a couple of other places to ensure we match up to
the end of the line, but don't match the line terminator itself.
Fix test-case gdb.cp/exceptprint.exp with make target check-read1 by limiting
the output of skip_libstdcxx_probe_tests_prompt by making the used command
more precise: using "info probes stap libstdcxx" instead of "info probes".
Tested on x86_64-linux.
Fix test-case gdb.threads/ia64-sigill.exp with make target check-read1 by
using a custom line-by-line exp_continue clause:
...
-re "\r\n\[^\r\n\]*(?=\r\n\[^\r\n\]*\r\n)" {
exp_continue
}
...
which drops a line each time it finds two lines in the buffer.
This allows the other clauses to use two-line patterns.
Tested on x86_64-linux.
I ran the testsuite in an environment simulating a stressed system in
combination with check-read1. This exposes a few more FAILs.
Fix some by using -lbl.
Tested on x86_64-linux.
I ran the testsuite in an environment simulating a stressed system in
combination with check-read1. This exposes a few more FAILs.
Fix some by using pipe / grep to filter out unnecessary output.
Tested on x86_64-linux.
I ran the testsuite in an environment simulating a stressed system in
combination with check-read1. This exposes a few more FAILs.
Fix some by using gdb_test_lines, as well as related gdb_get_lines.
Tested on x86_64-linux.
A few tests on the testsuite require dwarf5 to work. Up until now, the
way to do this was to explicitly add the command line flag -gdwarf-5.
This isn't very portable, in case a compiler requires a different flag
to emit dwarf5.
This commit adds a new option to gdb_compile that would be able to add
the correct flag (if known) or error out in case we are unable to tell
which flag to use. It also changes the existing tests to use this
general option instead of hard coding -gdwarf-5.
Reviewed-by: Keith Seitz <keiths@redhat.com>
Approved-By: Tom Tromey <tom@tromey.com>
This patch started as an attempt to allow the 'Size attribute to be
applied to types, and not just objects.
However, that turns out to be difficult due to the Ada semantcs of
'Size. In particular, Ada requires 'Size to denote the size of the
representation of the value, so for example Boolean'Size must be 1.
Implementing this properly requires information not readily available
to gdb... and while we could synthesize this information in many
cases, it also seemed to me that this wasn't strictly very useful when
debugging.
So instead, this patch adds support for the 'Object_Size attribute,
which is somewhat closer to 'sizeof'.
Note also that while 'Object_Size is defined for some dynamic types, I
chose not to implement this here, as again this information is not
readily available -- and I think it's preferable to error than to
print something that might be incorrect.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
I ran the testsuite with a patch setting dwarf_synchronous to false by
default, and ran into FAILs in test-cases gdb.dwarf2/dw2-inter-cu-error.exp
and gdb.dwarf2/dw2-inter-cu-error-2.exp, because the expected DWARF errors did
not show up as a result of the file command.
Fix this by forcing "maint set dwarf synchronous on".
Add the same in gdb.base/index-cache.exp, where this is also required.
Tested on aarch64-linux.
I ran into:
...
(gdb) pipe maint print objfiles self-spec | grep c1^M
name: c1^M
canonical: c1^M
qualified: c1^M
[3] ((addrmap *) 0xfffedfc1f010)^M
(gdb) FAIL: gdb.dwarf2/self-spec.exp: class c1 in cooked index
...
Fix this by renaming the class from c1 to class1.
Tested on aarch64-linux.
With target board unix we get:
...
$ gdb -q -batch outputs/gdb.cp/cplusfuncs/cplusfuncs \
-ex "info function operator\*"
All functions matching regular expression "operator\*":
File /home/vries/gdb/src/gdb/testsuite/gdb.cp/cplusfuncs.cc:
72: void foo::operator*(foo&);
85: void foo::operator*=(foo&);
...
but with target board cc-with-dwz-m:
...
All functions matching regular expression "operator\*":
File /usr/lib/gcc/aarch64-redhat-linux/14/include/stddef.h:
72: void foo::operator*(foo&);
85: void foo::operator*=(foo&);
...
The first operator:
...
$ c++filt _ZN3foomlERS_
foo::operator*(foo&)
...
matches address 0x410250 which is defined here in the CU in the exec:
...
<1><10f1>: Abbrev Number: 13 (DW_TAG_subprogram)
<10f2> DW_AT_specification: <alt 0x93>
<10f6> DW_AT_decl_line : 72
<10f7> DW_AT_decl_column : 7
<10f7> DW_AT_object_pointer: <0x1106>
<10f9> DW_AT_low_pc : 0x410250
<1101> DW_AT_high_pc : 32
<1102> DW_AT_frame_base : 1 byte block: 9c (DW_OP_call_frame_cfa)
<1104> DW_AT_call_all_calls: 1
...
and declared here in the PU in the .dwz file:
...
<2><93>: Abbrev Number: 20 (DW_TAG_subprogram)
<94> DW_AT_external : 1
<94> DW_AT_name : operator*
<98> DW_AT_decl_file : 2
<98> DW_AT_decl_line : 10
<99> DW_AT_decl_column : 9
<9a> DW_AT_linkage_name: _ZN3foomlERS_
<9e> DW_AT_accessibility: 1 (public)
<9e> DW_AT_declaration : 1
<9e> DW_AT_object_pointer: <0xa2>
...
When creating a new symbol for the operator, the DW_AT_decl_file attribute is
looked up, and found to be 2.
The 2 is supposed to be mapped using the PU, which has this file name table:
...
The File Name Table (offset 0x78, lines 3, columns 2):
Entry Dir Name
0 0 <dwz>
1 1 stddef.h
2 2 cplusfuncs.cc
...
Instead, it's mapped using the CU, which has this file name table:
...
The File Name Table (offset 0x34, lines 3, columns 2):
Entry Dir Name
0 1 cplusfuncs.cc
1 1 cplusfuncs.cc
2 2 stddef.h
...
This is PR symtab/30814. There's a similar PR for lto, PR symtab/25771, where
the same problem happens for two CUs.
Fix this by using the correct file name table.
Add a dwarf assembly test-case for PR25771.
Tested on aarch64-linux.
Reviewed-By: Tom Tromey <tom@tromey.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=25771
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30814
Add handling of '.' in gdb/contrib/spellcheck.sh.
While we're at, simplify the sed invocation by using a single s command
instead of 3 s commands.
Also introduce sed_join and grep_join.
Fix the following common misspellings:
...
bandwith -> bandwidth
emmitted -> emitted
immediatly -> immediately
suprize -> surprise
thru -> through
transfered -> transferred
...
Verified with shellcheck.
A question was asked on stackoverflow.com about the guile function
get-basic-type[1] which is mentioned in the docs along with an example
of its use.
The problem is, the function was apparently never actually added to
GDB. But it turns out that it's pretty easy to implement, so lets add
it now. Better late than never.
The implementation mirrors the Python get_basic_type function. I've
added a test which is a copy of the documentation example.
One issue is that the docs suggest that the type will be returned as
just "int", however, I'm not sure what this actually means. It makes
more sense that the function return a gdb:type object which would be
represented as "#<gdb:type int>", so I've updated the docs to show
this output.
[1] https://stackoverflow.com/questions/79058691/unbound-variable-get-basic-type-in-gdb-guile-session
Reviewed-By: Kevin Buettner <kevinb@redhat.com>
There is an invalid assumption within 'maint info inline-frames' which
triggers an assert:
(gdb) stepi
0x000000000040119d 18 printf ("Hello World\n");
(gdb) maintenance info inline-frames
../../src/gdb/inline-frame.c:554: internal-error: maintenance_info_inline_frames: Assertion `it != inline_states.end ()' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
----- Backtrace -----
... etc ...
The problem is this assert:
/* Stopped threads always have cached inline_state information. */
gdb_assert (it != inline_states.end ());
If you check out infrun.c and look in handle_signal_stop for the call
to skip_inline_frames then you'll find a rather large comment that
explains that we don't always compute the inline state information for
performance reasons. So the assertion is not valid.
I've updated the code so that if there is cached information we use
that, but if there is not then we just create our own information for
the current $pc of the current thread.
This means that, if there is cached information, GDB still correctly
shows which frame the inferior is in (it might not be in the inner
most frame).
If there is no cached information we will always display the inferior
as being in the inner most frame, but that's OK, because if
skip_inline_frames has not been called then GDB will have told the
user they are in the inner most frame, so everything lines up.
I've extended the test to check 'maint info inline-frames' after a
stepi which would previously have triggered the assertion.
Consider test-case gdb.dwarf2/local-var.exp. The corresponding source
contains a function with a local variable:
...
program test
logical :: local_var
local_var = .TRUE.
end
...
Currently, the local variable shows up in the cooked index:
...
[2] ((cooked_index_entry *) 0xfffec40063b0)
name: local_var
canonical: local_var
qualified: local_var
DWARF tag: DW_TAG_variable
flags: 0x2 [IS_STATIC]
DIE offset: 0xa3
parent: ((cooked_index_entry *) 0xfffec4006380) [test]
...
making the cooked index larger than necessary.
Fix this by skipping it in cooked_indexer::index_dies.
Tested on aarch64-linux.
PR symtab/32276
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32276
When running test-case gdb.ada/fixed_points.exp with system gcc 7, I run
into:
...
(gdb) PASS: gdb.ada/fixed_points.exp: scenario=all: print fp4_var / 1
get_compiler_info: gcc-7-5-0
p Float(Another_Fixed) = Float(Another_Delta * 5)^M
No definition of "another_delta" in current context.^M
(gdb) FAIL: gdb.ada/fixed_points.exp: scenario=all: value of another_fixed
...
This is a regression since commit 1411185a57 ("Introduce and use
gnat_version_compare"), which did:
...
# This failed before GCC 10.
- if {$scenario == "all" && [test_compiler_info {gcc-10-*}]} {
+ if {$scenario == "all" && [gnat_version_compare < 10]} {
gdb_test "p Float(Another_Fixed) = Float(Another_Delta * 5)" "true" \
"value of another_fixed"
}
...
Fix this by using gnat_version_compare >= 10 instead.
Tested on x86_64-linux, with gcc 7 - 13.
While testing a modified GNAT, I found that this test in
fun_renaming.exp was returning 0 for GCC 13:
if {[test_compiler_info {gcc-6*}]}
This patch introduces a new, more robust way to check the GNAT
compiler version, and changes the gda.ada tests to use it. A small
update to version_compare was also needed.
Note that, in its current form, this new code won't really interact
well with non-GCC compilers (specifically gnat-llvm). This doesn't
seem like a major issue at this point, though, because gnat-llvm
doesn't properly emit debuginfo yet, and when it does, more changes
will be needed in these tests anyway.
Reviewed-by: Keith Seitz <keiths@redhat.com>
A recent commit, "16a6f7d2ee3 gdb: avoid breakpoint::clear_locations
calls in update_breakpoint_locations", started checking if GDB correctly
relocates a breakpoint from inferior 1's declaration of the function
"bar" to inferior 2's declaration.
Unfortunately, inferior 2 never calls bar in its regular execution, and
because of that, clang would optimize that whole function away, making
it so there is no location for the breakpoint to be relocated to.
This commit changes the .c file so that the function is not optimized
away and the test fully passes with clang. It is important to actually
call bar instead of using __attribute__((used)) because the latter
causes the breakpoint locations to be inverted, 3.1 belongs to inferior
2 and 3.2 belongs to inferior 1, which will cause an unrelated failure.
Approved-By: Andrew Burgess <aburgess@redhat.com>
On arm-linux, with test-case gdb.base/scope-hw-watch-disable.exp I run into:
...
(gdb) awatch a^M
Can't set read/access watchpoint when hardware watchpoints are disabled.^M
(gdb) PASS: $exp: unsuccessful attempt to create an access watchpoint
rwatch b^M
Can't set read/access watchpoint when hardware watchpoints are disabled.^M
(gdb) PASS: $exp: unsuccessful attempt to create a read watchpoint
continue^M
Continuing.^M
^M
Program received signal SIGSEGV, Segmentation fault.^M
0xf7ec82c8 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6^M
(gdb) FAIL: $exp: continue until exit
...
Using "maint info break", we can see that the two failed attempts to set a
watchpoint each left behind a stale "watchpoint scope" breakpoint:
...
-5 watchpoint scope del y 0xf7ec569a inf 1
-5.1 y 0xf7ec569a inf 1
stop only in stack frame at 0xfffef4f8
-6 watchpoint scope del y 0xf7ec569a inf 1
-6.1 y 0xf7ec569a inf 1
stop only in stack frame at 0xfffef4f8
...
The SIGSEGV is a consequence of the stale "watchpoint scope" breakpoint: the
same happens if we:
- have can-use-hw-watchpoints == 1,
- set one of the watchpoints, and
- continue to exit.
The problem is missing symbol info on libc which is supposed to tell which
code is thumb. After doing "set arm fallback-mode thumb" the SIGSEGV
disappears.
Extend the test-case to check the "maint info break" command before and after
the two failed attempts, to make sure that we catch the stale
"watchpoint scope" breakpoints also on x86_64-linux.
Fix this in watch_command_1 by moving creation of the "watchpoint scope"
breakpoint after the call to update_watchpoint.
Tested on x86_64-linux.
PR breakpoints/31860
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31860
When running test-case gdb.dwarf2/enum-type-c++.exp with clang, we get:
...
FAIL: gdb.dwarf2/enum-type-c++.exp: val1 has a parent
FAIL: gdb.dwarf2/enum-type-c++.exp: print ns::A::val1
FAIL: gdb.dwarf2/enum-type-c++.exp: val2 has correct parent
FAIL: gdb.dwarf2/enum-type-c++.exp: print ns::ec::val2
...
The problem is that the debug info produced by clang does not contain any
references to enumerators val1 and val2, or the corresponding enumeration
types.
Instead, the variables u1 and u2 are considered to be simply of type int:
...
<1><fb>: Abbrev Number: 2 (DW_TAG_variable)
<fc> DW_AT_name : u1
<fd> DW_AT_type : <0x106>
<101> DW_AT_external : 1
<103> DW_AT_location : (DW_OP_addrx <0>)
<1><106>: Abbrev Number: 3 (DW_TAG_base_type)
<107> DW_AT_name : int
<108> DW_AT_encoding : 5 (signed)
<109> DW_AT_byte_size : 4
<1><10a>: Abbrev Number: 2 (DW_TAG_variable)
<10b> DW_AT_name : u2
<10c> DW_AT_type : <0x106>
<110> DW_AT_external : 1
<112> DW_AT_location : (DW_OP_addrx <0x1>)
...
Fix this by checking whether val1 and val2 are present in the cooked index
before checking whether they have the correct parent.
This cannot be expressed efficiently with gdb_test_lines, so factor out
gdb_get_lines and use that instead.
The test-case still calls "maint print objfiles" twice, but the first time is
for have_index. We should probably use a gdb_caching_proc for this.
Tested on aarch64-linux.
Reported-By: Guinevere Larsen <guinevere@redhat.com>
Reviewed-By: Keith Seitz <keiths@redhat.com>
Tested-By: Guinevere Larsen <guinevere@redhat.com>
I ran the testsuite in an environment simulating a stressed system in
combination with check-read1. This exposes a few more FAILs.
Fix the gdb.dwarf2 ones by using pipe / grep to filter out unnecessary output.
Tested on x86_64-linux.
On aarch64-linux, with make target check-read1, I run into:
...
(gdb) info reg vector^M
...
d19 {f = 0x0, u = 0x0, s = 0x0} {f =FAIL: gdb.base/reggroups.exp: fetch reggroup regs vector (timeout)
0, u = 0, s = 0}^M
...
The problem is that while (as documented) the corresponding gdb_test_multiple
doesn't work for vector registers, it doesn't skip them either. This causes
the timeout, and it also causes the registers after a vector register not to
be found.
Fix this by using -lbl style matching.
Make which reggroups and registers are found more explicit using verbose -log,
which makes us notice that regnames with underscores are skipped, so fix that
as well.
While we're at it, this:
...
set invalid_register_re "Invalid register .*"
...
and this:
...
-re $invalid_register_re {
fail "$test (unexpected invalid register response)"
}
...
means that the prompt may or may not be consumed. Fix this by limiting the
regexp to one line, and using exp_continue.
While we're at it, improve readability of the complex regexp matching a single
register by factoring out regexps.
Tested on aarch64-linux and x86_64-linux.
This changes a few implementations of "info proc mappings" to use
ui-out tables rather than printf.
Note that NetBSD and FreeBSD also use printfs here, but since I can't
test these, I didn't update them.
Approved-By: Andrew Burgess <aburgess@redhat.com>
When running test-case gdb.base/break-interp.exp with check-read1, I run into:
...
(gdb) info files^M
...
0x00007ffff7e75980 - 0x00007ffff7e796a0 @ 0x001f1970 is .bss in /data/vries/gdb/leap-15-5/build/gdb/testsuite/outputs/gdb.base/break-interp/break-interp-BINprelinkNOdebugNOFAIL: gdb.base/break-interp.exp: ldprelink=NO: ldsepdebug=NO: binprelink=NO: binsepdebug=NO: binpie=NO: INNER: symbol-less: info files (timeout)
pieNO.d/libc.so.6^M
...
The code has two adaptations to deal with the large output:
- nested gdb_test_multiple, and
- an exp_continue in the inner gdb_test_multiple.
The former seems unnecessary, and the latter doesn't trigger often enough
because of an incomplete hex number regexp, causing the timeout.
Get rid of both of these, and use -lbl instead.
Tested on x86_64-linux.
The commit:
commit 6cce025114
Date: Fri Mar 3 19:03:15 2023 +0000
gdb: only insert thread-specific breakpoints in the relevant inferior
added a couple of calls to breakpoint::clear_locations() inside
update_breakpoint_locations().
The intention of these calls was to avoid leaving redundant locations
around when a thread- or inferior-specific breakpoint was switched
from one thread or inferior to another.
Without the clear_locations() calls the tests gdb.multi/tids.exp and
gdb.multi/pending-bp.exp have some failures. A b/p is changed such
that the program space it is associated with changes. This triggers a
call to breakpoint_re_set_one() but the FILTER_PSPACE argument will be
the new program space. As a result GDB correctly calculates the new
locations and adds these to the breakpoint, but the old locations, in
the old program space, are incorrectly retained. The call to
clear_locations() solves this by deleting the old locations.
However, while working on another patch I realised that the approach
taken here is not correct. The FILTER_PSPACE argument passed to
breakpoint_re_set_one() and then on to update_breakpoint_locations()
might not be the program space to which the breakpoint is associated.
Consider this example:
(gdb) file /tmp/hello.x
Reading symbols from /tmp/hello.x...
(gdb) start
Temporary breakpoint 1 at 0x401198: file hello.c, line 18.
Starting program: /tmp/hello.x
Temporary breakpoint 1, main () at hello.c:18
18 printf ("Hello World\n");
(gdb) break main thread 1
Breakpoint 2 at 0x401198: file hello.c, line 18.
(gdb) info breakpoints
Num Type Disp Enb Address What
2 breakpoint keep y 0x0000000000401198 in main at hello.c:18
stop only in thread 1
(gdb) add-inferior -exec /tmp/hello.x
[New inferior 2]
Added inferior 2 on connection 1 (native)
Reading symbols from /tmp/hello.x...
(gdb) info breakpoints
Num Type Disp Enb Address What
2 breakpoint keep y <PENDING> main
stop only in thread 1.1
Notice that after creating the second inferior and loading a file the
thread-specific breakpoint was incorrectly made pending. Loading the
exec file in the second inferior triggered a call to
breakpoint_re_set() with the new, second, program space as the
current_program_space.
This program space ends up being passed to
update_breakpoint_locations().
In update_breakpoint_locations this condition is true:
if (all_locations_are_pending (b, filter_pspace) && sals.empty ())
and so we end up discarding all of the locations for this breakpoint,
making the breakpoint pending.
What we really want to do in update_breakpoint_locations() is, for
thread- or inferior- specific breakpoints, delete any locations which
are associated with a program space that this breakpoint is NOT
associated with.
But then I realised the answer was easier than that.
The ONLY time that a b/p can have locations associated with the
"wrong" program space like this is at the moment we change the thread
or inferior the b/p is associated with by calling
breakpoint_set_thread() or breakpoint_set_inferior().
And so, I think the correct solution is to hoist the call to
clear_locations() out of update_breakpoint_locations() and place a
call in each of the breakpoint_set_{thread,inferior} functions.
I've done this, and added a couple of new tests. All of which are
now passing.
Approved-By: Tom Tromey <tom@tromey.com>
