| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This is another fuzzer bug, gdb/23567. This time, the fuzzer has
specifically altered the size of .debug_str:
$ eu-readelf -S objdump
Section Headers:
[Nr] Name Type Addr Off Size ES Flags Lk Inf Al
[31] .debug_str PROGBITS 0000000000000000 0057116d ffffffffffffffff 1 MS 0 0 1
When this file is loaded into GDB, the DWARF reader crashes attempting
to access the string table (or it may just store a bunch of nonsense):
[gdb-8.3-6-fc30]
$ gdb -nx -q objdump
BFD: warning: /path/to/objdump has a corrupt section with a size (ffffffffffffffff) larger than the file size
Reading symbols from /path/to/objdump...
Segmentation fault (core dumped)
Nick has already committed a BFD patch to issue the warning seen above.
[gdb master 6acc1a0b]
$ gdb -BFD: warning: /path/to/objdump has a corrupt section with a size (ffffffffffffffff) larger than the file size
Reading symbols from /path/to/objdump...
(gdb) inf func
All defined functions:
File ./../include/dwarf2.def:
186: const
8 *>(.:
;'@�B);
747: const
8 *�(.:
;'@�B);
701: const
8 *�D �
(.:
;'@�B);
71: const
8 *(.:
;'@�B);
/* and more gibberish */
Consider read_indirect_string_at_offset_from:
static const char *
read_indirect_string_at_offset_from (struct objfile *objfile,
bfd *abfd, LONGEST str_offset,
struct dwarf2_section_info *sect,
const char *form_name,
const char *sect_name)
{
dwarf2_read_section (objfile, sect);
if (sect->buffer == NULL)
error (_("%s used without %s section [in module %s]"),
form_name, sect_name, bfd_get_filename (abfd));
if (str_offset >= sect->size)
error (_("%s pointing outside of %s section [in module %s]"),
form_name, sect_name, bfd_get_filename (abfd));
gdb_assert (HOST_CHAR_BIT == 8);
if (sect->buffer[str_offset] == '\0')
return NULL;
return (const char *) (sect->buffer + str_offset);
}
With sect_size being ginormous, the code attempts to access
sect->buffer[GINORMOUS], and depending on the layout of memory,
GDB either stores a bunch of gibberish strings or crashes.
This is an attempt to mitigate this by implementing a similar approach
used by BFD. In our case, we simply reject the section with the invalid
length:
$ ./gdb -nx -q objdump
BFD: warning: /path/to/objdump has a corrupt section with a size (ffffffffffffffff) larger than the file size
Reading symbols from /path/to/objdump...
warning: Discarding section .debug_str which has a section size (ffffffffffffffff) larger than the file size [in module /path/to/objdump]
DW_FORM_strp used without .debug_str section [in module /path/to/objdump]
(No debugging symbols found in /path/to/objdump)
(gdb)
Unfortunately, I have not found a way to regression test this, since it
requires poking ELF section headers.
gdb/ChangeLog:
2019-10-16 Keith Seitz <keiths@redhat.com>
PR gdb/23567
* dwarf2read.c (dwarf2_per_objfile::locate_sections): Discard
sections whose size is greater than the file size.
Change-Id: I896ac3b4eb2207c54e8e05c16beab3051d9b4b2f
|
|
This adds initial compile command support to the RISC-V port. This fixes
about 228 testsuite failures on a riscv64-linux machine. We need to get
the triplet right which is normally riscv64 or riscv32 instead of the
default riscv. Also, we need to get the compiler options right, since we
don't accept the default -m64 and -mcmodel=large options, so we need to
construct -march and -mabi options which are correct for the target. We
currently don't have info about all extensions used by the target, so this
may need to be adjusted later. For now, I'm assuming that we have all
extensions required by the linux platform spec.
gdb/
* riscv-tdep.c (riscv_gcc_target_options): New.
(riscv_gnu_triplet_regexp): New.
(riscv_gdbarch_init): Call set_gdbarch_gcc_triplet_options and
set_gdbarch_gnu_triplet_regexp.
Change-Id: I315ce8de7789ddf7bdd3b532f917519464941294
|
|
xml-builtin.c only has character arrays and no dependencies, so this
creates a simple header file for that purpose so that gdbserver
can include that instead of re-declaring xml_builtin.
Despite the name, feature_to_c.sh is already specific to xml_builtins
(it hardcodes the variable name), so making it always output the
include for xml-builtin.h seems fine.
gdb/ChangeLog:
2019-10-16 Christian Biesinger <cbiesinger@google.com>
* Makefile.in: Add xml-builtin.h.
* features/feature_to_c.sh: Add an include for xml-builtin.h
to ensure that the compiler checks that the types match.
* xml-builtin.h: New file.
* xml-support.c (fetch_xml_builtin): Add missing const.
* xml-support.h: Remove declaration of xml_builtins.
gdb/gdbserver/ChangeLog:
2019-10-16 Christian Biesinger <cbiesinger@google.com>
* server.c: Include xml-builtin.h.
(get_xml_features): Don't declare xml_builtins here.
Change-Id: I806ef0851c43ead90b545a11794e41f5e5178436
|
|
We currently have 12 KFAILS in gdb.base/infcall-nested-structs.exp for
PR tdep/25096.
A minimal version of the failure looks like this. Consider test.c:
...
struct s { int c; struct { int a; float b; } s1; };
struct s ref = { 0, { 'a', 'b' } };
int __attribute__((noinline,noclone)) check (struct s arg)
{ return arg.s1.a == 'a' && arg.s1.b == 'b' && arg.c == 0; }
int main (void)
{ return check (ref); }
...
When calling 'check (ref)' from main, we have '1' as expected:
...
$ g++ test.c -g ; ./a.out ; echo $?
1
...
But when calling 'check (ref)' from the gdb prompt, we get '0':
...
$ gdb a.out -batch -ex start -ex "p check (ref)"
Temporary breakpoint 1 at 0x400518: file test.c, line 8.
Temporary breakpoint 1, main () at test.c:8
8 { return check (ref); }
$1 = 0
...
The layout of struct s is this:
- the field c occupies 4 bytes at offset 0,
- the s1.a field occupies 4 bytes at offset 4, and
- the s1.b field occupies 4 bytes at offset 8.
When compiling at -O2, we can see from the disassembly of main:
...
4003f0: 48 8b 3d 31 0c 20 00 mov 0x200c31(%rip),%rdi \
# 601028 <ref>
4003f7: f3 0f 10 05 31 0c 20 movss 0x200c31(%rip),%xmm0 \
# 601030 <ref+0x8>
4003fe: 00
4003ff: e9 ec 00 00 00 jmpq 4004f0 <_Z5check1s>
...
that check is called with fields c and s1.a passed in %rdi, and s1.b passed
in %xmm0.
However, the classification in theclass (a variable representing the first and
second eightbytes, to put it in SYSV X86_64 psABI terms) in
amd64_push_arguments is incorrect:
...
(gdb) p theclass
$1 = {AMD64_INTEGER, AMD64_INTEGER}
...
and therefore the struct is passed using %rdi and %rsi instead of using %rdi
and %xmm0, which explains the failure.
The reason that we're misclassifying the argument in amd64_classify_aggregate
has to do with how nested struct are handled.
Rather than using fields c and s1.a for the first eightbyte, and using field
s1.b for the second eightbyte, instead field c is used for the first
eightbyte, and fields s1.a and s1.b are classified together in an intermediate
eightbyte, which is then used to merge with both the first and second
eightbyte.
Fix this by factoring out a new function amd64_classify_aggregate_field, and
letting it recursively handle fields of nested structs.
Tested on x86_64-linux.
Tested with g++ 4.8.5, 7.4.1, 8.3.1, 9.2.1.
Tested with clang++ 5.0.2 (which requires removing additional_flags=-Wno-psabi
and adding additional_flags=-Wno-deprecated).
gdb/ChangeLog:
2019-10-16 Tom de Vries <tdevries@suse.de>
PR tdep/25096
* amd64-tdep.c (amd64_classify_aggregate_field): Factor out of ...
(amd64_classify_aggregate): ... here.
(amd64_classify_aggregate_field): Handled fiels of nested structs
recursively.
gdb/testsuite/ChangeLog:
2019-10-16 Tom de Vries <tdevries@suse.de>
PR tdep/25096
* gdb.base/infcall-nested-structs.exp: Remove PR25096 KFAILs.
Change-Id: Id55c74755f0a431ce31223acc86865718ae0c123
|
|
Atm, when executing gdb.base/infcall-nested-structs.exp on x86_64-linux, we get:
...
FAIL: gdb.base/infcall-nested-structs.exp: l=c++: types-tc-tf: \
p/d check_arg_struct_02_01 (ref_val_struct_02_01)
FAIL: gdb.base/infcall-nested-structs.exp: l=c++: types-ts-tf: \
p/d check_arg_struct_02_01 (ref_val_struct_02_01)
FAIL: gdb.base/infcall-nested-structs.exp: l=c++: types-ti-tf: \
p/d check_arg_struct_02_01 (ref_val_struct_02_01)
=== gdb Summary ===
nr of expected passes 9255
nr of unexpected failures 3
nr of expected failures 142
...
The 3 FAILs are reported as PR tdep/25096.
The 142 XFAILs are for a gdb assertion failure, reported in PR tdep/24104,
which should have been KFAILs since there's a problem in gdb rather than in
the environment.
A minimal version of the assertion failure looks like this. Consider test.c:
...
struct s { struct { } es1; long f; };
struct s ref = { {}, 'f' };
int __attribute__((noinline,noclone)) check (struct s arg)
{ return arg.f == 'f'; }
int main (void)
{ return check (ref); }
...
When calling 'check (ref)' from main, we have '1' as expected:
...
$ g++ test3.c -g && ( ./a.out; echo $? )
1
...
But when calling 'check (ref)' from the gdb prompt, we get:
...
$ gdb a.out -batch -ex start -ex "p check (ref)"
Temporary breakpoint 1 at 0x4004f7: file test.c, line 8.
Temporary breakpoint 1, main () at test.c:8
8 { return check (ref); }
src/gdb/amd64-tdep.c:982: internal-error: \
CORE_ADDR amd64_push_arguments(regcache*, int, value**, CORE_ADDR, \
function_call_return_method): \
Assertion `!"Unexpected register class."' failed.
...
The assert happens in this loop in amd64_push_arguments:
...
for (j = 0; len > 0; j++, len -= 8)
{
int regnum = -1;
int offset = 0;
switch (theclass[j])
{
case AMD64_INTEGER:
regnum = integer_regnum[integer_reg++];
break;
case AMD64_SSE:
regnum = sse_regnum[sse_reg++];
break;
case AMD64_SSEUP:
gdb_assert (sse_reg > 0);
regnum = sse_regnum[sse_reg - 1];
offset = 8;
break;
default:
gdb_assert (!"Unexpected register class.");
}
...
}
...
when processing theclass[0], which is AMD64_NO_CLASS:
...
(gdb) p theclass
$1 = {AMD64_NO_CLASS, AMD64_INTEGER}
...
The layout of struct s is that the empty field es1 occupies one byte (due to
c++) at offset 0, and the long field f occupies 8 bytes at offset 8.
When compiling at -O2, we can see from the disassembly of main:
...
4003f0: 48 8b 3d 41 0c 20 00 mov 0x200c41(%rip),%rdi \
# 601038 <ref+0x8>
4003f7: e9 e4 00 00 00 jmpq 4004e0 <_Z5check1s>
4003fc: 0f 1f 40 00 nopl 0x0(%rax)
...
that check is called with field f passed in %rdi, meaning that the
classification in theclass is correct, it's just not supported in the loop in
amd64_push_arguments mentioned above.
Fix the assert by implementing support for 'AMD64_NO_CLASS' in that loop.
This exposes 9 more FAILs of the PR tdep/25096 type, so mark all 12 of them as
KFAIL.
Tested on x86_64-linux.
Tested with g++ 4.8.5, 7.4.1, 8.3.1, 9.2.1. With 4.8.5, 3 of the 12 KFAILs
are KPASSing.
Tested with clang++ 5.0.2 (which requires removing additional_flags=-Wno-psabi
and adding additional_flags=-Wno-deprecated).
gdb/ChangeLog:
2019-10-16 Tom de Vries <tdevries@suse.de>
PR tdep/24104
* amd64-tdep.c (amd64_push_arguments): Handle AMD64_NO_CLASS in loop
that handles 'theclass'.
gdb/testsuite/ChangeLog:
2019-10-16 Tom de Vries <tdevries@suse.de>
PR tdep/24104
* gdb.base/infcall-nested-structs.exp: Remove XFAIL for PR tdep/24104.
Add KFAIL for PR tdep/25096.
Change-Id: I8b66345bbf5c00209ca75b1209fd4d60b36e9ede
|
|
With g++-4.8, I see:
...
(gdb) PASS: gdb.cp/local-static.exp: c++: print free_inline_func(void)
print 'S::method()'::S_M_s_var_int^M
No symbol "S_M_s_var_int" in specified context.^M
(gdb) FAIL: gdb.cp/local-static.exp: c++: print 'S::method()'::S_M_s_var_int
...
The variable is declared like this (showing pruned .ii):
...
void S::method ()
{
static int S_M_s_var_int = 4;
}
...
But the DWARF generated for the variable is encapsulated in an unnamed lexical
block:
...
<1><121>: Abbrev Number: 5 (DW_TAG_structure_type)
<122> DW_AT_name : S
...
<2><14f>: Abbrev Number: 6 (DW_TAG_subprogram)
...
<150> DW_AT_name : (indirect string, offset: 0x599): method
<156> DW_AT_linkage_name: (indirect string, offset: 0x517): \
_ZN1S6methodEv /* demangled: dS::method() */
...
<1><3f8>: Abbrev Number: 21 (DW_TAG_subprogram)
<3f9> DW_AT_specification: <0x14f>
...
<3fe> DW_AT_low_pc : 0x4004fc
<406> DW_AT_high_pc : 0x2c /* 0x400528 */
...
<2><418>: Abbrev Number: 17 (DW_TAG_formal_parameter)
<419> DW_AT_name : (indirect string, offset: 0x68a): this
...
<2><424>: Abbrev Number: 18 (DW_TAG_lexical_block)
<425> DW_AT_low_pc : 0x400508
<42d> DW_AT_high_pc : 0x1e /* 0x400526 */
<3><435>: Abbrev Number: 22 (DW_TAG_variable)
<436> DW_AT_name : (indirect string, offset: 0x29d): S_M_s_var_int
...
which has the effect that the variable is not addressable unless the program
counter is in the range of the lexical block.
This is caused by gcc PR debug/55541, which was fixed in gcc 5.
Mark in total 225 FAILs as XFAIL.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-10-16 Tom de Vries <tdevries@suse.de>
PR testsuite/25059
* gdb.cp/local-static.exp (do_test): Add xfails for gcc PR debug/55541.
Change-Id: Ibe86707eecffc79f1bb474d7928ea7d0c39a00a2
|
|
On openSUSE Leap 15.1 (as well as on Fedora-x86_64-m64 buildbot) I see:
...
FAIL: gdb.base/jit-reader.exp: with jit-reader: after mangling: current frame: info registers
...
The problem is that r10 is printed signed:
...
r10 0xffffffffffffffb0 -80^M
...
but the regexp expects a signed value:
...
"r10 $hex +$decimal" \
...
Fix this by allowing signed values.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-10-16 Tom de Vries <tdevries@suse.de>
* gdb.base/jit-reader.exp: Allow non-pointer registers to be printed
as signed.
Change-Id: Ie494d24fad7a9af7ac6bfaf731c4aa04f1333830
|
|
This comit:
commit 0dc327459b19e6765c8fe80957f5c8620611628e
Date: Mon Oct 7 16:38:53 2019 +0100
gdb: Remove vec.{c,h} and update code to not include vec.h
Broke the GDB build due to leaving a reference to vec-ipa.o in the
Makefile.in, this file is built from vec.c which has been removed.
I got away with this as I had an old version of the vec-ipa.o file
still in my build tree.
With this commit in place a clean build now completed successfully.
gdb/ChangeLog:
* Makefile.in: Remove references to vec-ipa.o.
Change-Id: I4cf55951158dd7ee8f60cd054311a7c367e1d7bf
|
|
With the removal of the old VEC mechanism from the code base, update
comments that still make reference to VECs. There should be no user
visible changes after this commit.
gdb/ChangeLog:
* linespec.c (decode_digits_ordinary): Update comment.
* make-target-delegates: No longer need to handle VEC case.
* memrange.c (normalize_mem_ranges): Update comment.
* namespace.c (add_using_directive): Update comment.
* objc-lang.c (uniquify_strings): Update comment.
* ppc-linux-nat.c (struct thread_points): Update comment.
* probe.h (find_probes_in_objfile): Update comment.
* target.h (enum flash_preserve_mode): Update comment.
* varobj.c (varobj_restrict_range): Update comment.
* varobj.h (varobj_list_children): Update comment.
Change-Id: Iefd2e903705c3e79cd13b43395c7a1c167f9a088
|
|
Removes vec.c and vec.h from the source tree, and remove all the
remaining includes of vec.h. There should be no user visible changes
after this commit.
I did have a few issues rebuilding GDB after applying this patch due
to cached dependencies, I found that running this command in the build
directory resolved my build issues without requiring a 'make clean':
rm -fr gdb/gdbserver/gdbsupport/.deps/
gdb/ChangeLog:
* Makefile.in: Remove references to vec.h and vec.c.
* aarch64-tdep.c: No longer include vec.h.
* ada-lang.c: Likewise.
* ada-lang.h: Likewise.
* arm-tdep.c: Likewise.
* ax.h: Likewise.
* breakpoint.h: Likewise.
* charset.c: Likewise.
* cp-support.h: Likewise.
* dtrace-probe.c: Likewise.
* dwarf2read.c: Likewise.
* extension.h: Likewise.
* gdb_bfd.c: Likewise.
* gdbsupport/gdb_vecs.h: Likewise.
* gdbsupport/vec.c: Remove.
* gdbsupport/vec.h: Remove.
* gdbthread.h: Likewise.
* guile/scm-type.c: Likewise.
* inline-frame.c: Likewise.
* machoread.c: Likewise.
* memattr.c: Likewise.
* memrange.h: Likewise.
* namespace.h: Likewise.
* nat/linux-btrace.h: Likewise.
* osdata.c: Likewise.
* parser-defs.h: Likewise.
* progspace.h: Likewise.
* python/py-type.c: Likewise.
* record-btrace.c: Likewise.
* rust-exp.y: Likewise.
* solib-target.c: Likewise.
* stap-probe.c: Likewise.
* target-descriptions.c: Likewise.
* target-memory.c: Likewise.
* target.h: Likewise.
* varobj.c: Likewise.
* varobj.h: Likewise.
* xml-support.h: Likewise.
gdb/gdbserver/ChangeLog:
* Makefile.in: Remove references to vec.c.
Change-Id: I0c91d7170bf1b5e992a387fcd9fe4f2abe343bb5
|
|
This removes a use of VEC from GDB, from dwarf2read.c. This removal
is not very clean, and would probably benefit from additional
refactoring in the future.
The problem here is that the VEC is contained within struct
dwarf2_per_cu_data, which is treated as POD in dwarf2read.c. As such
it is actually a VEC pointer. When converting this to a std::vector
in an ideal world we would not use a std::vector pointer, and use the
std::vector directly. Sadly, to do that would require some rewriting
in dwarf2read.c - my concern would be introducing bugs during this
rewrite.
If we move to a std::vector pointer then we need to take care to
handle the case where the pointer is null. The old VEC library would
handle null for us, making the VEC interface very clean. With
std::vector we need to handle the null pointer case ourselves.
The achieve this then I've added a small number of function that wrap
up access to the std::vector, hopefully hiding the null pointer
management.
The final ugliness with this conversion is that, ideally, when
wrapping a data member behind an interface I would make the data
member private, however, treating the structure as POD once again
prevents this, so we are left with the data member being public, but
access (ideally) being through the published interface functions.
There should be no user visible changes after this commit.
gdb/ChangeLog:
* gdb/dwarf2read.c (dwarf2_per_objfile::~dwarf2_per_objfile):
Update for new std::vector based implementation.
(process_psymtab_comp_unit_reader): Likewise.
(scan_partial_symbols): Likewise.
(recursively_compute_inclusions): Likewise.
(compute_compunit_symtab_includes): Likewise.
(process_imported_unit_die): Likewise.
(queue_and_load_dwo_tu): Likewise.
(follow_die_sig_1): Likewise.
* gdb/dwarf2read.h: Remove DEF_VEC_P.
(typedef dwarf2_per_cu_ptr): Remove.
(struct dwarf2_per_cu_data) <imported_symtabs_empty>: New
function.
(struct dwarf2_per_cu_data) <imported_symtabs_push>: New function.
(struct dwarf2_per_cu_data) <imported_symtabs_size>: New function.
(struct dwarf2_per_cu_data) <imported_symtabs_free>: New function.
(struct dwarf2_per_cu_data) <imported_symtabs>: Change to
std::vector.
Change-Id: Id0f4bda977c9dd83b0ba3d7fb42f7e5e2b6869c8
|
|
One spot in windows-nat.c uses %ld to print the TID, but all other
spots use %x, as does the infrun logging. This makes it unnecessarily
hard to tell which other log messages correspond to this one. This
patch changes the one outlier to use %x.
gdb/ChangeLog
2019-10-15 Tom Tromey <tromey@adacore.com>
* windows-nat.c (windows_nat_target::resume): Use %x when logging
TID.
Change-Id: Ic66efeb8a7ec08e7fb007320318f51acbf976734
|
|
A couple of spots in windows-nat.c used the name "pid" to refer to the
thread ID. I found this confusing, so this patch changes the names.
gdb/ChangeLog
2019-10-15 Tom Tromey <tromey@adacore.com>
* windows-nat.c (windows_nat_target::fetch_registers)
(windows_nat_target::store_registers): Rename "pid" to "tid".
Change-Id: Ia1a447e8da822d01ad94a5ca3760342bbdc0e66c
|
|
This patch was inspired by a recent review that recommended using
std::string in a new implementation of the gcc_target_options gdbarch
function. It changes this function to return std::string rather than
an ordinary xmalloc'd string.
I believe this caught a latent memory leak in compile.c:get_args.
Tested on x86-64 Fedora 29.
gdb/ChangeLog
2019-10-15 Tom Tromey <tromey@adacore.com>
* gdbarch.h, gdbarch.c: Rebuild.
* gdbarch.sh (gcc_target_options): Change return type to
std::string.
* compile/compile.c (get_args): Update.
* nios2-tdep.c (nios2_gcc_target_options): Return std::string.
* arm-linux-tdep.c (arm_linux_gcc_target_options): Return
std::string.
* aarch64-linux-tdep.c (aarch64_linux_gcc_target_options): Return
std::string.
* arch-utils.c (default_gcc_target_options): Return std::string.
* arch-utils.h (default_gcc_target_options): Return std::string.
* s390-tdep.c (s390_gcc_target_options): Return std::string.
Change-Id: I51f61703426a323089e646da8f22320a2cafbc1f
|
|
That's an internal variable of breakpoint.c. Insted, use
iterate_over_breakpoints to update the breakpoint list.
gdb/ChangeLog:
2019-10-15 Christian Biesinger <cbiesinger@google.com>
* breakpoint.c (breakpoint_chain): Make static.
* tui/tui-winsource.c: Call iterate_over_breakpoints instead
of accessing breakpoint_chain.
Change-Id: Ic259b2c3a4c1f5a47f34cfd7fccbdcf274417429
|
|
This allows callers to pass in capturing lambdas. Also changes the return
type to bool.
gdb/ChangeLog:
2019-10-15 Christian Biesinger <cbiesinger@google.com>
* breakpoint.c (iterate_over_breakpoints): Change function pointer
to a gdb::function_view and return value to bool.
* breakpoint.h (iterate_over_breakpoints): Likewise.
* dummy-frame.c (pop_dummy_frame_bpt): Update.
(pop_dummy_frame): Update.
* guile/scm-breakpoint.c (bpscm_build_bp_list): Update.
(gdbscm_breakpoints): Update.
* python/py-breakpoint.c (build_bp_list): Update.
(gdbpy_breakpoints): Update.
* python/py-finishbreakpoint.c (bpfinishpy_detect_out_scope_cb):
Update.
(bpfinishpy_handle_stop): Update.
(bpfinishpy_handle_exit): Update.
* solib-svr4.c (svr4_update_solib_event_breakpoint): Update.
(svr4_update_solib_event_breakpoints): Update.
Change-Id: Ia9de4deecae562a70a40f5cd49f5a74d64570251
|
|
The infcall-nested-structs test case yields 36 FAILs on s390x because GCC
and GDB disagree on how to pass a C++ struct like this as an argument to a
function:
struct s { float x; static float y; };
For the purpose of argument passing, GCC ignores static fields, while GDB
does not. Thus GCC passes the argument in a floating-point register and
GDB passes it via memory.
Fix this by explicitly ignoring static fields when detecting single-field
structs.
gdb/ChangeLog:
* s390-tdep.c (s390_effective_inner_type): Ignore static fields
when unwrapping single-field structs.
|
|
On openSUSE Leap 15.1, we have:
...
FAIL: gdb.ada/mi_task_arg.exp: -stack-list-arguments 1 (unexpected output)
...
The problem is that the stack-list-arguments command prints a frame argument
'self_id' for function system.tasking.stages.task_wrapper:
...
frame={level="2",args=[{name="self_id",value="0x12345678"}]
...
where none (args=[]) is expected.
The frame argument is in fact correct. The FAIL does not show for say, fedora
30, because there the executable uses the system.tasking.stages.task_wrapper
from /lib64/libgnarl-9.so. Adding "additional_flags=-bargs
additional_flags=-shared additional_flags=-largs" to the flags argument of
gdb_compile_ada gives us the same PASS, but installing libada7-debuginfo gets
us the same FAIL again.
Fix the FAIL by allowing the 'self_id' argument.
Tested on x86_64-linux.
Change-Id: I5aee5856fa6aeb0cc78aa4fe69deecba5b00b77a
|
|
increasing timeout
Commit 580f1034 ("Increase timeout in
gdb.mi/list-thread-groups-available.exp") changed
gdb.mi/list-thread-groups-available.exp to significantly increase the
timeout, which was necessary for when running with make check-read1.
Pedro suggested a better alternative, which is to use gdb_test_multiple
and consume one entry at a time. This patch does that.
gdb/testsuite/ChangeLog:
* gdb.mi/list-thread-groups-available.exp: Read entries one by
one instead of increasing timeout.
Change-Id: I51b689458503240f24e401f054e6583d9172ebdf
|
|
include-what-you-use says:
../../../src/binutils-gdb/gdb/dwarf2read.c should remove these lines:
- #include <ctype.h> // lines 67-67
- #include <sys/stat.h> // lines 59-59
- #include <sys/types.h> // lines 83-83
- #include <cmath> // lines 88-88
- #include <forward_list> // lines 90-90
- #include <set> // lines 89-89
- #include <unordered_set> // lines 85-85
- #include "completer.h" // lines 60-60
- #include "expression.h" // lines 44-44
- #include "gdbsupport/byte-vector.h" // lines 78-78
- #include "gdbsupport/filestuff.h" // lines 71-71
- #include "gdbsupport/gdb_unlinker.h" // lines 74-74
After a quick glance, that makes sense, so this patch removes them.
gdb/ChangeLog:
* dwarf2read.c: Remove includes.
Change-Id: I13cfcb2f1d747144fddba7f66b329630b79dae90
|
|
We get this warning when building with clang:
CXX ui-out.o
/home/smarchi/src/binutils-gdb/gdb/ui-out.c:590:22: error: format string is not a string literal [-Werror,-Wformat-nonliteral]
do_message (style, format, args);
^~~~~~
This can be considered a legitimate warning, as call_do_message's format
parameter is not marked as a format string. Therefore, we should
normally mark the call_do_message method with the `format` attribute.
However, doing so just moves (and multiplies) the problem, as all the
uses of call_do_message in the vmessage method now warn. If we wanted
to continue on that path, we should silence the warning for each of
them, as a way of telling the compiler "it's ok, we know what we are
doing".
But since call_do_message is really just vmessage's little helper, it's
simpler to just silence the warning at that single point.
gdb/ChangeLog:
* ui-out.c (ui_out::call_do_message): Silence
-Wformat-nonliteral warning.
Change-Id: I58ad41793448f38835c5d6ba7b9e5c4dd8df260f
|
|
[ Port of gdb-8.3-branch commit 59047affb0a "Update ChangeLog entry of commit
98c90f8028 and mention PR c++/20020". ]
|
|
[ Port of gdb-8.3-branch commit 3d80b2e754f "Update ChangeLog entry of commit
3b752ac2e6 and mention PR testsuite/25016". ]
|
|
[ Port of gdb-8.3-branch commit 88f07f28d5b "Update ChangeLog entry of commit
7e38ddcb2e and mention PR breakpoints/25011". ]
|
|
[ Port of gdb-8.3-branch commit 5ca0b868fa7 "Update ChangeLog entry of commit
8ac39635f6 and mention PR gdb/25010". ]
|
|
In an attempt to reduce the number of files re-build when some headers
are touched, I ran include-what-you-use with breakpoint.c as a guinea
pig. It revealed a few files that were unnecessary to include, which
this patch removes.
breakpoint.c uses tilde_expand from readline, hence the necessity to
include tilde.h. AFAIK, it's fine to include just that, and not the
whole readline headers.
include-what-you-use also reported many header files that should be
included but aren't, I suppose that breakpoint.c currently includes them
indirectly. For now I'll pretend I didn't see that :).
gdb/ChangeLog:
* breakpoint.c: Remove some includes: continuations.h, skip.h,
mi/mi-main.h, readline/readline.h, readline/history.h. Add
include: readline/tilde.h.
-#include "skip.h"
#include "ax-gdb.h"
#include "dummy-frame.h"
#include "interps.h"
@@ -69,11 +67,9 @@
#include "thread-fsm.h"
#include "tid-parse.h"
#include "cli/cli-style.h"
-#include "mi/mi-main.h"
/* readline include files */
-#include "readline/readline.h"
-#include "readline/history.h"
+#include "readline/tilde.h"
/* readline defines this. */
#undef savestring
Change-Id: I88bfe9071f2f973fd84caaf04b95c33a4dfb33de
|
|
Normally the gdb.reverse/*.exp test-cases pass on my system (apart from the
record/23188 KFAIL for gdb.reverse/step-precsave.exp). But when specifying
GLIBC_TUNABLES=glibc.tune.hwcaps=-XSAVEC_Usable to force glibc to use
_dl_runtime_resolve_xsave instead of _dl_runtime_resolve_xsavec, we run into
1054 FAILs like this:
...
(gdb) PASS: gdb.reverse/sigall-reverse.exp: b gen_HUP
continue^M
Continuing.^M
Process record does not support instruction 0xfae64 at address \
0x7ffff7ded958.^M
Process record: failed to record execution log.^M
^M
Program stopped.^M
0x00007ffff7ded958 in _dl_runtime_resolve_xsave () from \
/lib64/ld-linux-x86-64.so.2^M
(gdb) FAIL: gdb.reverse/sigall-reverse.exp: get signal ABRT
...
The problem is that the xsave instruction is not supported in
reverse-debugging (PR record/25038).
Add KFAILs for this PR.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-10-13 Tom de Vries <tdevries@suse.de>
PR record/25038
* gdb.reverse/sigall-precsave.exp: Add PR record/25038 KFAIL.
* gdb.reverse/sigall-reverse.exp: Same.
* gdb.reverse/solib-precsave.exp: Same.
* gdb.reverse/solib-reverse.exp: Same.
* gdb.reverse/step-precsave.exp: Same.
* gdb.reverse/until-precsave.exp: Same.
* gdb.reverse/until-reverse.exp: Same.
* lib/gdb.exp (gdb_continue_to_breakpoint): Same.
|
|
This variable is declared in tracepoint.h, which is already included
by remote.c.
gdb/ChangeLog:
2019-10-12 Christian Biesinger <cbiesinger@google.com>
* remote.c (remote_target::get_trace_status): Remove declaration of
trace_regblock_size.
|
|
Also removes an unnecessary declaration of cmdlist in cli-cmds.c.
I don't understand why it is there, the definition of cmdlist is
at the top of the same file.
gdb/ChangeLog:
2019-10-12 Christian Biesinger <cbiesinger@google.com>
* cli/cli-cmds.c (max_user_call_depth): Move comment to header.
(show_user): Remove declaration of cmdlist.
* cli/cli-cmds.h (max_user_call_depth): Declare.
* cli/cli-script.c (execute_user_command): Remove declaration
of max_user_call_depth.
|
|
Since I had to look at these function comments to fix the RISC-V ARI warnings,
I noticed that they make no sense. The pulongest and plongest comments are
swapped. phex is missing a comment. And phex_nz doesn't mention how it is
different from phex.
* gdbsupport/print-utils.h (pulongest): Fix comment.
(plongest): Likewise.
(phex): Add missing comment, mention leading zeros.
(phex_nz): Add mention of no leading zeros to comment.
|
|
> gdb/riscv-tdep.c:1657: code: %ll: Do not use printf(%ll), instead use printf(%s,phex()) to dump a 'long long' value
gdb/riscv-tdep.c:1657: "Writing %lld-byte nop instruction to %s: %s\n",
> gdb/riscv-tdep.c:1658: code: long long: Do not use 'long long', instead use LONGEST
gdb/riscv-tdep.c:1658: ((unsigned long long) sizeof (nop_insn)),
fprintf_unfiltered doesn't support z (or j for that matter), and fixing that
is a larger patch than I'd like to write, so this does basically what the
ARI warnings recommends. We don't need the cast as there is a prototype for
plongest.
* riscv-tdep.c (riscv_push_dummy_code): Change %lld to %s and use
plongest instead of unsigned long long cast.
|
|
Once https://sourceware.org/ml/insight/2019-q4/msg00000.html lands,
we can just include gdbtk.h to get the declarations for
external_editor_command and gdbtk_test, instead of having to
declare them here in main.c.
gdb/ChangeLog:
2019-10-07 Christian Biesinger <cbiesinger@google.com>
* main.c (captured_main_1): Include gdbtk.h and remove declarations
for external_editor_command and gdbtk_test.
|
|
gdb/ChangeLog:
2019-10-10 Christian Biesinger <cbiesinger@google.com>
* mi/mi-cmd-var.c (varobjdebug): Remove declaration.
* varobj.c (varobjdebug): Move comment to...
* varobj.h (varobjdebug): ...here, and declare.
|
|
Some of the comparison functions in infcall-nested-structs.c contain
redundant comparisons like a.<some_field> == a.<some_field> instead of
a.<some_field> == b.<some_field>. They were introduced with this commit:
36eb4c5f9bbe6 - "infcall-nested-structs: Test up to five fields"
Fix the redundant comparisons.
gdb/testsuite/ChangeLog:
* gdb.base/infcall-nested-structs.c (cmp_struct_02_01)
(cmp_struct_02_02, cmp_struct_04_01, cmp_struct_04_02)
(cmp_struct_05_01, cmp_struct_static_02_01)
(cmp_struct_static_04_01, cmp_struct_static_06_01): Fix redundant
comparisons.
|
|
When running the gdb testsuite with target board unix/-fPIE/-pie, the
resulting ada executables are not PIE executables, because gnatmake doesn't
recognize -pie, and consequently doesn't pass it to gnatlink.
Fix this by replacing "-pie" with "-largs -pie -margs" in
target_compile_ada_from_dir, and doing the same for -no-pie.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-10-10 Tom de Vries <tdevries@suse.de>
PR testsuite/24888
* lib/ada.exp (target_compile_ada_from_dir): Route -pie/-no-pie to
gnatlink.
|
|
tui_data_window::show_registers currently calls erase_data_content.
However, I think it's better to have fewer calls to this (ideally just
one would suffice). This refactors that function to remove this call.
gdb/ChangeLog
2019-10-09 Tom Tromey <tom@tromey.com>
* tui/tui-regs.c (tui_data_window::show_registers): Don't call
erase_data_content.
|
|
This changes tui_gen_win_info::handle to be a specialization of
unique_ptr. This is perhaps mildly uglier in some spots, due to the
proliferation of "get"; but on the other hand it cleans up some manual
management and it allows for the removal of tui_delete_win.
gdb/ChangeLog
2019-10-09 Tom Tromey <tom@tromey.com>
* tui/tui-wingeneral.h (tui_delete_win): Don't declare.
* tui/tui-stack.c (tui_locator_window::rerender): Update.
* tui/tui-command.c (tui_cmd_window::resize)
(tui_refresh_cmd_win): Update.
* tui/tui-win.c (tui_resize_all, tui_set_focus_command): Update.
* tui/tui.c (tui_rl_other_window, tui_enable): Update.
* tui/tui-data.c (~tui_gen_win_info): Remove.
* tui/tui-layout.c (tui_gen_win_info::resize): Update.
* tui/tui-io.c (update_cmdwin_start_line, tui_putc, tui_puts)
(tui_redisplay_readline, tui_mld_flush)
(tui_mld_erase_entire_line, tui_mld_getc, tui_getc): Update.
* tui/tui-regs.c (tui_data_window::delete_data_content_windows)
(tui_data_window::erase_data_content)
(tui_data_item_window::rerender)
(tui_data_item_window::refresh_window): Update.
* tui/tui-wingeneral.c (tui_gen_win_info::refresh_window)
(box_win, tui_gen_win_info::make_window)
(tui_gen_win_info::make_visible): Update.
(tui_delete_win): Remove.
* tui/tui-winsource.c
(tui_source_window_base::do_erase_source_content): Update.
(tui_show_source_line, tui_source_window_base::update_tab_width)
(tui_source_window_base::update_exec_info): Update.
* tui/tui-data.h (struct curses_deleter): New.
(struct tui_gen_win_info) <handle>: Now a unique_ptr.
(struct tui_gen_win_info) <~tui_gen_win_info>: Define.
|
|
tui-wingeneral.h has an unused forward declaration. This removes it.
gdb/ChangeLog
2019-10-09 Tom Tromey <tom@tromey.com>
* tui/tui-wingeneral.h (struct tui_gen_win_info): Don't declare.
|
|
tui_win_is_auxiliary is not used, so remove it.
gdb/ChangeLog
2019-10-09 Tom Tromey <tom@tromey.com>
* tui/tui-data.c (tui_win_is_auxiliary): Remove.
* tui/tui-data.h (tui_win_is_auxiliary): Don't declare.
|
|
tui_default_win_viewport_height was only called from a single spot,
for a single type of window. This patch removes the function and
moves the logic into the sole caller.
gdb/ChangeLog
2019-10-09 Tom Tromey <tom@tromey.com>
* tui/tui-disasm.c (tui_get_low_disassembly_address): Compute
window height directly.
* tui/tui-layout.h (tui_default_win_viewport_height): Don't
declare.
* tui/tui-layout.c (tui_default_win_height): Remove.
(tui_default_win_viewport_height): Remove.
|
|
This removes two comments from tui.h. These were not useful.
gdb/ChangeLog
2019-10-09 Tom Tromey <tom@tromey.com>
* tui/tui.h: Remove comments.
|
|
On openSUSE Leap 15.1 using rustc version 1.36.0 (using llvm 7), I get:
...
(gdb) PASS: gdb.rust/simple.exp: print e2.0
print k^M
$54 = simple::SpaceSaver::Thebox(40, 0x0)^M
(gdb) FAIL: gdb.rust/simple.exp: print k
...
while we're expecting:
...
gdb_test "print k" " = simple::SpaceSaver::Nothing"
...
When using a relatively recent version of Rust with a somewhat older version
of LLVM, the Rust compiler will emit a legacy encoding of enums (see also
quirk_rust_enum in dwarf2read.c).
So, the variable k:
...
<17><3d58>: Abbrev Number: 15 (DW_TAG_variable)
<3d59> DW_AT_location : 3 byte block: 91 b8 4 (DW_OP_fbreg: 568)
<3d5d> DW_AT_name : (indirect string, offset: 0xf9a): k
<3d61> DW_AT_alignment : 1
<3d62> DW_AT_decl_file : 1
<3d63> DW_AT_decl_line : 129
<3d64> DW_AT_type : <0x4232>
...
has type:
...
<2><4232>: Abbrev Number: 11 (DW_TAG_union_type)
<4233> DW_AT_name : (indirect string, offset: 0x3037): SpaceSaver
<4237> DW_AT_byte_size : 16
<4238> DW_AT_alignment : 8
<3><4239>: Abbrev Number: 9 (DW_TAG_member)
<423a> DW_AT_name : (indirect string, offset: 0x29f5): RUST$ENCODED$ENUM$0$Nothing
<423e> DW_AT_type : <0x4245>
<4242> DW_AT_alignment : 8
<4243> DW_AT_data_member_location: 0
...
The "RUST$ENCODED$ENUM$0$Nothing" means that field 0 is both a pointer and a
discriminant, and if the value is 0, then the enum is just a data-less variant
named "Nothing".
However, the corresponding type has two fields, where not field 0 but field 1
is a pointer, and field 0 is a byte:
...
<2><4245>: Abbrev Number: 8 (DW_TAG_structure_type)
<4246> DW_AT_name : (indirect string, offset: 0x2a11): Thebox
<424a> DW_AT_byte_size : 16
<424b> DW_AT_alignment : 8
<3><424c>: Abbrev Number: 9 (DW_TAG_member)
<424d> DW_AT_name : (indirect string, offset: 0x670): __0
<4251> DW_AT_type : <0x436b>
<4255> DW_AT_alignment : 1
<4256> DW_AT_data_member_location: 8
<3><4257>: Abbrev Number: 9 (DW_TAG_member)
<4258> DW_AT_name : (indirect string, offset: 0x1662): __1
<425c> DW_AT_type : <0x45da>
<4260> DW_AT_alignment : 8
<4261> DW_AT_data_member_location: 0
...
Mark this as xfail.
gdb/testsuite/ChangeLog:
2019-10-09 Tom de Vries <tdevries@suse.de>
PR testsuite/25048
* gdb.rust/simple.exp: Add xfails for incorrect DWARF.
|
|
I'm seeing this failure:
...
(gdb) print /x $bnd0 = {0x10, 0x20}^M
$23 = {lbound = 0x10, ubound = 0x20}^M
(gdb) FAIL: gdb.arch/i386-mpx.exp: verify size for bnd0
...
The test expects a pretty printer to be actived printing 'size 17':
...
set test_string ".*\\\: size 17.*"
gdb_test "print /x \$bnd0 = {0x10, 0x20}" "$test_string" "verify size for bnd0"
...
but that doesn't happen.
The pretty printer is for the type of the $bnd0 register, which is created
here in i386_bnd_type:
...
t = arch_composite_type (gdbarch,
"__gdb_builtin_type_bound128", TYPE_CODE_STRUCT);
append_composite_type_field (t, "lbound", bt->builtin_data_ptr);
append_composite_type_field (t, "ubound", bt->builtin_data_ptr);
TYPE_NAME (t) = "builtin_type_bound128";
...
And the pretty-printer is registered here in
gdb/python/lib/gdb/printer/bound_registers.py:
...
gdb.printing.add_builtin_pretty_printer ('mpx_bound128',
'^__gdb_builtin_type_bound128',
MpxBound128Printer)
...
Fix the pretty printer by changing the regexp argument of
add_builtin_pretty_printer to match "builtin_type_bound128", the TYPE_NAME.
Tested on x86_64-linux.
gdb/ChangeLog:
2019-10-09 Tom de Vries <tdevries@suse.de>
* python/lib/gdb/printer/bound_registers.py: Use
'^builtin_type_bound128' as regexp argument for
add_builtin_pretty_printer.
|
|
This makes it clearer that the structs are only used in this file. It
required moving the definition of extension_language_guile further
down in the file, because static structs can't be forward-declared.
gdb/ChangeLog:
2019-10-09 Christian Biesinger <cbiesinger@google.com>
* guile/guile.c (guile_extension_script_ops): Remove forward
declaration and mark as static.
(guile_script_ops): Likewise.
(extension_language_guile): Move further down in the file so
it can reference the definitions for guile_{extension_,}script_ops.
|
|
Enable recording most of the new "arch13" instructions on z/Architecture
targets, except for the specialized-function-assist instructions:
SORTL - sort lists
DFLTCC - deflate conversion call
KDSA - compute digital signature authentication
gdb/ChangeLog:
* s390-tdep.c (390_process_record): Handle new arch13 instructions
except SORTL, DFLTCC, and KDSA.
|
|
windows_thread_info_struct::sf is unused, as is
struct safe_symbol_file_add_args in windows-nat.c.
This patch removes them both. Tested by grep and
rebuilding.
gdb/ChangeLog
2019-10-08 Tom Tromey <tromey@adacore.com>
* windows-nat.c (struct windows_thread_info_struct) <sf>: Remove.
(struct safe_symbol_file_add_args): Remove.
|
|
I noticed that windows-nat.c includes buildsym-legacy.h -- but there's
no reason to do so, as windows-nat.c doesn't create any symbols.
gdb/ChangeLog
2019-10-08 Tom Tromey <tromey@adacore.com>
* windows-nat.c: Don't include buildsym-legacy.h.
|
|
As pointed out by Simon, this changes ARI to allow the gdb-specific %p
printf extensions.
gdb/ChangeLog
2019-10-08 Tom Tromey <tromey@adacore.com>
* contrib/ari/gdb_ari.sh (%p): Allow gdb-specific %p extensions.
|
|
gdb/ChangeLog:
2019-10-08 Christian Biesinger <cbiesinger@google.com>
* gdbtypes.c (overload_debug): Move comment to header.
* gdbtypes.h (overload_debug): Declare.
* valops.c: Remove declaration of overload_debug, instead
include gdbtypes.h.
|
|
Also makes it localizable.
gdb/ChangeLog:
2019-10-08 Christian Biesinger <cbiesinger@google.com>
* language.c (show_language_command): Pass lang_frame_mismatch_warn
through _().
(lang_frame_mismatch_warn): Make const, mark with N_(), and
move comment...
* language.h (lang_frame_mismatch_warn): ... here. Also add
declaration.
* top.c (lang_frame_mismatch_warn): Remove declaration.
(check_frame_language_change): Pass lang_frame_mismatch_warn
through _().
|
