| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
I recently added two requires in test-case gdb.python/py-missing-objfile.exp:
...
# The following tests assume that the build-ids of binfile and libfile can be
# found in the core file.
require {expect_build_id_in_core_file $binfile}
require {expect_build_id_in_core_file $libfile}
...
However, at the point where the check is done, the files are no longer
available at that location, which makes the require fail.
First, make the problem visible, by making proc expect_build_id_in_core_file
throw an error if the filename argument specifies a non-existing file.
Then, fix test-case gdb.python/py-missing-objfile.exp by moving the calls to
expect_build_id_in_core_file to a point where the files exist.
Tested on x86_64-linux.
|
|
The comment says that it returns 0 if the target supports SME and 1 if
it doesn't, but it actually does the opposite. The code does the right
thing, so fix the comment.
|
|
variable
With test-case gdb.base/until-trailing-insns.exp I run into:
...
ERROR: tcl error code TCL READ VARNAME
ERROR: can't read "_line_unit_advertised_version": no such variable
while executing
"if {$_line_unit_advertised_version == "default"} {
set _line_unit_advertised_version $_line_unit_version
}"
...
Fix this by using the correct variable name in two places in Dwarf::lines:
use _line_unit_advertised_version instead of _line_advertised_unit_version.
Tested on x86_64-linux.
|
|
The Free Pascal Compiler fpc supports generating different versions of DWARF:
...
$ fpc -h
Free Pascal Compiler version 3.2.2 [2025/09/10] for x86_64
...
-gw Generate DWARFv2 debug information (same as -gw2)
-gw2 Generate DWARFv2 debug information
-gw3 Generate DWARFv3 debug information
-gw4 Generate DWARFv4 debug information (experimental)
...
The v4 support is experimental, and indeed the line number information is
broken (missing maximum_operations_per_instruction field in the .debug_line
header), so setting a breakpoint on a line number is not possible:
...
$ fpc -gw4 hello.pas
...
$ gdb -q hello
Reading symbols from hello...
(gdb) b hello.pas:8
No compiled code for line 8 in file "hello.pas".
Make breakpoint pending on future shared library load? (y or [n])
...
The brokenness is detected by llvm-dwarfdump (second warning):
...
$ llvm-dwarfdump -debug-line hello
hello: file format elf64-x86-64
.debug_line contents:
debug_line[0x00000000]
warning: parsing line table prologue at offset 0x0 found opcode base of 0. \
Assuming no standard opcodes
warning: unknown data in line table prologue at offset 0x0: parsing ended (at \
offset 0x00000017) before reaching the prologue end at offset 0x2a
...
Likewise, detect the situation the second warning describes in
dwarf_decode_line_header, getting us instead:
...
(gdb) b hello.pas:8
❌malformed line number program header, advertised length does not match \
actual length
(gdb)
...
Tested on x86_64-linux.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
The gdb.objc tests haven't compiled in years. This patch fixes this,
based on a comment in bug 31671.
I don't know whether this approach works with the clang implementation
of Objective-C. However, it does work with GCC, provided that
gnustep-base is installed.
|
|
In an effort to generate ELF files and DWARF info as close as possible
as an actual compiler would generate, change how we emit type unit
sections to emit each type unit in its own section, in COMDAT section
groups.
We currently emit all type units in a single, standard section (either
.debug_info or .debug_types, depending on the DWARF version). Compilers
emit each type unit in its own .debug_types section. Each section is
placed in a COMDAT section group with a signature based on the type
unit's signature. This lets the linker deduplicate identical type units
by discarding section groups with identical signatures (keeping only one
group with a given signature).
Looking at a .s file generated by gcc, we can see that this is how it
specifies the section for a type unit:
.section .debug_info,"G",@progbits,wi.006fd2152a3054a6,comdat
The "G" flag tells the assembler to place the section in a section
group with signature "wi.006fd2152a3054a6". That string was generated
from the type unit, signature. Finally, the comdat linkage field
indicates that the section group should have the COMDAT flag.
Update the tu proc to emit a section with these properties. In this
case, it's mandatory to specify the type of the section (progbits).
Update the _section proc to accept the new options "group_signature" and
"linkage".
As a result, if you look at the .debug_types section in a .o file from
gcc:
$ readelf -g main.o
COMDAT group section [ 1] `.group' [wt.006fd2152a3054a6] contains 2 sections:
[Index] Name
[ 11] .debug_types
[ 12] .rela.debug_types
COMDAT group section [ 2] `.group' [wt.c621aa8e3c23e450] contains 2 sections:
[Index] Name
[ 13] .debug_types
[ 14] .rela.debug_types
And a .o file created by our DWARF assembler:
$ readelf -g testsuite/outputs/gdb.dwarf2/struct-with-sig/struct-with-sig1.o
COMDAT group section [ 1] `.group' [sig.0x0000000000000001] contains 2 sections:
[Index] Name
[ 10] .debug_types
[ 11] .rela.debug_types
COMDAT group section [ 2] `.group' [sig.0x0000000000000002] contains 2 sections:
[Index] Name
[ 12] .debug_types
[ 13] .rela.debug_types
In both cases, in the fully linked files, there is a single .debug_types section
containing the two type units, as expected.
Before this patch, when I run gdb.dwarf2/fission-with-type-unit.exp, the
resulting .dwo file has a single .debug_info.dwo. After this patch it
has two: one with the type unit and one with the compile unit (the test
uses DWARF 5). Based on what I see gcc generate when using "-gdwarf-5
-gsplit-dwarf -fdebug-types-section", this is what we expect.
Change-Id: Ie1954dc697fe100b5dbe664d148c71fa02888d96
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
New in v2: return early if the section is .debug_str
The following patch will add more options to the _section proc, so
convert it to use options, to be more user-friendly.
Change-Id: I971e4e10e55d63af2a5e29dc5e1d00f368b3ecaa
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
When I wrote test gdb.dwarf2/fission-with-type-unit.exp, I did not use
build_executable_and_dwo_files, because it wouldn't work to have
multiple units in the .dwo file, each referring to their own abbrev
table using labels. build_executable_and_dwo_files extracts the .dwo
file content from the .o using objcopy (just like gcc does, I learned),
meaning that the .dwo file never runs through a linker. Anything
needing relocation (like labels pointing to abbrev tables) doesn't work.
I instead opted to use gdb_compile_shlib to build the .dwo file on its
own, so that those labels would get resolved. That causes problems now
that I'm trying to write a test with multiple type units in a .dwo file,
where each type unit should be in its own .debug_types section. Running
the .dwo file through the linker causes all the .debug_types section to
be collapsed into one. And generally, I think it was a bad idea to
generate a .dwo file using the linker, since the idea behind .dwo files
is that they do not need to be linked (therefore improving link
times). We want to produce files as close to what an actual compiler
would produce.
This patch fixes this by doing what compilers do in the same situation:
use a single abbrev table shared by all units in the .dwo file. This
requires the following changes in lib/dwarf.exp:
- Declare a new variable _dwo_abbrev_num, which holds the next
abbrev number to use in the .dwo file's abbrev section
(.debug_abbrev.dwo). Initialize this variable to 1.
- When producing a CU or TU in a .dwo file, use 0 as the abbrev table
offset.
- When generating a DIE, return $_dwo_abbrev_num or $_abbrev_num,
depending on whether the current CU is in a .dwo file.
- After producing a CU or TU in a .dwo file, don't append the
terminator byte.
- After finishing producing the CUs and TUs, append the terminator byte
in .debug_abbrev.dwo if we did output anything there.
Update gdb.dwarf2/fission-with-type-unit.exp to use
build_executable_and_dwo_files, as it should. Remove the
gdb_remote_download call from gdb.dwarf/fission-with-type-unit.exp,
because build_executable_and_dwo_files does not support remote hosts
anyway.
With this change, running with the cc-with-gdb-index board, I see:
(gdb) maint expand-symtabs
/home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:3056: internal-error: cutu_reader: Assertion `sig_type->signature == cu->header.signature' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
----- Backtrace -----
FAIL: gdb.dwarf2/fission-with-type-unit.exp: maint expand-symtabs (GDB internal error)
This is actually an improvement, as the test case didn't run properly
before. The compilation failed with:
gdb compile failed, During symbol reading: Could not find DWO CU fission-with-type-unit.dwo(0xf00d) referenced by CU at offset 0xc [in module /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.dwarf2/fission-with-type-unit/.tmp/fission-with-type-unit]
The reason was that the old code would try to generate the GDB index
during this step:
# Build main file.
if { [build_executable "${testfile}.exp" $binfile \
[list ${srcfile} ${main_asm_file}] {nodebug}] } {
return
}
... which is before the DWO file is even generated. With this patch
things are done in the correct order:
- The -dw.S file is generated
- The -dw.o file is compiled from the -dw.S
- The .dwo sections are extracted to the .dwo file, and stripped from
the -dw.o file
- The executable is linked from the .o and -dw.o
- gdb-add-index is ran on the executable
When gdb-add-index runs, the .dwo file exists, so GDB is able to produce
an index. That index is bogus though, because the .gdb_index format is
unable to describe skeletonless type units. And then GDB gets confused
trying to use that index, leading to the internal error.
Change-Id: Iabbcf00db97faf2a4fa5fc71652ad273081189f9
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
all failure paths
There are some paths of build_executable_and_dwo_files that return -1
without calling "untested". As a result, tests such as
gdb.dwarf2/fission-absolute-dwo.exp would exit without leaving a trace.
Add some untested calls to fix that.
Change-Id: I2e632b5b44b11b4beb39791316f1203f9a12bf4f
Approved-By: Tom Tromey <tom@tromey.com>
|
|
When merging the big "whitespace fix" commit in a downstream repo,
pre-commit/codespell identified a lot of typos, fix a few of them.
Change-Id: Ie898e9903daa4e6e0e49a623891a739071e91392
Approved-By: Tom de Vries <tdevries@suse.de>
|
|
This is the result of:
...
$ git rm -rf gdb/testsuite
$ git commit -a -m tmp
$ git revert HEAD
$ git rebase --whitespace=fix HEAD^
...
Tested on x86_64-linux.
PR build/33616
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33616
|
|
Add tests for FPMR support in gdb/gdbserver. These tests check
availability of FPMR, reading/writing to FPMR, core file generation and
preservation under sighandler frame unwinding.
A run of the full gdb testsuite has been done on aarch64-none-linux-gnu
without FPMR support. The gdb.arch tests were run on Shrinkwrap with
FPMR support.
Approved-By: Luis Machado <luis.machado.foss@gmail.com>
|
|
Fix typo in lib/compiler.cc: IBM'x -> IBM's.
|
|
Fix typo in gdb.base/nodebug.exp and lib/compiler.c: IBM'x -> IBM's.
|
|
On i686-linux (and likewise arm-linux), I run into:
...
(gdb) file str-chars^M
Reading symbols from str-chars...^M
warning: stabs debug information is not supported.^M
(No debugging symbols found in str-chars)^M
(gdb) delete breakpoints^M
...
Fix this by using fpc option -gw2.
Tested on i686-linux.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
PR testsuite/33564
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33564
|
|
Change-Id: I2e26a9953324c752edd01b37db6b176fd0ee9187
|
|
When running the following command on LoongArch:
git clone git://sourceware.org/git/binutils-gdb.git gdb
mkdir -p build && cd build && ../gdb/configure && make -j"$(nproc)"
make check-gdb TESTS="gdb.threads/step-over-thread-exit-while-stop-all-threads.exp"
there exists the following error:
gdb/gdb/testsuite/lib/my-syscalls.S:67:3: error: #error "Unsupported architecture"
this is because there is no SYSCALL macro for LoongArch, just add it.
With this patch, the above test passes on LoongArch.
Signed-off-by: Zewei Yang <yangzewei@loongson.cn>
Tested-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
|
|
Add proc subst_vars, an alias of subst -nobackslashes -nocommands.
I've used tailcall to implement this:
...
proc subst_vars { str } {
tailcall subst -nobackslashes -nocommands $str
}
...
but I found that this also works:
...
proc subst_vars { str } {
return [uplevel 1 [list subst -nobackslashes -nocommands $str]]
}
...
I've found other uses of subst that don't add "-nobackslashes -nocommands",
but really only use subst to do variable substitution. Also use subst_vars in
those cases.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
This commit is the second to last in the series fully removing support
for stabs in GDB, removing it from XCOFF inferiors. According to IBM's
AIX documentation[1], xcoff binaries can only have stabs or DWARF debug
info, meaning removing stabs seems pretty trivial, as anything that
isn't related to setting base information on the objfile or reading
dwarf can be removed.
The unfortunate part of this removal is that XCOFF minimal symbols are
encoded in stabs, so if an inferior has not been compiled with dwarf
debuginfo, GDB will only be able to do assembly-level debugging. Due to
this, the xcoff reader now emits a warning if no dwarf is read, saying:
"No usable debug information found". This change would also add a lot of
regressions to to AIX, so the gdb_compile proc has been changed to not
work when a test tries to compile a test with nodebug.
As a sidenote, gdb-stabs.h can just be removed from rs6000-aix-nat, as
none of the structs or macros defined in the header are used in the nat
file, so that is an unnecessary include.
This commit introduces some known regressions when testing GDB in AIX
systems. The main ones are:
* inferior function calls now crash with a corrupted stack. This seems
to be some fault of dwarf in explaining how to correctly set the frame
for a function.
* fortran tests can't runto_main: the fortran compiler does not add any
symbol for MAIN__ in the dwarf information, only in stabs, so the
fortran_runto_main proc can't set the breakpoint correctly.
* When dealing with c++ class methods, there are cases when we fail to
properly recognize a method call as a new function.
* When dealing with c++ virtual inheritance, GDB has issues finding a
derived class's members when it has been downcast to a base class.
[1] https://www.ibm.com/docs/en/aix/7.3?topic=formats-xcoff-object-file-format
Approved-By: Tom Tromey <tom@tromey.com>
|
|
I noticed my IDE (VSCode) starting to automatically trim trailing
whitespaces on save, despite the setting for it being disabled. I
realized that this is because the .editorconfig file now has
trim_trailing_whitespace = true
for many file types. If we have this EditorConfig setting forcing
editors to trim trailing whitespaces, I think it would make sense to
clean up trailing whitespaces from our files. Otherwise, people will
always get spurious whitespace changes when editing these files.
I did a mass cleanup using this command:
$ find gdb gdbserver gdbsupport -type f \( \
-name "*.c" -o \
-name "*.h" -o \
-name "*.cc" -o \
-name "*.texi" -o \
-name "*.exp" -o \
-name "*.tcl" -o \
-name "*.py" -o \
-name "*.s" -o \
-name "*.S" -o \
-name "*.asm" -o \
-name "*.awk" -o \
-name "*.ac" -o \
-name "Makefile*" -o \
-name "*.sh" -o \
-name "*.adb" -o \
-name "*.ads" -o \
-name "*.d" -o \
-name "*.go" -o \
-name "*.F90" -o \
-name "*.f90" \
\) -exec sed -ri 's/[ \t]+$//' {} +
I then did an autotools regen, because we don't actually want to change
the Makefile and Makefile.in files that are generated.
Change-Id: I6f91b83e3b8c4dc7d5d51a2ebf60706120efe691
|
|
With test-case gdb.python/py-corefile.exp I run into:
...
PASS: $exp: test mapped files data: show-build-ids
ERROR: tcl error sourcing gdb.python/py-corefile.exp.
ERROR: bad option "0x1fa178": \
must be -nobackslashes, -nocommands, or -novariables
while executing
"subst 0x$offset + 0"
...
Fix this using "[subst 0x$offset]" instead.
Tested on x86_64-linux.
|
|
After commit:
commit f69c1d03c4d6c68ae3f90facd63245426c028047
Date: Mon Aug 25 16:48:22 2025 +0100
gdb/python: add Corefile.mapped_files method
Tom reported a failure:
(gdb) check-build-ids
Python Exception <class 'AssertionError'>: build-id mismatch for /lib64/libc.so.6
Error occurred in Python: build-id mismatch for /lib64/libc.so.6
(gdb) FAIL: gdb.python/py-corefile.exp: test mapped files data: check-build-ids
The discussion thread can be found here:
https://inbox.sourceware.org/gdb-patches/de21b43c-e3bd-4354-aace-bd3f50c1c64c@suse.de
There are a couple of problems.
First, there is an issue where some versions of the linker didn't
place the build-id within the first page of an ELF. As a result, the
Linux kernel would not include the build-id in the generated core
file, and so GDB cannot to find the build-id.
In this patch I've added mitigation for this problem.
I changed the 'check-build-ids' command (added via Python as part of
the test) to 'show-build-ids'. The updated command prints a table
containing the build-ids for each objfile as found via GDB's
Progspace.objfiles, and via the Corefile.mapped_files. This table is
then read by the TCL test script, and the build-ids are checked. If
there's a difference, then GDB can analyse the on disk ELF and work
out if the difference is due to the linker issue mentioned above. If
it is, then the difference is ignored.
In order to check for this linker issue I added a new helper proc to
lib/gdb.exp, expect_build_id_in_core_file.
The second problem with the original test is that it would consider
separate debug files as files that should appear in the core file.
There was Python code in the test that filtered the objfile list to
disregard entries that would not appear in the core file, but this
code needed extending to cover separate debug files.
The final issue is that I'm only aware of GNU/Linux forcing the first
page of every mapped ELF into the generated core files, so this test
would likely fail on non-Linux systems. I've made the part of the
test that relies on this behaviour Linux only.
This change should resolve the FAIL that Tom reported. Giving Tom a
Co-Author credit as he fixed the second issue, and helped a lot
debugging the first issue.
Co-Authored-By: Tom de Vries <tdevries@suse.de>
|
|
Currently the DWARF assembler implements manual parsing for location
expressions. With a recent refactoring, this lead to the use of
[subst] in a number of places.
Following the same logic as the DW_AT_* change, this patch changes
location expressions to simply be nested Tcl code. This avoids the
need for subst and also allows more complex logic, should that ever be
needed.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33402
|
|
This changes the DWARF assembler to store the desired "uplevel" frame
in Dwarf::assemble. This frame is then used in the relevant "uplevel"
invocations in the assembler.
This is primarily useful for the next patch, but it also seems
somewhat cleaner in general to me, as the implementation can now be
refactored without worrying too much about introducing new stack
frames.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
