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 0dc327459b
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
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
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
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
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
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.
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:
36eb4c5f9b - "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.
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.
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 _().
There are conflicting comments about whether this was
introduced in GCC 2.4.5 or GCC 2.6 and I don't know
which one is correct...
gdb/ChangeLog:
2019-10-07 Christian Biesinger <cbiesinger@google.com>
* c-lang.h (vtbl_ptr_name): Declare.
* cp-valprint.c (vtbl_ptr_name): Remove "extern" now that we get
it from the header.
* stabsread.c (define_symbol): Remove declaration of vtbl_ptr_name.
It currently has a "manual" static assert.
gdb/ChangeLog:
2019-10-07 Christian Biesinger <cbiesinger@google.com>
* charset.c (your_gdb_wchar_t_is_bogus): Replace with a
gdb_static_assert.
Update a test script to handle the case where missing Ada debug
information means we can't catch exceptions. This was discussed on
the list here:
https://sourceware.org/ml/gdb-patches/2019-08/msg00607.html
And is similar to code that already exists in the test scripts
gdb.ada/catch_ex.exp and gdb.ada/mi_catch_ex.exp.
gdb/testsuite/ChangeLog:
* gdb.ada/catch_ex_std.exp: Handle being unabled to catch Ada
exceptions due to missing debug information.
Commit:
commit 30d1f01849
Date: Mon Oct 7 00:46:52 2019 +0000
gdb: CTF support
Introduces some structures with names that are already in use within
GBB, this violates C++'s one-definition rule. Specifically the
structures 'nextfield' and 'field_info' are now defined in
dwarf2read.c and ctfread.c.
This commit renames the new structures (in ctfread.c), adding a 'ctf_'
prefix. Maybe we should consider renaming the DWARF versions too in
the future to avoid accidental conflicts.
gdb/ChangeLog:
* ctfread.c (struct nextfield): Renamed to ...
(struct ctf_nextfield): ... this.
(struct field_info): Renamed to ...
(strut ctf_field_info): ... this.
(attach_fields_to_type): Update for renamed structures.
(ctf_add_member_cb): Likewise.
(ctf_add_enum_member_cb): Likewise.
(process_struct_members): Likewise.
(process_enum_type): Likewise.
Now that commit "225f296a023 Change gdb/version.in to 9.0.50.DATE-git (new
version numbering scheme)" has changed the gdb version number, we see:
...
FAIL: gdb.base/default.exp: show convenience ($_gdb_major = 8 not found)
...
Fix this by updating the expected _gdb_major/_gdb_minor to 9.1.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-10-07 Tom de Vries <tdevries@suse.de>
* gdb.base/default.exp: Expect _gdb_major/_gdb_minor to be 9.1.
This commit adds a new feature to gdb_test_multiple, an automatically
created variable gdb_test_name. The idea is to make it easier to
write tests using gdb_test_multiple, and avoid places where the string
passed to pass/fail within an action element is different to the
message passed to the top level gdb_test_multiple.
As an example, previously you might write this:
gdb_test_multiple "print foo" "test foo" {
-re "expected output 1" {
pass "test foo"
}
-re "expected output 2" {
fail "test foo"
}
}
This is OK, but it's easy for the pass/fail strings to come out of
sync, or contain a typo. A better version would look like this:
set testname "test foo"
gdb_test_multiple "print foo" $testname {
-re "expected output 1" {
pass $testname
}
-re "expected output 2" {
fail $testname
}
}
This is better, but its a bit of a drag having to create a new
variable each time.
After this patch you can now write this:
gdb_test_multiple "print foo" "test foo" {
-re "expected output 1" {
pass $gdb_test_name
}
-re "expected output 2" {
fail $gdb_test_name
}
}
The $gdb_test_name is setup by gdb_test_multiple, and cleaned up once
the test has completed. Nested calls to gdb_test_multiple are
supported, though $gdb_test_name will only ever contain the inner most
test message (which is probably what you want).
My only regret is that '$gdb_test_name' is so long, but I wanted
something that was unlikely to clash with any existing variable name,
or anything that a user is likely to want to use.
I've tested this on x86-64/GNU Linux and see no test regressions, and
I've converted one test script over to make use of this new technique
both as an example, and to ensure that the new facility doesn't get
broken. I have no plans to convert all tests over to this technique,
but I hope others will find this useful for writing tests in the
future.
gdb/testsuite/ChangeLog:
* lib/gdb.exp (gdb_test_multiple): Add gdb_test_name mechanism.
* gdb.base/annota1.exp: Update to use gdb_test_name.
This patch adds the CTF (Compact Ansi-C Type Format) support in gdb.
Two submissions on which this gdb work depends were posted earlier
in May:
* On the binutils mailing list - adding libctf which creates, updates,
reads, and manipulates the CTF data.
* On the gcc mailing list - expanding gcc to directly emit the CFT data
with a new command line option -gt.
CTF is a reduced form of debugging information whose main purpose is to
describe the type of C entities such as structures, unions, typedefs and
function arguments at the global scope only. It does not contain debug
information about source lines, location expressions, or local variables.
For more information on CTF, see the documentation in the libdtrace-ctf
source tree, available here:
<https://raw.githubusercontent.com/oracle/libdtrace-ctf/master/doc/ctf-format>.
This patch expands struct elfinfo by adding the .ctf section, which
contains CTF debugging info, and modifies elf_symfile_read() to read it.
If both DWARF and CTF exist in a program, only DWARF will be read. CTF data
will be read only when there is no DWARF. The two-stage symbolic reading
and setting strategy, partial and full, was used.
File ctfread.c contains functions to transform CTF data into gdb's internal
symbol table structures by iterately reading entries from CTF sections
of "data objects", "function info", "variable info", and "data types"
when setting up either partial or full symbol table. If the ELF symbol table
is available, e.g. not stripped, the CTF reader will associate the found
type information with these symbol entries. Due to the proximity between DWARF
and CTF (CTF being a much simplified subset of DWARF), some DWARF implementation
was reused to support CTF.
Test cases ctf-constvars.exp, ctf-cvexpr.exp, ctf-ptype.exp, and ctf-whatis.exp
have been added to verify the correctness of this support.
This patch has missing features and limitations which we will add and
address in the future patches.
gdb/ChangeLog
+2019-10-07 Weimin Pan <weimin.pan@oracle.com>
+
+ * gdb/ctfread.c: New file.
+ * gdb/ctfread.h: New file.
+ * gdb/elfread.c: Include ctfread.h.
+ (struct elfinfo text_p): New member ctfsect.
+ (elf_locate_sections): Mark CTF section.
+ (elf_symfile_read): Call elfctf_build_psymtabs.
+ * gdb/Makefile.in (LIBCTF): Add.
+ (CLIBS): Use it.
+ (CDEPS): Likewise.
+ (DIST): Add ctfread.c.
+ * Makefile.def (dependencies): Add all-libctf to all-gdb
+ * Makefile.in: Add "all-gdb: maybe-all-libctf"
+
gdb/testsuite/ChangeLog
+2019-10-07 Weimin Pan <weimin.pan@oracle.com>
+
+ * gdb.base/ctf-whatis.exp: New file.
+ * gdb.base/ctf-whatis.c: New file.
+ * gdb.base/ctf-ptype.exp: New file.
+ * gdb.base/ctf-ptype.c: New file.
+ * gdb.base/ctf-constvars.exp: New file.
+ * gdb.base/ctf-constvars.c: New file.
+ * gdb.base/ctf-cvexpr.exp: New file.
+
With gdb.cp/local-static.exp and gcc 4.8, I see:
...
gdb compile failed, src/gdb/testsuite/gdb.cp/local-static.c: In function 'main':
src/gdb/testsuite/gdb.cp/local-static.c:148:3: error: 'for' loop initial \
declarations are only allowed in C99 mode
for (int i = 0; i < 1000; i++)
^
src/gdb/testsuite/gdb.cp/local-static.c:148:3: note: use option -std=c99 or \
-std=gnu99 to compile your code
UNTESTED: gdb.cp/local-static.exp: c: failed to prepare
...
Fix this by moving the declaration of int i out of the for loop.
gdb/testsuite/ChangeLog:
2019-10-04 Tom de Vries <tdevries@suse.de>
* gdb.cp/local-static.c (main): Move declaration of int i out of the
for loop.
PR rust/24976 points out a crash in gdb when a single-field union is
used in Rust.
The immediate problem was a NULL pointer dereference in
quirk_rust_enum. However, that code is also erroneously treating a
single-field union as if it were a univariant enum. Looking at the
output of an older Rust compiler, it turns out that univariant enums
are distinguished by having a single *anonymous* field. This patch
changes quirk_rust_enum to limit its fixup to this case.
Tested with a new-enough version of the Rust compiler to cause the
crash; plus by using an older executable that uses the old univariant
encoding.
gdb/ChangeLog
2019-10-03 Tom Tromey <tom@tromey.com>
PR rust/24976:
* dwarf2read.c (quirk_rust_enum): Handle single-element unions.
gdb/testsuite/ChangeLog
2019-10-03 Tom Tromey <tom@tromey.com>
PR rust/24976:
* gdb.rust/simple.rs (Union2): New type.
(main): Use Union2.
* gdb.rust/simple.exp: Add test.
This commit allows symbol matching within Fortran code without having
to specify all of the symbol's scope. For example, given this Fortran
code:
module aaa
contains
subroutine foo
print *, "hello."
end subroutine foo
end module aaa
subroutine foo
print *, "hello."
end subroutine foo
program test
call foo
contains
subroutine foo
print *, "hello."
end subroutine foo
subroutine bar
use aaa
call foo
end subroutine bar
end program test
The user can now do this:
(gdb) b foo
Breakpoint 1 at 0x4006c2: foo. (3 locations)
(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep y <MULTIPLE>
1.1 y 0x00000000004006c2 in aaa::foo at nest.f90:4
1.2 y 0x0000000000400730 in foo at nest.f90:9
1.3 y 0x00000000004007c3 in test::foo at nest.f90:16
The user asks for a breakpoint on 'foo' and is given a breakpoint on
all three possible 'foo' locations. The user is, of course, still
able to specify the scope in order to place a single breakpoint on
just one of the foo functions (or use 'break -qualified foo' to break
on just the global foo).
gdb/ChangeLog:
* f-lang.c (f_language_defn): Use cp_get_symbol_name_matcher and
cp_search_name_hash.
* NEWS: Add entry about nested function support.
gdb/testsuite/ChangeLog:
* gdb.fortran/nested-funcs-2.exp: Run tests with and without the
nested function prefix.
This patch is a rebase and update of the following three patches:
https://sourceware.org/ml/gdb-patches/2018-11/msg00298.htmlhttps://sourceware.org/ml/gdb-patches/2018-11/msg00302.htmlhttps://sourceware.org/ml/gdb-patches/2018-11/msg00301.html
I have merged these together into a single commit as the second patch,
adding scope support to nested subroutines, means that some of the
changes in the first patch are now no longer useful and would have to
be backed out. The third patch is tightly coupled to the changes in
the second of these patches and I think deserves to live together with
it.
There is an extra change in cp-namespace.c that is new, this resolves
an issue with symbol lookup when placing breakpoints from within
nested subroutines.
There is also an extra test added to this commit 'nested-funcs-2.exp'
that was written by Richard Bunt from ARM, this offers some additional
testing of breakpoints on nested functions.
After this commit it is possible to place breakpoints on nested
Fortran subroutines and functions by using a fully scoped name, for
example, given this simple Fortran program:
program greeting
call message
contains
subroutine message
print *, "Hello World"
end subroutine message
end program greeting
It is possible to place a breakpoint in 'message' with:
(gdb) break greeting::message
Breakpoint 1 at 0x4006c9: file basic.f90, line 5.
What doesn't work with this commit is placing a breakpoint like this:
(gdb) break message
Function "message" not defined.
Making this work will come in a later commit.
gdb/ChangeLog:
* cp-namespace.c (cp_search_static_and_baseclasses): Only search
for nested static variables when searchin VAR_DOMAIN.
* dwarf2read.c (add_partial_symbol): Add nested subroutines to the
global scope, update comment.
(add_partial_subprogram): Call add_partial_subprogram recursively
for nested subroutines when processinng Fortran.
(load_partial_dies): Process the child entities of a subprogram
when processing Fortran.
(partial_die_parent_scope): Handle building scope
for Fortran nested functions.
(process_die): Record that nested functions have a scope.
(new_symbol): Always record Fortran subprograms on the global
symbol list.
(determine_prefix): How to build the prefix for Fortran
subprograms.
gdb/testsuite/ChangeLog:
* gdb.fortran/nested-funcs.exp: Tests for placing breakpoints on
nested functions.
* gdb.fortran/nested-funcs.f90: Update expected results.
* gdb.fortran/nested-funcs-2.exp: New file.
* gdb.fortran/nested-funcs-2.f90: New file.
gdb/doc/ChangeLog:
* doc/gdb.texinfo (Fortran Operators): Describe scope operator.
This commit removes some, but not all, of the test name duplication
within the gdb.python tests. On my local machine this takes the
number of duplicate test names in this set of tests from 174 to 85.
It is possible that different setups might encounter more duplicate
tests.
gdb/testsuite/ChangeLog:
* gdb.python/py-parameter.exp: Make test names unique.
* gdb.python/py-template.exp: Likewise.
* gdb.python/py-value.exp: Likewise.
This commit removes some, but not all, of the test name duplication
within the gdb.base tests. On my local machine this takes the number
of duplicate test names in this set of tests from 454 to 145. It is
possible that different setups might encounter more duplicate tests.
gdb/testsuite/ChangeLog:
* gdb.base/break-interp.exp: Reduce test name duplication.
* gdb.base/call-sc.exp: Likewise.
* gdb.base/callfuncs.exp: Likewise.
* gdb.base/charset.exp: Likewise.
* gdb.base/dump.exp: Likewise.
* gdb.base/ena-dis-br.exp: Likewise.
* gdb.base/relational.exp: Likewise.
* gdb.base/step-over-syscall.exp: Likewise.
* gdb.base/structs.exp: Likewise.
Make test names unique in the gdb.linespec tests. On my local machine
this removed 43 duplicate test names. It is possible that different
setups might still encounter some duplicates.
gdb/testsuite/ChangeLog:
* gdb.linespec/explicit.exp: Make test names unique.
* gdb.linespec/ls-errs.exp: Likewise.
Make test names unique in the gdb.reverse tests. On my local machine
this removed 825 duplicate test names. It is possible that different
setups might still encounter some duplicates.
gdb/testsuite/ChangeLog:
* gdb.reverse/break-precsave.exp: Make test names unique.
* gdb.reverse/break-reverse.exp: Likewise.
* gdb.reverse/finish-precsave.exp: Likewise.
* gdb.reverse/finish-reverse.exp: Likewise.
* gdb.reverse/machinestate-precsave.exp: Likewise.
* gdb.reverse/machinestate.exp: Likewise.
* gdb.reverse/readv-reverse.exp: Likewise.
* gdb.reverse/recvmsg-reverse.exp: Likewise.
* gdb.reverse/sigall-precsave.exp: Likewise.
* gdb.reverse/sigall-reverse.exp: Likewise.
* gdb.reverse/step-indirect-call-thunk.exp: Likewise.
* gdb.reverse/watch-precsave.exp: Likewise.
* gdb.reverse/watch-reverse.exp: Likewise.
It was observed that in a multi-threaded application on GNU/Linux,
that if the user has set the SIGSTOP to be pass (using GDB's handle
command) then the inferior would hang upon hitting a breakpoint.
What happens is that when a thread hits the breakpoint GDB tries to
stop all of the other threads by sending them a SIGSTOP and setting
the stop_requested flag in the target_ops structure - this can be seen
in infrun.c:stop_all_threads.
GDB then waits for all of the other threads to stop.
When the SIGSTOP event arrives we eventually end up in
linux-nat.c:linux_nat_filter_event, which has the job of deciding if
the event we're looking at (the SIGSTOP arriving in this case) is
something that should be reported back to the core of GDB.
One of the final actions of this function is to check if we stopped
due to a signal, and if we did, and the signal has been set to 'pass'
by the user then we ignore the event and resume the thread.
This code already has some conditions in place that mean the event is
reported to GDB even if the signal is in the set of signals to be
passed to the inferior.
In this commit I extend this condition such that:
If the signal is a SIGSTOP, and the thread's stop_requested flag is
set (indicating we're waiting for the thread to stop with a SIGSTOP)
then we should report this SIGSTOP to GDB and not pass it to the
inferior.
With this change in place the test now passes. Regression tested on
x86-64 GNU/Linux with no regressions.
gdb/ChangeLog:
* linux-nat.c (linux_nat_filter_event): Don't ignore SIGSTOP if we
have just sent the thread a SIGSTOP and are waiting for it to
arrive.
gdb/testsuite/ChangeLog:
* gdb.threads/stop-with-handle.c: New file.
* gdb.threads/stop-with-handle.exp: New file.
With gcc 4.8.1, we see this FAIL:
...
(gdb) PASS: gdb.base/list-missing-source.exp: list
info source^M
Current source file is outputs/gdb.base/list-missing-source/main.c^M
Source language is c.^M
Producer is GNU C 4.8.5 -mtune=generic -march=x86-64 -g -fno-stack-protector.^M
Compiled with DWARF 2 debugging format.^M
Does not include preprocessor macro info.^M
(gdb) FAIL: gdb.base/list-missing-source.exp: info source
...
The problem is that a "Compilation directory is <dir>" line is expected, but
this is missing due to the fact the the compilation unit for main.c doesn't
contain a DW_AT_comp_dir in the DW_TAG_compile_unit DIE.
Fix this by allowing the "Compilation directory" line to be missing.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-10-03 Tom de Vries <tdevries@suse.de>
PR testsuite/25059
* gdb.base/list-missing-source.exp: Allowing the "Compilation
directory" line to be missing.
The gdb.base/info-types.exp test-case FAILs with gcc/g++ 4.8 because the DWARF
record for the 'unsigned int' type is missing in the executables, while it is
present for gcc/g++ 7.4.1.
For a minimal example using gcc 7.4.1:
...
$ echo "enum enum_t { AA, BB, CC }; enum enum_t var;" > enum.c
$ gcc enum.c -c -g
...
we find that the enum type has DW_AT_encoding 'unsigned':
<1><1d>: Abbrev Number: 2 (DW_TAG_enumeration_type)
<1e> DW_AT_name : (indirect string, offset: 0x1f): enum_t
<22> DW_AT_encoding : 7 (unsigned)
<23> DW_AT_byte_size : 4
<24> DW_AT_type : <0x3e>
<28> DW_AT_decl_file : 1
<29> DW_AT_decl_line : 1
<2a> DW_AT_sibling : <0x3e>
...
and a DW_AT_type reference to the type 'unsigned int':
...
<1><3e>: Abbrev Number: 4 (DW_TAG_base_type)
<3f> DW_AT_byte_size : 4
<40> DW_AT_encoding : 7 (unsigned)
<41> DW_AT_name : (indirect string, offset: 0x26): unsigned int
...
With gcc 4.8.5 however, we have no 'unsigned' encoding, and no DW_AT_type:
...
<1><1d>: Abbrev Number: 2 (DW_TAG_enumeration_type)
<1e> DW_AT_name : (indirect string, offset: 0x1f): enum_t
<22> DW_AT_byte_size : 4
<23> DW_AT_decl_file : 1
<24> DW_AT_decl_line : 1
<25> DW_AT_sibling : <0x39>
...
as well as no record for 'unsigned int'.
Make the test-case pass with gcc/g++ 4.8 by making the presence of the
'unsigned int' type optional.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-10-03 Tom de Vries <tdevries@suse.de>
PR testsuite/25059
* gdb.base/info-types.exp: Make the presence of the 'unsigned int'
type optional.
In the following 3 commits:
commit df07e2c772
Date: Wed Sep 25 16:10:50 2019 +0100
gdb: Remove a use of VEC from dwarf2read.{c,h}
commit 554ac434b0
Date: Thu Sep 19 13:17:59 2019 -0400
gdb: Change a VEC to std::vector in btrace.{c,h}
commit 46f29a9a26
Date: Mon Sep 16 09:12:27 2019 -0400
gdb: Remove a VEC from gdbsupport/btrace-common.h
I incorrectly wrote 'std::vector <...>' instead of 'std::vector<...>',
this commit fixes this mistake. There should be no user visible
changes after this commit.
gdb/ChangeLog:
* btrace.c (btrace_add_pc): Remove whitespace before the template
parameter in 'std::vector <...>'.
(parse_xml_btrace_block): Likewise.
(btrace_maint_decode_pt): Likewise.
(btrace_maint_update_packets): Likewise.
(btrace_maint_print_packets): Likewise.
* btrace.h (struct btrace_maint_info): Likewise.
* dwarf2read.c (struct type_unit_group): Likewise.
(build_type_psymtabs_reader): Likewise.
* gdbsupport/btrace-common.c (btrace_data_append): Likewise.
* gdbsupport/btrace-common.h (struct btrace_data_bts): Likewise.
* nat/linux-btrace.c (perf_event_read_bts): Likewise.
There's a recent regression:
...
FAIL: gdb.gdb/unittest.exp: maintenance selftest
...
In more detail:
...
Running selftest help_doc_invariants.^M
help doc broken invariant: command 'set style metadata' help doc first line \
is not terminated with a '.' character^M
help doc broken invariant: command 'show style metadata' help doc first line \
is not terminated with a '.' character^M
Self test failed: self-test failed at gdb/unittests/help-doc-selftests.c:95^M
...
Fix this by adding a '.' at the end of the first line of the help text for
set/show style metadata.
Tested on x86_64-linux.
gdb/ChangeLog:
2019-10-03 Tom de Vries <tdevries@suse.de>
* cli/cli-style.c (_initialize_cli_style): Adding a '.' at the end of
the first line of the help text for set/show style metadata.
startup_with_shell was changed to be of "bool" type, but I noticed
that the definition in gdbserver disagreed. This disagreement caused
some regressions on a big-endian machine.
This patch removes the redundant declaration and definition of
startup_with_shell and ensures that such clashes will be diagnosed.
This moves the declaration to common-inferior.h, and introduces a new
common-inferior.c, as suggested by Pedro.
gdb/ChangeLog
2019-10-02 Tom Tromey <tromey@adacore.com>
* Makefile.in (COMMON_SFILES): Add common-inferior.c.
* gdbsupport/common-inferior.c: New file.
* infcmd.c (startup_with_shell): Don't define.
* nat/fork-inferior.h (startup_with_shell): Don't declare.
* gdbsupport/common-inferior.h (startup_with_shell): Declare.
* inferior.h (startup_with_shell): Don't declare.
gdb/gdbserver/ChangeLog
2019-10-02 Tom Tromey <tromey@adacore.com>
* Makefile.in (SFILES): Add common-inferior.c.
(OBS): Add common-inferior.o.
* server.c (startup_with_shell): Don't define.
gdb::string_view uses gdb_assert, so it should include that header.
And gdb_assert uses internal_error, so it should include errors.h.
gdb/ChangeLog:
2019-10-02 Christian Biesinger <cbiesinger@google.com>
* gdbsupport/gdb_assert.h: Include errors.h.
* gdbsupport/gdb_string_view.h: Include gdb_assert.h.
GDB's py-format-string test case depends on endianness. In particular it
relies on the first byte of the machine representation of 42 (as an int)
to be 42 as well. While this is indeed the case for little-endian
machines, big-endian machines store a zero in the first byte instead. The
wrong assumption leads to lots of FAILs on such architectures.
Fix this by filling the affected union with bytes of the same value, such
that endianness does not matter. Use the value 42, to keep the character
in the first byte unchanged.
gdb/testsuite/ChangeLog:
* gdb.python/py-format-string.c (string.h): New include.
(main): Fill a_struct_with_union.the_union.an_int with bytes of
the same value, for endianness-independence.
* gdb.python/py-format-string.exp (default_regexp_dict)
(test_pretty_structs, test_format): Adjust expected output to the
changed initialization.
This adds the $_ada_exception convenience variable. It is set by the
Ada exception catchpoints, and holds the address of the exception
currently being thrown. This is useful because it allows more
fine-grained filtering of exceptions than is possible using the
existing "catch" syntax.
This also simplifies Ada catchpoints somewhat; because the catchpoint
must now carry the "kind", it's possible to remove many helper
functions.
gdb/ChangeLog
2019-10-02 Tom Tromey <tromey@adacore.com>
* NEWS: Add $_ada_exception entry.
* ada-lang.c (struct ada_catchpoint): Add constructor.
<m_kind>: New member.
(allocate_location_exception, re_set_exception): Remove
"ex" parameter.
(should_stop_exception): Compute $_ada_exception.
(check_status_exception, print_it_exception)
(print_one_exception, print_mention_exception): Remove
"ex" parameter.
(allocate_location_catch_exception, re_set_catch_exception)
(check_status_exception, print_it_catch_exception)
(print_one_catch_exception, print_mention_catch_exception)
(print_recreate_catch_exception)
(allocate_location_catch_exception_unhandled)
(re_set_catch_exception_unhandled)
(check_status_exception, print_it_catch_exception_unhandled)
(print_one_catch_exception_unhandled)
(print_mention_catch_exception_unhandled)
(print_recreate_catch_exception_unhandled)
(allocate_location_catch_assert, re_set_catch_assert)
(check_status_assert, print_it_catch_assert)
(print_one_catch_assert, print_mention_catch_assert)
(print_recreate_catch_assert)
(allocate_location_catch_handlers, re_set_catch_handlers)
(check_status_handlers, print_it_catch_handlers)
(print_one_catch_handlers, print_mention_catch_handlers)
(print_recreate_catch_handlers): Remove.
(create_ada_exception_catchpoint): Update.
(initialize_ada_catchpoint_ops): Update.
gdb/doc/ChangeLog
2019-10-02 Tom Tromey <tromey@adacore.com>
* gdb.texinfo (Set Catchpoints, Convenience Vars): Document
$_ada_exception.
gdb/testsuite/ChangeLog
2019-10-02 Tom Tromey <tromey@adacore.com>
* gdb.ada/catch_ex_std.exp: Add $_ada_exception test.
commit 2ff0a9473 (Fix "catch exception" with dynamic linking) changed
how ada-lang.c creates expressions to determine if an exception
catchpoint should stop.
That patch is no longer needed now that copy relocations are handled
more directly.
gdb/ChangeLog
2019-10-02 Tom Tromey <tromey@adacore.com>
* ada-lang.c (ada_lookup_simple_minsyms): Remove.
(create_excep_cond_exprs): Simplify exception string computation.
(ada_exception_catchpoint_cond_string): Likewise.
Make gdb.base/print-file-var.exp test all combinations of:
- attribute hidden in the this_version_id symbols or not
- dlopen or not
- this_version_id symbol in main file or not
- C++
gdb/testsuite/ChangeLog
2019-10-02 Pedro Alves <palves@redhat.com>
Andrew Burgess <andrew.burgess@embecosm.com>
* gdb.base/print-file-var-lib1.c: Include <stdio.h> and
"print-file-var.h".
(this_version_id) Use ATTRIBUTE_VISIBILITY.
(get_version_1): Print this_version_id and its address.
Add extern "C" wrappers around interface functions.
* gdb.base/print-file-var-lib2.c: Include <stdio.h> and
"print-file-var.h".
(this_version_id) Use ATTRIBUTE_VISIBILITY.
(get_version_2): Print this_version_id and its address.
Add extern "C" wrappers around interface functions.
* gdb.base/print-file-var-main.c: Include <dlfcn.h>, <assert.h>,
<stddef.h> and "print-file-var.h".
Add extern "C" wrappers around interface functions.
[VERSION_ID_MAIN] (this_version_id): Define.
(main): Define v0. Use dlopen if SHLIB_NAME is defined.
* gdb.base/print-file-var.h: Add some #defines to simplify setting
up extern "C" blocks.
* gdb.base/print-file-var.exp (test): New, factored out from top
level.
(top level): Test all combinations of attribute hidden or not,
dlopen or not, and this_version_id symbol in main file or not.
Compile tests as both C++ and C, make test names unique.
In ELF, if a data symbol is defined in a shared library and used by
the main program, it will be subject to a "copy relocation". In this
scenario, the main program has a copy of the symbol in question, and a
relocation that tells ld.so to copy the data from the shared library.
Then the symbol in the main program is used to satisfy all references.
This patch changes gdb to handle this scenario. Data symbols coming
from ELF shared libraries get a special flag that indicates that the
symbol's address may be subject to copy relocation.
I looked briefly into handling copy relocations by looking at the
actual relocations in the main program, but this seemed difficult to
do with BFD.
Note that no caching is done here. Perhaps this could be changed if
need be; I wanted to avoid possible problems with either objfile
lifetimes and changes, or conflicts with the long-term (vapor-ware)
objfile splitting project.
gdb/ChangeLog
2019-10-02 Tom Tromey <tromey@adacore.com>
* symmisc.c (dump_msymbols): Don't use MSYMBOL_VALUE_ADDRESS.
* ada-lang.c (lesseq_defined_than): Handle
LOC_STATIC.
* dwarf2read.c (dwarf2_per_objfile): Add can_copy
parameter.
(dwarf2_has_info): Likewise.
(new_symbol): Set maybe_copied on symbol when
appropriate.
* dwarf2read.h (dwarf2_per_objfile): Add can_copy
parameter.
<can_copy>: New member.
* elfread.c (record_minimal_symbol): Set maybe_copied
on symbol when appropriate.
(elf_symfile_read): Update call to dwarf2_has_info.
* minsyms.c (lookup_minimal_symbol_linkage): New
function.
* minsyms.h (lookup_minimal_symbol_linkage): Declare.
* symtab.c (get_symbol_address, get_msymbol_address):
New functions.
* symtab.h (get_symbol_address, get_msymbol_address):
Declare.
(SYMBOL_VALUE_ADDRESS, MSYMBOL_VALUE_ADDRESS): Handle
maybe_copied.
(struct symbol, struct minimal_symbol) <maybe_copied>:
New member.
This changes current_source_symtab and current_source_line to be
per-program-space. This ensures that switching inferiors will
preserve the current "list" location for that inferior, and also
ensures that the default expression evaluation context always comes
with the current inferior.
No test case, because the latter problem crops up with an existing
gdb.multi test case once this entire series has been applied.
gdb/ChangeLog
2019-10-02 Tom Tromey <tromey@adacore.com>
* source.c (struct current_source_location): New.
(current_source_key): New global.
(current_source_symtab, current_source_line)
(current_source_pspace): Remove.
(get_source_location): New function.
(get_current_source_symtab_and_line)
(set_default_source_symtab_and_line)
(set_current_source_symtab_and_line)
(clear_current_source_symtab_and_line, select_source_symtab)
(info_source_command, print_source_lines_base)
(info_line_command, search_command_helper, _initialize_source):
Update.
select_source_symtab currently calls decode_line_with_current_source.
However, this function iterates over all program spaces, and so it is
possible that it will return a "main" from some other program space.
This patch changes select_source_symtab to simply use the symbol it
already found in the current program space.
gdb/ChangeLog
2019-10-02 Tom Tromey <tromey@adacore.com>
* source.c (select_source_symtab): Don't call
decode_line_with_current_source.
This changes lookup_global_symbol to look in the global block
of the passed-in block. If no block was passed in, it reverts to the
previous behavior.
This change is needed to ensure that 'FILENAME'::NAME lookups work
properly. As debugging Pedro's test case showed, this was not working
properly in the case where multiple identical names could be found
(the one situation where this feature is truly needed :-).
This also removes some old comments from basic_lookup_symbol_nonlocal
that no longer apply.
Note that the new test cases for this change will appear in a later
patch. They are in gdb.base/print-file-var.exp.
gdb/ChangeLog
2019-10-02 Andrew Burgess <andrew.burgess@embecosm.com>
* symtab.c (lookup_global_symbol): Search global block.
This changes SYMBOL_VALUE_ADDRESS to be an rvalue. The symbol readers
generally assign using this, so this also introduces
SET_SYMBOL_VALUE_ADDRESS and updates the readers. Making this change
is useful in a subsequent patch, which redefined SYMBOL_VALUE_ADDRESS.
gdb/ChangeLog
2019-10-02 Tom Tromey <tromey@adacore.com>
* coffread.c (process_coff_symbol): Update.
* dwarf2read.c (var_decode_location, new_symbol): Update.
* mdebugread.c (parse_symbol): Update.
* objfiles.c (relocate_one_symbol): Update.
* stabsread.c (define_symbol, fix_common_block)
(scan_file_globals): Update.
* symtab.h (SYMBOL_VALUE_ADDRESS): Expand to an rvalue.
(SET_SYMBOL_VALUE_ADDRESS): New macro.
* xcoffread.c (process_xcoff_symbol): Update.
My email address at IBM has changed from arnez@linux.vnet.ibm.com to
arnez@linux.ibm.com. Reflect that in the MAINTAINERS file.
gdb/ChangeLog:
* MAINTAINERS: Update my email address.
Removes a use of VEC from dwarf2read.{c,h} and replaces it with
std::vector. As far as possible this is a like for like replacement
with minimal refactoring.
There should be no user visible changes after this commit.
gdb/ChangeLog:
* dwarf2read.c (struct type_unit_group) <tus>: Convert to
std::vector.
(build_type_psymtabs_reader): Update for std::vector.
(build_type_psymtab_dependencies): Likewise.
* dwarf2read.h: Remove use of DEF_VEC_P.
(typedef sig_type_ptr): Delete.
Replace a VEC with a std::vector in btrace.h, and update btrace.c to
match. It is worth noting that this code appears to be currently
untested by the GDB testsuite. I've tried to do a like for like
replacement when moving to std::vector, with minimal refactoring to
try and avoid introducing any bugs.
As the new vector is inside a union I've currently used a pointer to
vector, which makes the code slightly uglier than it might otherwise
be, but again, due to lack of testing I'm reluctant to start
refactoring the code in a big way.
gdb/ChangeLog:
* btrace.c (btrace_maint_clear): Update to handle change from VEC
to std::vector.
(btrace_maint_decode_pt): Likewise, and move allocation of the
vector outside of the loop.
(btrace_maint_update_packets): Update to handle change from VEC to
std::vector.
(btrace_maint_print_packets): Likewise.
(maint_info_btrace_cmd): Likewise.
* btrace.h: Remove use of DEF_VEC_O.
(typedef btrace_pt_packet_s): Delete.
(struct btrace_maint_info) <packets>: Change fromm VEC to
std::vector.
* gdbsupport/btrace-common.h: Remove 'vec.h' include.
Converts a VEC into a std::vector in gdbsupport/btrace-common.h. This
commit just performs a mechanical conversion and doesn't do any
refactoring. One consequence of this is that the std::vector must
actually be a pointer to std::vector as it is placed within a union.
It might be possible in future to refactor to a class hierarchy and
remove the need for a union, but I'd rather have that be a separate
change to make it easier to see the evolution of the code.
gdb/ChangeLog:
* btrace.c (btrace_compute_ftrace_bts): Update for std::vector,
make accesses into the vector constant references.
(btrace_add_pc): Update for std::vector.
(btrace_stitch_bts): Likewise.
(parse_xml_btrace_block): Likewise.
(btrace_maint_update_packets): Likewise.
(btrace_maint_print_packets): Likewise.
(maint_info_btrace_cmd): Likewise.
* gdbsupport/btrace-common.c (btrace_data::fini): Update for
std::vector.
(btrace_data::empty): Likewise.
(btrace_data_append): Likewise.
* gdbsupport/btrace-common.h: Remove use of DEF_VEC_O.
(typedef btrace_block_s): Delete.
(struct btrace_block): Add constructor.
(struct btrace_data_bts) <blocks>: Change to std::vector.
* nat/linux-btrace.c (perf_event_read_bts): Update for
std::vector.
(linux_read_bts): Likewise.
gdb/gdbserver/ChangeLog:
* linux-low.c (linux_low_read_btrace): Update for change to
std::vector.
This changes "show logging filename" to style its output.
gdb/ChangeLog
2019-10-01 Tom Tromey <tom@tromey.com>
* cli/cli-logging.c (show_logging_filename): Use styled_string.
gdb/testsuite/ChangeLog
2019-10-01 Tom Tromey <tom@tromey.com>
* gdb.base/style.exp: Test "show logging filename".
This adds more uses of styled_string, changing gdb to style some
output that was previously left unstyled.
gdb/ChangeLog
2019-10-01 Tom Tromey <tom@tromey.com>
* stack.c (print_frame, info_frame_command_core): Use
styled_string.
* linux-thread-db.c (try_thread_db_load_1)
(try_thread_db_load_from_pdir_1): Use styled_string.
* auto-load.c (file_is_auto_load_safe, execute_script_contents)
(auto_load_section_scripts, info_auto_load_local_gdbinit)
(maybe_print_unsupported_script_warning)
(maybe_print_script_not_found_warning): Use styled_string.
* ada-lang.c (user_select_syms): Use styled_string.
This introduces a new "metadata" style and changes many places in gdb
to use it. The idea here is to let the user distinguish gdb output
from output that (conceptually at least) comes directly from the
inferior. The newly-styled category includes text that gdb
traditionally surrounds in "<...>", like "<unavailable>".
I only added a single test for this. In many cases this output is
difficult to test. Also, while developing this errors in the
implementation of the new printf formats showed up as regressions.
gdb/ChangeLog
2019-10-01 Tom Tromey <tom@tromey.com>
* p-lang.c (pascal_printstr): Use metadata style.
* value.c (show_convenience): Use metadata style.
* valprint.c (valprint_check_validity, val_print_optimized_out)
(val_print_not_saved, val_print_unavailable)
(val_print_invalid_address, generic_val_print, val_print)
(value_check_printable, val_print_array_elements): Use metadata
style.
* ui-out.h (class ui_out) <field_fmt>: New overload.
<do_field_fmt>: Add style parameter.
* ui-out.c (ui_out::field_fmt): New overload.
* typeprint.c (type_print_unknown_return_type)
(val_print_not_allocated, val_print_not_associated): Use metadata
style.
* tui/tui-out.h (class tui_ui_out) <do_field_fmt>: Add style
parameter.
* tui/tui-out.c (tui_ui_out::do_field_fmt): Update.
* tracepoint.c (tvariables_info_1): Use metadata style.
* stack.c (print_frame_arg, print_frame_info, print_frame)
(info_frame_command_core): Use metadata style.
* skip.c (info_skip_command): Use metadata style.
* rust-lang.c (rust_print_enum): Use metadata style.
* python/py-prettyprint.c (print_stack_unless_memory_error): Use
metadata style.
* python/py-framefilter.c (py_print_single_arg): Use metadata
style.
* printcmd.c (do_one_display, print_variable_and_value): Use
metadata style.
* p-valprint.c (pascal_val_print)
(pascal_object_print_value_fields): Use metadata style.
* p-typeprint.c (pascal_type_print_base): Use metadata style.
* mi/mi-out.h (class mi_ui_out) <do_field_fmt>: Add style
parameter.
* mi/mi-out.c (mi_ui_out::do_field_fmt): Update.
* m2-valprint.c (m2_print_long_set): Use metadata style.
* m2-typeprint.c (m2_print_type): Use metadata style.
* infcmd.c (print_return_value_1): Use metadata style.
* gnu-v3-abi.c (print_one_vtable): Use metadata style.
* f-valprint.c (info_common_command_for_block): Use metadata
style.
* f-typeprint.c (f_type_print_base): Use metadata style.
* expprint.c (print_subexp_standard): Use metadata style.
* cp-valprint.c (cp_print_value_fields): Use metadata style.
* cli/cli-style.h (class cli_style_option): Add constructor.
(metadata_style): Declare.
* cli/cli-style.c (metadata_style): New global.
(_initialize_cli_style): Register metadata style.
* cli-out.h (class cli_ui_out) <do_field_fmt>: Add style
parameter.
* cli-out.c (cli_ui_out::do_field_fmt): Update.
* c-typeprint.c (c_type_print_base_struct_union)
(c_type_print_base_1): Use metadata style.
* breakpoint.c (watchpoint_value_print)
(print_one_breakpoint_location): Use metadata style.
* break-catch-syscall.c (print_one_catch_syscall): Use metadata
style.
* break-catch-sig.c (signal_catchpoint_print_one): Use metadata
style.
* ada-valprint.c (val_print_packed_array_elements, printstr)
(print_field_values, ada_val_print_ref, ada_val_print): Use
metadata style.
* ada-typeprint.c (print_array_type, ada_print_type): Use metadata
style.
* ada-tasks.c (print_ada_task_info, info_task): Use metadata
style.
* ada-lang.c (user_select_syms): Use metadata style.
gdb/testsuite/ChangeLog
2019-10-01 Tom Tromey <tom@tromey.com>
* lib/gdb-utils.exp (style): Handle "metadata" argument.
* gdb.base/style.exp: Add metadata style test.
This changes the "pwd" command to style its output.
gdb/ChangeLog
2019-10-01 Tom Tromey <tom@tromey.com>
* cli/cli-cmds.c (pwd_command): Style output.
gdb/testsuite/ChangeLog
2019-10-01 Tom Tromey <tom@tromey.com>
* gdb.base/style.exp: Test "pwd".
This changes various spots in gdb to use the new %p format suffixes.
gdb/ChangeLog
2019-10-01 Pedro Alves <palves@redhat.com>
Tom Tromey <tom@tromey.com>
* symtab.c (print_symbol_info): Use %ps.
(print_msymbol_info): Use %ps.
* symfile.c (symbol_file_add_with_addrs): Use %ps.
* printcmd.c (print_variable_and_value): Use %ps.
* macrocmd.c (show_pp_source_pos): Use %ps.
* infrun.c (print_exited_reason): Use ui_out::message.
* breakpoint.c (watchpoint_check, print_one_breakpoint_location)
(describe_other_breakpoints): Use ui_out::message and new
formats.
(say_where): Use new formats.
(bkpt_print_it, tracepoint_print_one_detail): Use ui_out::message
and new formats.
This introduces a few gdb-specific %p format suffixes. This is useful
for emitting gdb-specific output in an ergonomic way. It also yields
code that is more i18n-friendly.
The comment before ui_out::message explains the details.
Note that the tests had to change a little. When using one of the gdb
printf functions with styling, there can be spurious style changes
emitted to the output. This did not seem worthwhile to fix, as the
low-level output functions are rather spaghetti-ish already, and I
didn't want to make them even worse.
This change also necessitated adding support for "*" as precision and
width in format_pieces. These are used in various spots in gdb, and
it seemed better to me to implement them than to remove the uses.
gdb/ChangeLog
2019-10-01 Pedro Alves <palves@redhat.com>
Tom Tromey <tom@tromey.com>
* unittests/format_pieces-selftests.c: Add gdb_format parameter.
(test_gdb_formats): New function.
(run_tests): Call it.
(test_format_specifier): Update.
* utils.h (fputs_filtered): Update comment.
(vfprintf_styled, vfprintf_styled_no_gdbfmt)
(fputs_styled_unfiltered): Declare.
* utils.c (fputs_styled_unfiltered): New function.
(vfprintf_maybe_filtered): Add gdbfmt parameter.
(vfprintf_filtered): Update.
(vfprintf_unfiltered, vprintf_filtered): Update.
(vfprintf_styled, vfprintf_styled_no_gdbfmt): New functions.
* ui-out.h (enum ui_out_flag) <unfiltered_output,
disallow_ui_out_field>: New constants.
(enum class field_kind): New.
(struct base_field_s, struct signed_field_s): New.
(signed_field): New function.
(struct string_field_s): New.
(string_field): New function.
(struct styled_string_s): New.
(styled_string): New function.
(class ui_out) <message>: Add comment.
<vmessage, call_do_message>: New methods.
<do_message>: Add style parameter.
* ui-out.c (ui_out::call_do_message, ui_out::vmessage): New
methods.
(ui_out::message): Rewrite.
* mi/mi-out.h (class mi_ui_out) <do_message>: Add style
parameter.
* mi/mi-out.c (mi_ui_out::do_message): Add style parameter.
* gdbsupport/format.h (class format_pieces) <format_pieces>: Add
gdb_extensions parameter.
(class format_piece): Add parameter to constructor.
(n_int_args): New field.
* gdbsupport/format.c (format_pieces::format_pieces): Add
gdb_extensions parameter. Handle '*'.
* cli-out.h (class cli_ui_out) <do_message>: Add style parameter.
* cli-out.c (cli_ui_out::do_message): Add style parameter. Call
vfprintf_styled_no_gdbfmt.
(cli_ui_out::do_field_string, cli_ui_out::do_spaces)
(cli_ui_out::do_text, cli_ui_out::field_separator): Allow
unfiltered output.
* ui-style.h (struct ui_file_style) <ptr>: New method.
gdb/testsuite/ChangeLog
2019-10-01 Tom Tromey <tom@tromey.com>
* gdb.base/style.exp: Update tests.
I noticed that format_pieces can create an empty literal piece.
However, there's never a need for one, so this patch removes the
possibility.
gdb/ChangeLog
2019-10-01 Tom Tromey <tom@tromey.com>
* unittests/format_pieces-selftests.c: Update. Add final format.
* gdbsupport/format.c (format_pieces::format_pieces): Don't add
empty literal pieces.
The pretty-print test case fails on s390/s390x because it relies on a
little-endian representation of bit fields. Little-endian architectures
typically allocate bit fields from least to most significant bit, but
big-endian architectures typically use the reverse order, allocating the
most significant bit first. Thus the two bit fields in each of the test
case's unions overlap either in their lower or in their higher bits,
depending on the target's endianness:
union {
int three : 3;
int four : 4;
};
Now, when initializing 'three' with 3, 'four' will become 3 on little
endian targets, but 6 on big-endian targets, making it FAIL there.
Fix this by initializing the longer bit field instead and using an
all-ones bit pattern. In this way the result does not depend on
endianness. Use 'unsigned' instead of int for one of the bit fields in
each of the unions, to increase the variety of resulting values.
gdb/testsuite/ChangeLog:
* gdb.base/pretty-print.c (struct s1_t): Change fields 'three' and
'six' to unsigned.
(s1): Initialize fields 'four' and 'six' instead of 'three' and
'five'. Use an all-ones bit pattern for each.
* gdb.base/pretty-print.exp: Adjust expected output of "print s1"
to its changed values.
Valgrind reports the following leak:
==32623== 56 bytes in 1 blocks are definitely lost in loss record 1,099 of 6,654
==32623== at 0x4835753: malloc (vg_replace_malloc.c:307)
==32623== by 0x25CF67: xmalloc (alloc.c:60)
==32623== by 0x65FBD9: xstrdup (xstrdup.c:34)
==32623== by 0x413D9E: captured_main_1(captured_main_args*) (main.c:553)
==32623== by 0x414FFA: captured_main (main.c:1172)
==32623== by 0x414FFA: gdb_main(captured_main_args*) (main.c:1197)
==32623== by 0x22531A: main (gdb.c:32)
Commit f2aec7f6d1 changed gdb_datadir to std::string.
So, xstrdup-ing the result of relocate_gdb_directory (returning a std::string)
is not needed and creates a leak.
Fix the leak by removing the xstrdup and the not needed c_str ().
Also removes a useless conversion of gdb_datadir to std::string.
gdb/ChangeLog
2019-10-01 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* main.c (relocate_gdbinit_path_maybe_in_datadir): Remove std::string
conversion of gdb_datadir.
(captured_main_1): Remove xstrdup when assigning to gdb_datadir,
remove not needed c_str ().
* Handle DW_FORM_strx forms everywhere.
Tested with CC=/usr/bin/gcc (version 8.3.0) against master branch (also with
-gsplit-dwarf and -gdwarf-4 flags) and there was no increase in the set of
tests that fails.
This is part of an effort to support DWARF 5 in gdb.
gdb/ChangeLog:
* dwarf2read.c (skip_one_die): Handle DW_FORM_strx forms.
(dwarf2_string_attr): Likewise.
This has better typesafety and is also marginally faster (either
due to inlining or because it avoids indirection through a
function pointer).
Note that in this change:
- return 1; /* fn1 has no name, so it is "less". */
+ return true; /* fn1 has no name, so it is "less". */
else if (name1) /* fn2 has no name, so it is "less". */
- return -1;
+ return false;
I am fairly sure the old code was wrong (ie. code didn't match the
comment and the comment seemed correct), so I fixed it.
gdb/ChangeLog:
2019-09-28 Christian Biesinger <cbiesinger@google.com>
* minsyms.c (compare_minimal_symbols): Rename to...
(minimal_symbol_is_less_than): ...this, and adjust to STL
conventions (return bool, take arguments as references)
(minimal_symbol_reader::install): Call std::sort instead
of qsort.
With rustc 1.37, I started seeing compiler warnings from the traits.rs
test case:
warning: trait objects without an explicit `dyn` are deprecated
It seems to me that we generally do not want warnings in these test
cases. At some point, we'll probably have to patch traits.rs to use
the "dyn" keyword; by that time I expect that all the Rust compilers
in common use will support it. In the meantime it seemed simplest to
simply disable all warnings in this file.
gdb/testsuite/ChangeLog
2019-09-30 Tom Tromey <tromey@adacore.com>
* gdb.rust/traits.rs: Disable all warnings.
This just clarifies some comments about the hashtables involved
in msymbols.
gdb/ChangeLog:
2019-09-29 Christian Biesinger <cbiesinger@google.com>
* minsyms.h (msymbol_hash): Document that this is a case-insensitive
hash and why.
* objfiles.h (struct objfile_per_bfd_storage) <demangled_names_hash,
msymbol_hash, msymbol_demangled_hash>: Improve comments.
The comment above the add_psymbol_to_list function seems outdated and
misleading, here's an attempt at improving it.
gdb/ChangeLog:
* psymtab.c (add_psymbol_to_list): Move comment to psympriv.h.
* psympriv.h (add_psymbol_to_list): Move comment here and update
it.
When running a test-case gdb.base/foo.exp with cc-with-dwz-m, a file
build/gdb/testsuite/outputs/gdb.base/foo/foo.dwz will be created, alongside
executable build/gdb/testsuite/outputs/gdb.base/foo/foo.
This can cause problems in f.i. test-cases that test file name completion.
Make these problems less likely by moving foo.dwz to a .tmp subdir:
build/gdb/testsuite/outputs/gdb.base/foo/.tmp/foo.dwz.
Tested on x86_64-linux.
gdb/ChangeLog:
2019-09-29 Tom de Vries <tdevries@suse.de>
* contrib/cc-with-tweaks.sh (get_tmpdir): New function.
Use $tmpdir/$(basename "$output_file").dwz instead of
"${output_file}.dwz".
gdb/testsuite/ChangeLog:
2019-09-29 Tom de Vries <tdevries@suse.de>
* gdb.dwarf2/gdb-index.exp: Handle new location of .dwz file.
With cc-with-dwz-m, we get:
...
PASS: gdb.dwarf2/gdb-index.exp: objcopy
PASS: gdb.dwarf2/gdb-index.exp: objcopy
...
Make the pass message unique by using with_test_prefix:
...
PASS: gdb.dwarf2/gdb-index.exp: objcopy
PASS: gdb.dwarf2/gdb-index.exp: modify dwz file: objcopy
...
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-09-29 Tom de Vries <tdevries@suse.de>
* gdb.dwarf2/gdb-index.exp: Use with_test_prefix for second objcopy.
hppa-linux-nat.c fails to build due to the gdbarch stuff not being
declared, for example:
hppa-linux-nat.c: In function ‘void fetch_register(regcache*, int)’:
hppa-linux-nat.c:230:7: error: ‘gdbarch_cannot_fetch_register’ was not declared in this scope
if (gdbarch_cannot_fetch_register (gdbarch, regno))
Include gdbarch.h to fix it.
gdb/ChangeLog:
PR gdb/25045
* hppa-linux-nat.c: Include gdbarch.h.
The commit 68f7d34dd5 "[gdb/testsuite] Add KFAIL for missing support of
reverse-debugging of vmovd" rewrites a gdb_test into a gdb_test_multiple but
forgets to add the $gdb_prompt part in the regexp.
Add the missing parts of the regexps.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-09-27 Tom de Vries <tdevries@suse.de>
* gdb.reverse/step-precsave.exp: Add missing $gdb_prompt in regexps.
On my openSUSE Leap 15.1 system I run into:
...
(gdb) PASS: gdb.reverse/step-precsave.exp: turn on process record
break 76^M
Breakpoint 2 at 0x400654: file step-reverse.c, line 76.^M
(gdb) PASS: gdb.reverse/step-precsave.exp: breakpoint at end of main
continue^M
Continuing.^M
Process record does not support instruction 0xc5 at address 0x7ffff783fc70.^M
Process record: failed to record execution log.^M
^M
Program stopped.^M
0x00007ffff783fc70 in __memset_avx2_unaligned_erms () from /lib64/libc.so.6^M
(gdb) FAIL: gdb.reverse/step-precsave.exp: run to end of main
...
The problem is that the vmovd instruction is not supported in
reverse-debugging (PR record/23188).
Add a KFAIL for this PR.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-09-27 Tom de Vries <tdevries@suse.de>
PR record/23188
* gdb.reverse/step-precsave.exp: Add kfail for PR record/23188.
In Fedora GDB, we carry the following patch:
8ac06474ff/f/gdb-attach-fail-reasons-5of5.patch
Its purpose is to try to detect a specific scenario where SELinux's
'deny_ptrace' option is enabled, which prevents GDB from ptrace'ing in
order to debug the inferior (PTRACE_ATTACH and PTRACE_TRACEME will
fail with EACCES in this case).
I like the idea of improving error detection and providing more
information to the user (a simple "Permission denied" can be really
frustrating), but I don't fully agree with the way the patch was
implemented: it makes GDB link against libselinux only for the sake of
consulting the 'deny_ptrace' setting, and then prints a warning if
ptrace failed and this setting is on.
My first thought (and attempt) was to make GDB print a generic warning
when a ptrace error happened; this message would just point the user
to our documentation, where she could find more information about
possible causes for the error (and try to diagnose/fix the problem).
This proved to be too simple, and I was convinced that it is actually
a good idea to go the extra kilometre and try to pinpoint the specific
problem (or problems) preventing ptrace from working, as well as
provide useful suggestions on how the user can fix things.
Here is the patch I came up with. It implements a new function,
'linux_ptrace_restricted_fail_reason', which does a few things to
check what's wrong with ptrace:
- It dlopen's "libselinux.so.1" and checks if the "deny_ptrace"
option is enabled.
- It reads the contents of "/proc/sys/kernel/yama/ptrace_scope" and
checks if it's different than 0.
For each of these checks, if it succeeds, the user will see a message
informing about the restriction in place, and how it can be disabled.
For example, if "deny_ptrace" is enabled, the user will see:
# gdb /usr/bin/true
...
Starting program: /usr/bin/true
warning: Could not trace the inferior process.
warning: ptrace: Permission denied
The SELinux 'deny_ptrace' option is enabled and preventing GDB
from using 'ptrace'. You can disable it by executing (as root):
setsebool deny_ptrace off
If you are debugging the inferior remotely, the ptrace restriction(s) need
to be disabled in the target system (e.g., where GDBserver is running).
During startup program exited with code 127.
(gdb)
In case "/proc/sys/kernel/yama/ptrace_scope" is > 0:
# gdb /usr/bin/true
...
Starting program: /usr/bin/true
warning: Could not trace the inferior process.
warning: ptrace: Operation not permitted
The Linux kernel's Yama ptrace scope is in effect, which can prevent
GDB from using 'ptrace'. You can disable it by executing (as root):
echo 0 > /proc/sys/kernel/yama/ptrace_scope
If you are debugging the inferior remotely, the ptrace restriction(s) need
to be disabled in the target system (e.g., where GDBserver is running).
During startup program exited with code 127.
(gdb)
If both restrictions are enabled, both messages will show up.
This works for gdbserver as well, and actually fixes a latent bug I
found: when ptrace is restricted, gdbserver would hang due to an
unchecked ptrace call:
# gdbserver :9988 /usr/bin/true
gdbserver: linux_ptrace_test_ret_to_nx: Cannot PTRACE_TRACEME: Operation not permitted
gdbserver: linux_ptrace_test_ret_to_nx: status 256 is not WIFSTOPPED!
gdbserver: linux_ptrace_test_ret_to_nx: failed to kill child pid 2668100 No such process
[ Here you would have to issue a C-c ]
Now, you will see:
# gdbserver :9988 /usr/bin/true
gdbserver: linux_ptrace_test_ret_to_nx: Cannot PTRACE_TRACEME: Permission denied
gdbserver: linux_ptrace_test_ret_to_nx: status 256 is not WIFSTOPPED!
gdbserver: linux_ptrace_test_ret_to_nx: failed to kill child pid 2766868 No such process
gdbserver: Could not trace the inferior process.
gdbserver: ptrace: Permission denied
The SELinux 'deny_ptrace' option is enabled and preventing GDB
from using 'ptrace'. You can disable it by executing (as root):
setsebool deny_ptrace off
If you are debugging the inferior remotely, the ptrace restriction(s) need
to be disabled in the target system (e.g., where GDBserver is running).
#
(I decided to keep all the other messages, even though I find them a
bit distracting).
If GDB can't determine the cause for the failure, it will still print
the generic error message which tells the user to check our
documentation:
There might be restrictions preventing ptrace from working. Please see
the appendix "Linux kernel ptrace restrictions" in the GDB documentation
for more details.
If you are debugging the inferior remotely, the ptrace restriction(s) need
to be disabled in the target system (e.g., where GDBserver is running).
This means that the patch expands our documentation and creates a new
appendix section named "Linux kernel ptrace restrictions", with
sub-sections for each possible restriction that might be in place.
Notice how, on every message, we instruct the user to "do the right
thing" if gdbserver is being used. This is because if the user
started gdbserver *before* any ptrace restriction was in place, and
then, for some reason, one or more restrictions get enabled, then the
error message will be displayed both on gdbserver *and* on the
connected GDB. Since the user will be piloting GDB, it's important to
explicitly say that the ptrace restrictions are enabled in the target,
where gdbserver is running.
The current list of possible restrictions is:
- SELinux's 'deny_ptrace' option (detected).
- YAMA's /proc/sys/kernel/yama/ptrace_scope setting (detected).
- seccomp on Docker containers (I couldn't find how to detect).
It's important to mention that all of this is Linux-specific; as far
as I know, SELinux, YAMA and seccomp are Linux-only features.
I tested this patch locally, on my Fedora 30 machine (actually, a
Fedora Rawhide VM), but I'm not proposing a testcase for it because of
the difficulty of writing one.
WDYT?
gdb/doc/ChangeLog:
2019-09-26 Sergio Durigan Junior <sergiodj@redhat.com>
* gdb.texinfo (Linux kernel ptrace restrictions): New appendix
section.
gdb/ChangeLog:
2019-09-26 Sergio Durigan Junior <sergiodj@redhat.com>
Jan Kratochvil <jan.kratochvil@redhat.com>
Pedro Alves <palves@redhat.com>
* gdbsupport/gdb-dlfcn.h (gdb_dlopen): Update comment and
mention that the function throws an error.
* inf-ptrace.c (default_inf_ptrace_me_fail_reason): New
function.
(inf_ptrace_me_fail_reason): New variable.
(inf_ptrace_me): Update call to 'trace_start_error_with_name'.
* inf-ptrace.h (inf_ptrace_me_fail_reason): New variable.
* linux-nat.c (attach_proc_task_lwp_callback): Call
'linux_ptrace_attach_fail_reason_lwp'.
(linux_nat_target::attach): Update call to
'linux_ptrace_attach_fail_reason'.
(_initialize_linux_nat): Set 'inf_ptrace_me_fail_reason'.
* nat/fork-inferior.c (trace_start_error_with_name): Add
optional 'append' argument.
* nat/fork-inferior.h (trace_start_error_with_name): Update
prototype.
* nat/linux-ptrace.c: Include "gdbsupport/gdb-dlfcn.h",
"gdbsupport/filestuff.h" and "nat/fork-inferior.h".
(selinux_ftype): New typedef.
(linux_ptrace_restricted_fail_reason): New function.
(linux_ptrace_attach_fail_reason_1): New function.
(linux_ptrace_attach_fail_reason): Change first argument type
from 'ptid_t' to 'pid_t'. Call
'linux_ptrace_attach_fail_reason_1' and
'linux_ptrace_restricted_fail_reason'.
(linux_ptrace_attach_fail_reason_lwp): New function.
(linux_ptrace_me_fail_reason): New function.
(errno_pipe): New variable.
(linux_fork_to_function): Initialize pipe before forking.
(linux_child_function): Deal with errno-passing from child.
Handle ptrace error.
(linux_check_child_ptrace_errno): New function.
(linux_check_child_ptrace_errno): Call
'linux_check_child_ptrace_errno'.
* nat/linux-ptrace.h (linux_ptrace_attach_fail_reason): Update
prototype.
(linux_ptrace_attach_fail_reason_lwp): New prototype.
(linux_ptrace_me_fail_reason): New prototype.
* remote.c (extended_remote_target::attach): Handle error
message passed by the server when attach fails.
gdb/gdbserver/ChangeLog:
2019-09-26 Sergio Durigan Junior <sergiodj@redhat.com>
Pedro Alves <palves@redhat.com>
* linux-low.c (linux_ptrace_fun): Call
'linux_ptrace_me_fail_reason'.
(attach_proc_task_lwp_callback): Call
'linux_ptrace_attach_fail_reason_lwp'.
(linux_attach): Call 'linux_ptrace_attach_fail_reason'.
* server.c (handle_v_attach): Use try..catch when calling
'attach_inferior', and send an error message to the client
when needed.
* thread-db.c (attach_thread): Call
'linux_ptrace_attach_fail_reason_lwp'.
I noticed that gdb_usleep is unused, so this patch removes it.
gdb/ChangeLog
2019-09-26 Tom Tromey <tom@tromey.com>
* Makefile.in (COMMON_SFILES): Remove gdb_usleep.c.
(HFILES_NO_SRCDIR): Remove gdb_usleep.h.
* gdb_usleep.h: Remove.
* gdb_usleep.c: Remove.
* utils.c: Don't include gdb_usleep.h.
dwarf2read.c will create stub types for Ada "Taft Amendment" types.
These stub types can currently be exposed to Python code, where they
show up as TYPE_CODE_VOID types (but that, mysteriously, can sometimes
be used in other ways).
While it's possible to work with such types by using strip_typedefs,
this seemed unpleasant to me. This patch takes another approach
instead, which is to try not to expose stub types to Python users.
gdb/ChangeLog
2019-09-26 Tom Tromey <tromey@adacore.com>
* python/py-type.c (type_to_type_object): Call check_typedef
for stub types.
gdb/testsuite/ChangeLog
2019-09-26 Tom Tromey <tromey@adacore.com>
* gdb.ada/py_taft.exp: New file.
* gdb.ada/py_taft/main.adb: New file.
* gdb.ada/py_taft/pkg.adb: New file.
* gdb.ada/py_taft/pkg.ads: New file.
initialize_utils only registers some commands, so it isn't necessary
to run it at any particular time during startup. This patch removes
it and merges its contents into _initialize_utils.
Tested by the buildbot.
gdb/ChangeLog
2019-09-26 Tom Tromey <tom@tromey.com>
* utils.h (initialize_utils): Don't declare.
* top.c (gdb_init): Don't call initialize_utils.
* utils.c (initialize_utils): Remove. Move contents...
(_initialize_utils): ... here.
I noticed that make_hex_string does essentially the same thing as
bin2hex, and furthermore is only called in a single spot. This patch
removes make_hex_string.
Tested by the builtbot.
gdb/ChangeLog
2019-09-25 Tom Tromey <tom@tromey.com>
* python/py-objfile.c (objfpy_get_build_id): Use bin2hex.
* utils.h (make_hex_string): Don't declare.
* utils.c (make_hex_string): Remove.
On my openSUSE Leap 15.1 x86_64 Skylake system with the default (4.12) kernel,
I run into:
...
FAIL: gdb.base/gcore.exp: corefile restored all registers
...
The problem is that there's a difference in the mxcsr register value before
and after the gcore command:
...
- mxcsr 0x0 [ ]
+ mxcsr 0x400440 [ DAZ OM ]
...
This can be traced back to amd64_linux_nat_target::fetch_registers, where
xstateregs is partially initialized by the ptrace call:
...
char xstateregs[X86_XSTATE_MAX_SIZE];
struct iovec iov;
amd64_collect_xsave (regcache, -1, xstateregs, 0);
iov.iov_base = xstateregs;
iov.iov_len = sizeof (xstateregs);
if (ptrace (PTRACE_GETREGSET, tid,
(unsigned int) NT_X86_XSTATE, (long) &iov) < 0)
perror_with_name (_("Couldn't get extended state status"));
amd64_supply_xsave (regcache, -1, xstateregs);
...
after which amd64_supply_xsave is called.
The amd64_supply_xsave call is supposed to only use initialized parts of
xstateregs, but due to a kernel bug on intel skylake (fixed from 4.14 onwards
by commit 0852b374173b "x86/fpu: Add FPU state copying quirk to handle XRSTOR
failure on Intel Skylake CPUs") it can happen that the mxcsr part of
xstateregs is not initialized, while amd64_supply_xsave expects it to be
initialized, which explains the FAIL mentioned above.
Fix the undetermined behaviour by initializing xstateregs before calling
ptrace, which makes sure we get a 0x0 for mxcsr when this kernel bug occurs,
and which also happens to fix the FAIL.
Furthermore, add an xfail for this FAIL which triggers the same kernel bug:
...
FAIL: gdb.arch/amd64-init-x87-values.exp: check_setting_mxcsr_before_enable: \
check new value of MXCSR is still in place
...
Both FAILs pass when using a 5.3 kernel instead on the system mentioned above.
Tested on x86_64-linux.
gdb/ChangeLog:
2019-09-24 Tom de Vries <tdevries@suse.de>
PR gdb/23815
* amd64-linux-nat.c (amd64_linux_nat_target::fetch_registers):
Initialize xstateregs before ptrace PTRACE_GETREGSET call.
gdb/testsuite/ChangeLog:
2019-09-24 Tom de Vries <tdevries@suse.de>
PR gdb/24598
* gdb.arch/amd64-init-x87-values.exp: Add xfail.
This makes it safer to use in general, and also allows using it on a
background thread in the future.
Inspired by tromey's patch at:
1226cbdfa4
(however, implemented in a different way)
gdb/ChangeLog:
2019-09-23 Christian Biesinger <cbiesinger@google.com>
* ada-exp.y (write_object_remaining): Update.
* ada-lang.c (ada_decode): Return a std::string instead of a char*
and eliminate the static buffer.
(ada_decode_symbol): Update.
(ada_la_decode): Update.
(ada_sniff_from_mangled_name): Update.
(is_valid_name_for_wild_match): Update.
(ada_lookup_name_info::matches): Update and simplify.
(name_matches_regex): Update.
(ada_add_global_exceptions): Update.
* ada-lang.h (ada_decode): Update signature.
* ada-varobj.c (ada_varobj_describe_simple_array_child): Update.
* dwarf-index-write.c (debug_names::insert): Update.
We currently run into:
...
248 n = callee1 (n + l5);
(gdb) PASS: gdb.base/restore.exp: caller5 calls callee1; return callee now
print l1
$51 = <optimized out>
(gdb) FAIL: gdb.base/restore.exp: caller5 calls callee1; return restored l1 \
to 32492
...
The problem is that we try to access the value of l1 in function caller5, but
variable l1 has no DW_AT_location attribute. Since l1 is declared using the
register keyword, it's valid for gcc to emit no DW_AT_location at -O0.
Change the FAIL into an UNSUPPORTED.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-09-22 Tom de Vries <tdevries@suse.de>
* gdb.base/restore.exp: Allow register variables to be optimized out at
-O0.
These int fields have been converted to bool, so their doc should say
"true" and not "nonzero".
gdb/ChangeLog:
* breakpoint.h (bp_location) <inserted, permanent, duplicate>:
Change "nonzero" to "true" in documentation.
All implementations of either function use it for the same purpose (except
Darwin, which is a no-op): to prefer a symbol in the current objfile over
symbols with the same name in other objfiles. There does not seem to be a
reason to have both mechanisms for that purpose.
gdb/ChangeLog:
2019-09-20 Christian Biesinger <cbiesinger@google.com>
* solib-darwin.c (darwin_lookup_lib_symbol): Remove.
(_initialize_darwin_solib): Don't set
darwin_so_ops.lookup_lib_global_symbol.
* solib-svr4.c (set_solib_svr4_fetch_link_map_offsets): Call
set_gdbarch_iterate_over_objfiles_in_search_order.
(elf_lookup_lib_symbol): Rename to...
(svr4_iterate_over_objfiles_in_search_order): this, and update
to iterate semantics.
(_initialize_svr4_solib): Don't set lookup_lib_global_symbol.
* solib.c (solib_global_lookup): Remove.
* solist.h (struct target_so_ops): Remove lookup_lib_global_symbol.
(solib_global_lookup): Remove.
* symtab.c (lookup_global_or_static_symbol): Remove call to
solib_global_lookup.
Instead of declaring debug_threads and using_threads in several
.c files, declare them in debug.h.
gdb/gdbserver/ChangeLog:
2019-09-20 Christian Biesinger <cbiesinger@google.com>
* debug.c (debug_threads): Remove comment in favor of the header.
* debug.h (using_threads): Add declaration.
(debug_threads): Add comment.
* linux-aarch64-low.c: Include debug.h and remove declaration of
debug_threads.
* nto-low.c: Likewise.
* remote-utils.c: Likewise.
* thread-db.c: Likewise.
This is a followup on the following commit...
commit b4be1b0648
Date: Wed Mar 13 15:13:03 2019 -0400
Subject: Fix MI output for multi-location breakpoints
... which mistakenly added NEWS entries in the "in gdb-8.3" section,
rather than in the "since gdb-8.3" one.
gdb/ChangeLog:
* NEWS: Move entries about default MI version now being
version 3, and about the GDB/MI fix for multi-location
breakpoints to the "since GDB 8.3" section.
The TUI window-related commands like "focus" are case insensitive.
This is not the norm in gdb, and I don't see a good reason to have it
here. This patch changes the TUI to be case sensitive, like the rest
of gdb.
gdb/ChangeLog
2019-09-20 Tom Tromey <tom@tromey.com>
* NEWS: Mention case-sensitivity of TUI commands.
* tui/tui-win.c (tui_set_focus_command): Now case-sensitive.
(tui_set_win_height_command, parse_scrolling_args): Likewise.
* tui/tui-layout.c (tui_layout_command): Now case-sensitive.
This changes a couple of spots in the TUI to use make_unique_xstrdup.
This simplifies the code slightly.
gdb/ChangeLog
2019-09-20 Tom Tromey <tom@tromey.com>
* tui/tui-source.c (tui_source_window::set_contents): Use
make_unique_xstrdup.
* tui/tui-disasm.c (tui_disasm_window::set_contents): Use
make_unique_xstrdup.
This removes various separator comments from the TUI. These aren't
used elsewhere in gdb, and they were incorrect in some cases as well.
gdb/ChangeLog
2019-09-20 Tom Tromey <tom@tromey.com>
* tui/tui-data.c: Remove separator comments.
* tui/tui-layout.c: Remove separator comments.
* tui/tui-win.c: Remove separator comments.
* tui/tui-wingeneral.c: Remove separator comments.
An earlier patch in the series removed the last call to strcat_to_buf,
so this patch removes the function entirely.
gdb/ChangeLog
2019-09-20 Tom Tromey <tom@tromey.com>
* tui/tui.h (strcat_to_buf): Don't declare.
* tui/tui.c (strcat_to_buf): Remove.
This renames tui_source_window::fullname to add the "m_" prefix, as it
is a private data member.
gdb/ChangeLog
2019-09-20 Tom Tromey <tom@tromey.com>
* tui/tui-source.h (struct tui_source_window) <m_fullname>: Rename
from "fullname".
* tui/tui-source.c (tui_source_window::set_contents)
(tui_source_window::location_matches_p)
(tui_source_window::maybe_update): Update.
As Pedro suggested, this patch renames the private data members of
tui_data_window to use the "m_" prefix.
gdb/ChangeLog
2019-09-20 Tom Tromey <tom@tromey.com>
* tui/tui-regs.h (struct tui_data_window) <get_current_group>:
Update.
<m_regs_content, m_regs_column_count, m_current_group>: Add "m_"
prefix.
* tui/tui-regs.c (tui_data_window::last_regs_line_no)
(tui_data_window::line_from_reg_element_no)
(tui_data_window::first_reg_element_no_inline)
(tui_data_window::show_registers)
(tui_data_window::show_register_group)
(tui_data_window::display_registers_from)
(tui_data_window::display_registers_from_line)
(tui_data_window::first_data_item_displayed)
(tui_data_window::delete_data_content_windows)
(tui_data_window::erase_data_content)
(tui_data_window::do_scroll_vertical)
(tui_data_window::refresh_window)
(tui_data_window::check_register_values): Update.
This changes two members of tui_locator_window to have type
std::string. This removes a static limit.
gdb/ChangeLog
2019-09-20 Tom Tromey <tom@tromey.com>
* tui/tui-stack.h (MAX_LOCATOR_ELEMENT_LEN): Remove define.
(struct tui_locator_window) <full_name, proc_name>: Now
std::string.
* tui/tui-stack.c (tui_locator_window::make_status_line)
(tui_locator_window::set_locator_fullname)
(tui_locator_window::set_locator_info): Update.
* tui/tui-source.c (tui_source_window::set_contents)
(tui_source_window::showing_source_p): Update.
Commit e594a5d1 ("Turn two locator functions into methods") turned
set_locator_fullname into a method on tui_locator_window. I missed it
at the time, but this change allows for the removal of a call to
tui_locator_win_info_ptr.
gdb/ChangeLog
2019-09-20 Tom Tromey <tom@tromey.com>
* tui/tui-stack.c (tui_locator_window::set_locator_fullname):
Don't call tui_locator_win_info_ptr.
There's no reason to call refresh in tui_resize_all. This call
flushes the curses window contents to the terminal -- but, because
we're about the resize all the windows, we're going to be sending more
data to the terminal momentarily. This patch removes the call.
gdb/ChangeLog
2019-09-20 Tom Tromey <tom@tromey.com>
* tui/tui-win.c (tui_resize_all): Don't call refresh.
The TUI has long had code to resize the locator, using 2 as the
height. However the code has "1" in a comment, like:
locator->resize (2 /* 1 */ ,
This patch fixes the resizing code to set the height to 1. Doing this
revealed what was probably the reason for setting the height to 2 in
the first place: this caused the locator window to scroll. However,
this is easily handled by calling scrollok on the locator window.
gdb/ChangeLog
2019-09-20 Tom Tromey <tom@tromey.com>
* tui/tui-win.c (tui_resize_all, tui_adjust_win_heights): Use 1 as
height for locator.
* tui/tui-stack.c (tui_locator_window::rerender): Call scrollok.
* tui/tui-layout.c (show_source_disasm_command, show_data)
(show_source_or_disasm_and_command): Use 1 as height for locator.
This changes the "win_resized" global to be a bool and then updates
the uses.
gdb/ChangeLog
2019-09-20 Tom Tromey <tom@tromey.com>
* tui/tui.c (tui_enable): Update.
* tui/tui-win.c (tui_sigwinch_handler, tui_async_resize_screen):
Update.
* tui/tui-data.h (tui_win_resized, tui_set_win_resized_to):
Update.
* tui/tui-data.c (win_resized): Now bool.
(tui_win_resized): Return bool.
(tui_set_win_resized_to): Accept a bool.
This changes tui_data_window::show_register_group to use "bool" rather
than "int".
gdb/ChangeLog
2019-09-20 Tom Tromey <tom@tromey.com>
* tui/tui-regs.h (struct tui_data_window) <show_register_group>:
Change type of "refresh_values_only".
* tui/tui-regs.c (tui_data_window::show_register_group): Change
type of "refresh_values_only".
tui_source_window_base::show_source_content is not used outside the
class any more, so this makes it private. Examining the callers shows
that it can't be called without source contents, so it can be
simplified as well.
gdb/ChangeLog
2019-09-20 Tom Tromey <tom@tromey.com>
* tui/tui-winsource.h (struct tui_source_window_base)
<show_source_content>: Now private.
* tui/tui-winsource.c
(tui_source_window_base::show_source_content): Don't handle empty
content case.
A couple of spots in tui-layout.c still call the show_source_content
method. However, now that re-rendering is done by the resize method,
these calls are no longer needed.
gdb/ChangeLog
2019-09-20 Tom Tromey <tom@tromey.com>
* tui/tui-layout.c (show_source_disasm_command)
(show_source_or_disasm_and_command): Don't call
show_source_content.
This changes tui_make_status_line to be a method on
tui_locator_window. This is a minor cleanup.
This also changes the new method to use the locator's width, rather
than the terminal width. This is important if we ever want to allow
windows to be made more narrow.
gdb/ChangeLog
2019-09-20 Tom Tromey <tom@tromey.com>
* tui/tui-stack.h (struct tui_locator_window) <make_status_line>:
Declare.
* tui/tui-stack.c (tui_locator_window::make_status_line): Rename
from tui_make_status_line.
(tui_locator_window::rerender): Update.
This changes tui_make_status_line to return std::string. This cleans
it up a bit, and removes some explicit memory management.
gdb/ChangeLog
2019-09-20 Tom Tromey <tom@tromey.com>
* tui/tui-stack.c (tui_make_status_line): Return std::string.
(tui_locator_window::rerender): Update.
The "fullname" field in tui_source_window_base is only used by one
subclass. This patch moves the field to that subclass, and changes it
to be a unique_xmalloc_ptr.
gdb/ChangeLog
2019-09-20 Tom Tromey <tom@tromey.com>
* tui/tui-winsource.h (struct tui_source_window_base)
<~tui_source_window_base>: Don't declare.
<fullname>: Remove.
* tui/tui-winsource.c (~tui_source_window_base): Remove.
* tui/tui-source.h (struct tui_source_window) <fullname>: New
member.
* tui/tui-source.c (tui_source_window::set_contents): Update.
(tui_source_window::location_matches_p)
(tui_source_window::maybe_update): Update.
The calls to tui_clear_source_windows_detail in tui_add_win_to_layout
aren't needed, because (after the resize unification) resizing will
update the window contents. Removing these calls lets us remove
several other things as well.
gdb/ChangeLog
2019-09-20 Tom Tromey <tom@tromey.com>
* tui/tui-data.h (tui_clear_source_windows_detail): Don't
declare.
* tui/tui-layout.c (tui_add_win_to_layout): Don't call
tui_clear_source_windows_detail.
* tui/tui-winsource.h (struct tui_source_window_base)
<clear_detail>: Don't declare.
* tui/tui-winsource.c (tui_source_window_base::clear_detail):
Remove.
* tui/tui-data.c (tui_clear_source_windows_detail): Remove.
PR ada/24919 concerns a crash that Tom de Vries noticed when running
the "catch_ex" Ada test case. He sent a test executable and tracked
this down to commit f21c2bd7b7 ("Fix Fortran regression with variables
in nested functions").
Looking at that patch, you can see the obvious error:
- return 0;
+ return true;
Oops! This patch fixes the bug.
Tested on x86-64 Fedora 29.
gdb/ChangeLog
2019-09-20 Tom Tromey <tromey@adacore.com>
PR ada/24919:
* block.c (contained_in): Fix final return value.
The variable is defined in valops.c and has an extern decl in
eval.c; move it to the header file.
gdb/ChangeLog:
2019-09-19 Christian Biesinger <cbiesinger@google.com>
* eval.c: Move declaration of overload_resolution to...
* value.h: ...here.
Instead of having several extern declarations for arm_apcs_32
in a few .c files, declare it in arm-tdep.h. This file is already
included from these .c files.
gdb/ChangeLog:
2019-09-19 Christian Biesinger <cbiesinger@google.com>
* arm-linux-nat.c: Remove extern declaration for arm_apcs_32.
* arm-linux-tdep.c: Likewise.
* arm-nbsd-nat.c: Likewise.
* arm-tdep.h: Declare arm_apcs_32.
And remove the declaration from dwarf2loc.c, for better typesafety.
gdb/ChangeLog:
2019-09-19 Christian Biesinger <cbiesinger@google.com>
* dwarf2loc.c: Remove extern declaration of dwarf_always_disassemble.
* dwarf2read.h: Declare dwarf_always_disassemble.
If gdb_test is used with fewer than five arguments, then the question_string
defaults to "^FOOBAR$":
...
if [llength $args]==5 {
set question_string [lindex $args 3]
set response_string [lindex $args 4]
} else {
set question_string "^FOOBAR$"
}
...
This can however match "FOOBAR", so perhaps "\$FOOBAR^" would have been a
better choice.
Eliminate the FOOBAR pattern from gdb_test by instead of defining a default
regexp, conditionally appending the regexp matching to a user_code variable.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-09-19 Tom de Vries <tdevries@suse.de>
* lib/gdb.exp (gdb_test): Eliminate "^FOOBAR$" pattern.
Currently in source_cache::ensure we catch the exception that triggers when
highlighter->highlight is called:
...
try
{
std::istringstream input (contents);
std::ostringstream output;
highlighter->highlight (input, output, lang_name, fullname);
...
and the file used earlier in the construction of the highlighter:
...
highlighter = new srchilite::SourceHighlight ("esc.outlang");
...
is missing.
The fact that this exception triggers when highlighter->highlight is called is
an implementation artefact of libsource-highlight.so though, and this could be
different for older or newer versions.
Make things more robust by also catching exceptions thrown during construction
of the highlighter. This makes the handling on master equivalent with what
has been committed for 8.3.1.
Tested on x86_64-linux.
gdb/ChangeLog:
2019-09-19 Tom de Vries <tdevries@suse.de>
PR gdb/25009
* source-cache.c (source_cache::ensure): Catch exception thrown during
construction of the highlighter.
In commit 81dc3ab594 "[gdb/testsuite] Handle unreachable network in
server-connect.exp" a regression was introduced in gdb_target_cmd, causing
ERRORs like this:
...
ERROR: tcl error sourcing src/gdb/testsuite/gdb.server/abspath.exp.
ERROR: wrong # args: should be "gdb_target_cmd {$args}"
while executing
"gdb_target_cmd $gdbserver_protocol $gdbserver_gdbport"
...
Fix the argument passing in gdb_target_cmd.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-09-19 Tom de Vries <tdevries@suse.de>
* lib/gdbserver-support.exp (gdb_target_cmd): Fix argument passing.
When running gdb.server/server-connect.exp I run into:
...
FAIL: gdb.server/server-connect.exp: tcp6: connect to gdbserver using tcp6:::1
FAIL: gdb.server/server-connect.exp: tcp6-with-brackets: connect to gdbserver \
using tcp6:[::1]
FAIL: gdb.server/server-connect.exp: udp6: connect to gdbserver using udp6:::1
FAIL: gdb.server/server-connect.exp: udp6-with-brackets: connect to gdbserver \
using udp6:[::1]
...
The FAIL is caused by the fact that the ipv6 loopback address is not available:
...
PASS: gdb.server/server-connect.exp: tcp6: start gdbserver
target remote tcp6:::1:2347^M
A program is being debugged already. Kill it? (y or n) y^M
tcp6:::1:2347: Network is unreachable.^M
(gdb) FAIL: gdb.server/server-connect.exp: tcp6: connect to gdbserver using tcp6:::1
...
This should be marked UNSUPPORTED rather than FAIL.
Furthermore, the test-case takes about 4 minutes, because the 'Network is
unreachable' response is not explicitly handled in gdb_target_cmd, so instead
it runs into the timeout case.
Fix this by handling the 'Network is unreachable' response as UNSUPPORTED.
This reduces testing time from 4 minutes to about 2 seconds.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-09-19 Tom de Vries <tdevries@suse.de>
* lib/gdbserver-support.exp (gdb_target_cmd_ext): Return 2 (meaning
UNSUPPORTED) for 'Network is unreachable' message. Factor out of ...
(gdb_target_cmd): ... here.
* gdb.server/server-connect.exp: Use gdb_target_cmd_ext, handle return
value 2.
... to include PR breakpoints/24541 (for documentation purposes).
For the reader's convenience, the commit in question was the following:
commit 677052f2a5
Author: Sergio Durigan Junior <sergiodj@redhat.com>
Date: Thu May 16 16:23:24 2019 -0400
Subject: Make stap-probe.c:stap_parse_register_operand's "regname"
an std::string
Readline 8.0 has a feature that lets an application name a keymap.
This in turn makes it simpler for users to bind keys in keymaps in
their .inputrc.
This patch gives a name to the TUI SingleKey keymap, so that
additional bindings can be made there. For example:
$if gdb
set keymap SingleKey
"X": "echo hello\\n\n"
$endif
The call to rl_initialize, in tui_initialize_readline, had to be
removed so that .inputrc was not read too early. Note that Readline
explicitly documents that this call is not needed.
gdb/ChangeLog
2019-09-18 Tom Tromey <tom@tromey.com>
* NEWS: Add entry.
* tui/tui.c (tui_initialize_readline): Set name of keymap. Do not
call rl_initialize.
(tui_enable): Do not call rl_initialize.
gdb/doc/ChangeLog
2019-09-18 Tom Tromey <tom@tromey.com>
* gdb.texinfo (Editing): Document readline application name.
(TUI Single Key Mode): Document TUI SingleKey keymap name.
Fixes:
CXX alpha-linux-nat.o
alpha-linux-nat.c: In member function 'virtual CORE_ADDR alpha_linux_nat_target::register_u_offset(gdbarch*, int, int)':
alpha-linux-nat.c:93:16: error: 'gdbarch_pc_regnum' was not declared in this scope
if (regno == gdbarch_pc_regnum (gdbarch))
^~~~~~~~~~~~~~~~~
alpha-linux-nat.c:93:16: note: suggested alternative: 'gdbarch_info'
if (regno == gdbarch_pc_regnum (gdbarch))
^~~~~~~~~~~~~~~~~
gdbarch_info
alpha-linux-nat.c:97:15: error: 'gdbarch_fp0_regnum' was not declared in this scope
if (regno < gdbarch_fp0_regnum (gdbarch))
^~~~~~~~~~~~~~~~~~
alpha-linux-nat.c:97:15: note: suggested alternative: 'gdbarch_info'
if (regno < gdbarch_fp0_regnum (gdbarch))
^~~~~~~~~~~~~~~~~~
gdbarch_info
make[2]: *** [Makefile:1638: alpha-linux-nat.o] Error 1
make[2]: Leaving directory '/home/chris/tmp/binutils-gdb/gdb'
2019-09-12 Christian Groessler <chris@groessler.org>
* alpha-linux-nat.c: Include gdbarch.h.
Following the int -> bool conversion of boolean options (commit
491144b5e2 ("Change boolean options to bool instead of int")), I see
this ASAN error:
==357543==ERROR: AddressSanitizer: global-buffer-overflow on address 0x55555b25d440 at pc 0x5555583ce9e1 bp 0x7fffffffd390 sp 0x7fffffffd380
READ of size 4 at 0x55555b25d440 thread T0
#0 0x5555583ce9e0 in term_cli_styling /home/simark/src/binutils-gdb/gdb/ui-file.c:111
#1 0x5555583cf8b0 in stdio_file::can_emit_style_escape() /home/simark/src/binutils-gdb/gdb/ui-file.c:308
#2 0x5555584450d2 in set_output_style /home/simark/src/binutils-gdb/gdb/utils.c:1442
#3 0x5555584491af in fprintf_styled(ui_file*, ui_file_style const&, char const*, ...) /home/simark/src/binutils-gdb/gdb/utils.c:2143
#4 0x5555582fa13c in print_gdb_version(ui_file*, bool) /home/simark/src/binutils-gdb/gdb/top.c:1339
#5 0x555557b723ab in captured_main_1 /home/simark/src/binutils-gdb/gdb/main.c:981
#6 0x555557b7353b in captured_main /home/simark/src/binutils-gdb/gdb/main.c:1172
#7 0x555557b735d0 in gdb_main(captured_main_args*) /home/simark/src/binutils-gdb/gdb/main.c:1197
#8 0x55555700a53d in main /home/simark/src/binutils-gdb/gdb/gdb.c:32
#9 0x7ffff64c9ee2 in __libc_start_main (/usr/lib/libc.so.6+0x26ee2)
#10 0x55555700a30d in _start (/home/simark/build/binutils-gdb/gdb/gdb+0x1ab630d)
0x55555b25d441 is located 0 bytes to the right of global variable 'cli_styling' defined in '/home/simark/src/binutils-gdb/gdb/cli/cli-style.c:31:6' (0x55555b25d440) of size 1
The reason of this is that we have this declaration of cli_styling in cli/cli-style.h:
extern bool cli_styling;
but ui-file.c uses its own local declaration:
extern int cli_styling;
Because of that, the code in ui-file.c thinks the variable is 4 bytes
long, when it is actually 1 byte long, so the generated code reads past
the variable.
Fix it by removing the declaration and making ui-file.c include
cli/cli-style.h.
gdb/ChangeLog:
* ui-file.c: Include cli/cli-style.h.
(term_cli_styling): Remove cli_styling declaration.
Give a test an actual name in order to avoid having a directory name
in the .sum file.
gdb/testsuite/ChangeLog:
* gdb.base/source-dir.exp: Avoid having directory names in test
names.
Fixes a few leaks in bfd and ld.
bfd/
* mach-o.c (bfd_mach_o_fat_member_init): Likewise. Replace
xstrdup and xmalloc with bfd_strdup and bfd_malloc. Return an
error status. Adjust calls.
* vms-lib.c (_bfd_vms_lib_get_module): Test mhd->id earlier.
Close bfd on failure. Replace xstrdup/bfd_alloc use with
bfd_malloc. Use bfd_set_filename.
gdb/
* solib-spu.c (spu_bfd_open): Use bfd_set_filename.
* spu-linux-nat.c (spu_bfd_open): Likewise.
ld/
* emultempl/pe.em (after_open): Use bfd_set_filename.
* emultempl/pep.em (after_open): Use bfd_set_filename.
This was an oversight in 491144b5e21bbfd41969c175aebb663976f59058;
dwarf2loc.c has an extern definition for dwarf_always_disassemble
that I missed. This patch updates it from int to bool to match
the definition in dwarf2read.c.
gdb/ChangeLog:
2019-09-18 Christian Biesinger <cbiesinger@google.com>
* dwarf2loc.c: Change extern declaration of dwarf_always_disassemble
to bool to match definition in dwarf2read.c.
The 'directory' command allows the user to provide a list of filesystem
directories in which to search for source code. The directories in this
search path are used as the base directory for the source filename from
the debug information (DW_AT_name). Thus the directory search path
provides alternatives to the existing compilation directory from the
debug information (DW_AT_comp_dir). Generally speaking, DW_AT_name
stores the filename argument passed to the compiler (including any
directory components), and DW_AT_comp_dir stores the current working
directory from which the compiler was executed. For example:
$ cd /path/to/project/subdir1
$ gcc -c a/test.c -g
The corresponding debug information will look like this:
DW_AT_name : a/test.c
DW_AT_comp_dir : /path/to/project/subdir1
When compiling with the -fdebug-prefix-map GCC option, the compilation
directory can be arbitrarily rewritten. In the above example, we may
rewrite the compilation directory as follows:
$ gcc -c a/test.c -g -fdebug-prefix-map=/path/to/project=
In this case, the corresponding debug information will look like:
DW_AT_name : a/test.c
DW_AT_comp_dir : /subdir1
This prevents GDB from finding the corresponding source code based on
the debug information alone. In some cases, a substitute-path command
can be used to re-map a consistent prefix in the rewritten compilation
directory to the real filesystem path. However, there may not be a
consistent prefix remaining in the debug symbols (for example in a
project that has source code in many subdirectories under the project's
root), thereby requiring multiple substitute-path rules. In this case,
it is easier to add the missing prefix to the directory search path via
the 'directory' command.
The function find_and_open_source currently searches in:
SEARCH_PATH/FILENAME
where SEARCH_PATH corresponds to each individual entry in the directory
search path (which is guaranteed to contain the compilation directory
from the debug information, as well as the current working directory).
FILENAME corresponds to the source filename (DW_AT_name), which may have
directory components in it. In addition, GDB searches in:
SEARCH_PATH/FILE_BASENAME
where FILE_BASENAME is the basename of the DW_AT_name entry.
This change modifies find_and_open_source to additionally search in:
SEARCH_PATH/COMP_DIR/FILENAME
where COMP_DIR is the compilation directory from the debug symbols. In
the example given earlier, running:
(gdb) directory /path/to/project
will now allow GDB to correctly locate the source code from the debug
information.
gdb/ChangeLog:
* source.c (prepare_path_for_appending): New function.
(openp): Make use of new function.
(find_and_open_source): Search for the compilation directory and
source file as a relative path beneath the directory search path.
gdb/doc/ChangeLog:
* gdb.texinfo (Source Path): Additional text to better describe
how the source path directory list is used when searching for
source files.
gdb/testsuite/ChangeLog:
* gdb.base/source-dir.exp: Add extra test for mapped compilation
directory.
The source_cache::get_line_charpos function can currently throw an
exception if the source file is missing, which doesn't match the
expected behaviour documented in the functions header file. The
documented behaviour is to return false on failure, and this is how
the function appears to be used throughout GDB.
I spotted this in the 'info source' command, currently for a missing
source file you'll see something like this:
(gdb) info source
Current source file is /path/to/src/file.c
Compilation directory is /path/to/build/
/path/to/src/file.c: No such file or directory.
(gdb)
After this patch we see this:
(gdb) info source
Current source file is /path/to/src/file.c
Compilation directory is /path/to/build/
Source language is c.
Producer is COMPILER VERSION AND FLAGS.
Compiled with DWARF 2 debugging format.
Does not include preprocessor macro info.
We don't currently indicate that the source file can't be found, and
maybe that would be something worth adding in the future.
gdb/ChangeLog:
* source-cache.c (source_cache::get_line_charpos): Catch
exceptions and return false, this matches the behaviour documented
in the header file.
gdb/testsuite/ChangeLog:
* gdb.base/list-missing-source.exp: New file.
A recent change enhanced a couple of notifications about Ada tasks to
include the task's name in addition to the task's number. That change
also modified the output of the "info tasks" when printing the detailed
information of one given task. I believe this change was unintentionally
left over from the initial version after it was decided that quoting
the task's name should not be done. This patch therefore undoes this
part of the patch.
gdb/ChangeLog:
* ada-tasks.c (info_task): Remove quoting of the task's name.
Tested on x86_64-linux, with both the official testsuite as well as
AdaCore's testsuite.
This just replaces the comment in the .c file with
"See symfile.h.".
gdb/ChangeLog:
2019-09-16 Christian Biesinger <cbiesinger@google.com>
* symfile.c (auto_solib_add): Replace comment with a reference
to the header file.
This was fixed in commit 272044897e.
2019-09-14 Christian Biesinger <cbiesinger@google.com>
* NEWS: Mention that gdb can now be compiled with Python 3
on Windows.
When running gdb.ada/rename_subscript_param.exp with gnatmake 7.4.1, we get:
...
FAIL: gdb.ada/rename_subscript_param.exp: print rename_subscript_param_b \
before changing its value
FAIL: gdb.ada/rename_subscript_param.exp: print rename_subscript_param_b \
after changing its value
...
The commit last touching the test-case (afcfda091e) states:
...
The test still fails with old compilers that do not properly
generate debug info for this renaming:
...
Fix this by requiring at least gnatmake 8 for the test-case.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-09-14 Tom de Vries <tdevries@suse.de>
PR teststuite/24599
* gdb.ada/rename_subscript_param.exp: Require gnatmake 8.
* lib/ada.exp (gnatmake_version_at_least): New proc.
This commit:
commit aa17805fb9
Date: Sat Aug 31 23:44:40 2019 +0100
gdb: Have 'maint info sections' print all sections again
introduced a use of log10 that took an int as a parameter.
Unfortunately this was causing a compilation error on Solaris, see:
https://sourceware.org/ml/gdb-patches/2019-09/msg00230.htmlhttps://sourceware.org/ml/gdb-patches/2019-09/msg00231.html
because there was only a float, double, or long double version of
log10, and the compiler doesn't know which to choose.
This commit should resolve this issue by casting the argument to
float.
gdb/ChangeLog:
* maint.c (maint_print_section_data::maint_print_section_data):
Force use of 'float log10 (float)' by casting the argument to
float.
Make use of exec_has_index_section library function rather than
manually checking in the 'maintenance info sections' output. Should
make no difference to the test results, just makes the code easier to
read.
gdb/testsuite/ChangeLog:
* gdb.base/maint.exp: Use exec_has_index_section.
In this commit:
commit 6eac171f06
Date: Fri Aug 16 00:25:14 2019 +0200
[gdb] Make maint info sections print relocated addresses
A couple of things broke with the 'maintenance info sections' command,
here is some before output:
(gdb) maintenance info sections
Exec file:
`/path/to/gdb/build/gdb/testsuite/outputs/gdb.base/maint/maint',
file type elf64-x86-64.
[0] 0x00400238->0x00400254 at 0x00000238: .interp ALLOC LOAD READONLY DATA HAS_CONTENTS
[1] 0x00400254->0x00400274 at 0x00000254: .note.ABI-tag ALLOC LOAD READONLY DATA HAS_CONTENTS
[2] 0x00400274->0x00400298 at 0x00000274: .note.gnu.build-id ALLOC LOAD READONLY DATA HAS_CONTENTS
[3] 0x00400298->0x004002bc at 0x00000298: .gnu.hash ALLOC LOAD READONLY DATA HAS_CONTENTS
[4] 0x004002c0->0x00400380 at 0x000002c0: .dynsym ALLOC LOAD READONLY DATA HAS_CONTENTS
[5] 0x00400380->0x004003e3 at 0x00000380: .dynstr ALLOC LOAD READONLY DATA HAS_CONTENTS
[6] 0x004003e4->0x004003f4 at 0x000003e4: .gnu.version ALLOC LOAD READONLY DATA HAS_CONTENTS
[7] 0x004003f8->0x00400418 at 0x000003f8: .gnu.version_r ALLOC LOAD READONLY DATA HAS_CONTENTS
[8] 0x00400418->0x00400460 at 0x00000418: .rela.dyn ALLOC LOAD READONLY DATA HAS_CONTENTS
[9] 0x00400460->0x004004c0 at 0x00000460: .rela.plt ALLOC LOAD READONLY DATA HAS_CONTENTS
[10] 0x004004c0->0x004004d7 at 0x000004c0: .init ALLOC LOAD READONLY CODE HAS_CONTENTS
[11] 0x004004e0->0x00400530 at 0x000004e0: .plt ALLOC LOAD READONLY CODE HAS_CONTENTS
[12] 0x00400530->0x00400802 at 0x00000530: .text ALLOC LOAD READONLY CODE HAS_CONTENTS
[13] 0x00400804->0x0040080d at 0x00000804: .fini ALLOC LOAD READONLY CODE HAS_CONTENTS
[14] 0x00400810->0x0040084e at 0x00000810: .rodata ALLOC LOAD READONLY DATA HAS_CONTENTS
[15] 0x00400850->0x004008c4 at 0x00000850: .eh_frame_hdr ALLOC LOAD READONLY DATA HAS_CONTENTS
[16] 0x004008c8->0x00400ab8 at 0x000008c8: .eh_frame ALLOC LOAD READONLY DATA HAS_CONTENTS
[17] 0x00600e00->0x00600e08 at 0x00000e00: .init_array ALLOC LOAD DATA HAS_CONTENTS
[18] 0x00600e08->0x00600e10 at 0x00000e08: .fini_array ALLOC LOAD DATA HAS_CONTENTS
[19] 0x00600e10->0x00600ff0 at 0x00000e10: .dynamic ALLOC LOAD DATA HAS_CONTENTS
[20] 0x00600ff0->0x00601000 at 0x00000ff0: .got ALLOC LOAD DATA HAS_CONTENTS
[21] 0x00601000->0x00601038 at 0x00001000: .got.plt ALLOC LOAD DATA HAS_CONTENTS
[22] 0x00601038->0x0060103c at 0x00001038: .data ALLOC LOAD DATA HAS_CONTENTS
[23] 0x00601040->0x006012c8 at 0x0000103c: .bss ALLOC
[24] 0x00000000->0x0000002c at 0x0000103c: .comment READONLY HAS_CONTENTS
[25] 0x00000000->0x00000060 at 0x00001068: .debug_aranges READONLY HAS_CONTENTS
[26] 0x00000000->0x0000061b at 0x000010c8: .debug_info READONLY HAS_CONTENTS
[27] 0x00000000->0x00000264 at 0x000016e3: .debug_abbrev READONLY HAS_CONTENTS
[28] 0x00000000->0x000001e6 at 0x00001947: .debug_line READONLY HAS_CONTENTS
[29] 0x00000000->0x00000487 at 0x00001b2d: .debug_str READONLY HAS_CONTENTS
(gdb)
And here is the output after the above commit:
(gdb) maintenance info sections
+maintenance info sections
Exec file:
`/path/to/gdb/build/gdb/testsuite/outputs/gdb.base/maint/maint',
file type elf64-x86-64.
0x00400238->0x00400254 at 0x00000238: .interp ALLOC LOAD READONLY DATA HAS_CONTENTS
0x00400254->0x00400274 at 0x00000254: .note.ABI-tag ALLOC LOAD READONLY DATA HAS_CONTENTS
0x00400274->0x00400298 at 0x00000274: .note.gnu.build-id ALLOC LOAD READONLY DATA HAS_CONTENTS
0x00400298->0x004002bc at 0x00000298: .gnu.hash ALLOC LOAD READONLY DATA HAS_CONTENTS
0x004002c0->0x00400380 at 0x000002c0: .dynsym ALLOC LOAD READONLY DATA HAS_CONTENTS
0x00400380->0x004003e3 at 0x00000380: .dynstr ALLOC LOAD READONLY DATA HAS_CONTENTS
0x004003e4->0x004003f4 at 0x000003e4: .gnu.version ALLOC LOAD READONLY DATA HAS_CONTENTS
0x004003f8->0x00400418 at 0x000003f8: .gnu.version_r ALLOC LOAD READONLY DATA HAS_CONTENTS
0x00400418->0x00400460 at 0x00000418: .rela.dyn ALLOC LOAD READONLY DATA HAS_CONTENTS
0x00400460->0x004004c0 at 0x00000460: .rela.plt ALLOC LOAD READONLY DATA HAS_CONTENTS
0x004004c0->0x004004d7 at 0x000004c0: .init ALLOC LOAD READONLY CODE HAS_CONTENTS
0x004004e0->0x00400530 at 0x000004e0: .plt ALLOC LOAD READONLY CODE HAS_CONTENTS
0x00400530->0x00400802 at 0x00000530: .text ALLOC LOAD READONLY CODE HAS_CONTENTS
0x00400804->0x0040080d at 0x00000804: .fini ALLOC LOAD READONLY CODE HAS_CONTENTS
0x00400810->0x0040084e at 0x00000810: .rodata ALLOC LOAD READONLY DATA HAS_CONTENTS
0x00400850->0x004008c4 at 0x00000850: .eh_frame_hdr ALLOC LOAD READONLY DATA HAS_CONTENTS
0x004008c8->0x00400ab8 at 0x000008c8: .eh_frame ALLOC LOAD READONLY DATA HAS_CONTENTS
0x00600e00->0x00600e08 at 0x00000e00: .init_array ALLOC LOAD DATA HAS_CONTENTS
0x00600e08->0x00600e10 at 0x00000e08: .fini_array ALLOC LOAD DATA HAS_CONTENTS
0x00600e10->0x00600ff0 at 0x00000e10: .dynamic ALLOC LOAD DATA HAS_CONTENTS
0x00600ff0->0x00601000 at 0x00000ff0: .got ALLOC LOAD DATA HAS_CONTENTS
0x00601000->0x00601038 at 0x00001000: .got.plt ALLOC LOAD DATA HAS_CONTENTS
0x00601038->0x0060103c at 0x00001038: .data ALLOC LOAD DATA HAS_CONTENTS
0x00601040->0x006012c8 at 0x0000103c: .bss ALLOC
0x00000000->0x00000000 at 0x00000000: *COM* IS_COMMON
0x00000000->0x00000000 at 0x00000000: *UND*
0x00000000->0x00000000 at 0x00000000: *ABS*
0x00000000->0x00000000 at 0x00000000: *IND*
(gdb)
We lost the section index numbers, but more importantly, we lost the
information about the .debug* sections. We also gained entries for
the "fake" sections *COM*, *UND*, *ABS*, and *IND*.
I noticed this when running:
make check-gdb RUNTESTFLAGS="--target_board=cc-with-gdb-index gdb.base/maint.exp"
As this test relies on looking in the 'maint info sections' output to
see if we have a .debug_names or .gdb_index section, and these are
debug sections so they no longer show up in the 'main info sections'
output, the gdb.base/maint.exp test fails.
This commit restores the old behaviour while keeping the important
change that the above commit introduced, the addresses printed for
sections are the relocated addresses where appropriate. The above
commit mentions using this test:
make check-gdb RUNTESTFLAGS="CFLAGS_FOR_TARGET='-pie' gdb.base/compare-sections.exp"
And this still passes after this commit.
The output for 'maint info sections' now looks like this:
(gdb) maintenance info sections
Exec file:
`/home/andrew/projects/binutils-gdb/build/gdb/testsuite/outputs/gdb.base/maint/maint',
file type elf64-x86-64.
[0] 0x00400238->0x00400254 at 0x00000238: .interp ALLOC LOAD READONLY DATA HAS_CONTENTS
[1] 0x00400254->0x00400274 at 0x00000254: .note.ABI-tag ALLOC LOAD READONLY DATA HAS_CONTENTS
[2] 0x00400274->0x00400298 at 0x00000274: .note.gnu.build-id ALLOC LOAD READONLY DATA HAS_CONTENTS
[3] 0x00400298->0x004002bc at 0x00000298: .gnu.hash ALLOC LOAD READONLY DATA HAS_CONTENTS
[4] 0x004002c0->0x00400380 at 0x000002c0: .dynsym ALLOC LOAD READONLY DATA HAS_CONTENTS
[5] 0x00400380->0x004003e3 at 0x00000380: .dynstr ALLOC LOAD READONLY DATA HAS_CONTENTS
[6] 0x004003e4->0x004003f4 at 0x000003e4: .gnu.version ALLOC LOAD READONLY DATA HAS_CONTENTS
[7] 0x004003f8->0x00400418 at 0x000003f8: .gnu.version_r ALLOC LOAD READONLY DATA HAS_CONTENTS
[8] 0x00400418->0x00400460 at 0x00000418: .rela.dyn ALLOC LOAD READONLY DATA HAS_CONTENTS
[9] 0x00400460->0x004004c0 at 0x00000460: .rela.plt ALLOC LOAD READONLY DATA HAS_CONTENTS
[10] 0x004004c0->0x004004d7 at 0x000004c0: .init ALLOC LOAD READONLY CODE HAS_CONTENTS
[11] 0x004004e0->0x00400530 at 0x000004e0: .plt ALLOC LOAD READONLY CODE HAS_CONTENTS
[12] 0x00400530->0x00400802 at 0x00000530: .text ALLOC LOAD READONLY CODE HAS_CONTENTS
[13] 0x00400804->0x0040080d at 0x00000804: .fini ALLOC LOAD READONLY CODE HAS_CONTENTS
[14] 0x00400810->0x0040084e at 0x00000810: .rodata ALLOC LOAD READONLY DATA HAS_CONTENTS
[15] 0x00400850->0x004008c4 at 0x00000850: .eh_frame_hdr ALLOC LOAD READONLY DATA HAS_CONTENTS
[16] 0x004008c8->0x00400ab8 at 0x000008c8: .eh_frame ALLOC LOAD READONLY DATA HAS_CONTENTS
[17] 0x00600e00->0x00600e08 at 0x00000e00: .init_array ALLOC LOAD DATA HAS_CONTENTS
[18] 0x00600e08->0x00600e10 at 0x00000e08: .fini_array ALLOC LOAD DATA HAS_CONTENTS
[19] 0x00600e10->0x00600ff0 at 0x00000e10: .dynamic ALLOC LOAD DATA HAS_CONTENTS
[20] 0x00600ff0->0x00601000 at 0x00000ff0: .got ALLOC LOAD DATA HAS_CONTENTS
[21] 0x00601000->0x00601038 at 0x00001000: .got.plt ALLOC LOAD DATA HAS_CONTENTS
[22] 0x00601038->0x0060103c at 0x00001038: .data ALLOC LOAD DATA HAS_CONTENTS
[23] 0x00601040->0x006012c8 at 0x0000103c: .bss ALLOC
[24] 0x00000000->0x0000002c at 0x0000103c: .comment READONLY HAS_CONTENTS
[25] 0x00000000->0x00000060 at 0x00001068: .debug_aranges READONLY HAS_CONTENTS
[26] 0x00000000->0x0000061b at 0x000010c8: .debug_info READONLY HAS_CONTENTS
[27] 0x00000000->0x00000264 at 0x000016e3: .debug_abbrev READONLY HAS_CONTENTS
[28] 0x00000000->0x000001e6 at 0x00001947: .debug_line READONLY HAS_CONTENTS
[29] 0x00000000->0x00000487 at 0x00001b2d: .debug_str READONLY HAS_CONTENTS
(gdb)
This is basically as it was before, except that the index numbers are
now padded so the section information all lines up.
When GDB has relocated a section then the relocated addresses will be
printed, otherwise the non-relocated addresses from the bfd will be
printed.
I've added a test to gdb.base/maint.exp to do some basic validation of
the output format.
gdb/ChangeLog:
* maint.c: Add 'cmath' include.
(struct maint_print_section_data): New structure.
(print_section_index): New function.
(print_bfd_section_info): Add header comment, small whitespace
cleanup, and update to call new print_section_index function.
(print_objfile_section_info): Likewise.
(maint_obj_section_from_bfd_section): New function.
(print_bfd_section_info_maybe_relocated): New function.
(maintenance_info_sections): Add header comment, always use
bfd_map_over_sections instead of ALL_OBJFILE_OSECTIONS.
gdb/testsuite/ChangeLog:
* gdb.base/maint.exp: Add test for 'maint info sections'.
I found that these tests:
make check-gdb RUNTESTFLAGS="--target_board=cc-with-gdb-index gdb.base/maint.exp"
make check-gdb RUNTESTFLAGS="--target_board=cc-with-debug-names gdb.base/maint.exp"
were causing GDB to segfault. It turns out that this test runs this
command:
maint print psymbols -pc main /path/to/some/file
which tries to lookup the partial_symtab for 'main'. The problem is
that there is no partial_symtab for 'main' as we are using the
.gdb_index or .debug_names instead of partial_symtabs.
What happens is that maintenance_print_symbols calls
find_pc_sect_psymtab, which looks for the partial_symtab in the
objfile's objfile->partial_symtabs->psymtabs_addrmap.
This is a problem because when we are using the indexes
psymtabs_addrmap is reused to hold things other than partial_symtabs,
this can be seen in dwarf2read.c in create_addrmap_from_index and
create_addrmap_from_aranges. If we then lookup in psymtabs_addrmap we
end up returning a pointer to something that isn't really a
partial_symtab, after which everything goes wrong.
Initially I simply added a check at the start of find_pc_sect_psymtab
that the objfile had some partial_symtabs, like:
if (objfile->partial_symtabs->psymtabs == NULL)
return NULL;
Figuring that if there were no partial_symtabs at all then this
function should always return NULL, however, this caused a failure in
the test gdb.python/py-event.exp which I didn't dig into too deeply,
but seems to be that in this tests there are initially no psymtabs,
but the second part of find_pc_sect_psymtab does manage to read some
in from somewhere, with the check I added the test fails as we
returned NULL here and this caused GDB to load in the full symtabs
earlier than was expected.
Instead I chose to guard only the access to psymtabs_addrmap with a
check that the function has some psymtabs. This allows my original
tests to pass, and the py-event.exp test to pass too.
Now, a good argument can be made that we simply should never call
find_pc_sect_psymtab on an objfile that is using indexes instead of
partial_symtabs. I did consider this approach, we could easily add an
assert into find_pc_sect_psymtab that if we find a partial_symtab in
psymtabs_addrmap then the psymtabs pointer must be non-null. The
responsibility would then be on the user of find_pc_sect_psymtab to
ensure that the objfile being checked is suitable. In the end I
didn't take this approach as the check in find_pc_sect_psymtab is
cheap and this ensures that any future miss-uses of the function will
not cause problems.
I also extended the comment on psymtabs_addrmap to indicate that it
holds more than just partial_symtabs as this was not at all clear from
the original comment, and caused me some confusion when I was
initially debugging this problem.
gdb/ChangeLog:
* psymtab.c (find_pc_sect_psymtab): Move baseaddr local into more
inner scope, add check that the objfile has psymtabs before
checking psymtabs_addrmap.
* psymtab.h (psymtab_storage) <psymtabs_addrmap>: Extend comment.
The test-case gdb.base/store.exp fails with gcc 7.4.0:
...
nr of unexpected failures 27
...
The first FAIL:
...
110 l = add_float (l, r);
(gdb) PASS: gdb.base/store.exp: continue to wack_float
print l
$21 = <optimized out>
FAIL: gdb.base/store.exp: var float l; print old l, expecting -1
...
relates to this bit in the test-case (compiled at -O0):
...
106 float
107 wack_float (register float u, register float v)
108 {
109 register float l = u, r = v;
110 l = add_float (l, r);
111 return l + r;
112 }
...
and it expects to be able to read and modify variable l before executing line
110, but it already fails to read the value, because l has no DW_AT_location
attribute in the debug info.
Variable l is declared with the register keyword, and GCC implements the
register keyword at -O0 like so:
...
the compiler allocates distinct stack memory for all variables that do not
have the register storage-class specifier; if register is specified, the
variable may have a shorter lifespan than the code would indicate and may
never be placed in memory.
...
The fact that l has no DW_AT_location attribute, matches with the documented
"variable may have a shorter lifespan that code would indicate", (though it
is the most extreme case of it) so the gcc behaviour is valid. We can of
course improve gcc to generate better debuginfo (filed gcc PR91611), but
this not a wrong-debug problem.
[ The test-case passes with gcc 4.2.1, but for the failing test discussed
above, it passes simply because it doesn't store l in a register. ]
With the debug info missing for l, reading and setting l is unsupported, so
fix the FAIL by marking the test UNSUPPORTED instead.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-09-12 Tom de Vries <tdevries@suse.de>
* gdb.base/store.exp: Allow register variables to be optimized out at
-O0.
With this patch, we e.g. get:
[Switching to task 2 "task_list(1)"]
[Current task is 2 "task_list(1)"]
instead of
[Switching to task 2]
[Current task is 2]
The logic to produce the taskno optionally followed
by the task name has been factorized in the task_to_str function.
Task names are output between double quotes in the new messages,
similarly to what GDB does for thread names.
However, no quotes are put around task names in 'info tasks' Name column.
This was discussed with Tom, that preferred no quotes there, while I
was more in favour of visual consistency.
I discussed with a few more users, which led to (exactly) 50% preferring
quotes and 50% preferring no quotes :).
To arrive to the decision to remove the quotes, the following "killing args"
were used:
* To have quotes or to not have quotes, that is the question; yes
but not *THE* question :).
* If there is not a clear majority that prefers quotes, better to
not disturb the existing user basis for a (somewhat) irrelevant
aspect.
* The opinion of the reviewer has more weight.
So, compared to the previous version, this version remotes the quotes
in 'info tasks'.
It improves the alignement of 'info tasks' output.
With this patch, we get:
(gdb) info task
ID TID P-ID Pri State Name
* 1 555555759030 48 Runnable main_task
2 555555759e30 1 48 Selective Wait mit
(gdb)
instead of
(gdb) info task
ID TID P-ID Pri State Name
* 1 555555759030 48 Runnable main_task
2 555555759e30 1 48 Selective Wait mit
(gdb)
(e.g. the first one properly shows parent and priority under the
correct header).
This is version 4 of the 'task name' patch.
Compared to version 3, the changes are:
output task names between quotes but not in 'info tasks'
gdb/ChangeLog
2019-09-12 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* NEWS: Announce that Ada task names are now shown at more places,
and between quotes (except in info task output).
* gdb/ada-tasks.c (task_to_str): New function.
(display_current_task_id): Call task_to_str.
(task_command_1): Likewise.
(print_ada_task_info): In non-mi mode, Properly align headers and data
when task-id length is > 9 (9 is the default for a 32 bits CORE_ADDR).
gdb/doc/ChangeLog
2019-09-12 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* gdb.texinfo (Ada Tasks): Tell the task name is printed, update
examples.
gdb/testsuite/ChangeLog
2019-09-12 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* gdb.ada/rdv_wait.exp: Update to new task names.
* gdb.base/task_switch_in_core.exp: Likewise.
* gdb.base/info_sources_base.c: Likewise.
It's been a long-standing nuisance that gdb reported unaligned accesses
on Solaris/SPARC as SIGSEGV, contrary to the shells and truss which
correctly report SIGBUS instead.
I could trace this down to the fault handling code in procfs.c
(procfs_target::wait): when pr_why is set to PR_FAULTED, the current
code sets the signal based on the fault number. For one, the code gets
this wrong for FLTACCESS (the unaligned access case) where it uses
SIGSEGV. What's worse, it's completely unnecessary to make up the
signal number inside gdb. Instead, it should just take what procfs
reports to avoid mismatches, which is what this patch does. I've
completely removed the explicit handling of the various fault codes: for
one, the list has already been incomplete, lacking FLTCPCOVF which
existed since at least Solaris 8. Besides, there's no reason to error
out on unknown fault codes: either the fault causes a signal which can
then be reported from procfs, or it doesn't (as for FLTPAGE) and no
reporting is necessary.
Tested on sparcv9-sun-solaris2.11 and x86_64-pc-solaris2.11. Also
spot-checked manually for a couple of cases (unaligned access, division
by 0, NULL pointer dereference).
* procfs.c (procfs_target::wait) <PR_FAULTED>: Get signal from
prstatus.pr_lwp.pr_info instead of making it up.
This simplifies memory management. I've also changed some global variables
to std::string accordingly (which store the result of these functions),
but not all because some are used with add_setshow_optional_filename_cmd
which requires a char*.
gdb/ChangeLog:
2019-09-11 Christian Biesinger <cbiesinger@google.com>
* auto-load.c (auto_load_expand_dir_vars): Update.
* defs.h (gdb_datadir): Change to std::string.
(python_libdir): Likewise.
(relocate_gdb_directory): Change return type to std::string.
* guile/guile.c (gdbscm_data_directory): Update.
(initialize_scheme_side): Update.
* jit.c (jit_reader_dir): Change to std::string.
(jit_reader_load_command): Update.
* main.c (gdb_datadir): Change to std::string.
(python_libdir): Likewise.
(set_gdb_data_directory): Update.
(relocate_path): Change to return std::string.
(relocate_gdb_directory): Change to return std::string.
(relocate_gdbinit_path_maybe_in_datadir): Update.
(captured_main_1): Update.
* python/python.c (do_start_initialization): Update.
* top.c (show_gdb_datadir): Update.
* xml-syscall.c (xml_init_syscalls_info): Update.
(init_syscalls_info): Update.
This simplifies get_init_files and makes it possible to reuse
this code in an upcoming patch for SYSTEM_GDBINIT_DIR.
gdb/ChangeLog:
2019-09-11 Christian Biesinger <cbiesinger@google.com>
* main.c (relocate_gdbinit_path_maybe_in_datadir): Factor this code
out of get_init_files.
(get_init_files): Update.
To avoid manual memory management.
Tested on buildbot.
gdb/ChangeLog:
2019-09-11 Christian Biesinger <cbiesinger@google.com>
* main.c (get_init_files): Change to use std::string.
(captured_main_1): Update.
(print_gdb_help): Update.
The code used to have undefined behaviour when template parameter is float and
host_float is NaN, because it attempted to convert NaN value to LONGEST at the
last statement. This frequently caused crashes on tests that checked "info
all-registers" (at least when the code is compiled with clang; I didn't test
with gdb).
gdb/ChangeLog:
*target-float.c (host_float_ops<T>::to_longest): Update
implementation.
This parameter is really a boolean, so change the type accordingly
and update the callers.
This is for symbol_set_names, add_psymbol_to_bcache, and
add_psymbol_to_list.
minimal_symbol_reader::record_full was already passing a bool
to symbol_set_names.
gdb/ChangeLog:
2019-09-11 Christian Biesinger <cbiesinger@google.com>
* dbxread.c (read_dbx_symtab): Update.
* dwarf2read.c (load_partial_dies): Update.
* mdebugread.c (parse_partial_symbols): Update.
(handle_psymbol_enumerators): Update.
* psympriv.h (add_psymbol_to_list): Change type of copy_names to bool.
* psymtab.c (add_psymbol_to_bcache): Likewise.
(add_psymbol_to_list): Likewise.
* symtab.c (symbol_set_names): Likewise.
* symtab.h (symbol_set_names): Likewise.
* xcoffread.c (scan_xcoff_symtab): Update.
This introduces a new bfd_set_filename function, which is then used in
various spots in gdb. This allows for the removal of some casts.
bfd/ChangeLog
2019-09-11 Tom Tromey <tom@tromey.com>
* opncls.c (bfd_set_filename): New function.
* bfd-in2.h: Regenerate.
gdb/ChangeLog
2019-09-11 Tom Tromey <tom@tromey.com>
* symfile-mem.c (symbol_file_add_from_memory): Use
bfd_set_filename.
* solib-darwin.c (darwin_bfd_open): Use bfd_set_filename.
* solib-aix.c (solib_aix_bfd_open): Use bfd_set_filename.
This updates the "save gdb-index" documentation to reflect the new
state of Ada support. It also corrects an existing grammatical error.
gdb/doc/ChangeLog
2019-09-10 Tom Tromey <tromey@adacore.com>
* gdb.texinfo (Index Files): Update Ada text.
This adds Ada support to the cc-with-tweaks.exp board file, so that we
can test Ada this way. The cc-with-tweaks.sh script already works
reasonably well as a wrapper for gnatmake.
gdb/testsuite/ChangeLog
2019-09-10 Tom Tromey <tromey@adacore.com>
* boards/cc-with-tweaks.exp: Set GNATMAKE_FOR_TARGET.
This patch adds support for Ada to .debug_names. I opted to leave
.gdb_index alone, because in my view it is a defunct format.
gdb/ChangeLog
2019-09-10 Tom Tromey <tromey@adacore.com>
* dwarf-index-write.c (write_psymbols): Extend error message.
(debug_names::insert): Add Ada code.
(debug_names::write_psymbols): Remove Ada check.
(debug_names) <m_string_obstack>: New member.
* dwarf2read.c (gdb_index_symbol_name_matcher): Remove.
(gdb_index_symbol_name_matcher::matches): Remove.
(mapped_index_base::find_name_components_bounds): Add "lang"
parameter.
(mapped_index_base::build_name_components): Also split names
according to Ada syntax.
(dw2_expand_symtabs_matching_symbol): Loop over languages. Change
type of "match_callback".
(check_match, check_find_bounds_finds)
(dw2_expand_symtabs_matching): Update.
(dw2_debug_names_iterator): Add new constructor.
(dw2_debug_names_map_matching_symbols): New function.
(dw2_debug_names_expand_symtabs_matching): Update.
(dwarf2_debug_names_functions): Use
dw2_debug_names_map_matching_symbols.
An internal Ada test case showed that the .debug_names code does not
compute the same list of file names as the partial symbol reader. In
particular, the partial symbol reader uses the DW_AT_name of the CU:
/* Allocate a new partial symbol table structure. */
filename = dwarf2_string_attr (comp_unit_die, DW_AT_name, cu);
if (filename == NULL)
filename = "";
pst = create_partial_symtab (per_cu, filename);
This patch changes the .debug_names reader to follow.
gdb/ChangeLog
2019-09-10 Tom Tromey <tromey@adacore.com>
* dwarf2read.c (dw2_get_file_names_reader): Add the
CU's file name to the results.
gdb/testsuite/ChangeLog
2019-09-10 Tom Tromey <tromey@adacore.com>
* gdb.ada/dgopt.exp: New file.
* gdb.ada/dgopt/x.adb: New file.
This patch further simplifies the map_matching_symbols callback, by
having it take a lookup_name_info rather than a plain string.
gdb/ChangeLog
2019-09-10 Tom Tromey <tromey@adacore.com>
* ada-lang.c (add_nonlocal_symbols): Combine calls to
map_matching_symbols. Update.
* dwarf2read.c (dw2_map_matching_symbols): Update.
* psymtab.c (match_partial_symbol): Change type; update.
(psym_map_matching_symbols): Likewise.
* symfile-debug.c (debug_qf_map_matching_symbols): Change
type; update.
* symfile.h (struct quick_symbol_functions)
<map_matching_symbols>: Change "name" to be a lookup_name_info.
Remove "match".
This introduces a new helper function,
iterate_over_symbols_terminated, and changes psym_map_matching_symbols
to use it. A subsequent patch will introduce a new user of this
function in the DWARF reader.
gdb/ChangeLog
2019-09-10 Tom Tromey <tromey@adacore.com>
* psymtab.c (map_block): Remove.
(psym_map_matching_symbols): Use iterate_over_symbols_terminated.
* symtab.c (iterate_over_symbols_terminated): New function.
* symtab.c (iterate_over_symbols_terminated): Declare.
This changes iterate_over_symbols to return a bool. This allows it to
be reused in another context in a subsequent patch.
gdb/ChangeLog
2019-09-10 Tom Tromey <tromey@adacore.com>
* ada-lang.c (ada_iterate_over_symbols): Return bool.
* language.h (struct language_defn) <la_iterate_over_symbols>:
Return bool.
* symtab.c (iterate_over_symbols): Return bool.
* symtab.h (iterate_over_symbols): Return bool.
This changes map_matching_symbols to take a
symbol_found_callback_ftype, rather than separate callback and data
parameters. This enables a future patch to clean up some existing
code so that it can more readily be shared.
gdb/ChangeLog
2019-09-10 Tom Tromey <tromey@adacore.com>
* ada-lang.c (aux_add_nonlocal_symbols): Change type.
(add_nonlocal_symbols): Update.
* dwarf2read.c (dw2_map_matching_symbols): Change type.
* psymtab.c (map_block, psym_map_matching_symbols): Change type.
* symfile-debug.c (debug_qf_map_matching_symbols): Change type.
* symfile.h (struct quick_symbol_functions) <map_matching_symbols>:
Change type of "callback". Remove "data".
* DW_UT_skeleton and DW_UT_split_compile compilation units have dwo ids
to match the compilation unit in the skeleton and .dwo files. The dwo_id is
in the header.
Tested with CC=/usr/bin/gcc (version 8.3.0) against master branch (also with
-gsplit-dwarf and -gdwarf-4 flags) and there was no increase in the set of
tests that fails.
This is part of an effort to support DWARF 5 in gdb.
gdb/ChangeLog:
* dwarf2read.c (comp_unit_head): Update comment.
(dwarf2_dwo_name): New function declaration.
(dwarf_unit_type_name): New function declaration.
(read_comp_unit_head): Add support for new compilation units,
DW_UT_partial, DW_UT_skeleton, DW_UT_split_compile, DW_UT_split_type.
Particularly, DW_UT_skeleton and DW_UT_split_compile have dwo_id
(currently named as "signature") in their header. Also clarify error
messages.
(lookup_dwo_id): New function. Returns the dwo id of the given
compile unit.
(lookup_dwo_unit): Use the new lookup_dwo_id function.
(init_cutu_and_read_dies): Use the new dwarf2_dwo_name and lookup_dwo_id
functions.
(create_dwo_cu_reader): Use the added lookup_dwo_id function.
(dwarf2_dwo_name): Get the dwo name if present.
(dwarf_unit_type_name): Convert DW_UT_* types to string for diagnostic
purposes.
This changes the "info win" command to use ui-out. This yields
somewhat nicer table output.
gdb/ChangeLog
2019-09-09 Tom Tromey <tom@tromey.com>
* tui/tui-win.c (tui_all_windows_info): Use ui_out.
Valgrind reports the below leak.
Make the variable progname_copy static, so that Valgrind continues
to find a pointer to the memory given to Python.
Note that the comment in do_start_initialization and the Python documentation
indicates that the progname given to Py_SetProgramName cannot be freed.
However, in Python 3.7.4, Py_SetProgramName does:
void
Py_SetProgramName(const wchar_t *program_name)
{
...
PyMem_RawFree(_Py_path_config.program_name);
_Py_path_config.program_name = _PyMem_RawWcsdup(program_name);
So, it looks like 3.7.4 Python duplicates its argument, which explains
the leak found by Valgrind.
It looks better to respect the doc and not have GDB freeing the string
given to Py_SetProgramName, and avoid the leak error by declaring
the progname_copy static.
This will work with Python versions that really use this string without
duplicating it, and avoids a leak report for Python version that duplicates
it.
==4023== 200 bytes in 1 blocks are definitely lost in loss record 4,545 of 7,116^M
==4023== at 0x4C29F33: malloc (vg_replace_malloc.c:307)^M
==4023== by 0x446D27: xmalloc (alloc.c:60)^M
==4023== by 0x657C77: do_start_initialization (python.c:1610)^M
==4023== by 0x657C77: _initialize_python() (python.c:1823)^M
==4023== by 0x75FE24: initialize_all_files() (init.c:231)^M
==4023== by 0x708A94: gdb_init(char*) (top.c:2242)^M
==4023== by 0x5E7460: captured_main_1 (main.c:857)^M
==4023== by 0x5E7460: captured_main (main.c:1161)^M
==4023== by 0x5E7460: gdb_main(captured_main_args*) (main.c:1186)^M
==4023== by 0x4122D4: main (gdb.c:32)^M
gdb/ChangeLog
2019-09-09 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* python/python.c (do_start_initialization): Make progname_copy static,
to avoid a leak report.
