| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Replace with equivalent methods on blockrange.
Change-Id: I20fd8f624e0129782c36768291891e7582d77c74
|
|
Replace with equivalent methods.
Change-Id: If86b8cbdfb0f52e22c929614cd53e73358bab76a
|
|
Replace with equivalent methods.
Change-Id: If9a239c511a664f2a59fecb6d1cd579881b23dc2
|
|
Replace with equivalent methods.
Change-Id: I334a319909a50b5cc5570a45c38c70e10dc00630
|
|
Replace with equivalent methods.
Change-Id: I31ec00f5bf85335c8b23d306ca0fe0b84d489101
|
|
Replace with equivalent methods.
Change-Id: I10a6c8a2a86462d9d4a6a6409a3f07a6bea66310
|
|
There are some subtle differences between architectures, like the size
of a "long" type, and this isn't currently accounted for in
gdb.base/parse_number.exp.
For example, on aarch64 a long type is 8 bytes, whereas a long type is
4 bytes for x86_64. This causes the following FAIL's:
FAIL: gdb.base/parse_number.exp: lang=asm: ptype 0xffffffffffffffff
FAIL: gdb.base/parse_number.exp: lang=auto: ptype 0xffffffffffffffff
FAIL: gdb.base/parse_number.exp: lang=c: ptype 0xffffffffffffffff
FAIL: gdb.base/parse_number.exp: lang=c++: ptype 0xffffffffffffffff
FAIL: gdb.base/parse_number.exp: lang=fortran: p/x 0xffffffffffffffff
FAIL: gdb.base/parse_number.exp: lang=fortran: ptype 0xffffffffffffffff
FAIL: gdb.base/parse_number.exp: lang=go: ptype 0xffffffffffffffff
FAIL: gdb.base/parse_number.exp: lang=local: ptype 0xffffffffffffffff
FAIL: gdb.base/parse_number.exp: lang=minimal: ptype 0xffffffffffffffff
FAIL: gdb.base/parse_number.exp: lang=objective-c: ptype 0xffffffffffffffff
FAIL: gdb.base/parse_number.exp: lang=opencl: ptype 0xffffffffffffffff
FAIL: gdb.base/parse_number.exp: lang=pascal: ptype 0xffffffffffffffff
There are some fortran-specific divergences as well, where 32-bit
architectures show "unsigned int" for both 32-bit and 64-bit integers
and 64-bit architectures show "unsigned int" and "unsigned long" for
32-bit and 64-bit integers.
There might be a bug that 32-bit fortran truncates 64-bit values to
32-bit, given "p/x 0xffffffffffffffff" returns "0xffffffff".
Here's what we get for aarch64:
(gdb) ptype 0xffffffff
type = unsigned int
(gdb) ptype 0xffffffffffffffff
type = unsigned long
(gdb) p sizeof (0xffffffff)
$1 = 4
(gdb) p sizeof (0xffffffffffffffff)
quit
$2 = 8
(gdb) ptype 0xffffffff
type = unsigned int
(gdb) ptype 0xffffffffffffffff
type = unsigned long
And for arm:
(gdb) ptype 0xffffffff
type = unsigned int
(gdb) ptype 0xffffffffffffffff
quit
type = unsigned long long
(gdb) p sizeof (0xffffffff)
quit
$1 = 4
(gdb) p sizeof (0xffffffffffffffff)
quit
$2 = 8
(gdb) ptype 0xffffffff
type = unsigned int
(gdb) ptype 0xffffffffffffffff
type = unsigned long
This patch...
* Makes the testcase iterate over all architectures, thus covering all
the different combinations of types/sizes every time.
* Adjusts the expected values and types based on the sizes of long
long, long and int.
A particularly curious architecture is s12z, which has 32-bit long
long, and thus no way to represent 64-bit integers in C-like
languages.
Co-Authored-By: Luis Machado <luis.machado@arm.com>
Change-Id: Ifc0ccd33e7fd3c7585112ff6bebe7d266136768b
|
|
unwind-secure-frames command
This patch makes use of the support for several stack pointers
introduced by the previous patch to switch between them as needed
during unwinding.
It introduces a new 'unwind-secure-frames' arm command to enable/disable
mode switching during unwinding. It is enabled by default.
It has been tested using an STM32L5 board (with cortex-m33) and the
sample applications shipped with the STM32Cube development
environment: GTZC_TZSC_MPCBB_TrustZone in
STM32CubeL5/Projects/NUCLEO-L552ZE-Q/Examples/GTZC.
The test consisted in setting breakpoints in various places and check
that the backtrace is correct: SecureFault_Callback (Non-secure mode),
__gnu_cmse_nonsecure_call (before and after the vpush instruction),
SecureFault_Handler (Secure mode).
This implies that we tested only some parts of this patch (only MSP*
were used), but remaining parts seem reasonable.
Signed-off-by: Torbjörn Svensson <torbjorn.svensson@st.com>
Signed-off-by: Christophe Lyon <christophe.lyon@foss.st.com>
Signed-off-by: Christophe Lyon <christophe.lyon@arm.com>
|
|
Armv8-M architecture with Security extension features four stack pointers
to handle Secure and Non-secure modes.
This patch adds support to switch between them as needed during
unwinding, and replaces all updates of cache->prev_sp with calls to
arm_cache_set_prev_sp.
Signed-off-by: Torbjörn Svensson <torbjorn.svensson@st.com>
Signed-off-by: Christophe Lyon <christophe.lyon@foss.st.com>
Signed-off-by: Christophe Lyon <christophe.lyon@arm.com>
|
|
This patch is a preparation for the rest of the series and adds two
arm_cache_init helper functions. It updates every place that updates
cache->saved_regs to call the helper instead.
Signed-off-by: Torbjörn Svensson <torbjorn.svensson@st.com>
Signed-off-by: Christophe Lyon <christophe.lyon@foss.st.com>
Signed-off-by: Christophe Lyon <christophe.lyon@arm.com>
|
|
This patch removes the hardcoded access to PSP in
arm_m_exception_cache() and relies on the definition with the XML
descriptions.
Signed-off-by: Christophe Lyon <christophe.lyon@foss.st.com>
Signed-off-by: Christophe Lyon <christophe.lyon@arm.com>
|
|
While working on adding support for Non-secure/Secure modes unwinding,
I noticed that the prologue analysis lacked support for vpush, which
is used for instance in the CMSE stub routine.
This patch updates thumb_analyze_prologue accordingly, adding support
for vpush of D-registers.
Signed-off-by: Christophe Lyon <christophe.lyon@foss.st.com>
Signed-off-by: Christophe Lyon <christophe.lyon@arm.com>
|
|
Tom and Simon feedback that there is a test failing in this commit:
commit a5c69b1e49bae4d0dcb20f324cebb310c63495c6
Date: Sun Apr 17 15:09:46 2022 +0800
gdb: fix using clear command to delete non-user breakpoints(PR cli/7161)
Then, I reproduced the same fail with Ubuntu 20.04 as Simon said, and I
fixed the nit in this patch. The root of the problem is not correctly
matching the presentation of internal breakpoints.
In addition, as Pedro pointed out, the original testcase is not portable
in some methods, so this patch fixes this issue and some other
improvements.
Tested on x86_64 ubuntu 20.04.4 and openSUSE Tumbleweed(VERSION_ID="20220425").
|
|
I learned about with_cwd today. I spotted a few spots that could use
it, to make the code more robust.
Change-Id: Ia23664cb827f25e79d31948e0c006a8dc61c33e1
|
|
This patch adds PowerPC specific tests to verify recording of various
instructions. The first test case checks the ISA 2.06 lxvd2x instruction.
The second test case tests several of the ISA 3.01 instructions. Specifically,
it checks the word and prefixed instructions and some of the Matrix
Multiply Assist (MMA) instructions.
The patch has been run on both Power 10 and Power 9 to verify the ISA
2.06 test case runs on both platforms without errors. The ISA 3.1 test
runs without errors on Power 10 and is skipped as expected on Power 9.
|
|
This patch adds support for the PowerPC ISA 3.1 instructions to the PowerPC
gdb instruction recording routines. Case statement entries are added to a
number of the existing routines for recording the 32-bit word instructions.
A few new functions were added to handle the new word instructions. The 64-bit
prefix instructions are all handled by a set of new routines. The function
ppc_process_prefix_instruction() is the primary function to handle the
prefixed instructions. It calls additional functions to handle specific
sets of prefixed instructions. These new functions are:
ppc_process_record_prefix_vsx_d_form(),
ppc_process_record_prefix_store_vsx_ds_form(),
ppc_process_record_prefix_op34(),
ppc_process_record_prefix_op33(),
ppc_process_record_prefix_op32(),
ppc_process_record_prefix_store(),
ppc_process_record_prefix_op59_XX3(),
ppc_process_record_prefix_op42().
|
|
Internally at AdaCore, we noticed that the new Windows thread name
code could fail. First, it might return a zero-length string, but in
gdb conventions it should return nullptr instead. Second, an encoding
failure could wind up showing replacement characters to the user; this
is confusing and not useful; it's better to recognize such errors and
simply discard the name. This patch makes both of these changes.
|
|
Convert bsd_kvm_corefile and the local filename in bsd_kvm_open to
std::string rather than simple char * pointers freed by xfree.
|
|
I noticed that these files failed to format with Black, because they use
print without parenthesis (which isn't Python 3 compatible).
I don't know if these files are still relevant, but the change is
trivial, so here it is.
Change-Id: I116445c2b463486016f824d32effffc915b60766
|
|
and gdb.arch/vsx-regs.exp
The format for printing the floating point values was changed by commit:
commit 56262a931b7ca8ee3ec9104bc7e9e0b40cf3d64e
Author: Tom Tromey <tromey@adacore.com>
Date: Thu Feb 17 13:43:59 2022 -0700
Change how "print/x" displays floating-point value
Currently, "print/x" will display a floating-point value by first
casting it to an integer type. This yields weird results like:
(gdb) print/x 1.5
$1 = 0x1
...
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=16242
The above change results in 417 regression test failures since the expected
Power vector register output no longer match.
This patch updates the expected Altivec floating point register prints to
the hexadecimal format for both big endian and little endian systems. The
patch also fixes a formatting isue with the decimal_vector expected value
assign statements.
The expected VSX vector_register1, vector_register1_vr, vector_register2,
vector_register2_vr variables are updated to include the new float128 entry.
Additionally, the comment in the vsx expect file about the initialization
of the vs registers is updated.
The patch has been tested on Power 10, Power 8 LE and Power 8 BE.
|
|
This changes the .gdb_index writer to skip linkage names. This was
always done historically (though somewhat implicitly).
|
|
If a variable is passed to function in FORTRAN as an argument the
variable is treated as an array with rank zero. GDB currently does
not support the case for assumed rank 0. This patch provides support
for assumed rank 0 and updates the testcase as well.
Without patch:
Breakpoint 1, arank::sub1 (a=<error reading variable:
failed to resolve dynamic array rank>) at assumedrank.f90:11
11 PRINT *, RANK(a)
(gdb) p a
failed to resolve dynamic array rank
(gdb) p rank(a)
failed to resolve dynamic array rank
With patch:
Breakpoint 1, arank::sub1 (a=0) at assumedrank.f90:11
11 PRINT *, RANK(a)
(gdb) p a
$1 = 0
(gdb) p rank(a)
$2 = 0
|
|
While working in gdb/infrun.c:restart_threads, I was wondering what are
the preconditions to call the function. It seems to me that
!step_over_info_valid_p should be a precondition (i.e. if we are doing
an inline step over breakpoint, we do not want to resume non stepping
threads as one of them might miss the breakpoint which is temporally
disabled).
To convince myself that this is true, I have added an assertion to
enforce this, and got one regression in the testsuite:
FAIL: gdb.base/step-over-syscall.exp: vfork: displaced=off: single step over vfork (GDB internal error)
This call to restart_threads originates from handle_vfork_done which
does not check if a step over is active when restarting other threads:
if (target_is_non_stop_p ())
{
scoped_restore_current_thread restore_thread;
insert_breakpoints ();
restart_threads (event_thread, event_thread->inf);
start_step_over ();
}
In this patch, I propose to:
- Call start_step_over before restart_threads. If a step over is already
in progress (as it is the case in the failing testcase),
start_step_over return immediately, and there is no point in restarting
all threads just to stop them right away for a step over breakpoint.
- Only call restart_threads if no step over is in progress at this
point.
In this patch, I also propose to keep the assertion in restart_threads
to help enforce this precondition, and state it explicitly.
I have also checked all other places which call restart_threads, and
they all seem to check that there is no step over currently active
before doing the call.
As for infrun-related things, I am never completely sure I did not miss
something. So as usual, all feedback and thoughts are very welcome.
Tested on x86_64-linux-gnu.
Change-Id: If5f5f98ec4cf9aaeaabb5e3aa88ae6ffd70d4f37
|
|
After this commit:
commit d08cbc5d3203118da5583296e49273cf82378042
Date: Wed Dec 22 12:57:44 2021 +0000
gdb: unbuffer all input streams when not using readline
Issues were reported with some MS-Windows hosts, see the thread
starting here:
https://sourceware.org/pipermail/gdb-patches/2022-March/187004.html
Filed in bugzilla as: PR mi/29002
The problem seems to be that calling setbuf on terminal file handles
is not always acceptable, see this mail for more details:
https://sourceware.org/pipermail/gdb-patches/2022-April/187310.html
This commit does two things, first moving the setbuf calls out of
gdb_readline_no_editing_callback so that we don't end up calling
setbuf so often.
Then, for MS-Windows hosts, we don't call setbuf for terminals, this
appears to resolve the issues that have been reported.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29002
|
|
When running:
$ make check TESTS="gdb.multi/multi-re-run.exp" RUNTESTFLAGS="--target_board=native-gdbserver"
I get:
target remote localhost:2347^M
Remote debugging using localhost:2347^M
Reading symbols from /lib64/ld-linux-x86-64.so.2...^M
Reading symbols from /usr/lib/debug//lib/x86_64-linux-gnu/ld-2.31.so...^M
0x00007ffff7fd0100 in _start () from /lib64/ld-linux-x86-64.so.2^M
(gdb) continue^M
Continuing.^M
Cannot execute this command while the target is running.^M
Use the "interrupt" command to stop the target^M
and then try again.^M
(gdb) FAIL: gdb.multi/multi-re-run.exp: re_run_inf=1: iter=1: runto: run to all_started
The test does:
- Connect to a remote target with inferior 2, continue and stop on the
all_started function
- Connect to a separate remote target / GDBserver instance with inferior 1,
continue and (expect to) stop on the all_started function
The failure seen above happens when trying to continue inferior 1.
What happens is:
- GDB tells inferior 1's remote target to continue
- We go into fetch_inferior_event, try to get an event at random from
the targets
- do_target_wait happens to pick inferior 2's target
- That target return TARGET_WAITKIND_NO_RESUMED, which makes sense:
inferior 2 is stopped, that target has no resumed thread
- handle_no_resumed tries to update the thread list of all targets:
for (auto *target : all_non_exited_process_targets ())
{
switch_to_target_no_thread (target);
update_thread_list ();
}
- When trying to update the thread list of inferior 1's target, it hits
the "Cannot execute this command while the target is running" error.
This target is working in "remote all-stop" mode, and it is currently
waiting for a stop reply, so it can't send packets to update the
thread list at this time.
To handle the problem described in the comment in handle_no_resumed, I
don't think it is necessary to update the thread list of all targets,
but only the event target. That comment describes a kind of race
condition where some target reports a breakpoint hit for a thread and
then its last remaining resumed thread exits, so sends a "no resumed"
event. If we ended up resuming the thread that hit a breakpoint, we
want to ignore the "no resumed" and carry on.
But I don't really see why we need to update the thread list on the
other targets. I can't really articulate this, it's more a gut feeling,
maybe I just fail to imagine the situation where this is needed. But
here is the patch anyway, so we can discuss it. The patch changes
handle_no_resumed to only update the thread list of the event target.
This fixes the test run shown above.
The way I originally tried to fix this was to make
remote_target::update_thread_list return early if the target is
currently awaiting a stop reply, since there's no way it can update the
thread list at that time. But that felt more like papering over the
problem. I then thought that we probably shouldn't be asking the target
to update the thread list unnecessarily.
Change-Id: Ide3df22b4f556478e155ad1c67ad4b4fe7c26a58
|
|
This commit replaces an earlier commit that worked around the issues
reported in bug PR gdb/28833.
The previous commit just implemented a work around in order to avoid
the worst results of the bug, but was not a complete solution. The
full solution was considered too risky to merge close to branching GDB
12. This improved fix has been applied after GDB 12 branched. See
this thread for more details:
https://sourceware.org/pipermail/gdb-patches/2022-March/186391.html
This commit replaces this earlier commit:
commit 74a159a420d4b466cc81061c16d444568e36740c
Date: Fri Mar 11 14:44:03 2022 +0000
gdb: work around prompt corruption caused by bracketed-paste-mode
Please read that commit for a full description of the bug, and why is
occurs.
In this commit I extend GDB to use readline's rl_deprep_term_function
hook to call a new function gdb_rl_deprep_term_function. From this
new function we can now print the 'quit' message, this replaces the
old printing of 'quit' in command_line_handler. Of course, we only
print 'quit' in gdb_rl_deprep_term_function when we are handling EOF,
but thanks to the previous commit (to readline) we now know when this
is.
There are two aspects of this commit that are worth further
discussion, the first is in the new gdb_rl_deprep_term_function
function. In here I have used a scoped_restore_tmpl to disable the
readline global variable rl_eof_found.
The reason for this is that, in rl_deprep_terminal, readline will
print an extra '\n' character before printing the escape sequence to
leave bracketed paste mode. You might then think that in the
gdb_rl_deprep_term_function function, we could simply print "quit" and
rely on rl_deprep_terminal to print the trailing '\n'. However,
rl_deprep_terminal only prints the '\n' when bracketed paste mode is
on. If the user has turned this feature off, no '\n' is printed.
This means that in gdb_rl_deprep_term_function we need to print
"quit" when bracketed paste mode is on, and "quit\n" when bracketed
paste mode is off.
We could absolutely do that, no problem, but given we know how
rl_deprep_terminal is implemented, it's easier (I think) to just
temporarily clear rl_eof_found, this prevents the '\n' being printed
from rl_deprep_terminal, and so in gdb_rl_deprep_term_function, we can
now always print "quit\n" and this works for all cases.
The second issue that should be discussed is backwards compatibility
with older versions of readline. GDB can be built against the system
readline, which might be older than the version contained within GDB's
tree. If this is the case then the system readline might not contain
the fixes needed to support correctly printing the 'quit' string.
To handle this situation I have retained the existing code in
command_line_handler for printing 'quit', however, this code is only
used now if the version of readline we are using doesn't not include
the required fixes. And so, if a user is using an older version of
readline, and they have bracketed paste mode on, then they will see
the 'quit' sting printed on the line below the prompt, like this:
(gdb)
quit
I think this is the best we can do when someone builds GDB against an
older version of readline.
Using a newer version of readline, or the patched version of readline
that is in-tree, will now give a result like this in all cases:
(gdb) quit
Which is what we want.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28833
|
|
In this commit:
commit a6b413d24ccc5d76179bab866834e11fd6fec294
Date: Fri Mar 11 14:44:03 2022 +0000
gdb: work around prompt corruption caused by bracketed-paste-mode
a change was made to GDB to work around bug PR gdb/28833. The
consequence of this work around is that, when bracketed paste mode is
enabled in readline, and GDB is quit by sending EOF, then the output
will look like this:
(gdb)
quit
The ideal output, which is what we get when bracketed paste mode is
off, is this:
(gdb) quit
The reason we need to make this change is explained in the original
commit referenced above. What isn't mentioned in the above commit, is
that the change that motivated this work around was only added in
readline 8, older versions of readline don't require the change.
In later commits in this series I will add a fix to GDB's in-tree copy
of readline (this fix is back-ported from upstream readline), and then
I will change GDB so that, when using the (patched) in-tree readline,
we can have the ideal output in all cases.
However, GDB can be built against the system readline. When this is
done, and the system readline is version 8, then we will still have to
use the work around (two line) style output.
But, if GDB is built against the system readline, and the system
readline is an older version 7 readline, then there's no reason why we
can't have the ideal output, after all, readline 7 doesn't include the
change that we need to work around.
This commit changes GDB so that, when using readline 7 we get the
ideal output in all cases. This change is trivial (a simple check
against the readline version number) so I think this should be fine to
include.
For testing this commit, you need to configure GDB including the
'--with-system-readline' flag, and build GDB on a system that uses
readline 7, for example 'Ubuntu 18.04'. Then run the test
'gdb.base/eof-exit.exp', you should expect everything to PASS.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28833
|
|
failure of gdb.threads/fork-plus-threads.exp
This test sometimes fail like this:
info threads^M
Id Target Id Frame ^M
11.12 process 2270719 Couldn't get registers: No such process.^M
(gdb) FAIL: gdb.threads/fork-plus-threads.exp: detach-on-fork=off: no threads left
[Inferior 11 (process 2270719) exited normally]^M
info inferiors^M
Num Description Connection Executable ^M
* 1 <null> /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/fork-plus-threads/fork-plus-threads ^M
11 <null> /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/fork-plus-threads/fork-plus-threads ^M
(gdb) FAIL: gdb.threads/fork-plus-threads.exp: detach-on-fork=off: only inferior 1 left (the program exited)
I can get it to fail quite reliably by pinning it to a core:
$ taskset -c 5 make check TESTS="gdb.threads/fork-plus-threads.exp"
The previous attempt at fixing this was:
https://sourceware.org/pipermail/gdb-patches/2021-October/182846.html
What we see is part due to a possible unfortunate ordering of events
given by the kernel, and what could be considered a bug in GDB.
The test program makes a number of forks, waits them all, then exits.
Most of the time, GDB will get and process the exit event for inferior 1
after the exit events of all the children. But this is not guaranteed.
After the last child exits and is waited by the parent, the parent can
exit quickly, such that GDB collects from the kernel the exit events for
the parent and that child at the same time. It then chooses one event
at random, which can be the event for the parent. This will result in
the parent appearing to exit before its child. There's not much we can
do about it, so I think we have to adjust the test to cope.
After expect has seen the "exited normally" notification for inferior 1,
it immediately does an "info thread" that it expects to come back empty.
But at this point, GDB might not have processed inferior 11's (the last
child) exit event, so it will look like there is still a thread. Of
course that thread is dead, we just don't know it yet. But that makes
the "no thread" test fail. If the test waited just a bit more for the
"exited normally" notification for inferior 11, then the list of threads
would be empty.
So, first change, make the test collect all the "exited normally"
notifications for all inferiors before proceeding, that should ensure we
see an empty thread list. That would fix the first FAIL above.
However, we would still have the second FAIL, as we expect inferior 11
to not be there, it should have been deleted automatically. Inferior 11
is normally deleted when prune_inferiors is called. That is called by
normal_stop, which is only called by fetch_inferior_event only if the
event thread completed an execution command FSM (thread_fsm). But the
FSM for the continue command completed when inferior 1 exited. At that
point inferior 11 was not prunable, as it still had a thread. When
inferior 11 exits, prune_inferiors is not called.
I think that can be considered a GDB bug. From the user point of view,
there's no reason why in one case inferior 11 would be deleted and not
in the other case.
This patch makes the somewhat naive change to call prune_inferiors in
fetch_inferior_event, so that it is called in this case. It is placed
at this particular point in the function so that it is called after the
user inferior / thread selection is restored. If it was called before
that, inferior 11 wouldn't be pruned, because it would still be the
current inferior.
Change-Id: I48a15d118f30b1c72c528a9f805ed4974170484a
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=26272
|
|
This fixes a build breakage in my recent coff-pe-read.c change.
I'm sorry about this. I don't understand how it happened, because I
definitely built and tested the series on Windows, and I didn't change
it before pushing. Something must have gone wrong on the Windows
build, but I don't know what. I'll investigate and and re-test to be
sure.
|
|
This changes another function in coff-pe-read.c to use 'const' more,
and to avoid the use of alloca by instead using std::string.
|
|
coff-pe-read.c uses xsnprintf and alloca, but using std::string is
better, and just as easy. In general I think alloca is something to
be avoided, and unbounded uses especially so.
|
|
coff-pe-read.c casts away const at one spot, but this is easily
replaced by calling bfd_get_filename directly in a couple of debugging
prints.
|
|
coff-pe-read.c iterates over BFD sections using bfd_map_over_sections,
but it's much simpler to use a for-each loop. This allows for the
removal of helper functions and types.
|
|
Pedro pointed out that gdb-add-index is much slower with the new DWARF
indexer. He also noticed that, in some cases, the generated
.gdb_index would have the wrong fully-qualified name for a method.
I tracked this down to a bug in the indexer. If a type could have
methods but was marked as a declaration, the indexer was ignoring it.
However, this meant that the internal map to find the qualified name
was not updated for this container.
|
|
The variable right_lib_flags is not being set correctly to define RIGHT.
The value RIGHT is needed to force the address of the library functions
lib1_func3 and lib2_func4 to occur at different address in the wrong and
right libraries.
With RIGHT defined correctly, functions lib1_func3 and lib2_func4 occur
at different addresses the test runs correctly on Powerpc.
The test needs the lib2 addresses to be different in the right and
wrong cases. That is the point of introducing function lib2_spacer
with the ifdef RIGHT compiler directive.
On Intel, the ARRAY_SIZE of 1 versus 8192 is sufficient to get the
dynamic linker to move the addresses of the library. You can also get
the same effect on PowerPC but you must use a value much larger than
8192.
The key thing is that the test was not properly setting RIGHT to
defined to get the lib2_spacer function on Intel and Powerpc.
Without the patch, we have the Intel backtrace for the bad libraries:
backtrace
#0 break_here () at /home/ ... /gdb/testsuite/gdb.base/solib-search.c:30
#1 0x00007ffff7fae156 in ?? ()
#2 0x00007fffffffc150 in ?? ()
#3 0x00007ffff7fbb156 in ?? ()
#4 0x00007fffffffc160 in ?? ()
#5 0x00007ffff7fae146 in ?? ()
#6 0x00007fffffffc170 in ?? ()
#7 0x00007ffff7fbb146 in ?? ()
#8 0x00007fffffffc180 in ?? ()
#9 0x0000555555555156 in main () at /home/ ... /binutils-gdb/gdb/testsuite/gdb.base/solib-search.c:23
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb) PASS: gdb.base/solib-search.exp: backtrace (with wrong libs) (data collection)
The backtrace on Intel with the good libraries is:
backtrace
#0 break_here () at /.../binutils-gdb/gdb/testsuite/gdb.base/solib-search.c:30
#1 0x00007ffff7fae156 in lib2_func4 () at /.../binutils-gdb/gdb/testsuite/gdb.base/solib-search-lib2.c:49
#2 0x00007ffff7fbb156 in lib1_func3 () at /.../gdb.base/solib-search-lib1.c:49
#3 0x00007ffff7fae146 in lib2_func2 () at /.../testsuite/gdb.base/solib-search-lib2.c:30
#4 0x00007ffff7fbb146 in lib1_func1 () at /.../gdb.base/solib-search-lib1.c:30
#5 0x0000555555555156 in main () at /...solib-search.c:23
(gdb) PASS: gdb.base/solib-search.exp: backtrace (with right libs) (data collection)
PASS: gdb.base/solib-search.exp: backtrace (with right libs)
In one case the backtrace is correct and the other it
is wrong on Intel. This is due to the fact that the ARRAY_SIZE caused
the dynamic linker to move the library function addresses around. I
believe it has to do with the default size of the data and code
sections used by the dynamic linker.
So without the patch the backtrace on PowerPC looks like:
backtrace
#0 break_here () at /.../solib-search.c:30
#1 0x00007ffff7f007f4 in lib2_func4 () at /.../solib-search-lib2.c:49
#2 0x00007ffff7f307f4 in lib1_func3 () at /.../solib-search-lib1.c:49
#3 0x00007ffff7f007ac in lib2_func2 () at /.../solib-search-lib2.c:30
#4 0x00007ffff7f307ac in lib1_func1 () at /.../solib-search-lib1.c:30
#5 0x000000001000074c in main () at /.../solib-search.c:23
for both the good and bad libraries.
The patch fixes defining RIGHT in solib-search-lib1.c and solib-search-
lib2.c. Note, without the patch the lib1_spacer and lib2_spacer
functions do not show up in the object dump of the Intel or Powerpc
libraries as it should. The patch fixes that by making sure RIGHT gets
defined.
Now with the patch the backtrace for the bad library on PowerPC looks
like:
backtrace
#0 break_here () at /.../solib-search.c:30
#1 0x00007ffff7f0083c in __glink_PLTresolve () from /.../solib-search-lib2.so
Backtrace stopped: frame did not save the PC
And the backtrace for the good libraries on PowerPC looks like:
backtrace
#0 break_here () at /.../solib-search.c:30
#1 0x00007ffff7f0083c in lib2_func4 () at /.../solib-search-lib2.c:49
#2 0x00007ffff7f3083c in lib1_func3 () at /.../solib-search-lib1.c:49
#3 0x00007ffff7f007cc in lib2_func2 () at /.../solib-search-lib2.c:30
#4 0x00007ffff7f307cc in lib1_func1 () at /.../solib-search-lib1.c:30
#5 0x000000001000074c in main () at /.../solib-search.c:23
(gdb) PASS: gdb.base/solib-search.exp: backtrace (with right libs) (data collection)
PASS: gdb.base/solib-search.exp: backtrace (with right libs)
The issue then is on Power where the ARRAY_SIZE of 1 versus 8192 is not
sufficient to cause the dymanic linker to allocate the libraries at
different addresses. I don't claim to understand the specifics of how
the dynamic linker works and what the default size is for the data and
code sections are. My guess is by default PowerPC allocates a larger
data size by default, which is large enough to hold array[8192]. The
default size of the data section allocated by the dynamic linker on
Intel is not large enough to hold array[8192] thus causing the code
section on Intel to have to move when the large array is defined.
Note on PowerPC, if you make ARRAY_SIZE big enough, then you will cause
the library addresses to occur at different addresses as the larger
data section forces the code section to a different address. That was
actually my original fix for the program until I spoke with Doug Evans
who originally wrote the test. Doug noticed that RIGHT was not getting
defined as he originally intended in the test.
With the patch to fix the definition of RIGHT, PowerPC has a bad and a
good backtrace because the address of lib1_func3 and lib2_func4 both
move because lib1_spacer and lib2_spacer are now defined
before lib1_func3 and lib2_func4.
Without the patch, the lib1_spacer and lib2_spacer function doesn't show
up in the binary for the correct or incorrect library on Intel or PowerPC.
With the patch, RIGHT gets defined as originally intended for the test on
both architectures and lib1_spacer and lib2_spacer function show up in the
binaries on both architectures changing the other function addresses as
intended thus causing the test work as intended on PowerPC.
|
|
This can be a local in dwarf_decode_line_header.
Change-Id: I2ecf4616d1a3197bd1e81ded9f999a2da9a685af
|
|
This doesn' have to be a field, it can simply be a local variable in
dwarf_decode_line_header. Name the local variable "unit_length", since
that's what the field in called in DWARF 4 and 5. It's always easier to
follow the code with the standard on the side when we use the same
terminology.
Change-Id: I3ad1022afd9410b193ea11b9b5437686c1e4e633
|
|
Commit c67f4e538 ("gdb/testsuite: make gdb.ada/mi_prot.exp stop at
expected location") introduced some DUPLICATEs in MI tests using
mi_continue_to_line, for example:
DUPLICATE: gdb.ada/mi_ref_changeable.exp: mi_continue_to_line: set temporary breakpoint
These test names were previously differentiated by the location passed
to mi_continue_to_line. Since the location can contain a path, that
commit removed the location from the test name, in favor of a hardcoded
string "set temporary breakpoint", hence removing the differentiator.
mi_continue_to_line receives a "test" parameter, containing a test
name. Add a "with_test_prefix" with that name, so that all tests
recorded during mi_continue_to_line have this in their name.
mi_continue_to_line passes that "test" string to mi_get_stop_line, that
is a bit superfluous. mi_get_stop_line only uses that string in case of
failures (it doesn't record a pass if everything goes fine). Since it's
not crucial, just remove it, and adjust all callers.
Adjust three gdb.mi/mi-var-*.exp tests to use prefixes to differentiate
the multiple calls to mi_run_inline_test (which calls
mi_continue_to_line).
Change-Id: I511c6caa70499f8657b1cde37d71068d74d56a74
|
|
Internally we noticed that some tests would fail like so on Windows:
warning: Section .debug_aranges in [...] has duplicate debug_info_offset 0x0, ignoring .debug_aranges.
Debugging showed that, in fact, a second CU was being created at this
offset. We tracked this down to the fact that, while the ELF reader
is careful to re-use the per-BFD data, other readers are not, and
could re-read the DWARF data multiple times.
However, since the change to allow an objfile to have multiple "quick
symbol" implementations, there's no reason for this approach -- it's
safe and easy for all symbol readers to reuse the per-BFD data when
reading DWARF.
This patch implements this idea, simplifying dwarf2_build_psymtabs and
making it private, and then switching to dwarf2_initialize_objfile as
the sole way to start the DWARF reader.
Note that, while I think the call to dwarf2_build_frame_info in
machoread.c is also obsolete, I haven't attempted to remove it here.
|
|
The following behaviour was observed in GDB:
(gdb) show remote X-packet
Support for the `p' packet is auto-detected, currently unknown.
Note the message mentions the 'p' packet. This is a regression since
this commit:
commit 8579fd136a614985bd27f20539c7bb7c5a51287d
Date: Mon Nov 8 14:58:46 2021 +0000
gdb/gdbsupport: make xstrprintf and xstrvprintf return a unique_ptr
Before this commit the behaviour was:
(gdb) show remote X-packet
Support for the `X' packet is auto-detected, currently unknown.
The problem was caused by a failed attempt to ensure that some
allocated strings were deleted when GDB exits. The code in the above
commit attempted to make use of 'static' to solve this problem,
however, the solution was just wrong.
In this new commit I instead allocate a static vector into which all
the allocated strings are stored, this ensures the strings are
released when GDB exits (which makes output from tools like valgrind
cleaner), but each string within the vector can be unique, which fixes
the regression.
|
|
In this review [1], Eli pointed out that we should be careful when
concatenating file names to avoid duplicated slashes. On Windows, a
double slash at the beginning of a file path has a special meaning. So
naively concatenating "/" and "foo/bar" would give "//foo/bar", which
would not give the desired results. We already have a few spots doing:
if (first_path ends with a slash)
path = first_path + second_path
else
path = first_path + slash + second_path
In general, I think it's nice to avoid superfluous slashes in file
paths, since they might end up visible to the user and look a bit
unprofessional.
Introduce the path_join function that can be used to join multiple path
components together (along with unit tests).
I initially wanted to make it possible to join two absolute paths, to
support the use case of prepending a sysroot path to a target file path,
or the prepending the debug-file-directory to a target file path. But
the code in solib_find_1 shows that it is more complex than this anyway
(for example, when the right hand side is a Windows path with a drive
letter). So I don't think we need to support that case in path_join.
That also keeps the implementation simpler.
Change a few spots to use path_join to show how it can be used. I
believe that all the spots I changed are guarded by some checks that
ensure the right hand side operand is not an absolute path.
Regression-tested on Ubuntu 18.04. Built-tested on Windows, and I also
ran the new unit-test there.
[1] https://sourceware.org/pipermail/gdb-patches/2022-April/187559.html
Change-Id: I0df889f7e3f644e045f42ff429277b732eb6c752
|
|
In a previous commit (b750766ac96: gdb/testsuite: Introduce and use
gdb_spawn_attach_cmdline), if gdb_spawn_attach_cmdline cannot have GDB
attach to the process because of ptrace restrictions (operation not
permitted), the proc issues UNTESTED. This should really be
UNSUPPORTED, as it is done in gdb_attach.
This patch fixes this oversight.
Change-Id: Ib87e33b9230f3fa7a85e06220ef4c63814b71f7d
|
|
We currently only test decimal and hexadecimal for the
gdb.Value.format_string() interface, this patch adds testcases for
binary format.
Tested on x86_64 openSUSE Tumbleweed(VERSION_ID="20220413").
|
|
The gdb_test_multiple pattern for the "notice empty URL" test in
gdb.debuginfod/fetch_src_and_symbols.exp misses expecting the prompt.
Fix it by using -re -wrap.
Also, by using "confirm off", the message GDB prints if Debuginfod
downloading is available doesn't contain "Enable debuginfod" any
longer. E.g.:
~~~
(gdb) file testsuite/outputs/gdb.debuginfod/fetch_src_and_symbols/fetch_src_and_symbols
Reading symbols from testsuite/outputs/gdb.debuginfod/fetch_src_and_symbols/fetch_src_and_symbols...
This GDB supports auto-downloading debuginfo from the following URLs:
<http://localhost:123>
Enable debuginfod for this session? (y or [n])
~~~
~~~
(gdb) with confirm off -- file testsuite/outputs/gdb.debuginfod/fetch_src_and_symbols/fetch_src_and_symbols
Reading symbols from testsuite/outputs/gdb.debuginfod/fetch_src_and_symbols/fetch_src_and_symbols...
This GDB supports auto-downloading debuginfo from the following URLs:
<http://127.0.0.1:8000>
<127.0.0.1:8000>
Debuginfod has been disabled.
To make this setting permanent, add 'set debuginfod enabled off' to .gdbinit.
(No debugging symbols found in testsuite/outputs/gdb.debuginfod/fetch_src_and_symbols/fetch_src_and_symbols)
(gdb)
~~~
I handled that correctly in the other tests that use test_urls, but
had forgotten to update the "notice empty URL" one.
Change-Id: I00040c83466e1494b3875574eb009c571a1504bf
|
|
Trailing whitespace in the string of debuginfod URLs causes an
out_of_range exception during the printing of URLs for the first
use notice.
To fix this, stop printing URLs when the substring to be printed
consists only of whitespace.
Also add first use notice testcases.
Co-Authored-By: Pedro Alves <pedro@palves.net>
|
|
Following a7e6a19e87f3d719ea23c65b580a6d9bca4ccab3 "gdb: testsuite: add
new gdb_attach to check "attach" command", this commit proposes to
introduce the gdb_spawn_attach_cmdline helper and use it in
gdb.base/attach.exp.
This helper starts GDB and adds the "--pid=$PID" argument.
Also note that both the original and new implementation use
gdb_spawn_with_cmdline_opts, which in the end uses default_gdb_spawn.
This makes sure that we use $INTERNAL_GDBFLAGS, which by default already
contain "-iex \"set height 0\" -iex \"set width 0\"". To avoid
repetition of those arguments, gdb_spawn_attach_cmdline does not repeat
those arguments.
To maintain a behavior similat to what gdb.base/attach.exp used to do,
gdb_spawn_attach_cmdline keeps the -quiet flag.
Tested on x86_64-gnu-linux
Change-Id: I1fdcdb71c86d9c5d34bb28fc86fac68bcec37358
|
|
This turns symbol_symtab into a method on symbol. It also replaces
symbol_set_symtab with a method.
|
|
This turns symbol_arch into a method on symbol.
|
|
This turns symbol_objfile into a method on symbol.
|
|
Symbols have an aclass_index method, but this isn't needed, because
the aclass index isn't useful outside of the symbol implementation.
|
