The global variable 'handle_id' in tracectf.c is only used in a single
function, so change it to be a local variable.
Reviewed-by: Keith Seitz <keiths@redhat.com>
This moves the definition of the ctf_target type into the
HAVE_LIBBABELTRACE block. This type is only used in this block, so it
makes sense to only define it there.
Reviewed-by: Keith Seitz <keiths@redhat.com>
This change traceframe_walk_blocks to take a function_view. This
simplifies the code somewhat and lets us entirely remove one helper
function.
Reviewed-by: Keith Seitz <keiths@redhat.com>
A user supplied an executable and a remote logfile that could be used
to crash gdb. The problem is that the BFD section for a particular
symbol was null, because the section was not marked "allocated".
Digging deeper, the problem was that elfread.c dropped the section for
absolute symbols. This patch fixes the crash.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30431
It was pointed out[1] that after this commit:
commit 3812b38d8d
Date: Thu Oct 20 11:14:33 2022 +0100
gdbserver: allow agent expressions to fail with invalid memory access
Now that agent expressions might fail with the error
expr_eval_invalid_memory_access, we might overflow the
eval_result_names array in tracepoint.cc. This is because the
eval_result_names array does not include a string for either
expr_eval_invalid_goto or expr_eval_invalid_memory_access.
I don't know if having expr_eval_invalid_goto missing is also a
problem, but it feels like eval_result_names should just include a
string for every possible error.
I could just add two more strings into the array, but I figure that a
more robust solution will be to move all of the error types, and their
associated strings, into a new ax-result-types.def file, and to then
include this file in both ax.h and tracepoint.cc in order to build
the enum eval_result_type and the eval_result_names string array.
Doing this means it is impossible to have a missing error string in
the future.
[1] https://inbox.sourceware.org/gdb-patches/01059f8a-0e59-55b5-f530-190c26df5ba3@palves.net/
Approved-By: Pedro Alves <pedro@palves.net>
When comparing the test results for two different runs of GDB I
noticed a difference in the results for gdb.base/frame-view.exp.
The difference was caused by one of the tests including a stack
address in the test name:
PASS: gdb.base/frame-view.exp: with_pretty_printer=false: select-frame view 0x7ffff7c5cea8 0x40115b
and
PASS: gdb.base/frame-view.exp: with_pretty_printer=true: select-frame view 0x7ffff7c5cea8 0x40115b
If for whatever reason the stack address changes between test runs
then it becomes harder to compare results.
Fix this by giving the test a descriptive name that doesn't include a
stack address:
PASS: gdb.base/frame-view.exp: with_pretty_printer=false: select thread 2 frame from thread 1
and
PASS: gdb.base/frame-view.exp: with_pretty_printer=true: select thread 2 frame from thread 1
There's no change to what is actually tested after this commit.
In this commit:
commit 8bcead6966
Date: Tue May 23 11:25:01 2023 +0100
gdb/testsuite: add test for core file with a 0 pid
a new test gdb.arch/core-file-pid0.exp was added. This test includes
a pre-generated core file for x86-64 and for other architectures the
test reports 'unsupported'.
However, after reporting 'unsupported' the test failed to perform an
early return, so the test would then carry on and try to actually
perform the test, which resulted in some TCL errors.
Fix this by returning after reporting the test unsupported.
This commit improves the output of this previous commit:
commit 2dc3457a45
Date: Fri Oct 14 13:22:55 2022 +0100
gdb: include breakpoint number in testing condition error message
The earlier commit extended the error message:
Error in testing breakpoint condition:
to include the breakpoint number, e.g.:
Error in testing breakpoint condition 3:
This commit extends takes this further, and includes the location
number if the breakpoint has multiple locations, so we might now see:
Error in testing breakpoint condition 3.2:
Just as with how GDB reports a normal breakpoint stop, if a breakpoint
only has a single location then the location number is not included,
this keeps things nice and consistent.
I've extended one of the tests to cover the new functionality.
Approved-By: Pedro Alves <pedro@palves.net>
Currently, the Fortran test suite does not run with NVIDIA's Fortran
compiler (nvfortran).
The goal here is to get the tests running and preventing further
regressions during future work. This change does not do anything to fix
existing failures.
Teach the compiler detection about nvfortran. There is no underlying
information about whether this compiler is related to flang classic or
flang, so we cannot reuse the main and type definitions. Therefore, we
explicitly record the main method and type information observed when
using nvfortran.
The main name was extracted by trying to set breakpoints on both MAIN_
and MAIN__.
The following mapping of test to type names was used to extract how
nvfortran reports types.
info-types.exp: fortran_int4, fortran_int8, fortran_real4,
fortran_logical4
common-block.exp: fortran_real8
complex.exp: fortran_complex4 fortran_complex8
logical.exp: fortran_character1. Ran ptype on "c".
Types defined as fortran_complex16 do not compile with nvfortran, so it
was left unset.
gdb.fortran regression tests run with GNU, Intel, Intel LLVM and ACfL.
No regressions detected.
The gdb.fortran test results with nvfortran 23.3 are as follows.
Before:
# of expected passes 523
# of unexpected failures 107
# of known failures 2
# of unresolved testcases 1
# of untested testcases 7
# of duplicate test names 2
After:
# of expected passes 5696
# of unexpected failures 271
# of known failures 12
# of untested testcases 9
# of unsupported tests 5
As can be seen from the above, there are now considerably more passing
assertions.
Approved-By: Tom Tromey <tom@tromey.com>
For example, objcopy --set-section-flags .data=alloc,large will add
SHF_X86_64_LARGE to the .data section. Omitting "large" will drop the
SHF_X86_64_LARGE flag.
The bfd_section flag is named generically, SEC_ELF_LARGE, in case other
processors want to follow SHF_X86_64_LARGE. SEC_ELF_LARGE has the same
value as SEC_TIC54X_BLOCK used by coff.
bfd/
* section.c: Define SEC_ELF_LARGE.
* bfd-in2.h: Regenerate.
* elf64-x86-64.c (elf_x86_64_section_flags, elf_x86_64_fake_sections,
elf_x86_64_copy_private_section_data): New.
binutils/
* NEWS: Mention the new feature for objcopy.
* doc/binutils.texi: Mention "large".
* objcopy.c (parse_flags): Parse "large".
(check_new_section_flags): Error if "large" is used with a
non-x86-64 ELF target.
* testsuite/binutils-all/x86-64/large-sections.d: New.
* testsuite/binutils-all/x86-64/large-sections.s: New.
* testsuite/binutils-all/x86-64/large-sections-i386.d: New.
* testsuite/binutils-all/x86-64/large-sections-2.d: New.
* testsuite/binutils-all/x86-64/large-sections-2-x32.d: New.
When debugging C++ programs, it is possible to trigger a spurious assert
failure when attempting to set a breakpoint on a malformed symbol name.
Names of the form 'A>::B' and 'A)::B' trigger this assert failure in
cp_lookup_bare_symbol:
$ gdb gdb
[...]
(gdb) br test>::assert
Function "test>::assert" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (test>::assert) pending.
(gdb) start
[...]
cp-namespace.c:181: internal-error: cp_lookup_bare_symbol: Assertion `strstr (name, "::") == NULL' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
----- Backtrace -----
0x5217e2 gdb_internal_backtrace_1
/home/amerey/binutils-gdb/gdb/bt-utils.c:122
0x521885 _Z22gdb_internal_backtracev
/home/amerey/binutils-gdb/gdb/bt-utils.c:168
0xaf8303 internal_vproblem
/home/amerey/binutils-gdb/gdb/utils.c:396
0xaf86be _Z15internal_verrorPKciS0_P13__va_list_tag
/home/amerey/binutils-gdb/gdb/utils.c:476
0xccdb3f _Z18internal_error_locPKciS0_z
/home/amerey/binutils-gdb/gdbsupport/errors.cc:58
0x5dded9 cp_lookup_bare_symbol
/home/amerey/binutils-gdb/gdb/cp-namespace.c:181
0x5de39d cp_lookup_symbol_in_namespace
/home/amerey/binutils-gdb/gdb/cp-namespace.c:328
[...]
Currently this assert is skipped if the symbol name contains '<' or '('.
Fix this spurious failure by also skipping the assert when the symbol
name contains '>' or ')'.
Regression tested on F38 x86_64.
Approved-By: Tom Tromey <tom@tromey.com>
A co-worker, Andry, noticed that the DAP setExpression implementation
returned the wrong fields -- it used "result" rather than "value", and
included "memoryReference", which isn't in the spec (an odd oversight,
IMO).
This patch fixes the problems.
Simon noticed a crash that could be caused via new Python
gdb.execute_mi function. Looking into this, I found a few unchecked
casts to mi_interp, like:
- struct mi_interp *mi = (struct mi_interp *) command_interp ();
This patch replaces all such casts with safer variants.
For -gdb-exit and mi_load_progress, I chose to have the functions
simply not generate any output. It didn't seem useful to do so.
Some casts I eliminated by adding a parameter to a function. Then, in
mi_execute_command, I changed the code to use
gdb::checked_static_cast. This is appropriate because this particular
overload can only be called by the MI interpreter.
There does not seem to be a very good way to test -gdb-exit.
Regression tested on x86-64 Fedora 36.
I noticed that the printf code for strings, printf_c_string and
printf_wide_c_string, don't take max-value-size into account, but do
load a complete string from the inferior into a GDB buffer.
As such it would be possible for an badly behaved inferior to cause
GDB to try and allocate an excessively large buffer, potentially
crashing GDB, or at least causing GDB to swap lots, which isn't
great.
We already have a setting to protect against this sort of thing, the
'max-value-size'. So this commit updates the two function mentioned
above to check the max-value-size and give an error if the
max-value-size is exceeded.
If the max-value-size is exceeded, I chose to continue reading
inferior memory to figure out how long the string actually is, we just
don't store the results. The benefit of this is that when we give the
user an error we can tell the user how big the string actually is,
which would allow them to correctly adjust max-value-size, if that's
what they choose to do.
The default for max-value-size is 64k so there should be no user
visible changes after this commit, unless the user was previously
printing very large strings. If that is the case then the user will
now need to increase max-value-size.
This commit removes the last alloca call from printcmd.c. This is
similar to the patches I originally posted here:
https://inbox.sourceware.org/gdb-patches/cover.1677533215.git.aburgess@redhat.com/
However, this change was not included in that original series.
The original series received push back because it was thought that
replacing alloca with a C++ container type would introduce unnecessary
malloc/free overhead.
However, in this case we are building a string, and (at least for
GCC), the std::string type has a small string optimisation, where
small strings are stored on the stack.
And in this case we are building what will usually be a very small
string, we're just constructing a printf format specifier for a hex
value, so it'll be something like '%#x' -- though it could also have a
width in there too -- but still, it should normally fit within GCCs
small string buffer.
So, in this commit, I propose replacing the use of alloca with a
std::string. This shouldn't result (normally) in any additional
malloc or free calls, so should be similar in performance to the
original approach.
There should be no user visible differences after this commit.
Remove a couple of uses of alloca from printcmd.c, and replace them
with gdb::byte_vector.
An earlier variant of this patch was proposed in this thread:
https://inbox.sourceware.org/gdb-patches/cover.1677533215.git.aburgess@redhat.com/
however, there was push back on that thread due to it adding extra
dynamic allocation, i.e. moving the memory buffers off the stack on to
the heap.
However, of all the patches originally proposed, I think in these two
cases moving off the stack is the correct thing to do. Unlike all the
other patches in the original series, where the data being read
was (mostly) small in size, a register, or a couple of registers, in
this case we are reading an arbitrary string from the inferior. This
could be any size, and so should not be placed on the stack.
So in this commit I replace the use of alloca with std::byte_vector
and simplify the logic a little (I think) to take advantage of the
ability of std::byte_vector to dynamically grow in size.
Of course, really, we should probably be checking the max-value-size
setting as we load the string to stop GDB crashing if a corrupted
inferior causes GDB to try read a stupidly large amount of
memory... but I'm leaving that for a follow on patch.
There should be no user visible changes after this commit.
Given this test program:
#include <wchar.h>
const wchar_t wide_str[] = L"wide string";
int
main (void)
{
return 0;
}
I observed this GDB behaviour:
$ gdb -q /tmp/printf-wchar_t
Reading symbols from /tmp/printf-wchar_t...
(gdb) start
Temporary breakpoint 1 at 0x40110a: file /tmp/printf-wchar_t.c, line 8.
Starting program: /tmp/printf-wchar_t
Temporary breakpoint 1, main () at /tmp/printf-wchar_t.c:8
25 return 0;
(gdb) printf "%ls\n", wide_str
(gdb)
Notice that the printf results in a blank line rather than the
expected 'wide string' output.
I tracked the problem down to printf_wide_c_string (in printcmd.c), in
this function we do this:
struct type *wctype = lookup_typename (current_language,
"wchar_t", NULL, 0);
int wcwidth = wctype->length ();
the problem here is that 'wchar_t' is a typedef. If we look at the
comment on type::length() we see this:
/* Note that if thistype is a TYPEDEF type, you have to call check_typedef.
But check_typedef does set the TYPE_LENGTH of the TYPEDEF type,
so you only have to call check_typedef once. Since value::allocate
calls check_typedef, X->type ()->length () is safe. */
What this means is that after calling lookup_typename we should call
check_typedef in order to ensure that the length of the typedef has
been setup correctly. We are not doing this in printf_wide_c_string,
and so wcwidth is incorrectly calculated as 0. This is what leads GDB
to print an empty string.
We can see in c_string_operation::evaluate (in c-lang.c) an example of
calling check_typedef specifically to fix this exact issue.
Initially I did fix this problem by adding a check_typedef call into
printf_wide_c_string, but then I figured why not move the
check_typedef call up into lookup_typename itself, that feels like it
should be harmless when looking up a non-typedef type, but will avoid
bugs like this when looking up a typedef. So that's what I did.
I can then remove the extra check_typedef call from c-lang.c, I don't
see any other places where we had extra check_typedef calls. This
doesn't mean we definitely had bugs -- so long as we never checked the
length, or, if we knew that check_typedef had already been called,
then we would be fine.
I don't see any test regressions after this change, and my new test
case is now passing.
Reviewed-By: Tom Tromey <tom@tromey.com>
"rename" conflicts with a function of that name, which gcc from that
same timeframe then complains about. Use a name matching that of
struct input_remap's respective field.
The ARC HS5x and ARC HS6x processors are based on the new ARCv3 ISA
that implements a full range of 32-bit and 64-bit instructions. These
processors feature a high-speed 10-stage, dual-issue pipeline that
offers increased utilization of functional units with a limited
increase in power and area. The HS5x processors feature a 32-bit
pipeline that can execute all ARCv3 32-bit instructions, while the
HS6x processors feature a full 64-bit pipeline and register file that
can execute both 32-bit and 64-bit instructions. In addition, the ARC
HS6x supports 64-bit virtual and 52-bit physical address spaces to
enable direct addressing of current and future large memories, as well
as 128-bit loads and stores for efficient data movement.
This readelf patch updates/adds Synopsys ARCv3 machine name fileds and
supported relocations.
Signed-off-by: Claudiu Zissulescu <claziss@synopsys.com>
The license header on a file I recently contributed was incorrect.
The file was added in commit:
commit 0879691698
Date: Tue May 23 11:25:21 2023 +0100
gdb: handle core files with .reg/0 section names
The problems were:
- GPLv2 instead of GPLv3,
- Use the FSF postal address rather than their URL.
Nobody else has touched the file since I merged it, so I don't believe
there are any problems with me changing the license, this commit does
just that.
Since commit 05c06f318f ("Linux: Access memory even if threads are
running"), GDB prefers pread64/pwrite64 to access inferior memory
instead of ptrace. That change broke reading shared libraries on
SPARC64 Linux, as reported by PR gdb/30525 ("gdb cannot read shared
libraries on SPARC64").
On SPARC64 Linux, surprisingly (to me), userspace shared libraries are
mapped at high 64-bit addresses:
(gdb) info sharedlibrary
Cannot access memory at address 0xfff80001002011e0
Cannot access memory at address 0xfff80001002011d8
Cannot access memory at address 0xfff80001002011d8
From To Syms Read Shared Object Library
0xfff80001000010a0 0xfff8000100021f80 Yes (*) /lib64/ld-linux.so.2
(*): Shared library is missing debugging information.
Those addresses are 64-bit addresses with the high bits set. When
interpreted as signed, they're negative.
The Linux kernel rejects pread64/pwrite64 if the offset argument of
type off_t (a signed type) is negative, which happens if the memory
address we're accessing has its high bit set. See
linux/fs/read_write.c sys_pread64 and sys_pwrite64 in Linux.
Thankfully, lseek does not fail in that situation. So the fix is to
use the 'lseek + read|write' path if the offset would be negative.
Fix this in both native GDB and GDBserver.
Tested on a SPARC64 GNU/Linux and x86-64 GNU/Linux.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30525
Change-Id: I79c724f918037ea67b7396fadb521bc9d1b10dc5
Currently riscv gdb code looks at arch byte order
when fetching instructions. This works when the
target is LE, but on BE arch it will byte swap the
instruction, while the riscv spec defines all
instructions are LE encoded regardless of
system memory endianess.
PR tdep/30252 reports that using GDB on Solaris fails an assertion in
target_resume:
target.c:2648: internal-error: target_resume: Assertion `inferior_ptid != null_ptid' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n)
The backtrace, after running it through c++filt, looks like:
----- Backtrace -----
0xa18914 gdb_internal_backtrace_1
/root/binutils-gdb/gdb/bt-utils.c:122
0xa18914 gdb_internal_backtrace()
/root/binutils-gdb/gdb/bt-utils.c:168
0xdec834 internal_vproblem
/root/binutils-gdb/gdb/utils.c:401
0xdecad8 internal_verror(char const*, int, char const*, __va_list_tag*)
/root/binutils-gdb/gdb/utils.c:481
0xf3638c internal_error_loc(char const*, int, char const*, ...)
/root/binutils-gdb/gdbsupport/errors.cc:58
0xd70580 target_resume(ptid_t, int, gdb_signal)
/root/binutils-gdb/gdb/target.c:2648
0xc59e85 procfs_target::wait(ptid_t, target_waitstatus*, enum_flags<target_wait_flag>)
/root/binutils-gdb/gdb/procfs.c:2187
0xcf6da7 sol_thread_target::wait(ptid_t, target_waitstatus*, enum_flags<target_wait_flag>)
/root/binutils-gdb/gdb/sol-thread.c:442
0xd73711 target_wait(ptid_t, target_waitstatus*, enum_flags<target_wait_flag>)
/root/binutils-gdb/gdb/target.c:2586
...
The problem is that the procfs backend, while inside target_wait,
called target_resume without switching to the leader thread of that
resumption.
The target_resume interface is:
/* Resume execution (or prepare for execution) of the current thread
(INFERIOR_PTID), while optionally letting other threads of the
current process or all processes run free.
...
Thus calling target_resume with inferior_ptid == null_ptid is bogus.
target_wait (which leads to procfs_target::wait on Solaris) is called
with inferior_ptid == null_ptid on entry exactly to help catch such
bogus uses.
From the backtrace, it seems that the relevant line in question is
procfs.c:2187:
2186 /* How to keep going without returning to wfi: */
2187 target_continue_no_signal (ptid);
2188 goto wait_again;
target_continue_no_signal is a small wrapper around target_resume,
which would make sense.
The fix is to not call target_resume or go via the target stack at
all. Instead, factor out a new proc_resume function out of
procfs_target::resume, and call that. The new function does not rely
on inferior_ptid.
I've not been able to test it myself, but Petr confirmed it fixes the
assertion failure with his test case, and Marcel Telka also confirmed
it solves the problem.
Tested-By: Petr Šumbera <petr.sumbera@oracle.com>
Tested-By: Marcel Telka <marcel@telka.sk>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30252
Change-Id: I6213c59b081d400a22e799ee621c2eff6dcafbf3
On MIPS, for PIC objects, symbols may reference 2 times:
once from the caller, and once from GOT.
Thus ld may complains 2 times about "undefined reference".
So we add a new "#?" line to every effected testsuite.
We should be using run_host_cmd everywhere we invoke a compiler in the
ld testsuite, if we want to use ld/ld-new just built. run_host_cmd
properly inserts $gcc_B_opt in cases where a user wants to test
binutils with a newly built compiler, ie. when $CC specifies -B itself.
Also, it is not good practice to exclude tests when non-native except
of course those tests that run a target binary. Compiling and linking
often shows up problems.
* testsuite/ld-elf/no-section-header.exp (binutils_run_test):
Use run_host_cmd to invoke $CC_FOR_TARGET. Run all tests
non-native too, except for attempting to run the binaries.
Run tests for ELF in general, not just linux.
* testsuite/ld-elf/pr25617-1-no-sec-hdr.rd: Allow localentry
symbol decoration, and support either sorting of symbols.
* testsuite/ld-elf/pr25617-1a-no-sec-hdr.rd: Likewise.
* testsuite/ld-elf/pr25617-1a-sec-hdr.rd: Likewise.
* testsuite/ld-elf/pr25617-1a-no-sec-hdr.nd: Accept D function syms.
* testsuite/ld-elf/start-shared-noheader-sysv.rd: Accept
mips-sgi-irix symbol output.
* testsuite/ld-elf/start-shared-noheader.nd: Likewise.
Catch "exec $CC_FOR_TARGET" won't use the gas/ld that we just build,
and in fact run_host_cmd_yesno is a better choice for it.
ld/ChangeLog:
* testsuite/ld-elf/indirect.exp: use run_host_cmd_yesno
instead of handwrite catch exec $CC_FOR_TARGET.
Currently, the var run_tests is defined by syntax {{}},
while in this case, variables cannot be used.
Thus $NOPIE_CFLAGS and $NOPIE_LDFLAGS are passed to cmd as names
instead of values:
gcc ... $NOPIE_CFLAGS -c .../indirect5a.c -o tmpdir/indirect5a.o
Let's use [list [list ]] syntax instead.
ld/ChangeLog:
* testsuite/ld-elf/indirect.exp(run_tests): use [list [list]]
syntax instead of {{}}.
Masking is not permitted for certain further insns, not falling in any
of the earlier categories. Introduce the Y macro (not expanding to any
output) to flag such cases.
Note that in a few cases entries already covered otherwise are converted
as well, to continue to allow sharing of the string literals.
Masking is not permitted in this case. See the code comment for how this
is being dealt with.
To avoid excess special casing of modes, have OP_M() call OP_E_memory()
directly.
While only zeroing-masking is possible in this case, this still requires
EVEX.z to be clear. Introduce a "global" flag right here, to be re-used
by checks which need to live in specific operand handlers.
Rather than corrupting disassmbly altogether, flag EVEX.z set as bad
when masking isn't in effect in the first place at the time the
destination operand is actually processed.
