Before commit 3b6acaee89 "Update more calls to add_prefix_cmd" we had the
following output for "show logging file":
...
$ gdb -q -batch -ex "set trace-commands on" \
-ex "set logging off" \
-ex "show logging file" \
-ex "set logging on" \
-ex "show logging file"
+set logging off
+show logging file
Future logs will be written to gdb.txt.
+set logging on
+show logging file
Currently logging to "gdb.txt".
...
After that commit we have instead:
...
+set logging off
+show logging file
The current logfile is "gdb.txt".
+set logging on
+show logging file
The current logfile is "gdb.txt".
...
Before the commit, whether logging is enabled or not can be deduced from the
output of the command. After the commit, the message is unified and it's no
longer clear whether logging is enabled or not.
Fix this by:
- adding a new command "show logging enabled"
- adding a corresponding new command "set logging enabled on/off"
- making the commands "set logging on/off" deprecated aliases of the
"set logging enabled on/off" command.
Update the docs and testsuite to use "set logging enabled". Mention the new
and deprecated commands in NEWS.
Tested on x86_64-linux.
Currently we have:
...
$ gdb -q -batch -ex "help set logging overwrite"
Set whether logging overwrites or appends to the log file.
If set, logging overrides the log file.
...
Fix overrides -> overwrites typo.
When implementing this command, I put "help doc" as a placeholder for
the help string, and forgot to update it. Change it for a real help
string.
Change-Id: Id23c2142c5073dc570bd8a706e9ec6fa8c40eb09
This reverts (par of) commit ab19827912.
This commit changed what the test expects when catching the execve
syscall based on the behavior seen on a Linux PowerPC machine. That is,
we get an "entry" event, but no "return" event. This is not what we get
on Linux with other architectures, though, and it seems like a
PowerPC-specific bug.
Revert the part of the patch related to this, but not the other hunk.
Change-Id: I4248776e4299f10999487be96d4acd1b33639996
In commit:
commit 633cf2548b
Date: Wed May 9 15:42:28 2018 -0600
Remove cleanups from mdebugread.c
the following change was made in the function parse_partial_symbols in
mdebugread.c:
- fdr_to_pst = XCNEWVEC (struct pst_map, hdr->ifdMax + 1);
- old_chain = make_cleanup (xfree, fdr_to_pst);
+ gdb::def_vector<struct pst_map> fdr_to_pst_holder (hdr->ifdMax + 1);
+ fdr_to_pst = fdr_to_pst_holder.data ();
The problem with this change is that XCNEWVEC calls xcalloc, which in
turn calls calloc, and calloc zero initializes the allocated memory.
In contrast, the new line gdb::def_vector<struct pst_map> specifically
does not initialize the underlying memory.
This is a problem because, later on in this same function, we
increment the n_globals field within 'struct pst_map' objects stored
in the vector. The incrementing is now being done from an
uninitialized starting point.
In this commit we switch from using gdb::def_vector to using
std::vector, this alone should be enough to ensure that the fields are
initialized to zero.
However, for extra clarity, I have also added initial values in the
'struct pst_map' to make it crystal clear how the struct will start
up.
This issue was reported on the mailing list here:
https://sourceware.org/pipermail/gdb-patches/2021-November/183693.html
Co-Authored-By: Lightning <lightningth@gmail.com>
When readline development package is missing make fails with
"configure: error: system readline is not new enough" which
might be confusing. This patch checks for the readline.h explicitly
and makes make to warn about the missing package.
Some time ago add_info_alias was changed (commit
e0f25bd971). These calls were not updated
and caused errors on compilation.
Change-Id: I354ae4e8b8926d785abc94ec7142471ffd76d2de
While working on target_waitstatus changes, I noticed a few places where
const target_waitstatus objects could be passed by reference instead of
by pointers. And in some cases, places where a target_waitstatus could
be passed as const, but was not. Convert them as much as possible.
Change-Id: Ied552d464be5d5b87489913b95f9720a5ad50c5a
I would like to print target_waitkind values in debug messages, so I
think that a target_waitkind-to-string function would be useful. While
at it, use it in target_waitstatus::to_string. This changes the output
of target_waitstatus::to_string a bit, but I think it is for the better.
The debug messages will show a string matching exactly the
target_waitkind enumerator (minus the TARGET_WAITKIND prefix).
As a convenience, make string_appendf return the same reference to
string it got as a parameter. This allows doing this:
return string_appendf (str, "foo");
... keeping the code concise.
Change-Id: I383dffc9c78614e7d0668b1516073905e798eef7
Make target_waitstatus_to_string a "to_string" method of
target_waitstatus, a bit like we have ptid_t::to_string already. This
will save a bit of typing.
Change-Id: Id261b7a09fa9fa3c738abac131c191a6f9c13905
A build error on x86_64 with x32 abi was reported here (
https://sourceware.org/pipermail/gdb/2021-November/049787.html ):
...
gdb/nat/amd64-linux-siginfo.c:280:42: error: \
'struct compat_x32_siginfo_t::<unnamed union>::<unnamed>' has no member \
named 'si_addr_bnd'
280 | #define cpt_si_lower _sifields._sigfault.si_addr_bnd._lower
| ^~~~~~~~~~~
gdb/nat/amd64-linux-siginfo.c:337:38: note: in expansion of macro 'cpt_si_lower'
337 | to->cpt_si_lower = from_ptrace.cpt_si_lower;
| ^~~~~~~~~~~~
...
The problem is that code added in commit d3d7d1ba3b "[gdb/tdep] Handle
si_addr_bnd in compat_siginfo_from_siginfo" doesn't compile on an x86_64 x32
setup, because compat_x32_siginfo_t doesn't have the si_addr_bnd fields.
Fix this conservatively by disabling the code for x32.
Tested on x86_64-linux.
I noticed a new gcc option -gdwarf64 and tried it out (using gcc 11.2.1).
With a test-case hello.c:
...
int
main (void)
{
printf ("hello\n");
return 0;
}
...
compiled like this:
...
$ gcc -g -gdwarf64 ~/hello.c
...
I ran into:
...
$ gdb -q -batch a.out
DW_FORM_line_strp pointing outside of .debug_line_str section \
[in module a.out]
...
Debugging gdb revealed that the string offset is:
...
(gdb) up
objfile=0x182ab70, str_offset=1378684502312,
form_name=0xeae9b5 "DW_FORM_line_strp")
at src/gdb/dwarf2/section.c:208
208 error (_("%s pointing outside of %s section [in module %s]"),
(gdb) p /x str_offset
$1 = 0x14100000128
(gdb)
...
which is read when parsing a .debug_line entry at 0x1e0.
Looking with readelf at the 0x1e0 entry, we have:
...
The Directory Table (offset 0x202, lines 2, columns 1):
Entry Name
0 (indirect line string, offset: 0x128): /data/gdb_versions/devel
1 (indirect line string, offset: 0x141): /home/vries
...
which in a hexdump looks like:
...
0x00000200 1f022801 00004101 00000201 1f020f02
...
What happens is the following:
- readelf interprets the DW_FORM_line_strp reference to .debug_line_str as
a 4 byte value, and sees entries 0x00000128 and 0x00000141.
- gdb instead interprets it as an 8 byte value, and sees as first entry
0x0000014100000128, which is too big so it bails out.
AFAIU, gdb is wrong. It assumes DW_FORM_line_strp is 8 bytes on the basis
that the corresponding CU is 64-bit DWARF. However, the .debug_line
contribution has it's own initial_length field, and encodes there that it's
32-bit DWARF.
Fix this by using the correct offset size for DW_FORM_line_strp references
in .debug_line.
Note: the described test-case does trigger this complaint (both with and
without this patch):
...
$ gdb -q -batch -iex "set complaints 10" a.out
During symbol reading: intermixed 32-bit and 64-bit DWARF sections
...
The reason that the CU has 64-bit dwarf is because -gdwarf64 was passed to
gcc. The reason that the .debug_line entry has 32-bit dwarf is because that's
what gas generates. Perhaps this is complaint-worthy, but I don't think it
is wrong.
Tested on x86_64-linux, using native and target board dwarf64.exp.
The v5 section version for .debug_line has:
- two new fields address_size and segment_selector_size
- a different way to encode the directory and filename tables.
Add support for this in the dwarf assembler.
For now, make the v5 directory and filename tables work with the v4 type of
specification in the test-cases by adding duplicate entries at position 0.
This will need to be properly fixed with an intrusive fix that changes how
directory and filename entries are specified in the test-cases, f.i:
...
set diridx [include_dir "${srcdir}/${subdir}"]
set fileidx [file_name "$srcfile" $diridx]
...
Tested on x86_64-linux.
Rather than generate dwarf immediately in procs include_dir and file_name,
postpone generation and store the data in variables. Then handle the
generation in a new proc _line_finalize_header.
Tested on x86-64-linux.
The .debug_line header got a new field in v4:
maximum_operations_per_instruction.
Generate this field in the dwarf assembler, for now hardcoding the value to 1,
meaning non-VLIW.
Tested on x86_64-linux.
Currently, for each MACRO_AT_range or MACRO_AT_func in dwarf assembly the
following is done:
- $srcdir/$subdir/$srcfile is compiled to an executable using
flags "debug"
- a new gdb instance is started
- the new executable is loaded.
This is inefficient, because the executable is identical within the same
Dwarf::assemble call.
Share the gdb instance in the same Dwarf::assemble invocation, which speeds
up a make check with RUNTESTFLAGS like this to catch all dwarf assembly
test-cases:
...
rtf=$(echo $(cd src/gdb/testsuite; find gdb.* -type f -name "*.exp" \
| xargs grep -l Dwarf::assemble))
...
from:
...
real 1m39.916s
user 1m25.668s
sys 0m21.377s
...
to:
...
real 1m29.512s
user 1m17.316s
sys 0m19.100s
...
Tested on x86_64-linux.
When running the testsuite I have the following:
Running .../gdb/testsuite/gdb.base/catch-signal.exp ...
DUPLICATE: gdb.base/catch-signal.exp: SIGHUP: continue
DUPLICATE: gdb.base/catch-signal.exp: SIGHUP: continue
DUPLICATE: gdb.base/catch-signal.exp: 1: continue
DUPLICATE: gdb.base/catch-signal.exp: 1: continue
DUPLICATE: gdb.base/catch-signal.exp: SIGHUP SIGUSR2: continue
DUPLICATE: gdb.base/catch-signal.exp: SIGHUP SIGUSR2: continue
This patch removes DUPLICATE in gdb.base/catch-signal.exp by explicitly
giving names to the offending 'gdb_test "continue"' statements to make
them distinct.
Tested on x86_64-linux.
When building gdb with g++ 4.8.5, I ran into:
...
ld: source-cache.o: in function `source_cache::ensure(symtab*)':
source-cache.c:207: undefined reference to \
srchilite::SourceHighlight::SourceHighlight(std::string const&)
...
[ I configured gdb without explicit settings related to source-highlight, so
we're excercising the enable_source_highlight=auto scenario. ]
The problem is that:
- the source-highlight library is build with system compiler
g++ 7.5.0 which uses the new libstdc++ library abi (see
https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html )
- gdb is build using g++ 4.8.5 which uses the old abi.
[ There's a compatibility macro _GLIBCXX_USE_CXX11_ABI, but that doesn't work
for this case. Instead, it enables the opposite case where the
source-highlight library is build with g++ 4.8.5 and gdb is build with
g++ 7.5.0. ]
Fix this by checking whether the source-highlight library is usable during
configuration.
In the enable_source_highlight=auto scenario, this allows the build to skip
the unusable library and finish successfully.
In the enable_source_highlight=yes scenario, this allows the build to error
out earlier.
Tested on x86_64-linux.
On OBS I ran into:
...
PASS: gdb.mi/mi-var-cp.exp: run to mi-var-cp.cc:81 (set breakpoint)
UNRESOLVED: gdb.mi/mi-var-cp.exp: unable to start target
...
followed by 81 FAILs and two more UNRESOLVEDs.
I didn't manage to reproduce this, but I did notice that the initial
problem causing the UNRESOLVED caused all subsequent UNRESOLVEDs and FAILs.
I emulated the problem by commenting out the send_gdb "run\n" in
mi_run_cmd_full.
Fix this by:
- handling mi_run_cmd failure in mi_get_inline_test
- handling mi_run_inline_test failure in gdb.mi/mi-var-cp.exp, and
other test-cases using mi_get_inline_test
Tested on x86_64-linux.
When running test-case gdb.dwarf2/loc-sec-offset.exp with target board -m32,
I run into:
...
builtin_spawn -ignore SIGHUP gcc -fno-stack-protector -m32 \
-fdiagnostics-color=never -c -o loc-sec-offset-dw641.o \
loc-sec-offset-dw64.S^M
as: loc-sec-offset-dw641.o: unsupported relocation type: 0x1^M
loc-sec-offset-dw64.S: Assembler messages:^M
loc-sec-offset-dw64.S:29: Error: cannot represent relocation type \
BFD_RELOC_64^M
...
Looking at line 29, we have:
...
.8byte .Labbrev1_begin /* Abbrevs */
...
It would be nice if the assembler could handle this somehow. But I guess
it's not unreasonable that an assembler for a 32-bit architecture will object
to handling 64-bit labels.
Instead, work around this in the dwarf assembler by emitting:
...
.4byte .Labbrev1_begin /* Abbrevs (lsw) */
.4byte 0 /* Abbrevs (msw) */
...
Tested on x86_64-linux with target board unix/-m32.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28383
On OBS I ran into a failure in test-case gdb.threads/thread-specific-bp.exp:
...
(gdb) PASS: gdb.threads/thread-specific-bp.exp: non-stop: continue to end
info breakpoint^M
Num Type Disp Enb Address What^M
1 breakpoint keep y 0x0000555555555167 in main at $src:36^M
breakpoint already hit 1 time^M
2 breakpoint keep y 0x0000555555555151 in start at $src:23^M
breakpoint already hit 1 time^M
3 breakpoint keep y 0x0000555555555167 in main at $src:36 thread 2^M
stop only in thread 2^M
4 breakpoint keep y 0x000055555555515c in end at $src:29^M
breakpoint already hit 1 time^M
(gdb) [Thread 0x7ffff7db1640 (LWP 19984) exited]^M
Thread-specific breakpoint 3 deleted - thread 2 no longer in the thread list.^M
FAIL: gdb.threads/thread-specific-bp.exp: non-stop: \
thread-specific breakpoint was deleted (timeout)
...
Fix this by waiting for the "[Thread 0x7ffff7db1640 (LWP 19984) exited]"
message before issuing the "info breakpoint command".
Tested on x86_64-linux.
This commit supplements whatis and ptype command tests for print of
const-volatile qualifiers.
gdb/testsuite/ChangeLog:
2021-11-16 Christina Schimpe <christina.schimpe@intel.com>
* gdb.cp/ptype-cv-cp.cc: New const and volatile typedef
variables.
* gdb.cp/ptype-cv-cp.exp: Add new tests.
Make ptype print const/volatile qualifiers when template or typedef
attributes are substituted.
For a programm like
~~~
template<typename DataT>
class Cfoo
{
typedef float myfloat;
public:
DataT me0;
const DataT me1=1;
const myfloat me2=2.0;
};
int main()
{
Cfoo<int> cfoo;
return 0;
}
~~~
gdb outputs the following type for cfoo's attributes:
~~~
(gdb) b 14
Breakpoint 1 at 0x1170: file tmp.cc, line 14.
(gdb) run
Starting program: /tmp
Breakpoint 1, main () at tmp.cc:14
14 return 0;
(gdb) ptype cfoo
type = class Cfoo<int> [with DataT = int] {
public:
DataT me0;
DataT me1;
myfloat me2;
private:
typedef float myfloat;
}
~~~
The cv qualifiers (const in this case) are ignored for me1 and me2.
After:
~~~
(gdb) ptype cfoo
type = class Cfoo<int> [with DataT = int] {
public:
DataT me0;
const DataT me1;
const myfloat me2;
private:
typedef float myfloat;
}
~~~
gdb/ChangeLog:
2021-11-16 Christina Schimpe <christina.schimpe@intel.com>
* gdb/c-typeprint.c: Print cv qualifiers in case of parameter
substitution.
gdb/testsuite/ChangeLog:
2021-11-16 Christina Schimpe <christina.schimpe@intel.com>
* gdb.cp/templates.cc: New template class Cfoo with const,
template, typdef and integer attributes.
* gdb.cp/templates.exp: Add new test using ptype and ptype/r
commmands for template class CFoo.
Without this commit, doing...
make check RUNTESTFLAGS="--target_board=native-extended-gdbserver" \
TESTS="gdb.base/dprintf-execution-x-script.exp"
...will show one failure.
Here's a snippet from gdb.log showing the circumstances - I've trimmed
the paths for readability:
builtin_spawn gdb -nw -nx -data-directory data-directory -iex set height 0 -iex set width 0 -iex set auto-connect-native-target off -iex set sysroot -ex set height unlimited -x testsuite/gdb.base/dprintf-execution-x-script.gdb --args testsuite/outputs/gdb.base/dprintf-execution-x-script/dprintf-execution-x-script
...
Reading symbols from testsuite/outputs/gdb.base/dprintf-execution-x-script/dprintf-execution-x-script...
Dprintf 1 at 0x40116e: file testsuite/gdb.base/dprintf-execution-x-script.c, line 38.
Breakpoint 2 at 0x40113a: file testsuite/gdb.base/dprintf-execution-x-script.c, line 26.
testsuite/gdb.base/dprintf-execution-x-script.gdb:21: Error in sourced command file:
Don't know how to run. Try "help target".
(gdb) FAIL: gdb.base/dprintf-execution-x-script.exp: load and run script with -x
...
GNU gdb (GDB) 12.0.50.20211118-git
Copyright (C) 2021 Free Software Foundation, Inc.
...
(gdb) set height 0
(gdb) set width 0
(gdb) builtin_spawn gdbserver/gdbserver --once --multi localhost:2346
Listening on port 2346
target extended-remote localhost:2346
Remote debugging using localhost:2346
...
[Tests after this point will pass.]
Note that the command which spawns gdb prevents the gdb script from
using the native target via "-iex set auto-connect-native-target off".
Moreover, the script in question contains a "run" command, so GDB
doesn't know how to run (since it's prevented from using the native
target and no alternate "target" command has been issued. But, once
GDB finishes starting up, the test will spawn a gdbserver and then
connect to it. The other (two) tests after this point both pass.
I've fixed this by using gdb_test_multiple instead of gdb_test.
When a "Don't know how to run message" is received, the test is
unsupported.
I've also added a comment explaining the reason for needing to check
for "Don't know how to run" despite bailing out at the top of the test
via:
if ![target_can_use_run_cmd] {
return 0
}
When building with g++ 4.8, I get:
CXX unittests/array-view-selftests.o
/home/smarchi/src/binutils-gdb/gdb/unittests/array-view-selftests.c:123:42: error: expected 'class' before 'Container'
template<template<typename ...> typename Container>
^
I am no C++ template expert, but it looks like if I change "typename" for
"class", as the compiler kind of suggests, the code compiles.
Change-Id: I9c3edd29fb2b190069f0ce0dbf3bc3604d175f48
When building with g++ 4.8, I get:
CXX ia64-tdep.o
/home/smarchi/src/binutils-gdb/gdb/ia64-tdep.c:3862:1: error: could not convert '{ia64_allocate_new_rse_frame, ia64_store_argument_in_slot, ia64_set_function_addr}' from '<brace
-enclosed initializer list>' to 'const ia64_infcall_ops'
};
^
This happens since commit 345bd07cce ("gdb: fix gdbarch_tdep ODR
violation"), which added default values for ia64_infcall_ops fields. It
looks like g++ 4.8 doesn't like initializing the ia64_infcall_ops object
using the brace-enclosed initializer list when the ia64_infcall_ops
fields are assigned default values.
Later compilers don't have a problem with that, so I suppose that the
code is correct, but still, change it to make gcc 4.8 happy. Don't
initialize the fields of ia64_infcall_ops directly, instead
default-initialize ia64_gdbarch_tdep::infcall_ops.
Change-Id: I35e3a61abd7b7bbcafe6cb207078c738c5266d76
The contents of rs6000-tdep.h (AIX_TEXT_SEGMENT_BASE) is AIX-specific,
so I thought that this file should be named rs6000-aix-tdep.h. But
there's already a rs6000-aix-tdep.h, so then I though
AIX_TEXT_SEGMENT_BASE should simply be moved there, and rs6000-tdep.h
deleted. But then I realized that AIX_TEXT_SEGMENT_BASE is only used in
rs6000-aix-tdep.c, so move it to the beginning of that file.
Change-Id: Ia212c6fae202f31aedb46575821cd642beeda7a3
This file seems to be AIX-specific, according to its contents and
configure.nat. Rename it to rs6000-aix-nat.c, to make that clear (and
to follow the convention).
Change-Id: Ib418dddc6b79b2e28f64431121742b5e87f5f4f5
The documentation for the examining memory command x contains an example:
...
You can also specify a negative repeat count to examine memory backward from
the given address. For example, 'x/-3uh 0x54320' prints three halfwords (h)
at 0x54314, 0x54328, and 0x5431c.
...
The 0x54328 looks like a typo, which was intended to be 0x54318.
But the series uses a 4-byte distance, while the halfword size used in the
command means a 2-byte distance, so the series should be:
...
0x5431a, 0x5431c, and 0x5431e.
...
Fix this by updating the addresses in the example accordingly.
Reported here ( https://sourceware.org/pipermail/gdb/2021-November/049784.html
).
Commit 345bd07cce ("gdb: fix gdbarch_tdep ODR violation") made a bunch
of files define a *_gdbarch_tdep class that inherits from a gdbarch_tdep
base. But some of these files don't include gdbarch.h, where
gdbarch_tdep is defined. This may cause build errors if gdbarch.h isn't
already included by chance by some other header file. Avoid this by
making them include gdbarch.h.
Change-Id: If433d302007e274daa4f656cfc94f769cf1aa68a
Change gdb_assert_not_reached to accept a format string plus
corresponding arguments. This allows giving more precise messages.
Because the format string passed by the caller is prepended with a "%s:"
to add the function name, the callers can no longer pass a translated
string (`_(...)`). Make the gdb_assert_not_reached include the _(),
just like the gdb_assert_fail macro just above.
Change-Id: Id0cfda5a57979df6cdaacaba0d55dd91ae9efee7
Remove check_continue "execve" from Proc test_catch_syscall_execve.
The check_continue proceedure checs that the command, execve, starts and
checks for the return from the command. The execve command starts a new
program and thus the return from the command causing the test to fail.
The call to proc check_continue "execve" is removed and replaced with
just the call to check_call_to_syscall "execve" to verify the command
executed. The next test in proc test_catch_syscall_execve verifies that
the new program started and hit the break point in main.
Update the check for the PowerPC architecture. Power Little Endian systems
include "le" in the name. The istarget "power64-*-linux*" check fails to
match LE sytems. The expected string is updated to capture both Big Endian
and Little Endian systems. Power 10 LE istarget prints as:
powerpc64le-unknown-linux-gnu.
This patch fixes three failures and the error:
ERROR: can't read "arch1": no such variable
Patch tested on Power 10 ppc64le GNU/Linux platform.
This patch fixes eight test failures on PowerPC for the test
gdb.base/break-interp.exp. The patch adds a funtion and registers it to
setup the displaced stepping for ppc-linux platform. The patch moves the
struct ppc_inferior_data to the ppc-tdep.h include file to make it visible
to the ppc-linux-tdep.c and rs6000-tdep.c files. Additionally the function
get_ppc_per_inferior is made external in ppc-tdep.h to make it visible in
both files.
Tested on Power 10 ppc64le-linux with no regressions.
The test complains of duplicate tests.
DUPLICATE: gdb.arch/ppc-longdouble.exp: continue to breakpoint: return
The do_test calls gdb_continue_to_breakpoint "return". The duplicates
are the result of calling do_test three times with different arguments.
This patch fixes the duplicate tests by adding $name to the
gdb_continue_to_breakpoint argument.
Patch tested on Power 10 ppc64le GNU/Linux, no duplicate tests reported,
no new regression errors.
On OBS I ran into:
...
(gdb) shell diff -s outputs/gdb.base/signals-state-child/standalone.txt \
outputs/gdb.base/signals-state-child/gdb.txt^M
diff: outputs/gdb.base/signals-state-child/standalone.txt: \
No such file or directory^M
(gdb) FAIL: gdb.base/signals-state-child.exp: signals states are identical
...
I managed to reproduce this by adding "sleep (5)" at the start of main in
signals-state-child.c.
Fix this by waiting on the result of the spawned command.
Tested on x86_64-linux.
Commit 345bd07cce ("gdb: fix gdbarch_tdep ODR violation") changes a
declaration in s390-tdep.h from
struct gdbarch_tdep { ... };
to
struct s390_gdbarch_tdep : gdbarch_tdep { ... };
and now requires that gdbarch_tdep has been declared before. Which is
usually the case, except when compiling s390-linux-nat.c, where
s390-tdep.h is included before gdbarch.h. Thus the s390x build errors out
with the compiler complaining about a missing class name after the colon.
Fix this in s390-linux-nat.c, by including gdbarch.h before s390-tdep.h.
Augment the register description XML to expose the BTI BTYPE field contained
in the CPSR register. It will be displayed like so:
cpsr 0x60001000 [ EL=0 BTYPE=0 SSBS C Z ]
On gcc-12 build fails as:
../../gdbserver/../gdb/nat/linux-osdata.c: In function 'void linux_xfer_osdata_processes(buffer*)':
../../gdbserver/../gdb/nat/linux-osdata.c:330:39: error:
'__builtin___sprintf_chk' may write a terminating nul past the end of the destination [-Werror=format-overflow=]
330 | sprintf (core_str, "%d", i);
| ^
It's an off-by-one case in an infeasible scenario for negative
huge core count. The change switches to std::string for memory
handling.
Tested by running 'info os processes' and checking CPU cores column.
Add aliases read_core_file_mappings_loop_ftype and
read_core_file_mappings_pre_loop_ftype. Intended for use with
read_core_file_mappings.
Also add build_id parameter to read_core_file_mappings_loop_ftype.
In commit 50888e42dc ("gdb: change functions returning value contents
to use gdb::array_view"), I believe I made a mistake with the length of
the array views returned by some functions. All functions return a view
of `TYPE_LENGTH (value_type (type))` length. This is not correct when
the value's enclosing type is larger than the value's type. In that
case, the value's contents buffer is of the size of the enclosing type,
and the value's actual contents is a slice of that (as returned by
value_contents). So, functions value_contents_all_raw,
value_contents_for_printing and value_contents_for_printing_const are
not correct. Since they are meant to return the value's contents buffer
as a whole, they should have the size of the enclosing type.
There is nothing that uses the returned array view size at the moment,
so this didn't cause a problem. But it became apparent when trying to
adjust some callers.
Change-Id: Ib4e8837e1069111d2b2784d3253d5f3002419e68
__func__ is standard C++11:
https://en.cppreference.com/w/cpp/language/function
Also, in C++11, __func__ expands to the demangled function name, so the
mention in the comment above FUNCTION_NAME doesn't apply anymore.
Finally, in places where FUNCTION_NAME is used, I think it's enough to
print the function name, no need to print the whole signature.
Therefore, I propose to just remove FUNCTION_NAME and update users to
use the standard __func__.
Change-Id: I778f28155422b044402442dc18d42d0cded1017d
The motivation is to reduce the number of places where unmanaged
pointers are returned from allocation type routines. All of the
callers are updated.
There should be no user visible changes after this commit.
While reviewing this patch:
https://sourceware.org/pipermail/gdb-patches/2021-November/183227.html
I spotted that the patch could be improved if we threw
OPTIMIZED_OUT_ERROR rather than GENERIC_ERROR in a few places.
This commit updates error_value_optimized_out and
require_not_optimized_out to throw OPTIMIZED_OUT_ERROR.
I ran the testsuite and saw no regressions. This doesn't really
surprise me, we don't usually write code like:
catch (const gdb_exception_error &ex)
{
(if ex.error == GENERIC_ERROR)
...
else
...
}
There are a three places where we write something like:
catch (const gdb_exception_error &ex)
{
(if ex.error == OPTIMIZED_OUT_ERROR)
...
}
In frame.c:unwind_pc, stack.c:info_frame_command_core, and
value.c:value_optimized_out, but if we are hitting these cases then
it's not significantly changing GDB's behaviour.
Test-case gdb.base/foll-vfork.exp has inferior output that is not needed, but
which makes the regexp matching more difficult (see commit 1f28b70def
"[gdb/testsuite] Fix regexp in gdb.base/foll-vfork.exp").
Remove the inferior output, and revert commit 1f28b70def to make the matching
more restrictive.
Tested on x86_64-linux.
As discussed here [1], do some re-work in the "set debuginfod commands".
First, use "set debuginfod enabled on/off/ask" instead of "set
debuginfod on/off/ask". This is more MI-friendly, and it gives an
output that makes more sense in "info set", for example.
Then, make the show commands not call "error" when debuginfod support is
not compiled in. This makes the commands "show" and "show debuginfod"
stop early, breaking gdb.base/default.exp:
Running /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.base/default.exp ...
FAIL: gdb.base/default.exp: info set
FAIL: gdb.base/default.exp: show
- Make the "debuginfod enabled" setting default to "off" when debuginfod
support is not compiled in, and "ask" otherwise.
- Make the setter of "debuginfod enabled" error out when debuginfod
support is not compiled in, so that "debuginfod enabled" will always
remain "off" in that case.
- Make the setter of "debuginfod verbose" work in any case. I don't
see the harm in letting the user change that setting, since the user will
hit an error if they try to enable the use of debuginfod.
- I would do the same for the "debuginfod urls" setter, but because
this one needs to see the DEBUGINFOD_URLS_ENV_VAR macro, provided by
libdebuginfod, I made that one error out as well if debuginfod
support is not compiled it (otherwise, I would have left it like
"debuginfod verbose". Alternatively, we could hard-code
"DEBUGINFOD_URLS" in the code (in fact, it was prior to this patch,
but I think it was an oversight, as other spots use
DEBUGINFOD_URLS_ENV_VAR), or use a dummy string to store the setting,
but I don't really see the value in that.
Rename debuginfod_enable to debuginfod_enabled, just so it matches the
setting name.
[1] https://sourceware.org/pipermail/gdb-patches/2021-October/182937.html
Change-Id: I45fdb2993f668226a5639228951362b7800f09d5
Co-Authored-By: Aaron Merey <amerey@redhat.com>
Commit 345bd07cce ("gdb: fix gdbarch_tdep ODR violation") forgot to
update the gdbarch_tdep calls in the native files other than x86-64
Linux. This patch updates them all (to the best of my knowledge).
These are the files I was able to build-test:
aarch64-linux-nat.c
amd64-bsd-nat.c
arm-linux-nat.c
ppc-linux-nat.c
windows-nat.c
xtensa-linux-nat.c
And these are the ones I could not build-test:
aix-thread.c
arm-netbsd-nat.c
ppc-fbsd-nat.c
ppc-netbsd-nat.c
ia64-tdep.c (the part that needs libunwind)
ppc-obsd-nat.c
rs6000-nat.c
If there are still some build problems related to gdbarch_tdep in them,
they should be pretty obvious to fix.
Change-Id: Iaa3d791a850e4432973757598e634e3da6061428
While build-testing this file, the compiler complained about these two
unused variables, remove them.
Change-Id: I3c54f779f12c16ef6184af58aca75eaad042ce4e
