| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This commit changes gdb/version.in to 14.2.
|
|
If you try to call Frame.static_link for a frame without debug info,
gdb crashes:
```
Temporary breakpoint 1, 0x000000013f821650 in main ()
(gdb) py print(gdb.selected_frame().static_link())
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
```
The problem was a missing check if get_frame_block returns nullptr
inside frame_follow_static_link.
With this, it works:
```
Temporary breakpoint 1, 0x000000013f941650 in main ()
(gdb) py print(gdb.selected_frame().static_link())
None
```
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31366
Approved-By: Tom Tromey <tom@tromey.com>
|
|
On arm-linux the linaro CI occasionally reports:
...
(gdb) up 10
#4 0x0001b864 in pthread_join ()
(gdb) FAIL: gdb.threads/staticthreads.exp: up 10
...
while this is expected:
...
(gdb) up 10
#3 0x00010568 in main (argc=1, argv=0xfffeede4) at staticthreads.c:76
76 pthread_join (thread, NULL);
(gdb) PASS: gdb.threads/staticthreads.exp: up 10
...
Thiago investigated the problem, and using valgrind found an invalid read in
arm_exidx_fill_cache.
The problem happens as follows:
- an objfile and corresponding per_bfd are allocated
- some memory is allocated in arm_exidx_new_objfile using
objfile->objfile_obstack, for the "exception table entry cache".
- a symbol reread is triggered, and the objfile, including the
objfile_obstack, is destroyed
- a new objfile is allocated, using the same per_bfd
- again arm_exidx_new_objfile is called, but since the same per_bfd is used,
it doesn't allocate any new memory for the "exception table entry cache".
- the "exception table entry cache" is accessed by arm_exidx_fill_cache,
and we have a use-after-free.
This is a regression since commit a2726d4ff80 ("[ARM] Store exception handling
information per-bfd instead of per-objfile"), which changed the "exception
table entry cache" from per-objfile to per-bfd, but failed to update the
obstack_alloc.
Fix this by using objfile->per_bfd->storage_obstack instead of
objfile->objfile_obstack.
I couldn't reproduce the FAIL myself, but Thiago confirmed that the patch
fixes it.
Tested on arm-linux.
Approved-By: Luis Machado <luis.machado@arm.com>
PR tdep/31254
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31254
|
|
When a user attempts to use the "list ." command with an inferior that
doesn't have debug symbols, GDB would crash. This was reported as PR
gdb/31256.
The crash would happen when attempting to get the current symtab_and_line
for the stop location, because the symtab would return a null pointer
and we'd attempt to dereference it to print the line.
This commit fixes that by checking for an empty symtab and erroring out
of the function if it happens.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31256
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Since 3c45e9f915ae4aeab7312d6fc55a947859057572 gdb crashes when trying
to print a global variable stub without a running inferior, because of
a missing nullptr-check (the block_scope function took care of that
check before it was converted to a method).
With this check it works again:
```
(gdb) print s
$1 = <incomplete type>
```
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31128
Approved-By: Tom Tromey <tom@tromey.com>
(cherry picked from commit 576745e26c0ec76a53ba45b20af464628a50b3e4)
|
|
I noticed it when I was trying to set a breakpoint at ExitProcess:
```
(gdb) b ExitProcess
Breakpoint 1 at 0x14001fdd0
(gdb) r
Starting program: C:\qiewer\heob\heob64.exe
Warning:
Cannot insert breakpoint 1.
Cannot access memory at address 0x3dbf4120
Cannot insert breakpoint 1.
Cannot access memory at address 0x77644120
```
The problem doesn't exist in gdb 13.2, and the difference can easily be
seen when printing ExitProcess.
gdb 14.1:
```
(gdb) p ExitProcess
$1 = {<text variable, no debug info>} 0x77644120 <UserHandleGrantAccess+36128>
```
gdb 13.2:
```
(gdb) p ExitProcess
$1 = {<text variable, no debug info>} 0x77734120 <ntdll!RtlExitUserProcess>
```
The new behavior started with 9675da25357c7a3f472731ddc6eb3becc65b469a,
where VMA was then calculated relative to FORWARD_DLL_NAME, while it was
relative to DLL_NAME before.
Fixed by calculating VMA relative to DLL_NAME again.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31112
Approved-By: Tom Tromey <tom@tromey.com>
(cherry picked from commit 2574cd903dd84e7081506e24c2e232ecda11a736)
|
|
This commit changes gdb/version.in to 14.1.90.DATE-git.
This commit also makes the following changes in gdb/testsuite:
* gdb.base/default.exp: Change $_gdb_minor to 2.
|
|
This commit changes gdb/version.in to 14.1.
|
|
If a target provides a target description including registers from the
XSAVE extended region, but does not provide an XSAVE layout, use a
fallback XSAVE layout based on the included registers. This fallback
layout matches GDB's behavior in earlier releases which assumes the
layout from Intel CPUs.
This fallback layout is currently only used for remote targets since
native targets which support XSAVE provide an explicit layout derived
from CPUID.
PR gdb/30912
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30912
Approved-By: Simon Marchi <simon.marchi@efficios.com>
(cherry picked from commit 66637e209cc836c19a21a28e91046649c7702037)
|
|
While working on cancellation, I noticed that a DAP 'pause' request
would set the "do not emit the continue" flag. This meant that a
subsequent request that should provoke a 'continue' event would
instead suppress the event.
I then tried writing a more obvious test case for this, involving an
inferior call -- and discovered that gdb.events.cont does not fire for
an inferior call.
This patch installs a new event listener for gdb.events.inferior_call
and arranges for this to emit continue and stop events when
appropriate. It also fixes the original bug, by adding a check to
exec_and_expect_stop.
(cherry picked from commit c618a1c548193d2a6a8c3d909a3d1c620a156b5d)
|
|
Hannes' patch to show local variables in the TUI pointed out that
NoOpStructPrinter should ignore static members. This patch implements
this.
(cherry picked from commit 4a1b9a4badc8954221926b231b81392fa625653c)
|
|
DAP specifies that a request can fail with the "notStopped" message if
the inferior is running but the request requires that it first be
stopped.
This patch implements this for gdb. Most requests are assumed to
require a stopped inferior, and the exceptions are noted by a new
'request' parameter.
You may notice that the implementation is a bit racy. I think this is
inherent -- unless the client waits for a stop event before sending a
request, the request may be processed at any time relative to a stop.
https://sourceware.org/bugzilla/show_bug.cgi?id=31037
Reviewed-by: Kévin Le Gouguec <legouguec@adacore.com>
(cherry picked from commit cfd00e8050a58aacc6489ec0379908be1a12be73)
|
|
ExecutionInvoker is no longer really needed, due to the previous DAP
refactoring. This patch removes it in favor of an ordinary function.
One spot (the 'continue' request) could still have used it, but is
more succinctly expressed as a lambda.
Reviewed-by: Kévin Le Gouguec <legouguec@adacore.com>
(cherry picked from commit 68caad9d0b06d0ac231ce083ff62410a5a1806c1)
|
|
Nearly every DAP request implementation forwards its work to the gdb
thread, using send_gdb_with_response. This patch refactors the
'request' decorator to make this automatic, and to provide some
parameters so that the unusual requests can express their needs as
well.
In a few spots this simplifies the code by removing an unnecessary
helper function. This could be done in more places as well if we
wanted.
The main motivation for this patch is that I thought it would be
helpful for cancellation. I am still working on that, but meanwhile
the parameterization of 'request' makes it easy to handle the
'notStopped' response as well.
Reviewed-by: Kévin Le Gouguec <legouguec@adacore.com>
(cherry picked from commit c98921b258b55272c5b4066d96441e4e07626eb2)
|
|
DAP specifies a StackFrameFormat object that can be used to change how
the "name" part of a stack frame is constructed. While this output
can already be done in a nicer way (and also letting the client choose
the formatting), nevertheless it is in the spec, so I figured I'd
implement it.
While implementing this, I discovered that the current code does not
correctly preserve frame IDs across requests. I rewrote frame
iteration to preserve this, and it turned out to be simpler to combine
these patches.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30475
(cherry picked from commit 1920148904fe5ca0035c1addf2376f9ab13ffd3d)
|
|
This changes ada-nested.exp to fix a test name (the test expects three
variables but is named "two"), and to iterate over all the variables
that are found. It also adds a workaround to a problem Tom de Vries
found with an older version of GNAT -- it emits a duplicate "x".
(cherry picked from commit e1ccbfffb5e0121c084898ac63f042187621d4ec)
|
|
Kévin found a bug in an earlier version of this series that was based
on a misconception I had about Symbol.is_variable. This patch fixes
the documentation to explain the method a bit better.
Approved-By: Eli Zaretskii <eliz@gnu.org>
(cherry picked from commit 5006ea556dad71c4c868cf5705e007e72e3b02b4)
|
|
A co-worker requested that the DAP scope for a nested function's frame
also show the variables from outer frames. DAP doesn't directly
support this notion, so this patch arranges to put these variables
into the inner frames "Locals" scope.
I chose to do this only for DAP. For CLI and MI, gdb currently does
not do this, so this preserves the behavior.
Note that an earlier patch (see commit 4a1311ba) removed some code
that seemed to do something similar. However, that code did not
actually work.
(cherry picked from commit ebea770b19c09489fe5e2cb5c1fd568f0f21e17e)
|
|
While working on static links, I noticed that the DAP scopes code does
not handle the scenario where a frame decorator returns None. This
situation should be handled identically to a frame decorator returning
an empty iterator.
(cherry picked from commit e9dacb1d6caa5770d3e1722adc0ec74ff13a7a89)
|
|
This adds a new gdb.Frame.static_link method to the gdb Python layer.
This can be used to find the static link frame for a given frame.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
(cherry picked from commit 4ead09a294adbb718d642874a554e78d931c2830)
|
|
This moves the follow_static_link function to frame.c and exports it
for use elsewhere. The API is changed slightly to make it more
generically useful.
(cherry picked from commit 19b83d5c9bac1db207dce26859c6ca84135615b0)
|
|
This adds the method block::function_block, to easily access a block's
enclosing function block.
(cherry picked from commit ba707cadae18a7cc8bb47a736d3d0438d44262a9)
|
|
This adds a couple of convenience methods, block::is_static_block and
block::is_global_block.
(cherry picked from commit edf1b9640bbc981c8a094d6ca29d444b1ed50a2c)
|
|
This patch implements the DAP setVariable request.
setVariable is a bit odd in that it specifies the variable to modify
by passing in the variable's container and the name of the variable.
This approach can't handle variable shadowing (there are a couple of
open DAP bugs on this topic), so this patch renames duplicates to
avoid the problem.
(cherry picked from commit 87e3cc466e8ea352639beb6db40a36e339d608d1)
|
|
GCC doesn't complain, but it's still wrong.
|
|
A pretty-printer's 'children' method may return values other than a
gdb.Value -- it may return any value that can be converted to a
gdb.Value.
I noticed that this case did not work for DAP. This patch fixes the
problem.
|
|
Andry pointed out that the DAP code did not properly handle
gdb.LazyString results from a pretty-printer, yielding:
TypeError: Object of type LazyString is not JSON serializable
This patch fixes the problem, partly with a small patch in varref.py,
but mainly by implementing tp_str for LazyString.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
|
|
Andry noticed that given a DAP setExpression request, where the
expression to set is a register, DAP will return the wrong value -- it
will return the old value, not the updated one.
This happens because gdb.Value.assign (which was recently added for
DAP) does not update the value.
In this patch, I chose to have the assign method update the Value
in-place. It's also possible to have it return a new value, but this
didn't seem very useful to me.
|
|
Andry Ogorodnik, a co-worker, noticed that multiple "scopes" requests
with the same frame would yield different variableReference values in
the response.
This patch adds a regression test for this, and adds a scope cache in
scopes.py, ensuring that multiple identical requests will get the same
response.
Tested-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
|
|
Since commit 1e5ccb9c5ff4fd8ade4a8694676f99f4abf2d679, we have an assertion in
displaced_step_buffers::copy_insn_closure_by_addr that makes sure a closure
is available whenever we have a match between the provided address argument and
the buffer address.
That is fine, but the report in PR30872 shows this assertion triggering when
it really shouldn't. After some investigation, here's what I found out.
The 32-bit Arm architecture is the only one that calls
gdbarch_displaced_step_copy_insn_closure_by_addr directly, and that's because
32-bit Arm needs to figure out the thumb state of the original instruction
that we displaced-stepped through the displaced-step buffer.
Before the assertion was put in place by commit
1e5ccb9c5ff4fd8ade4a8694676f99f4abf2d679, there was the possibility of
getting nullptr back, which meant we were not doing a displaced-stepping
operation.
Now, with the assertion in place, this is running into issues.
It looks like displaced_step_buffers::copy_insn_closure_by_addr is
being used to return a couple different answers depending on the
state we're in:
1 - If we are actively displaced-stepping, then copy_insn_closure_by_addr
is supposed to return a valid closure for us, so we can determine the
thumb mode.
2 - If we are not actively displaced-stepping, then copy_insn_closure_by_addr
should return nullptr to signal that there isn't any displaced-step buffers
in use, because we don't have a valid closure (but we should always have
this).
Since the displaced-step buffers are always allocated, but not always used,
that means the buffers will always contain data. In particular, the buffer
addr field cannot be used to determine if the buffer is active or not.
For instance, we cannot set the buffer addr field to 0x0, as that can be a
valid PC in some cases.
My understanding is that the current_thread field should be a good candidate
to signal that a particular displaced-step buffer is active or not. If it is
nullptr, we have no threads using that buffer to displaced-step. Otherwise,
it is an active buffer in use by a particular thread.
The following fix modifies the displaced_step_buffers::copy_insn_closure_by_addr
function so we only attempt to return a closure if the buffer has an assigned
current_thread and if the buffer address matches the address argument.
Alternatively, I think we could use a function to answer the question of
whether we're actively displaced-stepping (so we have an active buffer) or
not.
I've also added a testcase that exercises the problem. It should reproduce
reliably on Arm, as that is the only architecture that faces this problem
at the moment.
Regression-tested on Ubuntu 20.04. OK?
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30872
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
__SVE_VQ_BYTES is only available if SVE definitions are available in
the system's headers, and this is not true for all systems.
For this purpose, we define SVE_VQ_BYTES. This patch fixes the
name of the constant being used.
|
|
A user pointed out that the -lsocket check in gdb should also apply to
gdbserver -- otherwise it can't find the Solaris socketpair. This
patch makes the change. It also removes a couple of redundant
function checks from gdb's configure.ac.
This was tested by the person who reported the bug.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30927
Approved-By: Pedro Alves <pedro@palves.net>
|
|
This commit changes gdb/version.in to 14.0.91.DATE-git.
|
|
This commit changes gdb/version.in to 14.0.91.
|
|
This commit updates the NEWS files for the upcoming GDB 14 release.
|
|
Now that the GDB 14 branch has been created,
this commit bumps the version number in gdb/version.in to
14.0.90.DATE-git
For the record, the GDB 14 branch was created
from commit 8f12a1a841cd0c447de7a5a0f134a0efece73588.
|
|
On x86_64-linux, with test-case gdb.arch/i386-signal.exp I run into:
...
builtin_spawn -ignore SIGHUP gcc -fno-stack-protector i386-signal.c \
-fdiagnostics-color=never -fno-pie -g -no-pie -lm -o i386-signal^M
/tmp/cc2xydTG.s: Assembler messages:^M
/tmp/cc2xydTG.s:50: Error: operand size mismatch for `push'^M
compiler exited with status 1
output is:
/tmp/cc2xydTG.s: Assembler messages:^M
/tmp/cc2xydTG.s:50: Error: operand size mismatch for `push'^M
gdb compile failed, /tmp/cc2xydTG.s: Assembler messages:
/tmp/cc2xydTG.s:50: Error: operand size mismatch for `push'
UNTESTED: gdb.arch/i386-signal.exp: failed to compile
...
This is with gas 2.41, it compiles without problems with gas 2.40. Some more
strict checking was added in commit 5cc007751cd ("x86: further adjust
extend-to-32bit-address conditions"). This may or may not be a gas regression
( https://sourceware.org/pipermail/binutils/2023-October/129818.html ).
The offending bit is:
...
" push $sigframe\n"
...
which refers to a function:
...
" .globl sigframe\n"
"sigframe:\n"
...
The test-case passes with target board unix/-m32.
Make the test-case work by using pushq instead of push for the
is_amd64_regs_target case.
Tested on x86_64-linux, with target boards:
- unix/-m64 (is_amd64_regs_target == 1), and
- unix/-m32 (is_amd64_regs_target == 0),
PR testsuite/30928
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30928
|
|
Linux kernel commit commit 317c8194e6ae ("rseq: Introduce feature size
and alignment ELF auxiliary vector entries") introduced two new auxvs:
AT_RSEQ_FEATURE_SIZE and AT_RSEQ_ALIGN. Support them in GDB. This
fixes auxv.exp on kernels >= v6.3.
Change-Id: I8966c4d5c73eb7b45de6d410a9b28a6628edad2e
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30540
Approved-By: Tom Tromey <tom@tromey.com>
|
|
I'm seeing a lot of variability in the failures of
gdb.threads/process-dies-while-detaching.exp on aarch64-linux. On this
platform, a problem yet to be investigated causes GDB to miss the _exit
breakpoint. What happens next is random because after missing that
breakpoint, GDB is out of sync with the inferior. This causes the tests
following that point in the testcase to fail in a random way.
In this scenario it's better to exit the testcase early to avoid random
results in the testsuite.
We are relying on gdb_continue_to_breakpoint to return the result of
gdb_test_multiple. This is already the case because in Tcl the return
value of a function is the return value of the last command it runs. But
change gdb_continue_to_breakpoint to explicitly return this value, to make
it clear this is the intended behaviour.
Tested on aarch64-linux.
Tested-By: Guinevere Larsen <blarsen@redhat.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
I spotted two entries in the NEWS file that I believe are in the wrong
place, these are:
- An entry about MI v1 being deprecated, this feels like it should
be the first entry under the 'MI changes' heading, and
- An entry for the $_shell convenience function which is currently
under the 'New commands' heading (sort of), when I think this
should be listed in the general news section.
|
|
The last few commits resolved the KFAILs in gdb.base/args.exp. With
those out of the way we can clean up this test script a little.
In this commit I have:
- Stopped passing 'nowarnings' flag when building the source file.
I see no reason why this source should issue a warning,
- Moved setup of GDBFLAGS into args_test proc, callers that passed a
newline needed a small tweak, and also the matching code needs
updating for newline handling, but I think this is nicer, the
argument lists are now given just once,
- Updated comment on args_test,
- Updated other comments.
There should be no change in what is tested after this commit.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Similarly to how single quotes were mishandled, which was fixed two
commits ago, this commit fixes handling of newlines in arguments
passed to gdbserver.
We already had a test that covered this, gdb.base/args.exp, which,
when run with the native-extended-gdbserver board contained several
KFAIL covering this situation.
In this commit I remove the unnecessary, attempt to quote incoming
newlines within arguments, and do some minimal cleanup of the related
code. There is additional cleanup that can be done, but I'm leaving
that for the next commit.
Then I've removed the KFAIL from the test case, and performed some
minimal cleanup there too.
After this commit the gdb.base/args.exp is 100% passing with the
native-extended-gdbserver board file.
During review I was pointed to this older series:
https://inbox.sourceware.org/gdb-patches/20211022071933.3478427-1-m.weghorn@posteo.de/
which also includes this fix as part of a larger set of changes. I'm
giving a Co-Authored-By credit to the author of that original series.
I believe this smaller fix brings some benefits on its own, though the
original series does offer additional improvements. Once this is
merged I'll take a look at rebasing and resubmitting the original series.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27989
Co-Authored-By: Michael Weghorn <m.weghorn@posteo.de>
Approved-By: Tom Tromey <tom@tromey.com>
|
|
When I posted the previous patch for review Andreas Schwab pointed out
that passing a trailing empty argument also doesn't work.
The fix for this is in the same area of code as the previous patch,
but is sufficiently different that I felt it deserved a patch of its
own.
I noticed that passing arguments containing single quotes to gdbserver
didn't work correctly:
gdb -ex 'set sysroot' --args /tmp/show-args
Reading symbols from /tmp/show-args...
(gdb) target extended-remote | gdbserver --once --multi - /tmp/show-args
Remote debugging using | gdbserver --once --multi - /tmp/show-args
stdin/stdout redirected
Process /tmp/show-args created; pid = 176054
Remote debugging using stdio
Reading symbols from /lib64/ld-linux-x86-64.so.2...
(No debugging symbols found in /lib64/ld-linux-x86-64.so.2)
0x00007ffff7fd3110 in _start () from /lib64/ld-linux-x86-64.so.2
(gdb) set args abc ""
(gdb) run
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /tmp/show-args \'
stdin/stdout redirected
Process /tmp/show-args created; pid = 176088
2 args are:
/tmp/show-args
abc
Done.
[Inferior 1 (process 176088) exited normally]
(gdb) target native
Done. Use the "run" command to start a process.
(gdb) run
Starting program: /tmp/show-args \'
2 args are:
/tmp/show-args
abc
Done.
[Inferior 1 (process 176095) exited normally]
(gdb) q
The 'shows-args' program used here just prints the arguments passed to
the inferior.
Notice that when starting the inferior using the extended-remote
target there is only a single argument 'abc', while when using the
native target there is a second argument, the blank line, representing
the empty argument.
The problem here is that the vRun packet coming from GDB looks like
this (I've removing the trailing checksum):
$vRun;PROGRAM_NAME;616263;
If we compare this to a packet with only a single argument and no
trailing empty argument:
$vRun;PROGRAM_NAME;616263
Notice the lack of the trailing ';' character here.
The problem is that gdbserver processes this string in a loop. At
each point we maintain a pointer to the character just after a ';',
and then we process everything up to either the next ';' character, or
to the end of the string.
We break out of this loop when the character we start with (in that
loop iteration) is the null-character. This means in the trailing
empty argument case, we abort the loop before doing anything with the
empty argument.
In this commit I've updated the loop, we now break out using a 'break'
statement at the end of the loop if the (sub-)string we just processed
was empty, with this change we now notice the trailing empty
argument.
I've updated the test case to cover this issue.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
I noticed that passing arguments containing single quotes to gdbserver
didn't work correctly:
gdb -ex 'set sysroot' --args /tmp/show-args
Reading symbols from /tmp/show-args...
(gdb) target extended-remote | gdbserver --once --multi - /tmp/show-args
Remote debugging using | gdbserver --once --multi - /tmp/show-args
stdin/stdout redirected
Process /tmp/show-args created; pid = 176054
Remote debugging using stdio
Reading symbols from /lib64/ld-linux-x86-64.so.2...
(No debugging symbols found in /lib64/ld-linux-x86-64.so.2)
0x00007ffff7fd3110 in _start () from /lib64/ld-linux-x86-64.so.2
(gdb) set args \'
(gdb) r
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /tmp/show-args \'
stdin/stdout redirected
Process /tmp/show-args created; pid = 176088
2 args are:
/tmp/show-args
\'
Done.
[Inferior 1 (process 176088) exited normally]
(gdb) target native
Done. Use the "run" command to start a process.
(gdb) run
Starting program: /tmp/show-args \'
2 args are:
/tmp/show-args
'
Done.
[Inferior 1 (process 176095) exited normally]
(gdb) q
The 'shows-args' program used here just prints the arguments passed to
the inferior.
Notice that when starting the inferior using the extended-remote
target the second argument is "\'", while when running using native
target the argument is "'". The second of these is correct, the \'
used with the "set args" command is just to show GDB that the single
quote is not opening an argument string.
It turns out that the extra backslash is injected on the gdbserver
side when gdbserver processes the arguments that GDB passes it, the
code that does this was added as part of this much larger commit:
commit 2090129c36c7e582943b7d300968d19b46160d84
Date: Thu Dec 22 21:11:11 2016 -0500
Share fork_inferior et al with gdbserver
In this commit I propose removing the specific code that adds what I
believe is a stray backslash. I've extended an existing test to cover
this case, and I now see identical behaviour when using an
extended-remote target as with the native target.
This partially fixes PR gdb/27989, though there are still some issues
with newline handling which I'll address in a later commit.
During review I was pointed to this older series:
https://inbox.sourceware.org/gdb-patches/20211022071933.3478427-1-m.weghorn@posteo.de/
which also includes this fix as part of a larger set of changes. I'm
giving a Co-Authored-By credit to the author of that original series.
I believe this smaller fix brings some benefits on its own, though the
original series does offer additional improvements. Once this is
merged I'll take a look at rebasing and resubmitting the original series.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27989
Co-Authored-By: Michael Weghorn <m.weghorn@posteo.de>
Approved-By: Tom Tromey <tom@tromey.com>
|
|
If you want to install GDB in a custom prefix, have it look for debug info
in that prefix but also in the distro's default location (typically,
/usr/lib/debug) and run the GDB testsuite before doing "make install", you
have a bit of a problem:
Configuring GDB with '--prefix=$PREFIX' sets the GDB 'debug-file-directory'
parameter to $PREFIX/lib/debug. Unfortunately this precludes GDB from
looking for distro-installed debug info in /usr/lib/debug. For regular GDB
use you could set debug-file-directory to $PREFIX:/usr/lib/debug in
$PREFIX/etc/gdbinit so that GDB will look in both places, but if you want
to run the testsuite then that doesn't help because in that case GDB runs
with the '-nx' option.
There's the configure option '--with-separate-debug-dir' to set the default
value for 'debug-file-directory', but it accepts only one directory and not
a list. I considered modifying it to accept a list, but it's not obvious
how to do that because its value is also used by BFD, as well as processed
for "relocatability".
I thought it was simpler to add a new option to specify a list of
additional directories that will be appended to the debug-file-directory
setting.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Tom Tromey <tom@tromey.com>
|
|
With gcc-10 we have:
...
(gdb) break package2.Foo^M
Breakpoint 2 at 0x402563: file package2.go, line 5.^M
(gdb) PASS: gdb.go/package.exp: setting breakpoint 1
...
but with gcc-11:
...
gdb) break package2.Foo^M
Function "package2.Foo" not defined.^M
Make breakpoint pending on future shared library load? (y or [n]) n^M
(gdb) FAIL: gdb.go/package.exp: gdb_breakpoint: set breakpoint at package2.Foo
...
In the gcc-10 case, though the exec contains dwarf, it's not used to set the
breakpoint (which is an independent problem, filed as PR go/30941), instead
the minimal symbol information is used.
The minimal symbol information changed between gcc-10 and gcc-11:
...
$ nm a.out.10 | grep Foo
000000000040370d T go.package2.Foo
0000000000404e50 R go.package2.Foo..f
$ nm a.out.11 | grep Foo
0000000000403857 T go_0package2.Foo
0000000000405030 R go_0package2.Foo..f
...
A new v3 mangling scheme was used. The mangling schemes define a separator
character and mangling character:
- for v2, dot is used both as separator character and mangling character, and
- for v3, dot is used as separator character and underscore as mangling
character.
For more details, see [1] and [2].
In v3, "_0" demangles to ".". [ See gcc commit a01dda3c23b ("compiler, libgo:
change mangling scheme"), function Special_char_code::Special_char_code. ]
Handle the new go_0 prefix in unpack_mangled_go_symbol, which fixes the
test-case.
Note that this doesn't fix this regression:
...
$ gccgo-10 package2.go -c -g0
$ gccgo-10 package1.go package2.o -g0
$ gdb -q -batch a.out -ex "break go.package2.Foo"
Breakpoint 1 at 0x40370d
$ gccgo-11 package2.go -c -g0
$ gccgo-11 package1.go package2.o -g0
$ gdb -q -batch a.out -ex "break go.package2.Foo"
Function "go.package2.Foo" not defined.
...
With gcc-10, we set a breakpoint on the mangled minimal symbol. That
one has simply changed for gcc-11, so it's equivalent to using:
...
$ gdb -q -batch a.out -ex "break go_0package2.Foo"
Breakpoint 1 at 0x403857
...
which does work.
Tested on x86_64-linux:
- openSUSE Leap 15.4, using gccgo-7,
- openSUSE Tumbleweed, using gccgo-13.
PR go/27238
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27238
[1] https://go-review.googlesource.com/c/gofrontend/+/271726
[2] https://github.com/golang/go/issues/41862#issuecomment-707244103
|
|
Use objfile->pspace instead of current_program_space.
Change-Id: I127a1788e155b321563114452ed5b530f1d1f618
Approved-By: Tom Tromey <tom@tromey.com>
|
|
The free_objfile observable is never called with a nullptr objfile.
Change-Id: I1e990edeb45bc38009ccb129c623911097ab65fe
Approved-By: Tom Tromey <tom@tromey.com>
|
|
The new_objfile observer is currently used to indicate both when a new
objfile is added to program space (when passed non-nullptr) and when all
objfiles of a program space were just removed (when passed nullptr).
I think this is confusing (and Andrew apparently thinks so too [1]).
Add a new "all_objfiles_removed" observer to remove the second role from
"new_objfile".
Some existing users of new_objfile do nothing if the passed objfile is
nullptr. For them, we can simply drop the nullptr check. For others,
add a new all_objfiles_removed callback, and refactor things a bit to
keep the existing behavior as much as possible.
Some callbacks relied on current_program_space, and following
the refactoring now use either objfile->pspace or the pspace passed to
all_objfiles_removed. I think this should be relatively safe, and in
general a step in the right direction.
On the notify side, I found only one call site to change from
new_objfile to all_objfiles_removed, in clear_symtab_users. It is not
entirely clear to me that this is entirely correct. clear_symtab_users
appears to be called in spots that don't remove all objfiles
(functions finish_new_objfile, remove_symbol_file_command, reread_symbols,
do_module_cleanups). But I think that this patch at least makes the
current code clearer.
[1] https://gitlab.com/gnutools/binutils-gdb/-/commit/a0a031bce0527b1521788b5dad640e7883b3a252
Change-Id: Icb648f72862e056267f30f44dd439bd4ec766f13
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Make the current_program_space references bubble up a bit.
Change-Id: Id047a48cc8d8a45504cdbb5960bafe3e7735d652
Approved-By: Tom Tromey <tom@tromey.com>
|
