| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
... to sim/ppc/powerpc.igen
This file is in the NOT_FSF_LIST because this file has a copyright
which is not assigned to the FSF. Since the file got renamed,
the corresponding entry in NOT_FSF_LIST needs to be renamed as well.
|
|
This commit updates the copyright year displayed by gdb, gdbserver
and gdbreplay's help message from 2022 to 2023, as per our Start
of New Year procedure. The corresponding source files' copyright
header are also updated accordingly.
|
|
There's a command "disable probes", but SystemTap probes, for instance
libc:longjmp cannot be disabled:
...
$ gdb -q -batch a.out -ex start -ex "disable probes libc ^longjmp$"
...
Probe libc:longjmp cannot be disabled.
Probe libc:longjmp cannot be disabled.
Probe libc:longjmp cannot be disabled.
...
Add a command "maintenance ignore-probes" that ignores probes during
get_probes, such that we can easily pretend to use a libc without the
libc:longjmp probe:
...
(gdb) maint ignore-probes -verbose libc ^longjmp$
ignore-probes filter has been set to:
PROVIDER: 'libc'
PROBE_NAME: '^longjmp$'
OBJNAME: ''
(gdb) start ^M
...
Ignoring SystemTap probe libc longjmp in /lib64/libc.so.6.^M
Ignoring SystemTap probe libc longjmp in /lib64/libc.so.6.^M
Ignoring SystemTap probe libc longjmp in /lib64/libc.so.6.^M
...
The "Ignoring ..." messages can be suppressed by not using -verbose.
Note that as with "disable probes", running simply "maint ignore-probes"
ignores all probes.
The ignore-probes filter can be reset by using:
...
(gdb) maint ignore-probes -reset
ignore-probes filter has been reset
...
For now, the command is only supported for SystemTap probes.
PR cli/27159
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27159
|
|
[ Partial resubmission of an earlier submission by Andrew (
https://sourceware.org/pipermail/gdb-patches/2012-September/096347.html ), so
listing him as co-author. ]
With x86_64-linux and target board unix/-m32, we have:
...
(gdb) continue^M
Continuing.^M
Exception #10^M
^M
Breakpoint 3, throw_exception_1 (e=10) at py-finish-breakpoint2.cc:23^M
23 throw new int (e);^M
(gdb) FAIL: gdb.python/py-finish-breakpoint2.exp: \
check FinishBreakpoint in catch()
...
The following scenario happens:
- set breakpoint in throw_exception_1, a function that throws an exception
- continue
- hit breakpoint, with call stack main.c:38 -> throw_exception_1
- set a finish breakpoint
- continue
- hit the breakpoint again, with call stack main.c:48 -> throw_exception
-> throw_exception_1
Due to the exception, the function call did not properly terminate, and the
finish breakpoint didn't trigger. This is expected behaviour.
However, the intention is that gdb detects this situation at the next stop
and calls the out_of_scope callback, which would result here in this test-case
in a rather confusing "exception did not finish" message. So the problem is
that this message doesn't show up, in other words, the out_of_scope callback
is not called.
[ Note that the fact that the situation is detected only at the next stop
(wherever that happens to be) could be improved upon, and the earlier
submission did that by setting a longjmp breakpoint. But I'm considering this
problem out-of-scope for this patch. ]
Note that the message does show up later, at thread exit:
...
[Inferior 1 (process 20046) exited with code 0236]^M
exception did not finish ...^M
...
The decision on whether to call the out_of_scope call back is taken in
bpfinishpy_detect_out_scope_cb, and the interesting bit is here:
...
if (b->pspace == current_inferior ()->pspace
&& (!target_has_registers ()
|| frame_find_by_id (b->frame_id) == NULL))
bpfinishpy_out_of_scope (finish_bp);
...
In the case of the thread exit, the callback triggers because
target_has_registers () == 0.
So why doesn't the callback trigger in the case of the breakpoint?
Well, the b->frame_id is the frame_id of the frame of main (the frame
in which the finish breakpoint is supposed to trigger), so AFAIU
frame_find_by_id (b->frame_id) == NULL will only be true once we've
left main, at which point I guess we don't stop till thread exit.
Fix this by saving the frame in which the finish breakpoint was created, and
using frame_find_by_id () == NULL on that frame instead, such that we have:
...
(gdb) continue^M
Continuing.^M
Exception #10^M
^M
Breakpoint 3, throw_exception_1 (e=10) at py-finish-breakpoint2.cc:23^M
23 throw new int (e);^M
exception did not finish ...^M
(gdb) FAIL: gdb.python/py-finish-breakpoint2.exp: \
check FinishBreakpoint in catch()
...
Still, the test-case is failing because it's setup to match the behaviour that
we get on x86_64-linux with target board unix/-m64:
...
(gdb) continue^M
Continuing.^M
Exception #10^M
stopped at ExceptionFinishBreakpoint^M
(gdb) PASS: gdb.python/py-finish-breakpoint2.exp: \
check FinishBreakpoint in catch()
...
So what happens here? Again, due to the exception, the function call did not
properly terminate, but the finish breakpoint still triggers. This is somewhat
unexpected. This happens because it just so happens to be that the frame
return address at which the breakpoint is set, is also the first instruction
after the exception has been handled. This is a know problem, filed as
PR29909, so KFAIL it, and modify the test-case to expect the out_of_scope
callback.
Also add a breakpoint after setting the finish breakpoint but before throwing
the exception, to check that we don't call the out_of_scope callback too early.
Tested on x86_64-linux, with target boards unix/-m32.
Co-Authored-By: Andrew Burgess <aburgess@redhat.com>
PR python/27247
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27247
|
|
On ubuntu 22.04.1 x86_64, I run into:
...
(gdb) PASS: gdb.base/print-symbol-loading.exp: shlib off: \
set print symbol-loading off
sharedlibrary .*^M
Symbols already loaded for /lib/x86_64-linux-gnu/libc.so.6^M
Symbols already loaded for /lib/x86_64-linux-gnu/libpthread.so.0^M
(gdb) FAIL: gdb.base/print-symbol-loading.exp: shlib off: load shared-lib
...
The test-case expects the libc.so line, but not the libpthread.so line.
However, we have:
...
$ ldd /lib/x86_64-linux-gnu/libc.so.6
linux-vdso.so.1 (0x00007ffd7f7e7000)
libgtk3-nocsd.so.0 => /lib/x86_64-linux-gnu/libgtk3-nocsd.so.0 (0x00007f4468c00000)
/lib64/ld-linux-x86-64.so.2 (0x00007f4469193000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f4468f3e000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f4468f39000)
...
so it's not unexpected that libpthread.so is loaded if libc.so is loaded.
Fix this by accepting the libpthread.so line.
Tested on x86_64-linux.
PR testsuite/29919
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29919
|
|
gdb.threads/watchpoint-fork.exp
On Ubuntu 22.04.1 x86_64, with glibc 2.35 I run into:
...
watchpoint-fork-mt.c: In function 'start':^M
watchpoint-fork-mt.c:67:7: warning: 'pthread_yield' is deprecated: \
pthread_yield is deprecated, use sched_yield instead \
[-Wdeprecated-declarations]^M
67 | i = pthread_yield ();^M
| ^^M
...
Fix this as suggested, by using sched_yield instead.
Tested on x86_64-linux.
|
|
On Ubuntu 22.04.1 x86_64 (with glibc 2.35), I run into:
...
(gdb) PASS: gdb.base/corefile.exp: $_exitcode is void
bt^M
#0 __pthread_kill_implementation (...) at ./nptl/pthread_kill.c:44^M
#1 __pthread_kill_internal (...) at ./nptl/pthread_kill.c:78^M
#2 __GI___pthread_kill (...) at ./nptl/pthread_kill.c:89^M
#3 0x00007f4985e1a476 in __GI_raise (...) at ../sysdeps/posix/raise.c:26^M
#4 0x00007f4985e007f3 in __GI_abort () at ./stdlib/abort.c:79^M
#5 0x0000556b4ea4b504 in func2 () at gdb.base/coremaker.c:153^M
#6 0x0000556b4ea4b516 in func1 () at gdb.base/coremaker.c:159^M
#7 0x0000556b4ea4b578 in main (...) at gdb.base/coremaker.c:171^M
(gdb) PASS: gdb.base/corefile.exp: backtrace
up^M
#1 __pthread_kill_internal (...) at ./nptl/pthread_kill.c:78^M
78 in ./nptl/pthread_kill.c^M
(gdb) FAIL: gdb.base/corefile.exp: up
...
The problem is that the regexp used here:
...
gdb_test "up" "#\[0-9\]* *\[0-9xa-fH'\]* in .* \\(.*\\).*" "up"
...
does not fit the __pthread_kill_internal line which lacks the instruction
address due to inlining.
Fix this by making the regexp less strict.
Tested on x86_64-linux.
|
|
On ubuntu 22.04.1 x86_64, I run into:
...
(gdb) info probes all rtld rtld_map_complete^M
No probes matched.^M
(gdb) XFAIL: gdb.threads/dlopen-libpthread.exp: info probes all rtld rtld_map_complete
UNTESTED: gdb.threads/dlopen-libpthread.exp: no matching probes
...
This has been filed as PR testsuite/17016.
The problem is that the name rtld_map_complete is used, which was only
available in Fedora 17, and upstream the name map_complete was used.
In the email thread discussing a proposed patch (
https://sourceware.org/legacy-ml/gdb-patches/2014-09/msg00712.html ) it was
suggested to make the test-case handle both names.
So, handle both names: map_complete and rtld_map_complete.
This exposes the following FAIL:
...
(gdb) info sharedlibrary^M
From To Syms Read Shared Object Library^M
$hex $hex Yes /lib64/ld-linux-x86-64.so.2^M
$hex $hex Yes (*) /lib/x86_64-linux-gnu/libgtk3-nocsd.so.0^M
$hex $hex Yes /lib/x86_64-linux-gnu/libc.so.6^M
$hex $hex Yes /lib/x86_64-linux-gnu/libdl.so.2^M
$hex $hex Yes /lib/x86_64-linux-gnu/libpthread.so.0^M
(*): Shared library is missing debugging information.^M
(gdb) FAIL: gdb.threads/dlopen-libpthread.exp: libpthread.so not found
...
due to using a glibc (v2.35) that has libpthread integrated into libc.
Fix this by changing the FAIL into UNSUPPORTED.
Tested on x86_64-linux.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17016
|
|
-fcf-protection
On Ubuntu 22.04.1 x86_64, I run into:
...
gdb.reverse/step-indirect-call-thunk.c: In function 'inc':^M
gdb.reverse/step-indirect-call-thunk.c:22:1: error: '-mindirect-branch' and \
'-fcf-protection' are not compatible^M
22 | { /* inc.1 */^M
| ^^M
...
Fix this by forcing -fcf-protection=none, if supported.
Tested on x86_64-linux.
|
|
On Ubuntu 22.04.1 x86_64, I run into:
...
(gdb) PASS: gdb.cp/step-and-next-inline.exp: no_header: not in inline 1
next^M
51 if (t != NULL^M
(gdb) FAIL: gdb.cp/step-and-next-inline.exp: no_header: next step 1
...
This is due to -fcf-protection, which adds the endbr64 at the start of get_alias_set:
...
0000000000001180 <_Z13get_alias_setP4tree>:
1180: f3 0f 1e fa endbr64
1184: 48 85 ff test %rdi,%rdi
...
so the extra insn gets an is-stmt line number entry:
...
INDEX LINE ADDRESS IS-STMT PROLOGUE-END
...
11 50 0x0000000000001180 Y
12 50 0x0000000000001180
13 51 0x0000000000001184 Y
14 54 0x0000000000001184
...
and when stepping into get_alias_set we step to line 50:
...
(gdb) PASS: gdb.cp/step-and-next-inline.exp: no_header: in main
step^M
get_alias_set (t=t@entry=0x555555558018 <xx>) at step-and-next-inline.cc:50^M
50 {^M
...
In contrast, with -fcf-protection=none, we get:
...
0000000000001170 <_Z13get_alias_setP4tree>:
1170: 48 85 ff test %rdi,%rdi
...
and:
...
INDEX LINE ADDRESS IS-STMT PROLOGUE-END
...
11 50 0x0000000000001170 Y
12 51 0x0000000000001170 Y
13 54 0x0000000000001170
...
so when stepping into get_alias_set we step to line 51:
...
(gdb) PASS: gdb.cp/step-and-next-inline.exp: no_header: in main
step^M
get_alias_set (t=t@entry=0x555555558018 <xx>) at step-and-next-inline.cc:51^M
51 if (t != NULL^M
...
Fix this by rewriting the gdb_test issuing the step command to check which
line the step lands on, and issuing an extra next if needed.
Tested on x86_64-linux, both with and without -fcf-protection=none.
PR testsuite/29920
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29920
|
|
Make comp_unit_head.length private, to enforce using accessor functions.
Replace accessor function get_length with get_length_with_initial and
get_length_without_initial, to make it explicit which variant we're using.
Tested on x86_64-linux.
PR symtab/29343
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29343
|
|
This patch fixes a review comment by Tom de Vries. He pointed out
that the new timestamp.exp should use the $decimal convenience regexp.
|
|
PR cli/29945 points out that "set debug timestamp 1" stopped working
-- this is a regression due to commit b8043d27 ("Remove a ui-related
memory leak").
This patch fixes the bug and adds a regression test.
I think this should probably be backported to the gdb 13 branch.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29945
|
|
The gdb.gdb self-tests were timing out for me, which turned out to be
PR testsuite/29325. Looking into it, the problem is that the version
of the Boehm GC that is used by Guile on my machine causes a SEGV
during stack probing. This unexpected stop confuses the tests and
causes repeated timeouts.
This patch adapts the two failing tests. This makes them work for me,
and reduces the running time of gdb.gdb from 20 minutes to about 11
seconds.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29325
|
|
PR symtab/29343 points out that it would be beneficial if
comp_unit_head had a constructor and used initializers. This patch
implements this. I'm unsure if this is sufficient to close the bug,
but at least it's a step.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29343
|
|
In commit:
commit 9f50fe0835850645bd8ea9bb1efe1fe6c48dfb12
Date: Wed Dec 7 15:55:25 2022 +0000
gdb/testsuite: new test for recent dwarf reader issue
A new test (gdb.base/signed-builtin-types.exp) was added that made use
of 'info sources' to figure out if the debug information for a
particular object file had been fully expanded or not. Unfortunately
some lines of the 'info sources' output can be very long, this was
observed on some systems where the debug information for the
dynamic-linker was installed, in this case, the list of source files
associated with the dynamic linker was so long it would cause expect's
internal buffer to overflow.
This commit switches from using 'info sources' to 'maint print
objfile', the output from the latter command is more compact, but
also, can be restricted to a single named object file.
With this change in place I am no longer seeing buffer overflow errors
from expect when running gdb.base/signed-builtin-types.exp.
|
|
This changes dwarf2_has_info to return bool.
|
|
I see this fail since commit 991180627851 ("Use toplevel configure for
GMP and MPFR for gdb"):
FAIL: gdb.base/float128.exp: show configuration
The test fails to find --with-mpfr or --without-mpfr in the "show
configuration" output. Since MPFR has become mandatory, we can just
remove that check and simplify the test to assume MPFR support is there.
Change-Id: I4f3458470db0029705b390dfefed3a66dfc0633a
Approved-By: Tom de Vries <tdevries@suse.de>
|
|
This allows to build GDB even though the default value of
_WIN32_WINNT is lower than the one needed to expose some
new APIs used here, and leave the test for their actual
support to run time.
* gdb/nat/windows-nat.c (EXTENDED_STARTUPINFO_PRESENT): Define if
not defined.
(create_process_wrapper): Use 'gdb_lpproc_thread_attribute_list'
instead of 'PPROC_THREAD_ATTRIBUTE_LIST' (which might not be defined
at compile time). This fixes compilation error using mingw.org's
MinGW.
|
|
When I moved my last patch forward, somehow I missed removing
the #endif for the HAVE_LIBMPFR case.
Committed as obvious after a quick build.
gdb/ChangeLog:
* top.c: Remove the extra #endif which was missed.
|
|
This patch uses the toplevel configure parts for GMP/MPFR for
gdb. The only thing is that gdb now requires MPFR for building.
Before it was a recommended but not required library.
Also this allows building of GMP and MPFR with the toplevel
directory just like how it is done for GCC.
We now error out in the toplevel configure of the version
of GMP and MPFR that is wrong.
OK after GDB 13 branches? Build gdb 3 ways:
with GMP and MPFR in the toplevel (static library used at that point for both)
With only MPFR in the toplevel (GMP distro library used and MPFR built from source)
With neither GMP and MPFR in the toplevel (distro libraries used)
Changes from v1:
* Updated gdb/README and gdb/doc/gdb.texinfo.
* Regenerated using unmodified autoconf-2.69
Thanks,
Andrew Pinski
ChangeLog:
* Makefile.def: Add configure-gdb dependencies
on all-gmp and all-mpfr.
* configure.ac: Split out MPC checking from MPFR.
Require GMP and MPFR if the gdb directory exist.
* Makefile.in: Regenerate.
* configure: Regenerate.
gdb/ChangeLog:
PR bug/28500
* configure.ac: Remove AC_LIB_HAVE_LINKFLAGS
for gmp and mpfr.
Use GMPLIBS and GMPINC which is provided by the
toplevel configure.
* Makefile.in (LIBGMP, LIBMPFR): Remove.
(GMPLIBS, GMPINC): Add definition.
(INTERNAL_CFLAGS_BASE): Add GMPINC.
(CLIBS): Exchange LIBMPFR and LIBGMP
for GMPLIBS.
* target-float.c: Make the code conditional on
HAVE_LIBMPFR unconditional.
* top.c: Remove code checking HAVE_LIBMPFR.
* configure: Regenerate.
* config.in: Regenerate.
* README: Update GMP/MPFR section of the config
options.
* doc/gdb.texinfo: Likewise.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28500
|
|
When asking GDB to print a variable from an imported namespace, we only
want to see variables imported in lines that the inferior has already
gone through, as is being tested last in gdb.cp/nsusing.exp. However
with the proposed change to gdb.cp/nsusing.exp, we get the following
failures:
(gdb) PASS: gdb.cp/nsusing.exp: continue to breakpoint: marker10 stop
print x
$9 = 911
(gdb) FAIL: gdb.cp/nsusing.exp: print x, before using statement
next
15 y += x;
(gdb) PASS: gdb.cp/nsusing.exp: using namespace M
print x
$10 = 911
(gdb) PASS: gdb.cp/nsusing.exp: print x, only using M
Showing that the feature wasn't functioning properly, it just so
happened that gcc ordered the namespaces in a convenient way.
This happens because GDB doesn't take into account the line where the
"using namespace" directive is written. So long as it shows up in the
current scope, we assume it is valid.
To fix this, add a new member to struct using_direct, that stores the
line where the directive was written, and a new function that informs if
the using directive is valid already.
Unfortunately, due to a GCC bug, the failure still shows up. Compilers
that set the declaration line of the using directive correctly (such as
Clang) do not show such a bug, so the test includes an XFAIL for gcc
code.
Finally, because the final test of gdb.cp/nsusing.exp has turned into
multiple that all would need XFAILs for older GCCs (<= 4.3), and that
GCC is very old, if it is detected, the test just exits early.
Approved-by: Tom Tromey <tom@tromey.com>
|
|
These headers define the register numbers for each port to implement
the sim_fetch_register & sim_store_register interfaces. While gdb
uses these, the APIs are part of the sim, not gdb. Move the headers
out of the gdb/ include namespace and into sim/ instead.
|
|
The libtool patch broke install-strip of gdb:
/bin/sh ../../gdb/../mkinstalldirs /src/gdb/inst/share/gdb/python/gdb
transformed_name=`t='s,y,y,'; \
echo gdb | sed -e "$t"` ; \
if test "x$transformed_name" = x; then \
transformed_name=gdb ; \
else \
true ; \
fi ; \
/bin/sh ../../gdb/../mkinstalldirs /src/gdb/inst/bin ; \
/bin/sh ./libtool --mode=install STRIPPROG='strip' /bin/sh /src/gdb/gdb.git/install-sh -c -s \
gdb \
/src/gdb/inst/bin/$transformed_name ; \
/bin/sh ../../gdb/../mkinstalldirs /src/gdb/inst/include/gdb ; \
/usr/bin/install -c -m 644 jit-reader.h /src/gdb/inst/include/gdb/jit-reader.h
libtool: install: `/src/gdb/inst/bin/gdb' is not a directory
libtool: install: Try `libtool --help --mode=install' for more information.
Since INSTALL_PROGRAM_ENV is no longer at the beginning of the command, the
gdb executable is not installed with install-strip.
|
|
This changes bpstat to use 'bool' rather than 'char', and updates the
uses.
|
|
This changes the uses of value_print_options to use 'true' and 'false'
rather than integers.
|
|
quick_symbol_functions::relocated is only needed for psymtabs, and
there it is only needed for Rust. However, because we've switched the
DWARF reader away from psymtabs, this means there's no longer a need
for this method at all.
|
|
MI version 1 is long since obsolete. Several years ago, I filed
PR mi/23170 for this. I think it's finally time to remove this.
Any users of MI 1 can and should upgrade to a newer version.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=23170
|
|
I found a few vestiges of MI version 0 in the test suite. This patch
removes them.
|
|
Commit b5661ff2 ("gdb: fix possible use-after-free when
executing commands") used lookup_cmd_exact () to lookup
command again after its execution to avoid possible
use-after-free error.
However this change broke test gdb.base/define.exp which
defines a post-hook for subcommand ("target testsuite").
In this case, lookup_cmd_exact () returned NULL because
there's no command 'testsuite' in top-level commands.
This commit fixes this case by looking up the command again
using the original command line via lookup_cmd ().
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This commit a new section for the next release branch, and renames
the section of the current branch, now that it has been cut.
|
|
Now that the GDB 13 branch has been created,
this commit bumps the version number in gdb/version.in to
14.0.50.DATE-git
For the record, the GDB 13 branch was created
from commit 71c90666e601c511a5f495827ca9ba545e4cb463.
Also, as a result of the version bump, the following changes
have been made in gdb/testsuite:
* gdb.base/default.exp: Change $_gdb_major to 14.
|
|
As of 1bcb0708f229 ("gdb/linux-nat: Check whether /proc/pid/mem is
writable"), GDB checks if /proc/pid/mem is writable. This is done
early at GDB startup, in order to get a consistent warning, instead of
a warning that depends on whenever GDB writes to inferior memory.
PR gdb/29907 points out that some build systems (like QEMU's,
apparently) may call 'gdb --version' to check GDB's presence & its
version on the system, and that Gentoo's build process has sandboxing
which blocks the /proc/pid/mem access and thus GDB warns, which
results in build fails.
To help with that, this patch delays the /proc/pid/mem check until we
start or attach to an inferior. Ends up potentially emiting a warning
close where we already emit other ptrace- and /proc- related warnings,
which just Feels Right.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29907
Change-Id: I5537653ecfbbe76a04ab035e40e59d09b4980763
|
|
Once in a while I run into:
...
FAIL: gdb.threads/detach-step-over.exp: \
breakpoint-condition-evaluation=host: target-non-stop=off: non-stop=off: \
displaced=off: iter 1: all threads running
...
In can easily reproduce this by doing:
...
# Wait a bit, to give time for the threads to hit the
# breakpoint.
- sleep 1
return true
...
Fix this by counting the running threads in a loop, effectively allowing 10
seconds (instead of 1) for the threads to start running, but only sleeping if
needed.
Reduces total execution time from 1m27s to 56s.
Tested on x86_64-linux.
|
|
When the source program contains a goto label, it turns out it's
actually pretty hard for a user to find out more about that label.
For example:
(gdb) p some_label
No symbol "some_label" in current context.
(gdb) disassemble some_label
No symbol "some_label" in current context.
(gdb) x/10i some_label
No symbol "some_label" in current context.
(gdb) break some_label
Breakpoint 2 at 0x401135: file /tmp/py-label-symbol-value.c, line 35.
In all cases, some_label is a goto label within the current frame.
Only placing a breakpoint on the label worked.
This all seems a little strange to me, it feels like asking about a
goto label would not be an unreasonable thing for a user to do.
This commit doesn't fix any of the above issues, I mention them just
to provide a little context for why the following issue has probably
not been seen before.
It turns out there is one way a user can access the symbol for a goto
label, through the Python API:
python frame = gdb.selected_frame()
python frame_pc = frame.pc()
python block = gdb.current_progspace().block_for_pc(frame_pc)
python symbol,_ = gdb.lookup_symbol('some_label', block, gdb.SYMBOL_LABEL_DOMAIN)
python print(str(symbol.value()))
../../src/gdb/findvar.c:204: internal-error: store_typed_address: Assertion `type->is_pointer_or_reference ()' failed.
The problem is that label symbols are created using the
builtin_core_addr type, which is a pure integer type.
When GDB tries to fetch the value of a label symbol then we end up in
findvar.c, in the function language_defn::read_var_value, in the
LOC_LABEL case. From here store_typed_address is called to store the
address of the label into a value object with builtin_core_addr type.
The problem is that store_typed_address requires that the destination
type be a pointer or reference, which the builtin_core_addr type is
not.
Now it's not clear what type a goto label address should have, but
GCC has an extension that allows users to take the address of a goto
label (using &&), in that case the result is of type 'void *'.
I propose that when we convert the CORE_ADDR value to a GDB value
object, we use builtin_func_ptr type instead of builtin_core_addr,
this means the result will be of type 'void (*) ()'. The benefit of
this approach is that when gdbarch_address_to_pointer is called the
target type will be correctly identified as a pointer to code, which
should mean any architecture specific adjustments are done correctly.
We can then cast the new value to 'void *' type with a call to
value_cast_pointer, this should not change the values bit
representation, but will just update the type.
After this asking for the value of a label symbol works just fine:
(gdb) python print(str(symbol.value()))
0x401135 <main+35>
And the type is maybe what we'd expect:
(gdb) python print(str(symbol.value().type))
void *
|
|
Replace the use of struct buffer in linux-osdata.c with std::string.
There is no change in the logic, so there should be no user-visible
change.
Change-Id: I27f53165d401650bbd0bebe8ed88221e25545b3f
Approved-By: Pedro Alves <pedro@palves.net>
|
|
This commit:
commit 53cf95c3389a3ecd97276d322e4a60fe3396a201
Date: Wed Dec 14 14:17:44 2022 +0000
gdb: make more use of make_target_connection_string
Introduced a couple of inefficient uses of std::string, both of which
are fixed in this commit.
There should be no user visible changes after this commit.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This commit adds a test that creates a Python command that redefines
itself during its execution. This is to test use-after-free in
execute_command ().
This test needs run with ASan enabled in order to fail when it
should.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
PR gdb/28947
The address_significant gdbarch setting was introduced as a way to remove
non-address bits from pointers, and it is specified by a constant. This
constant represents the number of address bits in a pointer.
Right now AArch64 is the only architecture that uses it, and 56 was a
correct option so far.
But if we are using Pointer Authentication (PAuth), we might use up to 2 bytes
from the address space to store the required information. We could also have
cases where we're using both PAuth and MTE.
We could adjust the constant to 48 to cover those cases, but this doesn't
cover the case where GDB needs to sign-extend kernel addresses after removal
of the non-address bits.
This has worked so far because bit 55 is used to select between kernel-space
and user-space addresses. But trying to clear a range of bits crossing the
bit 55 boundary requires the hook to be smarter.
The following patch renames the gdbarch hook from significant_addr_bit to
remove_non_address_bits and passes a pointer as opposed to the number of
bits. The hook is now responsible for removing the required non-address bits
and sign-extending the address if needed.
While at it, make GDB and GDBServer share some more code for aarch64 and add a
new arch-specific testcase gdb.arch/aarch64-non-address-bits.exp.
Bug-url: https://sourceware.org/bugzilla/show_bug.cgi?id=28947
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
The passed in string can't be nullptr, it makes more sense to pass in a
reference.
Change-Id: Idc8bd38abe1d6d9b44aa227d7856956848c233b3
|
|
[I sent this earlier today, but I don't see it in the archives.
Resending it through a different computer / SMTP.]
The use of the static buffer in command_line_input is becoming
problematic, as explained here [1]. In short, with this patch [2] that
attempt to fix a post-hook bug, when running gdb.base/commands.exp, we
hit a case where we read a "define" command line from a script file
using command_command_line_input. The command line is stored in
command_line_input's static buffer. Inside the define command's
execution, we read the lines inside the define using command_line_input,
which overwrites the define command, in command_line_input's static
buffer. After the execution of the define command, execute_command does
a command look up to see if a post-hook is registered. For that, it
uses a now stale pointer that used to point to the define command, in
the static buffer, causing a use-after-free. Note that the pointer in
execute_command points to the dynamically-allocated buffer help by the
static buffer in command_line_input, not to the static object itself,
hence why we see a use-after-free.
Fix that by removing the static buffer. I initially changed
command_line_input and other related functions to return an std::string,
which is the obvious but naive solution. The thing is that some callees
don't need to return an allocated string, so this this an unnecessary
pessimization. I changed it to passing in a reference to an std::string
buffer, which the callee can use if it needs to return
dynamically-allocated content. It fills the buffer and returns a
pointers to the C string inside. The callees that don't need to return
dynamically-allocated content simply don't use it.
So, it started with modifying command_line_input as described above, all
the other changes derive directly from that.
One slightly shady thing is in handle_line_of_input, where we now pass a
pointer to an std::string's internal buffer to readline's history_value
function, which takes a `char *`. I'm pretty sure that this function
does not modify the input string, because I was able to change it (with
enough massaging) to take a `const char *`.
A subtle change is that we now clear a UI's line buffer using a
SCOPE_EXIT in command_line_handler, after executing the command.
This was previously done by this line in handle_line_of_input:
/* We have a complete command line now. Prepare for the next
command, but leave ownership of memory to the buffer . */
cmd_line_buffer->used_size = 0;
I think the new way is clearer.
[1] https://inbox.sourceware.org/gdb-patches/becb8438-81ef-8ad8-cc42-fcbfaea8cddd@simark.ca/
[2] https://inbox.sourceware.org/gdb-patches/20221213112241.621889-1-jan.vrany@labware.com/
Change-Id: I8fc89b1c69870c7fc7ad9c1705724bd493596300
Reviewed-By: Tom Tromey <tom@tromey.com>
|
|
Don't delete the runtime-generated command files. This makes it easier
to reproduce tests by hand.
Change-Id: I4e53484eea216512f1c5d7dfcb5c464b36950946
Approved-By: Tom Tromey <tom@tromey.com>
|
|
It seems to me that streq and compare_cstrings belong near the other
string utility functions in common-utils.h; and furthermore that streq
ought to be inlined. This patch makes this change.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
I stumbled across subset_compare today, and after looking at the
callers I realized it could be removed and replaced with calls to
startswith.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
Spotted a couple of places in findvar.c where we use:
if ( ! CONDITION )
internal_error ("...");
this commit changes these to be:
gdb_assert ( CONDITION );
which I think is better.
Unless we happen to hit the internal_error calls (which was bad) there
should be no user visible changes after this commit.
|
|
Some obvious int to bool conversion in remote-sim.c, there should be
no user visible changes after this commit.
|
|
I noticed that we have a function make_target_connection_string which
wraps all the logic for creating a string that describes a target
connection - but in some places we are not calling this function,
instead we duplicate the function's logic.
This commit cleans this up, and calls make_target_connection_string
where possible.
There should be no user visible changes after this commit.
|
|
Some obvious int to bool conversion in tracefile.c.
Should be no user visible changes after this commit.
|
|
With gcc 4.8.5, I run into:
...
Running gdb.base/condbreak-multi-context.exp ...
gdb compile failed, condbreak-multi-context.cc:21:11: warning: non-static \
data member initializers only available with -std=c++11 or -std=gnu++11 \
[enabled by default]
int b = 20;
^
...
Fix this by making it a static const.
Tested on x86_64-linux, with gcc 4.8.5, 7.5.0 and clang 13.0.1.
|
|
Each program space can have an associated core file. Include this
information in the output of 'maint info program-spaces'.
|
