| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
The decref_target function is not really needed. Calling
target_ops::decref will just redirect to decref_target anyway, so why
not just rename decref_target to target_ops::decref?
That's what this commit does.
It's not exactly renaming to target_ops::decref, because the decref
functionality is handled by a policy class, so the new name is now
target_ops_ref_policy::decref.
There should be no user visible change after this commit.
|
|
This commit changes the target_stack class from using a C style array
of 'target_ops *' to using a C++ std::array<target_ops_ref, ...>. The
benefit of this change is that some of the reference counting of
target_ops objects is now done automatically.
This commit fixes a crash in gdb.python/py-inferior.exp where GDB
crashes at exit, leaving a core file behind.
The crash occurs in connpy_connection_dealloc, and is actually
triggered by this assert:
gdb_assert (conn_obj->target == nullptr);
Now a little aside...
... the assert is never actually printed, instead GDB crashes due
to calling a pure virtual function. The backtrace at the point of
crash looks like this:
#7 0x00007fef7e2cf747 in std::terminate() () from /lib64/libstdc++.so.6
#8 0x00007fef7e2d0515 in __cxa_pure_virtual () from /lib64/libstdc++.so.6
#9 0x0000000000de334d in target_stack::find_beneath (this=0x4934d78, t=0x2bda270 <the_dummy_target>) at ../../s>
#10 0x0000000000df4380 in inferior::find_target_beneath (this=0x4934b50, t=0x2bda270 <the_dummy_target>) at ../.>
#11 0x0000000000de2381 in target_ops::beneath (this=0x2bda270 <the_dummy_target>) at ../../src/gdb/target.c:3047
#12 0x0000000000de68aa in target_ops::supports_terminal_ours (this=0x2bda270 <the_dummy_target>) at ../../src/gd>
#13 0x0000000000dde6b9 in target_supports_terminal_ours () at ../../src/gdb/target.c:1112
#14 0x0000000000ee55f1 in internal_vproblem(internal_problem *, const char *, int, const char *, typedef __va_li>
Notice in frame #12 we called target_ops::supports_terminal_ours,
however, this is the_dummy_target, which is of type dummy_target,
and so we should have called dummy_target::supports_terminal_ours.
I believe the reason we ended up in the wrong implementation of
supports_terminal_ours (which is a virtual function) is because we
made the call during GDB's shut-down, and, I suspect, the vtables
were in a weird state.
Anyway, the point of this patch is not to fix GDB's ability to
print an assert during exit, but to address the root cause of the
assert. With that aside out of the way, we can return to the main
story...
Connections are represented in Python with gdb.TargetConnection
objects (or its sub-classes). The assert in question confirms that
when a gdb.TargetConnection is deallocated, the underlying GDB
connection has itself been removed from GDB. If this is not true then
we risk creating multiple different gdb.TargetConnection objects for
the same connection, which would be bad.
To ensure that we have one gdb.TargetConnection object for each
connection, the all_connection_objects map exists, this maps the
process_stratum_target object (the connection) to the
gdb.TargetConnection object that represents the connection.
When a connection is removed in GDB the connection_removed observer
fires, which we catch with connpy_connection_removed, this function
then sets conn_obj->target to nullptr, and removes the corresponding
entry from the all_connection_objects map.
The first issue here is that connpy_connection_dealloc is being called
as part of GDB's exit code, which is run after the Python interpreter
has been shut down. The connpy_connection_dealloc function is used to
deallocate the gdb.TargetConnection Python object. Surely it is
wrong for us to be deallocating Python objects after the interpreter
has been shut down.
The reason why connpy_connection_dealloc is called during GDB's exit
is that the global all_connection_objects map is still holding a
reference to the gdb.TargetConnection object. When the map is
destroyed during GDB's exit, the gdb.TargetConnection objects within
the map can finally be deallocated.
The reason why all_connection_objects has contents when GDB exits, and
the reason the assert fires, is that, when GDB exits, there are still
some connections that have not yet been removed from GDB, that is,
they have a non-zero reference count.
If we take a look at quit_force (top.c) you can see that, for each
inferior, we call pop_all_targets before we (later in the function)
call do_final_cleanups. It is the do_final_cleanups call that is
responsible for shutting down the Python interpreter. The
pop_all_targets calls should, in theory, cause all the connections to
be removed from GDB.
That this isn't working indicates that some targets have a non-zero
reference count even after this final pop_all_targets call, and
indeed, when I debug GDB, that is what I see.
I tracked the problem down to delete_inferior where we do some house
keeping, and then delete the inferior object, which calls
inferior::~inferior.
In neither delete_inferior or inferior::~inferior do we call
pop_all_targets, and it is this missing call that means we leak some
references to the target_ops objects on the inferior's target_stack.
In this commit I will provide a partial fix for the problem. I say
partial fix, but this will actually be enough to resolve the crash.
In a later commit I will provide the final part of the fix.
As mentioned at the start of the commit message, this commit changes
the m_stack in target_stack to hold target_ops_ref objects. This
means that when inferior::~inferior is called, and m_stack is
released, we automatically decrement the target_ops reference count.
With this change in place we no longer leak any references, and now,
in quit_force the final pop_all_targets calls will release the final
references. This means that the targets will be correctly closed at
this point, which means the connections will be removed from GDB and
the Python objects deallocated before the Python interpreter shuts
down.
There's a slight oddity in target_stack::unpush, where we std::move
the reference out of m_stack like this:
auto ref = std::move (m_stack[stratum]);
the `ref' isn't used explicitly, but it serves to hold the
target_ops_ref until the end of the scope while allowing the m_stack
entry to be reset back to nullptr. The alternative would be to
directly set the m_stack entry to nullptr, like this:
m_stack[stratum] = nullptr;
The problem here is that when we set the m_stack entry to nullptr we
first decrement the target_ops reference count, and then set the array
entry to nullptr.
If the decrement means that the target_ops object reaches a zero
reference count then the target_ops object will be closed by calling
target_close. In target_close we ensure that the target being closed
is not in any inferiors target_stack.
As we decrement before clearing, then this check in target_close will
fail, and an assert will trigger.
By using std::move to move the reference out of m_stack, this clears
the m_stack entry, meaning the inferior no longer contains the
target_ops in its target_stack. Now when the REF object goes out of
scope and the reference count is decremented, target_close can run
successfully.
I've made use of the Python connection_removed listener API to add a
test for this issue. The test installs a listener and then causes
delete_inferior to be called, we can then see that the connection is
then correctly removed (because the listener triggers).
|
|
While working on some other target_ops reference count related code, I
spotted that in remote.c we do some manual reference count handling,
i.e. we call target_ops::incref and decref_target (which wraps
target_ops::decref).
I think it would be better to make use of gdb::ref_ptr to automate the
reference count management.
So, this commit updates scoped_mark_target_starting in two ways,
first, I use gdb::ref_ptr to handle the reference counts. Then,
instead of using the scoped_mark_target_starting constructor and
destructor to set and reset the starting_up flag, I now use a
scoped_restore_tmpl object to set and restore the flag.
The above changes mean that the scoped_mark_target_starting destructor
can be completely removed, and the constructor body is now empty.
I've also fixed a typo in the class comment.
The only change in behaviour after this commit is that previously we
didn't care what the value of starting_up was, we just set it to true
in the constructor and false in the destructor.
Now, I assert that the flag is initially false, then set the flag true
when the scoped_mark_target_starting is created.
As the starting_up flag is initialized to false then, for the assert
to fire, we would need to recursively enter
remote_target::start_remote_1, which I don't think is something we
should be doing, so I think the new assert is an improvement.
|
|
After the previous commit converted symbol-lookup debug to use the new
debug scheme, this commit adds SYMBOL_LOOKUP_SCOPED_DEBUG_ENTER_EXIT.
The previous commit didn't add SYMBOL_LOOKUP_SCOPED_DEBUG_ENTER_EXIT
because symbol-lookup debug is controlled by an 'unsigned int' rather
than a 'bool' control variable, we use the numeric value to offer
different levels of verbosity for symbol-lookup debug.
The *_SCOPED_DEBUG_ENTER_EXIT mechanism currently relies on capturing
a reference to the bool control variable, and evaluating the variable
both on entry, and at exit, this is done in the scoped_debug_start_end
class (see gdbsupport/common-debug.h).
This commit templates scoped_debug_start_end so that the class can
accept either a 'bool &' or an invokable object, e.g. a lambda
function, or a function pointer.
The existing scoped_debug_start_end and scoped_debug_enter_exit macros
in common-debug.h are updated to support scoped_debug_enter_exit being
templated, however, nothing outside of common-debug.h needs to change.
I've then added SYMBOL_LOOKUP_SCOPED_DEBUG_ENTER_EXIT in symtab.h, and
added a couple of token uses in symtab.c. I didn't want to add too
much in this first commit, this is really about updating
common-debug.h to support this new functionality.
Within symtab.h I created a couple of global functions that can be
used to query the status of the symbol_lookup_debug control variable,
these functions are then used within the two existing macros:
symbol_lookup_debug_printf
symbol_lookup_debug_printf_v
and also in the new SYMBOL_LOOKUP_SCOPED_DEBUG_ENTER_EXIT macro.
|
|
Convert the implementation of 'set debug symbol-lookup' to the new
debug printing scheme.
In a few places I've updated the debug output to remove places where
the printed debug message included the function name, the new debug
scheme already adds that, but I haven't done all the possible updates.
|
|
This commit provides a test for this commit:
commit 55fc1623f942fba10362cb199f9356d75ca5835b
Date: Thu Nov 3 13:49:17 2022 -0600
Add name canonicalization for C
Which resolves PR gdb/29105. My reason for writing this test was a
desire to better understand the above commit, my process was to study
the commit until I thought I understood it, then write a test to
expose the issue. As the original commit didn't have a test, I
thought it wouldn't hurt to commit this upstream.
The problem tested for here is already described in the above commit,
but I'll give a brief description here. This description describes
GDB prior to the above commit:
- Builtin types are added to GDB using their canonical name,
e.g. "short", not "signed short",
- When the user does something like 'p sizeof(short)', then this is
handled in c-exp.y, and results in a call to lookup_signed_type
for the name "int". The "int" here is actually being looked up as
the type for the result of the 'sizeof' expression,
- In lookup_signed_type GDB first adds a 'signed' and looks for that
type, so in this case 'signed int', and, if that lookup fails, GDB
then looks up 'int',
- The problem is that 'signed int' is not the canonical name for a
signed int, so no builtin type with that name will be found, GDB
will then go to each object file in turn looking for a matching
type,
- When checking each object file, GDB will first check the partial
symtab to see if the full symtab should be expanded or not.
Remember, at this point GDB is looking for 'signed int', there
will be no partial symbols with that name, so GDB will not expand
anything,
- However, GDB checks each partial symbol using multiple languages,
not just the current language (C in this case), so, when GDB
checks using the C++ language, the symbol name is first
canonicalized (the code that does this can be found
lookup_name_info::language_lookup_name). As the canonical form of
'signed int' is just 'int', GDB then looks for any symbols with
the name 'int', most partial symtabs will contain such a symbol,
so GDB ends up expanding pretty much every symtab.
The above commit fixes this by avoiding the use of non-canonical names
with C, now the initial builtin type lookup will succeed, and GDB
never even considers whether to expand any additional symtabs.
The test case creates a library that includes char, short, int, and
long types, and a test program that links against the library.
In the test script we start the inferior, but don't allow it to
progress far enough that the debug information for the library has
been fully expanded yet.
Then we evaluate some 'sizeof(TYPE)' expressions.
In the buggy version of GDB this would cause the debug information
for the library to be fully expanded, while in the fixed version of
GDB this will not be the case.
We use 'info sources' to determine if the debug information has been
fully expanded or not.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29105
|
|
The following commit broke the readnow detection in the testsuite:
commit dfaa040b440084dd73ebd359326752d5f44fc02c
Date: Mon Mar 29 18:31:31 2021 -0600
Remove some "OBJF_READNOW" code from dwarf2_debug_names_index
The testsuite checks if GDB was started with the -readnow flag by
using the 'maintenance print objfiles' command, and looking for the
string 'faked for "readnow"' in the output. This is implemented in
two helper procs `readnow` (gdb.exp) and `mi_readnow` (mi-support.exp).
The following tests all currently depend on this detection:
gdb.base/maint.exp
gdb.cp/nsalias.exp
gdb.dwarf2/debug-aranges-duplicate-offset-warning.exp
gdb.dwarf2/dw2-stack-boundary.exp
gdb.dwarf2/dw2-zero-range.exp
gdb.dwarf2/gdb-index-nodebug.exp
gdb.mi/mi-info-sources.exp
gdb.python/py-symbol.exp
gdb.rust/traits.exp
The following test also includes detection of 'readnow', but does the
detection itself by checking $::GDBFLAGS for the readnow flag:
gdb.opt/break-on-_exit.exp
The above commit removed from GDB the code that produced the 'faked
for "readnow"' string, as a consequence the testsuite can no longer
correctly spot when readnow is in use, and many of the above tests
will fail (at least partially).
When looking at the above tests, I noticed that gdb.rust/traits.exp
does call `readnow`, but doesn't actually use the result, so I've
removed the readnow call, this simplifies the next part of this patch
as gdb.rust/traits.exp was the only place an extra regexp was passed
to the readnow call.
Next I have rewritten `readnow` to check the $GDBFLAGS for the
-readnow flag, and removed the `maintenance print objfiles` check. At
least for all the tests above, when using the readnow board, this is
good enough to get everything passing again.
For the `mi_readnow` proc, I changed this to just call `readnow` from
gdb.exp, I left the mi_readnow name in place - in the future it might
be the case that we want to do some different checks here.
Finally, I updated gdb.opt/break-on-_exit.exp to call the `readnow`
proc.
With these changes, all of the tests listed above now pass correctly
when using the readnow board.
|
|
As Hannes pointed out, the Windows target-async patches broke C-c
handling there. Looking into this, I found a few oddities, fixed
here.
First, windows_nat_target::interrupt calls GenerateConsoleCtrlEvent.
I think this event can be ignored by the inferior, so it's not a great
way to interrupt. Instead, using DebugBreakProcess (or a more
complicated thing for Wow64) seems better.
Second, windows_nat_target did not implement the pass_ctrlc method.
Implementing this lets us remove the special code to call
SetConsoleCtrlHandler and instead integrate into gdb's approach to C-c
handling. I believe that this should also fix the race that's
described in the comment that's being removed.
Initially, I thought a simpler version of this patch would work.
However, I think what happens is that some other library (I'm not sure
what) calls SetConsoleCtrlHandler while gdb is running, and this
intercepts and handles C-c -- so that the gdb SIGINT handler is not
called. C-break continues to work, presumably because whatever
handler is installed ignores it.
This patch works around this issue by ensuring that the gdb handler
always comes first.
|
|
This refactors the code to check for terminal sharing.
is_gdb_terminal is exported, and sharing_input_terminal_1 is renamed,
slightly refactored, and moved to posix-hdep.c. A new
Windows-specific implementation of this function is added to
mingw-hdep.c.
MSDN has a warning about GetConsoleProcessList
This API is not recommended and does not have a virtual terminal
equivalent. [...] Applications remoting via cross-platform
utilities and transports like SSH may not work as expected if
using this API.
However, we believe this isn't likely to be an issue for gdb.
|
|
sigint_ours (and sigquit_ours) can be used without being set. Avoid
this problem by changing them to gdb::optional and checking that they
are in fact set before using the value.
|
|
A subsequent patch will introduce a global 'install_sigint_handler'
function, so first rename the static one in extension.c.
|
|
On s390x-linux, I run into:
...
(gdb) continue^M
Continuing.^M
breakpoint.c:5784: internal-error: bpstat_stop_status_nowatch: \
Assertion `!target_stopped_by_watchpoint ()' failed.^M
A problem internal to GDB has been detected,^M
further debugging may prove unreliable.^M
FAIL: gdb.threads/watchpoint-fork.exp: parent: singlethreaded: \
breakpoint after the first fork (GDB internal error)
...
What happens is the follow:
- a watchpoint event triggers
- the event is processed, s390_linux_nat_target::stopped_by_watchpoint is called and
it returns true, as expected
- the watchpoint event is reported by gdb, and gdb stops
- we issue a continue command
- a fork event triggers
- the event is processed, and during processing that event
s390_linux_nat_target::stopped_by_watchpoint is called again, and returns
true
- the assertion fails, because the function is expected to return false
The function s390_linux_nat_target::stopped_by_watchpoint returns true the
second time, because it looks at the exact same data that was looked at when
it was called the first time, and that data hasn't changed.
There's code in the same function that intends to prevent that from happening:
...
/* Do not report this watchpoint again. */
memset (&per_lowcore, 0, sizeof (per_lowcore));
if (ptrace (PTRACE_POKEUSR_AREA, s390_inferior_tid (), &parea, 0) < 0)
perror_with_name (_("Couldn't clear watchpoint status"));
...
and that probably used to work for older kernels, but no longer does since
linux kernel commit 5e9a26928f55 ("[S390] ptrace cleanup").
Fix this by copying this:
...
siginfo_t siginfo;
if (!linux_nat_get_siginfo (inferior_ptid, &siginfo))
return false;
if (siginfo.si_signo != SIGTRAP
|| (siginfo.si_code & 0xffff) != TRAP_HWBKPT)
return false;
...
from aarch64_linux_nat_target::stopped_data_address and remove the
obsolete watchpoint status clearing code.
Tested on s390x-linux.
Approved-By: Ulrich Weigand <uweigand@de.ibm.com>
|
|
A couple of calls to parse_probe_linespec had an unnecessary cast. I
suspect this cast was never needed, but once commands were changed to
take a 'const' argument, they became completely obsolete. Tested by
rebuilding.
|
|
After this commit:
commit 33c1395cf5e9deec7733691ba32c450e5c27f757
Date: Fri Nov 11 15:26:46 2022 +0000
gdb/testsuite: fix gdb.trace/unavailable-dwarf-piece.exp with Clang
The gdb.trace/unavailable-dwarf-piece.exp test script was creating a
temporary file in the build/gdb/testsuite/ directory, instead of in
the expected place in the outputs directory.
Fix this by adding a call to standard_output_file.
|
|
On s390x-linux, I run into:
...
(gdb) disassemble test^M
Dump of assembler code for function test:^M
0x0000000001000638 <+0>: stg %r11,88(%r15)^M
0x000000000100063e <+6>: lgr %r11,%r15^M
0x0000000001000642 <+10>: nop 0^M
=> 0x0000000001000646 <+14>: nop 0^M
0x000000000100064a <+18>: nop 0^M
0x000000000100064e <+22>: lhi %r1,0^M
0x0000000001000652 <+26>: lgfr %r1,%r1^M
0x0000000001000656 <+30>: lgr %r2,%r1^M
0x000000000100065a <+34>: lg %r11,88(%r11)^M
0x0000000001000660 <+40>: br %r14^M
End of assembler dump.^M
(gdb) FAIL: gdb.python/py-disasm.exp: global_disassembler=: disassemble test
...
The problem is that the test-case expects "nop" but on s390x we have instead
"nop\t0".
Fix this by allowing the insn.
Tested on s390x-linux and x86_64-linux.
|
|
is_nocall_function anticipates only being called for a function or a
method. However, PR gdb/29871 points out a situation where an unusual
expression -- but one that parses to a valid, if extremely weird,
function call -- breaks this assumption.
This patch changes is_nocall_function to remove this assert and
instead simply return 'false' in this case.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29871
|
|
In 2014, the function `gdbpy_should_stop' has been replaced with
`gdbpy_breakpoint_cond_says_stop'
This replaces `gdbpy_should_stop' with `gdbpy_breakpoint_cond_says_stop' in the
comments.
Since `gdbpy_should_stop' has been renamed as noted in `gdb/ChangeLog-2014':
* python/py-breakpoint.c (gdbpy_breakpoint_cond_says_stop): Renamed
from gdbpy_should_stop. Change result type to enum scr_bp_stop.
Change-Id: I0ef3491ce5e057c5e75ef8b569803b30a5838575
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
On s390x-linux, I run into:
...
(gdb) print {unsigned char}{65}^M
$749 = 0 '\000'^M
(gdb) FAIL: gdb.base/printcmds.exp: print {unsigned char}{65}
...
In contrast, on x86_64-linux, we have:
...
(gdb) print {unsigned char}{65}^M
$749 = 65 'A'^M
(gdb) PASS: gdb.base/printcmds.exp: print {unsigned char}{65}
...
The first problem here is that the test is supposed to be a regression test
for PR20630, which can be reproduced (for an unfixed gdb) like this:
...
(gdb) p {unsigned char[]}{0x17}
gdbtypes.c:4641: internal-error: copy_type: \
Assertion `TYPE_OBJFILE_OWNED (type)' failed.
...
but it's not due to insufficient quoting (note the dropped '[]').
That's easy to fix, but after that we have on s390 (big endian):
...
(gdb) print {unsigned char[]}{65}^M
$749 = ""^M
...
and on x86_64 (little endian):
...
(gdb) print {unsigned char[]}{65}^M
$749 = "A"^M
...
Fix this by using 0xffffffff, such that in both cases we have:
...
(gdb) print {unsigned char[]}{0xffffffff}^M
$749 = "\377\377\377\377"^M
...
Tested on x86_64-linux and s390x-linux.
|
|
My earlier patch to fix PR rust/29859 introduced a new operator
precedence bug in the Rust parser. Assignment operators are
right-associative in Rust. And, while this doesn't often matter, as
Rust assignments always have the value (), still as a matter of
principle we should get this correct.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29859
|
|
On s390x-linux (big endian), I run into:
...
(gdb) x /xh main^M
0x1000638 <main>: 0x0000^M
(gdb) FAIL: gdb.base/write_mem.exp: x /xh main
...
In contrast, on x86_64-linux (little endian), we have the expected:
...
(gdb) x /xh main^M
0x4004a7 <main>: 0x4242^M
(gdb) PASS: gdb.base/write_mem.exp: x /xh main
...
The problem is that the test-case hard-codes expectations about endiannes by
writing an int-sized value (4 bytes in this case) and then printing only a
halfword by using "/h" (so, two bytes).
If we print 4 bytes, we have for s390x:
...
0x1000638 <main>: 0x00004242^M
...
and for x86_64:
...
0x4004a7 <main>: 0x00004242^M
...
Fix this by removing the "/h".
Tested on x86_64-linux and s390x-linux.
|
|
In principle, `execute_command()` does following:
struct cmd_list_element *c;
c = lookup_cmd ( ... );
...
/* If this command has been pre-hooked, run the hook first. */
execute_cmd_pre_hook (c);
...
/* ...execute the command `c` ...*/
...
execute_cmd_post_hook (c);
This may lead into use-after-free error. Imagine the command
being executed is a user-defined Python command that redefines
itself. In that case, struct `cmd_list_element` pointed to by
`c` is deallocated during its execution so it is no longer valid
when post hook is executed.
To fix this case, this commit looks up the command once again
after it is executed to get pointer to (possibly newly allocated)
`cmd_list_element`.
|
|
On s390x-linux with target board unix/-m31, I run into:
...
(gdb) PASS: gdb.guile/scm-lazy-string.exp: bad length
print ptr^M
$1 = 0x804006b0 <error: Cannot access memory at address 0x804006b0>^M
(gdb) FAIL: gdb.guile/scm-lazy-string.exp: ptr: print ptr
...
A minimal example is:
...
$ gdb -q -batch -ex "set trace-commands on" -x gdb.in
+file scm-lazy-string
+break main
Breakpoint 1 at 0x4005d2: file scm-lazy-string.c, line 23.
+run
Breakpoint 1, main () at scm-lazy-string.c:23
23 const char *ptr = "pointer";
+step
24 const char array[] = "array";
+print ptr
$1 = 0x804006b0 <error: Cannot access memory at address 0x804006b0>
...
If we delete the breakpoint after running to it, we have instead the expected:
...
+delete
+step
24 const char array[] = "array";
+print ptr
$1 = 0x4006b0 "pointer"
...
The problem is in displaced stepping, forced by the presence of the breakpoint,
when stepping over this insn:
...
0x4005d2 <main+10> larl %r1,0x4006b0
...
With normal stepping we have:
...
(gdb) p /x $r1
$2 = 0x3ff004006b0
...
but with displaced stepping we have instead (note the 0x80000000 difference):
...
(gdb) p /x $r1
$1 = 0x3ff804006b0
(gdb)
...
The difference comes from this code in s390_displaced_step_fixup:
...
/* Handle LOAD ADDRESS RELATIVE LONG. */
else if (is_ril (insn, op1_larl, op2_larl, &r1, &i2))
{
/* Update PC. */
regcache_write_pc (regs, from + insnlen);
/* Recompute output address in R1. */
regcache_cooked_write_unsigned (regs, S390_R0_REGNUM + r1,
amode | (from + i2 * 2));
}
...
where the "amode |" adds the 0x80000000.
Fix this by removing the "amode |".
Tested on s390-linux, with native and target board unix/-m31.
Approved-By: Ulrich Weigand <uweigand@de.ibm.com>
|
|
With the AArch64 Scalable Matrix Extension we have a new TPIDR2 register, and
it will be added to the existing NT_ARM_TLS register set. Kernel patches are
being reviewed here:
https://lore.kernel.org/linux-arm-kernel/20220818170111.351889-1-broonie@kernel.org/
From GDB's perspective, we handle it in a similar way to the existing TPIDR
register. But we need to consider cases of systems that only have TPIDR and
systems that have both TPIDR and TPIDR2.
With that in mind, the following patch adds the required code to support
TPIDR2 and turns the org.gnu.gdb.aarch64.tls feature into a
dynamically-generated target description as opposed to a static target
description containing only TPIDR.
That means we can remove the gdb/features/aarch64-tls.xml file and replace the
existing gdb/features/aarch64-tls.c auto-generated file with a new file that
dynamically generates the target description containing either TPIDR alone or
TPIDR and TPIDR2.
In the future, when *BSD's start to support this register, they can just
enable it as is being done for the AArch64 Linux target.
The core file read/write code has been updated to support TPIDR2 as well.
On GDBserver's side, there is a small change to the find_regno function to
expose a non-throwing version of it.
It always seemed strange to me how find_regno causes the whole operation to
abort if it doesn't find a particular register name. The patch moves code
from find_regno into find_regno_no_throw and makes find_regno call
find_regno_no_throw instead.
This allows us to do register name lookups to find a particular register
number without risking erroring out if nothing is found.
The patch also adjusts the feature detection code for aarch64-fbsd, since
the infrastructure is shared amongst all aarch64 targets. I haven't added
code to support TPIDR2 in aarch64-fbsd though, as I'm not sure when/if
that will happen.
|
|
On powerpc64le-linux, I run into:
...
(gdb) PASS: gdb.guile/scm-symtab.exp: step out of func2
guile (print (> (sal-line (find-pc-line (frame-pc (selected-frame)))) line))^M
= #f^M
(gdb) FAIL: gdb.guile/scm-symtab.exp: test find-pc-line with resume address
...
The problem is as follows: the instructions for the call to func2 are:
...
1000070c: 39 00 00 48 bl 10000744 <func1>
10000710: 00 00 00 60 nop
10000714: 59 00 00 48 bl 1000076c <func2>
10000718: 00 00 00 60 nop
1000071c: 00 00 20 39 li r9,0
...
and the corresponding line number info is:
...
scm-symtab.c:
File name Line number Starting address View Stmt
scm-symtab.c 42 0x1000070c x
scm-symtab.c 43 0x10000714 x
scm-symtab.c 44 0x1000071c x
...
The test-case looks at the line numbers for two insns:
- the insn of the call to func2 (0x10000714), and
- the insn after that (0x10000718),
and expects the line number of the latter to be greater than the line number
of the former.
However, both insns have the same line number: 43.
Fix this by replacing ">" with ">=".
Tested on x86_64-linux and powerpc64le-linux.
|
|
When running test-case gdb.tui/tui-layout-asm-short-prog.exp on SLE-12-SP3
aarch64, I run into:
...
FAIL: gdb.tui/tui-layout-asm-short-prog.exp: check asm box contents
FAIL: gdb.tui/tui-layout-asm-short-prog.exp: check asm box contents again
...
due to:
...
(gdb) file tui-layout-asm-short-prog^M
Reading symbols from tui-layout-asm-short-prog...^M
(No debugging symbols found in tui-layout-asm-short-prog)^M
...
I managed to reproduce the same behaviour on openSUSE Leap 15.4 x86_64, by
removing the debug option.
Fix this by making the test-case unsupported if no debug info is found.
Tested on x86_64-linux.
|
|
When building GDB with the following CFLAGS and CXXFLAGS as part of
configure line:
CFLAGS=-std=gnu11 CXXFLAGS=-std=gnu++11
Then run the selftest.exp, I see:
======
Running /home/lee/dev/binutils-gdb/gdb/testsuite/gdb.gdb/selftest.exp
...
FAIL: gdb.gdb/selftest.exp: run until breakpoint at captured_main
WARNING: Couldn't test self
=== gdb Summary ===
# of unexpected failures 1
/home/lee/dev/binutils-gdb/gdb/gdb version 13.0.50.20221206-git -nw -nx
-iex "set height 0" -iex "set width 0" -data-directory
/home/lee/dev/binutils-gdb/gdb/testsuite/../data-directory
======
It is the fact that when I use the previously mentioned CFLAGS and
CXXFLAGS as part of the configuration line, the default value (-O2 -g)
is overridden, then GDB has no debug information. When there's no debug
information, GDB should not run the testcase in selftest.exp.
The root cause of this FAIL is that the $gdb_file_cmd_debug_info didn't
get the right value ("nodebug") during the gdb_file_cmd procedure.
That's because in this commit,
commit 3453e7e409f44a79ac6695589836edb8a49bfb08
Date: Sat May 19 11:25:20 2018 -0600
Clean up "Reading symbols" output
It changed "no debugging..." to "No debugging..." which causes the above
problem. This patch only updates the corresponding pattern to fix this
issue.
With this patch applied, I see:
======
Running /home/lee/dev/binutils-gdb/gdb/testsuite/gdb.gdb/selftest.exp
...
=== gdb Summary ===
# of untested testcases 1
/home/lee/dev/binutils-gdb/gdb/gdb version 13.0.50.20221206-git -nw -nx
-iex "set height 0" -iex "set width 0" -data-directory
/home/lee/dev/binutils-gdb/gdb/testsuite/../data-directory
======
Tested on x86_64-linux.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
While playing with JIT reader I experienced GDB to crash on null-pointer
dereference when stepping through non-jitted code.
The problem was that dwarf2_frame_find_fde () assumed that all objfiles
have BFD but that's not always true. To address this problem, this
commit skips such objfiles.
To test the fix we put breakpoint in jit_function_add (). The JIT reader
does not know how unwind this function so unwinding eventually falls
back to DWARF unwinder which in turn iterates over objfiles. Since the
the code is jitted, it is guaranteed it would eventually process JIT
objfile.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
Instead of using `select_frame (nullptr)` to invalidate the selected
frame, introduce a function to do that. There is no change in behavior,
but it makes the intent a bit clearer. It also allows adding an assert
in select_frame that fi is not nullptr, so it avoids passing nullptr by
mistake.
Change-Id: I61643f46bc8eca428334513ebdaadab63997bdd0
Reviewed-By: Bruno Larsen <blarsen@redhat.com>
|
|
Add KFAILs in test-case gdb.base/longjmp.exp for PR gdb/26967, covering
various ways that gdb is unable to recover the longjmp target if the libc
probe is not supported.
Tested on x86_64-linux.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
I saw that bppy_init used a non-const "char *". Fixing this revealed
that the xstrdup here was also unnecessary, so this patch removes it.
|
|
This is just a couple of cosmetic fixes in ppc-sysv-tdep.c: fixing
some formatting and correcting a typo.
|
|
PR rust/29859 points out an operator precedence bug in the Rust
parser. This patch fixes it and adds a regression test.
|
|
When running test-case gdb.base/longjmp.exp, we have:
...
PASS: gdb.base/longjmp.exp: next over setjmp (1)
...
PASS: gdb.base/longjmp.exp: next over setjmp (2)
...
The trailing " (1)" and " (2)" are interpreted as comments rather than parts
of the test name, and therefore this is a duplicate, which is currently not
detected by our duplicate detection mechanism (PR testsuite/29772).
Fix the duplicate by using with_test_prefix.
Tested on x86_64-linux.
|
|
When running test-case gdb.base/longjmp.exp on x86_64-linux, the master
longjmp breakpoint is set using probes and the test-case passes:
...
(gdb) PASS: gdb.base/longjmp.exp: next to longjmp (1)
next^M
0x00000000004005cc 49 if (setjmp (env) == 0) /* patt1 */^M
(gdb) PASS: gdb.base/longjmp.exp: next over longjmp(1)
next^M
56 resumes++;^M
(gdb) PASS: gdb.base/longjmp.exp: next into else block (1)
...
However, if I disable
create_longjmp_master_breakpoint_probe, we have instead:
...
(gdb) PASS: gdb.base/longjmp.exp: next to longjmp (1)
next^M
56 resumes++;^M
(gdb) FAIL: gdb.base/longjmp.exp: next over longjmp(1)
...
At first glance, the failure mode doesn't look too bad: we stop
a few insns later than the passing scenario.
For contrast, if we do the same on powerpc64le, the failure mode is:
...
(gdb) PASS: gdb.base/longjmp.exp: next to longjmp (1)
next^M
^M
Breakpoint 3, main () at longjmp.c:59^M
59 i = 1; /* miss_step_1 */^M
(gdb) FAIL: gdb.base/longjmp.exp: next over longjmp(1)
...
Here we only stop because of running into the safety net breakpoint at
miss_step_1.
So, how does this happen on x86_64? Let's look at the code:
...
4005c7: e8 94 fe ff ff call 400460 <_setjmp@plt>
4005cc: 85 c0 test %eax,%eax
4005ce: 75 1e jne 4005ee <main+0x3b>
4005d0: 8b 05 8e 0a 20 00 mov 0x200a8e(%rip),%eax # 601064 <longjmps>
4005d6: 83 c0 01 add $0x1,%eax
4005d9: 89 05 85 0a 20 00 mov %eax,0x200a85(%rip) # 601064 <longjmps>
4005df: be 01 00 00 00 mov $0x1,%esi
4005e4: bf 80 10 60 00 mov $0x601080,%edi
4005e9: e8 82 fe ff ff call 400470 <longjmp@plt>
4005ee: 8b 05 74 0a 20 00 mov 0x200a74(%rip),%eax # 601068 <resumes>
...
The next over the longjmp call at 4005e9 is supposed to stop at the longjmp
target at 4005cc, but instead we stop at 4005ee, where we have the step-resume
breakpoint inserted by the next. In other words, we accidentally "return"
from the longjmp call to the insn immediately after it (even though
a longjmp is a noreturn function).
Try to avoid this accident and make the failure mode on x86_64 the same as on
powerpc64le, by switching the then and else branch.
Tested on x86_64-linux.
|
|
According to the riscv psabi, the mapping relationship between the
DWARF registers and the machine registers is as follows:
DWARF Number | Register Name | Description
0 - 31 | x0 - x31 | Integer Registers
32 - 63 | f0 - f31 | Floating-point Registers
This is not modelled quite right in riscv_dwarf_reg_to_regnum, the
DWARF register numbers 31 and 63 are not handled correctly due to a
use of '<' instead of '<='. This commit fixes this issue.
|
|
Make the inferior_ptid bubble up to linux_nat_target::xfer_partial.
Change-Id: I62dbc5734c26648bb465f449c2003c73751cd812
|
|
I noticed we could reduce duplication a bit here.
Change-Id: If24e54d1dac71b46f7c1f68a18a073d4c084b644
|
|
Not a big deal, but it seems strange to check errno instead of the
ptrace return value to know whether it succeeded.
Change-Id: If0a6d0280ab0e5ecb077e546af0d6fe489c5b9fd
|
|
No caller cares about the value of *SIGINFO on failure. It's also
documented in the function doc that *SIGINFO is uninitialized (I
understand "untouched") on failure.
Change-Id: I5ef38a5f58e3635e109b919ddf6f827f38f1225a
|
|
Change return type to bool.
Change-Id: I1bf0360bfdd1b5994cd0f96c268d806f96fe51a4
|
|
No behavior change expected.
Change-Id: Ifaa64ecd619483646b024fd7c62e571e92a8eedb
|
|
I noticed that when running these two tests in sequence:
Running /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.ada/arrayptr.exp ...
ERROR: GDB process no longer exists
ERROR: Couldn't run foo-all
Running /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.ada/assign_1.exp ...
The results in gdb.sum are:
Running /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.ada/arrayptr.exp ...
PASS: gdb.ada/arrayptr.exp: scenario=all: compilation foo.adb
ERROR: GDB process no longer exists
UNRESOLVED: gdb.ada/arrayptr.exp: scenario=all: gdb_breakpoint: set breakpoint at foo.adb:40 (eof)
ERROR: Couldn't run foo-all
Running /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.ada/assign_1.exp ...
UNRESOLVED: gdb.ada/assign_1.exp: changing the language to ada
PASS: gdb.ada/assign_1.exp: set convenience variable $xxx to 1
The UNRESOLVED for arrayptr.exp is fine, as GDB crashes in that test,
while trying to run to main. However, the UNRESOLVED in assign_1.exp
doesn't make sense, GDB behaves as expected in that test:
(gdb) set lang ada^M
(gdb) UNRESOLVED: gdb.ada/assign_1.exp: changing the language to ada
print $xxx := 1^M
$1 = 1^M
(gdb) PASS: gdb.ada/assign_1.exp: set convenience variable $xxx to 1
The problem is that arrayptr.exp calls perror when failing to run to
main, then returns. perror makes it so that the next test (as in
pass/fail) will be recorded as UNRESOLVED. However, here, the next test
(as in pass/fail) is in the next test (as in .exp). Hence the spurious
UNRESOLVED in assign_1.exp.
These perror when failing to run to X are not really useful, especially
since runto records a FAIL on error, by default. Remove all the
perrors on runto failure I could find.
When there wasn't one already, add a return statement when failing to
run, to avoid running the test of the test unnecessarily.
I thought of adding a check ran between test (in gdb_finish
probably) where we would emit a warning if errcnt > 0, meaning a test
quit and left a perror "active". However, reading that variable would
poke into the DejaGNU internals, not sure it's a good idea.
Change-Id: I2203df6d06e199540b36f56470d1c5f1dc988f7b
|
|
The missing newline causes testsuite issues because the gdb prompt gets output
to an unexpected location.
|
|
Use as many tabs as possible for indentation and pad with spaces to keep
the argument aligned to the opening parenthesis in the line above.
Co-developed-by: Simon Marchi <simon.marchi@efficios.com>
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
Use tab for the first eight spaces of indentation, and align the gdb_printf
arguments to the open parenthesis of the function call.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
|
|
Add a pid parameter to linux_proc_xfer_memory_partial, making the
inferior_ptid reference bubble up close to the target_ops::xfer_partial
boundary. No behavior change expected.
Change-Id: I58171b00ee1bba1ea22efdbb5dcab8b1ab3aac4c
|
|
Add a few debug statements that were useful to me when debugging why the
glibc probes interface wasn't getting used.
Change-Id: Ic20744f9fc80a90f196896b0829949411620c540
|
|
solib implementations are typically used one at a time. So it will be
rare that you will want to enable debug for one solib kind, and
absolutely want to keep the others disabled. To make things simpler,
instead of adding separate variables / macros / commands for each solib
implementation, merge the existing ones (frv and aix) into a unified
"set/show debug solib", with the solib_debug_printf macro.
Change-Id: I6e18bbc7401724f37ae66681badb079d75ecf7fa
|
|
Recent commit 32a5aa26256 ("[gdb/testsuite] Fix gdb.ada/float-bits.exp
for powerpc64le") started using command "maint print architecture", which
produces ~275 lines.
Rewrite the corresponding gdb_test_multiple to read line-by-line, to prevent
timeouts on slower test setups.
Note that this doesn't fix a timeout in the test-case on aarch64 due to:
...
gdbarch_dump: read_core_file_mappings = <0x817438>
(gdb) aarch64_dump_tdep: Lowest pc = 0x0x8000
...
Tested on x86_64-linux.
|
