This adds a "-5" flag to cc-with-tweaks, mirroring dwz's "-5" flag,
and also adds a new cc-with-dwz-5 target board.
The "-5" flag tells dwz to use the DWARF 5 .debug_sup section in
multi-file mode.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32808
DWARF 5 standardized the .gnu_debugaltlink section that dwz emits in
multi-file mode. This is handled via some new forms, and a new
.debug_sup section.
This patch adds support for this to gdb. It is largely
straightforward, I think, though one oddity is that I chose not to
have this code search the system build-id directories for the
supplementary file. My feeling was that, while it makes sense for a
distro to unify the build-id concept with the hash stored in the
.debug_sup section, there's no intrinsic need to do so.
This in turn means that a few tests -- for example those that test the
index cache -- will not work in this mode.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32808
Acked-By: Simon Marchi <simon.marchi@efficios.com>
dwz_file::read_string calls 'read' on the section, but this isn't
needed as the sections have all been pre-read.
This patch makes this change, and refactors dwz_file a bit to make
this more obvious -- by making it clear that only the "static
constructor" can create a dwz_file.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Tested-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
There was a comment in gdb.python/py-color.exp that was probably left
over from a copy & paste, it incorrectly described what the test
script was testing.
Fixed in this commit.
There's no change in what is tested with this commit.
A few minor GNU/GDB coding style issues in py-color.c:
- Space after '&' reference operator in one place.
- Some excessive indentation on a couple of lines.
- Spaces after '!' logical negation operator.
- Using a pointer as a bool in a couple of places.
There should be no functional changes after this commit.
In this review:
https://inbox.sourceware.org/gdb-patches/86sem6ase5.fsf@gnu.org
it was pointed out that I should use @samp{} around some text I was
adding to the documentation. However, the offending snippet of
documentation was something I copied from elsewhere in python.texi.
This commit fixes the original to use @samp{}.
I noticed that this commit:
commit 6447969d0a
Date: Sat Oct 5 22:27:44 2024 +0300
Add an option with a color type.
has an unnecessary `Py_INCREF (self);` in gdb.Color.__init__. This
means that the reference count on all gdb.Color objects (that pass
through __init__) will be +1 from where they should normally be, and
this will stop the gdb.Color objects from being deallocated.
Fix by removing the Py_INCREF call.
Add a test which exposes the memory leak.
Approved-By: Tom Tromey <tom@tromey.com>
We currently have two memory leak tests in gdb.python/ and there's a
lot of duplication between these two.
In the next commit I'd like to add yet another memory leak test, which
would mean a third set of scripts which duplicate the existing two.
And three is where I draw the line.
This commit factors out the core of the memory leak tests into a new
module gdb_leak_detector.py, which can then be imported by each
tests's Python file in order to make writing the memory leak tests
easier.
I've also added a helper function to lib/gdb-python.exp which captures
some of the common steps needed in the TCL file in order to run a
memory leak test.
Finally, I use this new infrastructure to rewrite the two existing
memory leak tests.
What I considered, but ultimately didn't do, is merge the two memory
leak tests into a single TCL script. I did consider this, and for the
existing tests this would be possible, but future tests might require
different enough setup that this might not be possible for all future
tests, and now that we have helper functions in a central location,
the each individual test is actually pretty small now, so leaving them
separate seemed OK.
There should be no change in what is actually being tested after this
commit.
Approved-By: Tom Tromey <tom@tromey.com>
This fixes a crash on Windows NT 4.0, where windows-nat failed dynamic loading
some Win32 functions and print a warning message with styled string, which
depends on ui-style regex. By using `compiled_regex` constructor, the regex is
guaranteed to be initialized before `_initialize_xxx` functions.
Approved-By: Tom Tromey <tom@tromey.com>
On Intel, gprofng should adjusts return addresses, including user leaf functions.
gprofng/ChangeLog
2025-04-18 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
* src/CallStack.cc (add_stack): Adjust return addresses on Intel.
For linux target, when trying to run a program from gdb, the
following defect is seen:
Program received signal SIGILL, Illegal instruction.
0x48004674 in _dl_debug_state () from target:/lib/ld.so.1
* microblaze-linux-tdep.c (microblaze_linux_memory_remove_breakpoint):
Call make_scoped_restore_show_memory_breakpoints
Signed-off-by: Gopi Kumar Bulusu <gopi@sankhya.com>
Signed-off-by: Michael J. Eager <eager@eagercon.com>
Seen on x86_64-linux Ubuntu 24.04.2 using gcc-13.3.0 with
CFLAGS="-m32 -g -O2 -fsanitize=address,undefined"
In function ‘sprintf’,
inlined from ‘s_mri_for’ at gas/config/tc-m68k.c:6941:5:
/usr/include/bits/stdio2.h:30:10: error: null destination pointer [-Werror=format-overflow=]
30 | return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
31 | __glibc_objsize (__s), __fmt,
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
32 | __va_arg_pack ());
| ~~~~~~~~~~~~~~~~~
Rewrite the code without sprintf, as in other parts of s_mri_for.
See also commit 760fb390fd and following commits.
Note that adding -D_FORTIFY_SOURCE=0 to CFLAGS (which is a good idea
when building with sanitizers) merely transforms the sprintf_chk error
here into one regarding plain sprintf.
Tidy early out errors which didn't free matching_vector. Don't
bfd_preserve_restore if we get to err_ret from the first
bfd_preserve_save, which might fail from a memory allocation leaving
preserve.marker NULL. Also take bfd_lock a little earlier before
modifying abfd->format to simplify error return path from a lock
failure.
These are only used by cutu_reader, so make them methods of cutu_reader.
This makes it a bit more obvious in which context this code is called.
lookup_dwo_unit_in_dwp can't be made a method of cutu_reader, as it is
used in another context (lookup_dwp_signatured_type /
lookup_signatured_type), which happens during CU expansion.
Change-Id: Ic62c3119dd6ec198411768323aaf640ed165f51b
Approved-By: Tom Tromey <tom@tromey.com>
get_dwp_file lazily looks for a .dwp file for the given objfile. It is
called by indexing workers, when a cutu_reader object looks for a DWO
file. It is called with the "dwo_lock" held, meaning that the first
worker to get there will do the work, while the others will wait at the
lock.
I'm trying to reduce the time where this lock is taken and do other
refactorings to make it easier to reason about the DWARF reader code.
Moving the lookup of the .dwp file ahead, before we start parallelizing
work, helps makes things simpler, because we can then assume everywhere
else that we have already checked for a .dwp file.
Put the call to open_and_init_dwp_file in dwarf2_has_info, right next to
where we look up .dwz files. I used the same try-catch pattern as for
the .dwz file lookup.
Change-Id: I615da85f62a66d752607f0dbe9f0372dfa04b86b
Approved-By: Tom Tromey <tom@tromey.com>
Following a previous patch, these functions can accept a per_bfd
instead of a per_objfile.
Change-Id: Iacc8924d2e49a05920d9a7fde2f7584f709fbdd2
Approved-By: Tom Tromey <tom@tromey.com>
Instead of passing a boolean to create_dwp_hash_table to select the
section to read, it's simpler to just pass the section.
Change-Id: Ie043c31e80518239f6403288dcf03f7769c58e8c
Approved-By: Tom Tromey <tom@tromey.com>
The sections would have been read already in
dwarf2_locate_common_dwp_sections or dwarf2_locate_dwo_sections, with
this call:
dw_sect->read (objfile);
Change-Id: Ice0ed5d9a2070967826a59b2d6f724451ace22f4
Approved-By: Tom Tromey <tom@tromey.com>
The comment over dwarf2_section_info::get_size says:
In other cases, you must call this function, because for compressed
sections the size field is not set correctly until the section has
been read
From what I can see (while debugging a test case compiled with -gz on
Linux), that's not true. For compressed sections, bfd_section_size
returns the uncompressed size. asection::size contains the uncompressed
size while asection::compressed_size contains the compressed size:
(top-gdb) p sec
$13 = (asection *) 0x521000119778
(top-gdb) p sec.compressed_size
$14 = 6191
(top-gdb) p sec.size
$15 = 12116
I therefore propose to remove dwarf2_section_info::get_size, as it
appears that reading in the section is orthogonal to knowing its size.
If the assumption above is false, it would be nice to document in which
case it's false.
I checked the callers, and I don't think that we need to add any
dwarf2_section_info::read calls to compensate for the fact that get_size
used to do it.
Change-Id: I428571e532301d49f1d8242d687e1fcb819b75c1
Approved-By: Tom Tromey <tom@tromey.com>
I noticed a few spots in ada-varobj.c that refer to calling xfree,
where the type in question has changed to std::string. This patch
removes these obsolete comments.
The test added in commit 4fe96ddaf6 results in an asan complaint:
loongarch-parse.y:225:16: runtime error: left shift of negative value -1
To avoid the complaint, perform left shifts as unsigned (which gives
the same result on 2's complement machines). Do the same for
addition, subtraction and multiplication. Furthermore, warn on
divide/modulus by zero.
After building gdb with -fsanitize=threads, and running test-case
gdb.cp/cplusfuncs.exp, I run into a single timeout:
...
FAIL: gdb.cp/cplusfuncs.exp: info function operator=( (timeout)
...
and the test-case takes 2m33s to finish.
This is due to expanding CUs from libstdc++.
After de-installing package libstdc++6-debuginfo, the timeout disappears and
testing time goes down to 9 seconds.
Fix this by not running to main, which brings testing time down to 3 seconds.
With a gdb built without -fsanitize=threads, testing time goes down from 11
seconds to less than 1 second.
Tested on x86_64-linux.
Reviewed-By: Keith Seitz <keiths@redhat.com>
value_struct_elt_bitpos is weird: it takes an in/out value parameter,
and it takes an error string parameter. However, it only has a single
caller, which never uses the "out" value.
I think it was done this way to mimic value_struct_elt. However,
value_struct_elt is pretty ugly and I don't think it's worth
imitating.
This patch cleans up value_struct_elt_bitpos a bit.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Fixes [1]. Previously iteration over GNU properties of an input file
could stop before reaching GNU_PROPERTY_AARCH64_FEATURE_1_AND which
would result in incorrect inference of properties of the output file.
In the particular use case described in [1], the memory seal property
GNU_PROPERTY_MEMORY_SEAL with number 3, if present in the input file,
prevented reading information from GNU_PROPERTY_AARCH64_FEATURE_1_AND
property due to filtering by property number.
[1] PR32818 https://sourceware.org/bugzilla/show_bug.cgi?id=32818
With test-case gdb.threads/clone-attach-detach.exp I usually get:
...
(gdb) attach <pid> &^M
Attaching to program: clone-attach-detach, process <pid>^M
[New LWP <lwp>]^M
(gdb) PASS: $exp: bg attach <n>: attach
[Thread debugging using libthread_db enabled]^M
Using host libthread_db library "/lib64/libthread_db.so.1".^M
...
but sometimes I run into:
...
(gdb) attach <pid> &^M
Attaching to program: clone-attach-detach, process <pid>^M
[New LWP <lwp>]^M
(gdb) [Thread debugging using libthread_db enabled]^M
Using host libthread_db library "/lib64/libthread_db.so.1".^M
FAIL: $exp: bg attach <n>: attach (timeout)
...
I managed to reproduce this using make target check-readmore and
READMORE_SLEEP=100.
Fix this using -no-prompt-anchor.
Tested on x86_64-linux.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
gdb/copyright.py currently changes some files that it shouldn't:
- despite having a `gnulib/import` entry in EXCLUDE_LIST, it does
change the files under that directory
- it is missing `sim/Makefile.in`
Change the exclude list logic to use glob patterns. This makes it
easier to specify exclusions of full directories or files by basename,
while simplifying the code.
Merge EXCLUDE_LIST and NOT_FSF_LIST, since there's no fundamental reason
to keep them separate (they are treated identically). I kept the
comment that explains that some files are excluded due to not being
FSF-licensed.
Merge EXCLUDE_ALL_LIST in EXCLUDE_LIST, converting the entries to glob
patterns that match everywhere in the tree (e.g. `**/configure`).
Tested by running the script on the parent commit of d01e823438
("Update copyright dates to include 2025") and diff'ing the result with
d01e823438. The only differences are:
- the files that we don't want to modify (gnulib/import and
sim/Makefile.in)
- the files that need to be modified by hand
Running the script on latest master produces no diff.
Change-Id: I318dc3bff34e4b3a9b66ea305d0c3872f69cd072
Reviewed-By: Guinevere Larsen <guinevere@redhat.com>
Add `pyright: strict` at the top of the file, then adjust the fallouts.
This annotation is understood by pyright, and thus any IDE using pyright
behind the scenes (VSCode and probably others).
I presume that any GDB developer running this script is using a recent
enough version of Python, so specify the type annotations using the
actual types when possible (e.g. `list[str]` instead of
`typing.List[str]`). I believe this required Python 3.9.
Change-Id: I3698e28555e236a03126d4cd010dae4b5647ce48
Reviewed-By: Guinevere Larsen <guinevere@redhat.com>
With test-case gdb.base/bg-execution-repeat.exp, occasionally I run into a
timeout:
...
(gdb) c 1&
Will stop next time breakpoint 1 is reached. Continuing.
(gdb) PASS: $exp: c 1&: c 1&
Breakpoint 2, foo () at bg-execution-repeat.c:23
23 return 0; /* set break here */
PASS: $exp: c 1&: breakpoint hit 1
Will stop next time breakpoint 2 is reached. Continuing.
(gdb) PASS: $exp: c 1&: repeat bg command
print 1
$1 = 1
(gdb) PASS: $exp: c 1&: input still accepted
interrupt
(gdb) PASS: $exp: c 1&: interrupt
Program received signal SIGINT, Interrupt.
foo () at bg-execution-repeat.c:24
24 }
PASS: $exp: c 1&: interrupt received
set var do_wait=0
(gdb) PASS: $exp: c 1&: set var do_wait=0
continue&
Continuing.
(gdb) PASS: $exp: c 1&: continue&
FAIL: $exp: c 1&: breakpoint hit 2 (timeout)
...
I can reproduce it reliably by adding a "sleep (1)" before the "do_wait = 1"
in the .c file.
The timeout happens as follows:
- with the inferior stopped at main, gdb continues (command c 1&)
- the inferior hits the breakpoint at foo
- gdb continues (using the repeat command functionality)
- the inferior is interrupted
- inferior variable do_wait gets set to 0. The assumption here is that the
inferior has progressed enough that do_wait is set to 1 at that point, but
that happens not to be the case. Consequently, this has no effect.
- gdb continues
- the inferior sets do_wait to 1
- the inferior enters the wait function, and wait for do_wait to become 0,
which never happens.
Fix this by moving the "do_wait = 1" to before the first call to foo.
Tested on x86_64-linux.
Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
