This changes dwarf2-frame.c to use the type-safe registry API.
gdb/ChangeLog
2019-05-08 Tom Tromey <tom@tromey.com>
* dwarf2-frame.c (dwarf2_frame_objfile_data): Change type.
(dwarf2_frame_find_fde, dwarf2_build_frame_info)
(_initialize_dwarf2_frame): Update.
This changes objc-lang.c to use the type-safe registry API.
gdb/ChangeLog
2019-05-08 Tom Tromey <tom@tromey.com>
* objc-lang.c (objc_objfile_data): Change type.
(find_methods): Update.
(_initialize_objc_lang): Remove.
This changes stabsread.c to use the type-safe registry API.
gdb/ChangeLog
2019-05-08 Tom Tromey <tom@tromey.com>
* stabsread.c (rs6000_builtin_type_data): Change type.
(rs6000_builtin_type, _initialize_stabsread): Update.
mips_pdr_data is unused, so this patch removes it.
gdb/ChangeLog
2019-05-08 Tom Tromey <tom@tromey.com>
* mips-tdep.c (mips_pdr_data): Remove.
(_initialize_mips_tdep): Update.
This changes hppa-tdep.c to use the type-safe registry API.
gdb/ChangeLog
2019-05-08 Tom Tromey <tom@tromey.com>
* hppa-tdep.c (hppa_objfile_priv_data): Change type.
(hppa_init_objfile_priv_data, read_unwind_info)
(find_unwind_entry, _initialize_hppa_tdep): Update.
This changes elfread.c to use the type-safe registry API. This also
fixes a potential memory leak, by changing the hash table so that it
is no longer allocated on an obstack.
gdb/ChangeLog
2019-05-08 Tom Tromey <tom@tromey.com>
* elfread.c (elf_objfile_gnu_ifunc_cache_data): Change type.
(elf_gnu_ifunc_record_cache): Update. Don't allocate hash table
on obstack.
(elf_gnu_ifunc_resolve_by_cache, _initialize_elfread): Update.
This changes mdebugread.c to use the type-safe registry API.
gdb/ChangeLog
2019-05-08 Tom Tromey <tom@tromey.com>
* mdebugread.c (basic_type_data): Change type.
(basic_type, _initialize_mdebugread): Update.
This adds a no-op deleter, which is used in subsequent patches.
gdb/ChangeLog
2019-05-08 Tom Tromey <tom@tromey.com>
* common/gdb_unique_ptr.h (struct noop_deleter): New.
This changes the probes code in elfread.c to use the type-safe
registry API. While doing this, I saw that the caller of get_probes
owns the probes, so I went through the code and changed the vectors to
store unique_ptrs, making the ownership relationship more clear.
gdb/ChangeLog
2019-05-08 Tom Tromey <tom@tromey.com>
* symfile.h (struct sym_probe_fns) <sym_get_probes>: Change type.
* symfile-debug.c (debug_sym_get_probes): Change type.
* stap-probe.c (handle_stap_probe):
(stap_static_probe_ops::get_probes): Change type.
* probe.h (class static_probe_ops) <get_probes>: Change type.
* probe.c (class any_static_probe_ops) <get_probes>: Change type.
(parse_probes_in_pspace): Update.
(find_probes_in_objfile, find_probe_by_pc, collect_probes):
Update.
(any_static_probe_ops::get_probes): Change type.
* elfread.c (elfread_data): New typedef.
(probe_key): Change type.
(elf_get_probes): Likewise. Update.
(probe_key_free): Remove.
(_initialize_elfread): Update.
* dtrace-probe.c (class dtrace_static_probe_ops) <get_probes>:
Change type.
(dtrace_process_dof_probe, dtrace_process_dof)
(dtrace_static_probe_ops::get_probe): Change type.
This changes xcoffread.c to use the type-safe registry API. It also
renames coff_symfile_info to xcoff_symfile_info, to avoid any possible
ODR violation.
gdb/ChangeLog
2019-05-08 Tom Tromey <tom@tromey.com>
* xcoffread.c (struct xcoff_symfile_info): Rename from
coff_symfile_info. Add initializers.
(xcoff_objfile_data_key): Move lower. Change type.
(XCOFF_DATA): Rewrite.
(xcoff_free_info): Remove.
(xcoff_symfile_init, _initialize_xcoffread, read_xcoff_symtab)
(read_symbol, read_symbol_lineno, find_linenos, init_stringtab)
(xcoff_initial_scan): Update.
This changes solib-svr4y.c to use the type-safe registry API.
gdb/ChangeLog
2019-05-08 Tom Tromey <tom@tromey.com>
* solib-svr4.c (struct svr4_info): Add initializers and
destructor.
<probes_table>: Now an htab_up.
(solib_svr4_pspace_data): Change type.
(free_probes_table): Simplify.
(~svr4_info): Rename from svr4_pspace_data_cleanup.
(get_svr4_info, probes_table_htab_remove_objfile_probes)
(probes_table_remove_objfile_probes, register_solib_event_probe)
(solib_event_probe_at, svr4_update_solib_event_breakpoint)
(_initialize_svr4_solib): Update.
This changes remote.c to use the type-safe registry API.
gdb/ChangeLog
2019-05-08 Tom Tromey <tom@tromey.com>
* remote.c (remote_pspace_data): Change type.
(remote_pspace_data_cleanup): Remove.
(get_remote_exec_file, set_pspace_remote_exec_file)
(_initialize_remote): Update.
This changes breakpoint.c to use the type-safe registry API.
gdb/ChangeLog
2019-05-08 Tom Tromey <tom@tromey.com>
* breakpoint.c (breakpoint_objfile_key): Change type.
(get_breakpoint_objfile_data): Update.
(free_breakpoint_objfile_data): Remove.
(_initialize_breakpoint): Update.
This changes dwarf2_per_objfile to use the type-safe registry API.
This also changes dwarf2_per_objfile not to be allocated on an
obstack. It seemed clearer to me to simply allocate it on the heap;
and I didn't see a drawback from doing so.
gdb/ChangeLog
2019-05-08 Tom Tromey <tom@tromey.com>
* dwarf2read.h (struct dwarf2_per_objfile): Don't inherit from
allocate_on_obstack.
* dwarf2read.c (dwarf2_objfile_data_key): Change type.
(get_dwarf2_per_objfile): Update.
(set_dwarf2_per_objfile): Remove.
(dwarf2_has_info, dwarf2_get_section_info): Update.
(dwarf2_free_objfile): Remove.
(_initialize_dwarf2_read): Update.
This changes auto-load.c to use the type-safe registry API. It also
changes a couple of types to "bool", removing uses of "FALSE".
gdb/ChangeLog
2019-05-08 Tom Tromey <tom@tromey.com>
* auto-load.c (struct auto_load_pspace_info): Add destructor and
initializers.
<unsupported_script_warning_printed,
script_not_found_warning_printed>: Now bool.
(auto_load_pspace_data): Change type.
(~auto_load_pspace_info): Rename from
auto_load_pspace_data_cleanup.
(get_auto_load_pspace_data, init_loaded_scripts_info)
(clear_section_scripts, maybe_print_unsupported_script_warning)
(maybe_print_script_not_found_warning, _initialize_auto_load):
Update.
This changes inflow.c to use the type-safe registry API. This fixes a
latent bug in swap_terminal_info, which previously said:
terminal_info *info_a
= (terminal_info *) inferior_data (a, inflow_inferior_data);
terminal_info *info_b
= (terminal_info *) inferior_data (a, inflow_inferior_data);
... both of which examine 'a'.
gdb/ChangeLog
2019-05-08 Tom Tromey <tom@tromey.com>
* inflow.c (struct terminal_info): Add destructor and
initializers.
(inflow_inferior_data): Change type.
(~terminal_info): Rename from inflow_inferior_data_cleanup.
(get_inflow_inferior_data, inflow_inferior_exit)
(swap_terminal_info, _initialize_inflow): Update.
This changes DECLARE_REGISTRY to add a type-safe interface. This
interface is a C++ class that handles the details of registering a
key, and provides various useful methods, including policy-based
cleanup.
gdb/ChangeLog
2019-05-08 Tom Tromey <tom@tromey.com>
* registry.h (DECLARE_REGISTRY): Define the _key class.
Commit 2e62ab400f added a second 'New commands' section to the NEWS
file, this commit merges the two together.
gdb/ChangeLog:
* NEWS: Merge two 'New commands' sections.
- set print frame-arguements all
- an Ada function named pck.call_me calls a C function named break_me
- you put a breakpoint in break_me and the program reaches this
breakpoint.
Now display the backtrace:
(gdb) bt
#0 break_me () at [...]
#1 0x000000000040243e in pck.call_me (
s={P_ARRAY = 0x7fffffffe21c, P_BOUNDS = 0x41e6e8}) at [...]
whereas we should expect:
(gdb) bt
#0 break_me () at [...]
#1 0x000000000040243e in pck.call_me (s="test") at [...]
The problem is that GDB prints the S parameter in the pck.call_me Ada
function using the current language, so the C one, because the program
is stopped in a C function, whereas it should use the pck.call_me frame
one. This behavior is ok when user manually changes the language but it's
not the right one when language is auto.
This patch fixes this problem so now when using auto language, all Ada
frame arguments are printed using Ada like syntax when the frame is part
of Ada code, even if the program is stopped in a frame using a different
language.
If the user explicitly sets a language (using "set language ...") then
no change here, all the Ada frame arguments are printed using this
language.
gdb/ChangeLog:
* ada-valprint.c (ada_val_print_gnat_array): Remove language
parameter and use Ada language definition instead.
(ada_val_print_ptr): Remove unused language parameter.
(ada_val_print_num): Remove language parameter and use Ada language
definition instead.
(ada_val_print_enum, ada_val_print_flt): Remove unused language
parameter.
(ada_val_print_struct_union, ada_val_print_ref): Remove language
parameter and use Ada language definition instead.
(ada_val_print_1): Update all ada_val_print_xxx calls.
Remove language parameter.
(ada_val_print): Update ada_val_print_1 call.
gdb/testsuite/ChangeLog:
* gdb.ada/frame_arg_lang.exp: New testcase.
* gdb.ada/frame_arg_lang/bla.adb: New file.
* gdb.ada/frame_arg_lang/pck.ads: New file.
* gdb.ada/frame_arg_lang/pck.adb: New file.
* gdb.ada/frame_arg_lang/foo.c: New file.
Tested on x86_64-linux, no regressions.
I noticed a three globals in remote.c that could be static. This
patch makes this change.
gdb/ChangeLog
2019-05-08 Tom Tromey <tromey@adacore.com>
* remote.c (remote_hw_watchpoint_limit)
(remote_hw_watchpoint_length_limit, remote_hw_breakpoint_limit):
Now static.
The "watchdog" global is only used in remote.c, so this patch moves it
there and makes it static.
gdb/ChangeLog
2019-05-08 Tom Tromey <tromey@adacore.com>
* maint.c (_initialize_maint_cmds): Move initialization code to
remote.c.
(watchdog, show_watchdog): Move to remote.c.
* remote.c (watchdog, show_watchdog): Move from maint.c. Make
"watchdog" static.
(_initialize_remote): Move initialization code from maint.c.
* defs.h (watchdog): Don't declare.
This moves the interpreter_p declaration from defs.h to main.h. I
think this makes more sense, as it is defined in main.c. Also, this
declaration was in the wrong place -- between a comment and the things
the comment described.
gdb/ChangeLog
2019-05-08 Tom Tromey <tromey@adacore.com>
* tui/tui-interp.c: Include main.h.
* interps.c: Include main.h.
* main.h (interpreter_p): Declare.
* defs.h (interpreter_p): Don't declare.
I noticed that read_unsigned_leb128 is declared in defs.h. There's no
reason this should be here, so this patch moves it to dwarf2read.h.
gdb/ChangeLog
2019-05-08 Tom Tromey <tromey@adacore.com>
* dwarf2loc.c: Include dwarf2read.h.
* defs.h (read_unsigned_leb128): Don't declare.
* dwarf2read.h (read_unsigned_leb128): Declare.
When merging commit 99f20f ("Fix style bug when paging") to master, I
had to make some changes to get it to compile again. Unfortunately, I
must not have added these to the index at the correct time, because
they were not committed.
This patch fixes the problem.
gdb/ChangeLog
2019-05-08 Tom Tromey <tromey@adacore.com>
* utils.c (fputs_maybe_filtered): Call can_emit_style_escape as a
method.
Philippe pointed out a styling bug that would occur in some conditions
when paging:
https://sourceware.org/ml/gdb-patches/2019-04/msg00101.html
I was finally able to reproduce this, and this patch fixes the bug.
The problem occurred when text overflowed the line, causing a
pagination prompt, but when no wrap column had been set. In this
case, the current style was reset to show the prompt, but then not
reset back to the previously applied style before emitting the rest of
the line.
The fix is to record the applied style in this case, and re-apply it
afterward -- but only if the pager prompt was emitted, something that
the existing style.exp pointed out on the first, more naive, version
of the patch.
Tested on x86-64 Fedora 29.
gdb/ChangeLog
2019-05-08 Tom Tromey <tromey@adacore.com>
* utils.c (fputs_maybe_filtered): Reset style after paging, even
when no wrap column is set.
A user here noticed that the Python Value.string method did not work
for Ada arrays. I tracked this down to an oddity in value_as_address
-- namely, it calls coerce_array, but that function will not force
array coercion when the language has c_style_arrays=false, as Ada
does.
This patch fixes the problem by changing c_get_string so that arrays
take the "in GDB's memory" branch. The actual patch is somewhat more
complicated than you might think, because the caller can request more
array elements than the type allows. This is normal when the type is
using the C struct hack.
Tested on x86-64 Fedora 29.
gdb/ChangeLog
2019-05-08 Tom Tromey <tromey@adacore.com>
* c-lang.c (c_get_string): Handle non-C-style arrays.
gdb/testsuite/ChangeLog
2019-05-08 Tom Tromey <tromey@adacore.com>
* gdb.python/py-value.exp (test_value_in_inferior): Add Ada test.
Consider this short C example:
struct inner
{
unsigned x;
unsigned y : 3;
unsigned z : 3;
};
struct outer
{
unsigned char o : 3;
struct inner i __attribute__ ((packed));
};
When I use "ptype/o" on this, I get:
(gdb) ptype/o struct outer
/* offset | size */ type = struct outer {
/* 0: 5 | 1 */ unsigned char o : 3;
/* XXX 5-bit hole */
/* 1 | 8 */ struct inner {
/* 1 | 4 */ unsigned int x;
/* 5:29 | 4 */ unsigned int y : 3;
/* 5:26 | 4 */ unsigned int z : 3;
/* XXX 2-bit padding */
/* XXX 3-byte padding */
/* total size (bytes): 8 */
} i;
/* total size (bytes): 9 */
}
In the location of "o" ("0: 5"), the "5" means "there are 5 bits left
relative to the size of the underlying type.
I find this very difficult to follow. On irc, Sergio said that this
choice came because it is what pahole does. However, I think it's not
very useful, and maybe is just an artifact of the way that
DW_AT_bit_offset was defined in DWARF 3.
This patch changes ptype/o to print the offset of a bitfield in a more
natural way, that is, using the bit number according to the platform's
bit numbering.
With this patch, the output is now:
(gdb) ptype/o struct outer
/* offset | size */ type = struct outer {
/* 0: 0 | 1 */ unsigned char o : 3;
/* XXX 5-bit hole */
/* 1 | 8 */ struct inner {
/* 1 | 4 */ unsigned int x;
/* 5: 0 | 4 */ unsigned int y : 3;
/* 5: 3 | 4 */ unsigned int z : 3;
/* XXX 2-bit padding */
/* XXX 3-byte padding */
/* total size (bytes): 8 */
} i;
/* total size (bytes): 9 */
}
This is better, IMO, because now the "offset" of a bitfield is
consistent with the offset of an ordinary member, referring to its
offset from the start of the structure.
gdb/ChangeLog
2019-05-08 Tom Tromey <tromey@adacore.com>
* typeprint.c (print_offset_data::update): Print the bit offset,
not the number of bits remaining.
gdb/doc/ChangeLog
2019-05-08 Tom Tromey <tromey@adacore.com>
* gdb.texinfo (Symbols): Document change to ptype/o.
gdb/testsuite/ChangeLog
2019-05-08 Tom Tromey <tromey@adacore.com>
* gdb.base/ptype-offsets.exp: Update tests.
I noticed that ptype/o will print:
/* 3: 3 | 1 */ signed char a4 : 2;
/* XXX 3-bit hole */
That is, "*/" at the end of the "hole" message does not line up with
the other comment ends. I thought it would be a bit nicer if this did
line up, so I fixed it. Then, to my surprise, I found that I could
not make ptype-offsets.exp fail.
I still am not sure why it doesn't fail, but changing the tests to use
string_to_regexp and changing the quoting helped. This in turn showed
that some of the existing test cases were wrong, so I've also updated
them here.
gdb/ChangeLog
2019-05-08 Tom Tromey <tromey@adacore.com>
* typeprint.c (print_offset_data::maybe_print_hole): Add extra
padding at end of comment.
gdb/testsuite/ChangeLog
2019-05-08 Tom Tromey <tromey@adacore.com>
* gdb.base/ptype-offsets.exp: Use string_to_regexp. Fix test
cases.
* gdb.base/ptype-offsets.cc (struct abc) <my_int_type>: Now
"short".
While looking at a different Ada problem, I found that printing a
record containing a VLA did not work properly.
I tracked the problem down to dwarf2_evaluate_property trying, and
failing, to compare two types that differed only in qualifiers.
This patch changes dwarf2_evaluate_property to ignore qualifiers when
comparing types.
Tested on x86-64 Fedora 29.
gdb/ChangeLog
2019-05-08 Tom Tromey <tromey@adacore.com>
* dwarf2loc.c (dwarf2_evaluate_property) <PROP_ADDR_OFFSET>:
Compare main types.
gdb/testsuite/ChangeLog
2019-05-08 Tom Tromey <tromey@adacore.com>
* gdb.ada/vla.exp: New file.
* gdb.ada/vla/vla.adb: New file.
When adding a debug print here in index-cache.exp:
...
proc_with_prefix test_cache_disabled { cache_dir } {
lassign [ls_host $cache_dir] ret files_before
+ puts "before: '$files_before'"
+ exit
...
we have:
...
files_before: ''
...
When further adding:
...
proc_with_prefix test_cache_disabled { cache_dir } {
+ exec touch $cache_dir/foo.1 $cache_dir/foo.2 $cache_dir/foo.3
...
we have:
...
files_before: 'foo.1'
...
while we're expecting file_before to contain foo.[123].
Fix this by making the return statement in ls_host return a list rather than a
string (in accordance with the ls_host documentation), after which we have:
...
files_before: 'foo.1 foo.2 foo.3'
...
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-05-07 Tom de Vries <tdevries@suse.de>
* gdb.base/index-cache.exp (ls_host): Fix return statement.
When running gdb.dlang/watch-loc.exp with target board cc-with-debug-names, we
run into:
...
FAIL: gdb.dlang/watch-loc.exp: disassemble _Dmain (GDB internal error)
...
in more detail:
...
(gdb) disassemble _Dmain
gdb/dwarf2read.c:5293: internal-error: \
compunit_symtab* dw2_find_pc_sect_compunit_symtab(objfile*, \
bound_minimal_symbol, CORE_ADDR, obj_section*, int): \
Assertion `result != NULL' failed.
...
The problem is that the .debug_aranges section in watch-loc.c contains a
debug_info_offset which is set to 0:
...
asm (
" .pushsection .debug_aranges,\"\",%progbits\n"
" .4byte .Laranges_end - .Laranges_start\n"
".Laranges_start:\n"
" .2byte 0x2\n"
" .4byte 0\n"
...
while the compilation unit at offset 0 in the .debug_section in the executable
is in fact not the compilation unit generated from watch-loc-dw.S.
[ Note: this is a non-trivial test-case. The file watch-loc-dw.S contains a
.debug_info section, but not an .debug_aranges section or any actual code.
The file watch-loc.c contains code and a .debug_aranges section, but no other
debug section. So, the intent for the .debug_aranges section in watch-loc.c
is to refer to a compilation unit in the .debug_info section in
watch-loc-dw.S. ]
This happens when linked in object files contain dwarf info and are placed in
the .debug_info section before the compilation units generated from
watch-loc.c and watch-loc-dw.S.
Fix this by defining the debug_info_offset field using a label .Lcu1_begin
that defines the start of an empty .debug_section compilation unit:
...
asm (
+ " .pushsection .debug_info,\"\",%progbits\n"
+ ".Lcu1_begin:"
+ " .popsection\n"
" .pushsection .debug_aranges,\"\",%progbits\n"
" .4byte .Laranges_end - .Laranges_start \n"
".Laranges_start:\n"
" .2byte 0x2\n"
- " .4byte 0\n"
+ " .4byte .Lcu1_begin\n"
...
which during linking merges with the start of the .debug_info section of
watch-loc-dw.S.
Tested on x86_64-linux with native, cc-with-gdb-index and cc-with-debug-names.
gdb/testsuite/ChangeLog:
2019-05-07 Tom de Vries <tdevries@suse.de>
PR testsuite/24522
* gdb.dlang/watch-loc.c: Fix debug_info_offset in .debug_aranges
section.
When running gdb.dwarf2/dw2-case-insensitive.exp with target board
cc-with-debug-names, we run into:
...
FAIL: gdb.dwarf2/dw2-case-insensitive.exp: regexp case-sensitive off \
(GDB internal error)
...
in more detail:
...
(gdb) info functions fUnC_lang
gdb/dwarf2read.c:5293: internal-error: \
compunit_symtab* dw2_find_pc_sect_compunit_symtab(objfile*, \
bound_minimal_symbol, CORE_ADDR, obj_section*, int): \
Assertion `result != NULL' failed.
...
The problem is that the .debug_aranges section in dw2-case-insensitive-debug.S
contains a debug_info_offset which is set to 0:
...
.section .debug_aranges,"",@progbits
.4byte .Laranges_end - .Laranges_start
.Laranges_start:
.2byte 0x2
.4byte 0
...
while the compilation unit at offset 0 in the .debug_section of the executable
is in fact not the compilation unit generated from
dw2-case-insensitive-debug.S.
This happens when linked in object files contain dwarf info and are placed in
the .debug_info section before the compilation unit generated from
dw2-case-insensitive-debug.S.
Fix this by defining the debug_info_offset field using the label .Lcu1_begin
that defines the start of the compilation unit:
...
- .4byte 0
+ .4byte .Lcu1_begin
...
Tested on x86_64-linux with native, cc-with-gdb-index and cc-with-debug-names.
gdb/testsuite/ChangeLog:
2019-05-07 Tom de Vries <tdevries@suse.de>
PR testsuite/24522
* gdb.dwarf2/dw2-case-insensitive-debug.S: Fix debug_info_offset in
.debug_aranges section.
When running gdb.dwarf2/multidictionary.exp with target board cc-with-dwz and
current dwz, we run into a dwz abort:
...
gdb compile failed, gdb/contrib/cc-with-tweaks.sh: line 188: 11484 Aborted \
(core dumped) $DWZ "$output_file" > /dev/null 2>&1
UNTESTED: gdb.dwarf2/multidictionary.exp: multidictionary.exp
...
The dwz abort (PR dwz/24169) is caused by an invalid DW_FORM_ref_addr in the
multidictionary binary.
The multidictionary binary is build from multidictionary.S which is generated
using the dwarf assembler, and multidictionary.S contains dwarf for 3
compilation units.
In multidictionary0.o (generated from multidictionary.S), we find a concrete
formal parameter DIE:
...
<2><dc>: Abbrev Number: 4 (DW_TAG_formal_parameter)
<dd> DW_AT_abstract_origin: <0xa6>
...
referring to an abstract formal parameter DIE at 0xa6:
...
<2><a6>: Abbrev Number: 8 (DW_TAG_formal_parameter)
<a7> DW_AT_name : msg
<ab> DW_AT_type : <0x92>
...
but in the multidictionary binary the concrete formal parameter DIE is still
referring to 0xa6:
...
<2><1a3>: Abbrev Number: 4 (DW_TAG_formal_parameter)
<1a4> DW_AT_abstract_origin: <0xa6>
...
while the abstract formal parameter DIE has moved to 0x16d:
...
<2><16d>: Abbrev Number: 8 (DW_TAG_formal_parameter)
<16e> DW_AT_name : msg
<172> DW_AT_type : <0x159>
...
The concrete formal parameter DIE is specified in multidictionary.S like this:
...
.Llabel21:
.uleb128 4
.4byte .Llabel17 - .Lcu1_begin
...
The problem is that the .Lcu1_begin label is assumed to mark the start of the
.debug_info section in the executable, but in fact it marks the start of the
first compilation unit from multidictionary.S in the executable. Usually
these two entities are the same, but they are not when linked in object files
contain dwarf info and are placed in the .debug_info section before the
compilation units generated from multidictionary.S.
Fix this in the dwarf assembler by generating instead the label itself:
...
.Llabel21:
.uleb128 4
.4byte .Llabel17
...
resulting in a relocation in the object file:
...
Offset Info Type Sym. Value Sym. Name + Addend
0000000000dd 00040000000a R_X86_64_32 0000000000000000 .debug_info + a6
...
and resulting in the correct offset in the executable:
...
<2><1a3>: Abbrev Number: 4 (DW_TAG_formal_parameter)
<1a4> DW_AT_abstract_origin: <0x16d>
...
Tested on x86_64-linux with native and cc-with-dwz.
gdb/testsuite/ChangeLog:
2019-05-07 Tom de Vries <tdevries@suse.de>
PR testsuite/24159
* lib/dwarf.exp: Fix handling of DW_FORM_ref_addr.
I noticed that scoped_mmap.h included config.h, and that scoped_mmap.c
included defs.h. This patch fixes both of these problems.
Tested by the buildbot.
gdb/ChangeLog
2019-05-06 Tom Tromey <tom@tromey.com>
* common/scoped_mmap.c: Include common-defs.h.
* common/scoped_mmap.h: Don't include config.h.
This line of code...
*(int64_t *) ptr = *(int32_t *) ptr;
...in linux-x86-low.c is not needed (and does not work correctly)
within a 32-bit executable. I added an __x86_64__ ifdef (which is
used extensively elsewhere in the file for like purposes) to prevent
this code from being included in 32-bit builds.
It fixes the following regressions when running on native
i686-pc-linux-gnu:
FAIL: gdb.server/abspath.exp: continue to main
FAIL: gdb.server/connect-without-multi-process.exp: multiprocess=auto: continue to main
FAIL: gdb.server/connect-without-multi-process.exp: multiprocess=off: continue to main
FAIL: gdb.server/ext-restart.exp: restart: run to main
FAIL: gdb.server/ext-restart.exp: run to main
FAIL: gdb.server/ext-run.exp: continue to main
FAIL: gdb.server/ext-wrapper.exp: print d
FAIL: gdb.server/ext-wrapper.exp: restart: print d
FAIL: gdb.server/ext-wrapper.exp: restart: run to marker
FAIL: gdb.server/ext-wrapper.exp: run to marker
FAIL: gdb.server/no-thread-db.exp: continue to breakpoint: after tls assignment
FAIL: gdb.server/reconnect-ctrl-c.exp: first: stop with control-c
FAIL: gdb.server/reconnect-ctrl-c.exp: second: stop with control-c
FAIL: gdb.server/run-without-local-binary.exp: run test program until the end
FAIL: gdb.server/server-kill.exp: continue to breakpoint: after server_pid assignment
FAIL: gdb.server/server-kill.exp: tstatus
FAIL: gdb.server/server-run.exp: continue to main
gdb/gdbserver/ChangeLog:
* linux-x86-low.c (x86_fill_gregset): Don't compile 64-bit
sign extension code on 32-bit builds.
In gdb.base/index-cache.exp, handle the case that binfile contains either a
.gdb_index or .debug_names index section.
Tested on x86_64-linux with native, cc-with-gdb-index and cc-with-debug-names.
gdb/testsuite/ChangeLog:
2019-05-06 Tom de Vries <tdevries@suse.de>
* lib/gdb.exp (exec_has_index_section): New proc.
* gdb.base/index-cache.exp: Handle case that binfile contains an index
section.
This removes a VEC from aarch64-tdep.c, replacing it with a
std::vector.
gdb/ChangeLog
2019-05-04 Tom Tromey <tom@tromey.com>
* aarch64-tdep.c (stack_item_t): Remove typedef and DEF_VEC.
(struct aarch64_call_info): Add initializers.
<si>: Now a std::vector.
(pass_on_stack, aarch64_push_dummy_call): Update.
This replaces a VEC in ppc-linux-nat.c with a std::vector.
gdb/ChangeLog
2019-05-04 Simon Marchi <simon.marchi@efficios.com>
Tom Tromey <tom@tromey.com>
* ppc-linux-nat.c (thread_points_p): Remove typedef and DEF_VEC.
(ppc_threads): Now a std::vector. Now static.
(hwdebug_find_thread_points_by_tid)
(ppc_linux_nat_target::low_new_thread, ppc_linux_thread_exit):
Update.
This changes arm-linux-nat.c to use gdb_assert_not_reached rather than
an assert of false.
gdb/ChangeLog
2019-05-04 Tom Tromey <tom@tromey.com>
* arm-linux-nat.c (arm_linux_nat_target::can_use_hw_breakpoint):
Use gdb_assert_not_reached.
This changes compile_cplus_convert_enum to use "false".
Note that this variable is never modified, which seems like an error.
I filed PR compile/24473 for this.
gdb/ChangeLog
2019-05-04 Tom Tromey <tom@tromey.com>
* compile/compile-cplus-types.c (compile_cplus_convert_enum): Use
"false".
This changes select_frame_for_mi to use "false" rather than "FALSE".
gdb/ChangeLog
2019-05-04 Tom Tromey <tom@tromey.com>
* stack.c (select_frame_for_mi): Use "false", not "FALSE".
The 'is' operator is not meant to be used for comparisons. It currently working
is an implementation detail of CPython. CPython 3.8 has added a SyntaxWarning
for this.
This patch partly reverts commit 8a6d42345 ("Change representation of
psymbol to flush out accessors"); specifically, it changes
partial_symbol to no longer derive from general_symbol_info.
The basic problem here is that the bcache compares objects bitwise,
and this change made it less likely that the relevant fields in the
psymbol would be fully initialized. This could be seen by running a
test under valgrind on the Fedora-i686 buildbot.
I considered a simpler patch, namely just zeroing the psymbol's
"value" field in add_psymbol_to_bcache. However, it wasn't clear to
me that this memset could not then be optimized away by the compiler.
Regression tested by the buildbot. I think this should go in 8.3 as
well.
gdb/ChangeLog
2019-05-04 Tom Tromey <tom@tromey.com>
* psymtab.c (psymbol_name_matches, match_partial_symbol)
(lookup_partial_symbol, print_partial_symbols)
(recursively_search_psymtabs, sort_pst_symbols, psymbol_hash)
(psymbol_compare): Update.
(add_psymbol_to_bcache): Clear the entire psymbol.
(maintenance_check_psymtabs): Update.
* psympriv.h (struct partial_symbol): Don't derive from
general_symbol_info.
<obj_section, unrelocated_address, address,
set_unrelocated_address>: Update.
<ginfo>: New member.
* dwarf-index-write.c (write_psymbols, debug_names::insert)
(debug_names::write_psymbols): Update.
Add a target board that makes it easy to run the test suite with a
.debug_names section added to executables.
gdb/ChangeLog:
2019-05-04 Tom de Vries <tdevries@suse.de>
* contrib/cc-with-tweaks.sh: Support -n arg.
gdb/testsuite/ChangeLog:
2019-05-04 Tom de Vries <tdevries@suse.de>
* boards/cc-with-debug-names.exp: New file.
Valgrind reports leaks such as the below in the tests:
gdb.threads/corethreads.exp
gdb.threads/gcore-thread.exp
gdb.ada/task_switch_in_core.exp
gdb.trace/tfile.exp
gdb.base/siginfo-thread.exp
==12701== 1,123 (72 direct, 1,051 indirect) bytes in 1 blocks are definitely lost in loss record 2,928 of 3,247
==12701== at 0x4C2C4CC: operator new(unsigned long) (vg_replace_malloc.c:344)
==12701== by 0x5CF771: get_thread_arch_aspace_regcache(ptid_t, gdbarch*, address_space*) (regcache.c:330)
==12701== by 0x5CF92A: get_thread_regcache (regcache.c:366)
==12701== by 0x5CF92A: get_current_regcache() (regcache.c:372)
==12701== by 0x4C7964: get_current_frame() (frame.c:1587)
==12701== by 0x4C7A3C: get_selected_frame(char const*) (frame.c:1651)
==12701== by 0x669EAD: print_thread_info_1(ui_out*, char const*, int, int, int) (thread.c:1151)
==12701== by 0x66A9A1: info_threads_command(char const*, int) (thread.c:1217)
==12701== by 0x40A878: cmd_func(cmd_list_element*, char const*, int) (cli-decode.c:1892)
...
Fix these leaks by clearing registers and frame caches.
This leak and fix is similar to the leak fixed by 799efbe8e0
Some versions of gcc have a bug that causes
for (struct mumble : something)
... to give a compiler error. We routinely work around this bug in
gdb, but apparently had not done so in a while. This patch fixes the
remaining known cases of this problem.
gdb/ChangeLog
2019-05-03 Sandra Loosemore <sandra@codesourcery.com>
Tom Tromey <tom@tromey.com>
* dictionary.c (collate_pending_symbols_by_language): Remove
"struct" from foreach.
* symtab.c (lookup_global_symbol_from_objfile)
(lookup_symbol_in_objfile_from_linkage_name): Remove "struct" from
foreach.
* ser-tcp.c (net_open): Remove "struct" from foreach.
* objfiles.c (objfile_relocate, objfile_rebase)
(objfile_has_symbols): Remove "struct" from foreach.
* minsyms.c (lookup_minimal_symbol_by_pc_section): Remove "struct"
from foreach.
* dwarf2read.c (handle_struct_member_die): Remove "struct" from
foreach.
* darwin-nat.c (thread_info_from_private_thread_info): Remove
"struct" from foreach.
* ada-lang.c (create_excep_cond_exprs)
(ada_exception_catchpoint_cond_string): Remove "struct" from
foreach.
An internal bug report points out that, when a global character enum
type is used, casting fails, like:
(gdb) print global_char_enum'('F')
$1 = 70
The bug here turns out to be that enumerators are qualified, so for
example the mangled name might be "pck__QU48", rather than "QU48".
This patch fixes the problem by only examining the suffix of the
enumerator. This is ok because the type is already known, and because
the mangling scheme ensures that there won't be clashes.
Tested on x86-64 Fedora 29.
gdb/ChangeLog
2019-05-03 Tom Tromey <tromey@adacore.com>
* ada-exp.y (convert_char_literal): Check suffix of each
enumerator.
gdb/testsuite/ChangeLog
2019-05-03 Tom Tromey <tromey@adacore.com>
* gdb.ada/char_enum/pck.ads (Global_Enum_Type): New type.
* gdb.ada/char_enum/foo.adb: Use Global_Enum_Type.
* gdb.ada/char_enum.exp: Add test.
This patch comes from PR ada/21406. It adds the noyywrap option to
ada-lex.l. This was already done (by the same author) for other .l
files in the binutils-gdb tree, so it seems reasonably safe.
Tested on x86-64 Fedora 29.
gdb/ChangeLog
2019-05-03 Dilyan Palauzov <dilyan.palauzov@aegee.org>
PR ada/21406:
* ada-exp.y (yywrap): Don't define.
* ada-lex.l (%option): Add noyywrap
(yywrap): Remove.
Add a target board cc-with-gdb-index.exp, to make it easy to run cc-with-tweaks
with CC_WITH_TWEAKS_FLAGS='-i'.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-05-03 Tom de Vries <tdevries@suse.de>
* boards/cc-with-gdb-index.exp: New file.
This changeset defines _WIN32_WINNT to at least 0x0501, the level
of Windows XP, unless defined to a higher level, in a single
place. It then removes all the overrides of _WIN32_WINNT in
individual files as no longer needed. Doing this also solves
compilation of windows-nat.c with mingw.org's MinGW, as that
file uses CONSOLE_FONT_INFO which needs the XP level to become
exposed in the Windows headers, while mingw.org defaults to
Windows 9X.
gdb/ChangeLog:
2019-05-03 Eli Zaretskii <eliz@gnu.org>
* common/common-defs.h [__MINGW32__ || __CYGWIN__]: Define
_WIN32_WINNT to the XP level, unless already defined to a higher
level.
* unittests/parse-connection-spec-selftests.c:
* ser-tcp.c:
* common/netstuff.c [USE_WIN32API]: Remove the _WIN32_WINNT
override.
gdb/gdbserver/ChangeLog:
2019-05-03 Eli Zaretskii <eliz@gnu.org>
* remote-utils.c:
* gdbreplay.c [USE_WIN32API]: Remove the _WIN32_WINNT override.
If you put the separate debug file in a global debug directory, GDB on
MS-Windows would fail to find it. This happens because we obtain the
directory to look up the debug file by concatenating the debug
directory name with the leading directories of the executable, and the
latter includes the drive letter on MS-Windows. So we get an invalid
file name like
d:/usr/lib/debug/d:/usr/bin/foo.debug
This commit fixes that by removing the colon of the drive letter,
thus producing
d:/usr/lib/debug/d/usr/bin/foo.debug
gdb/ChangeLog:
2019-05-03 Eli Zaretskii <eliz@gnu.org>
* symfile.c (find_separate_debug_file): Remove colon from the
drive spec of DOS/Windows file names of the target, so that the
file name produced from DEBUGDIR and the target's directory will
be valid on DOS/Windows systems.
gdb/doc/ChangeLog:
2019-05-03 Eli Zaretskii <eliz@gnu.org>
* gdb.texinfo (Separate Debug Files): Document how the
subdirectory of the global debug directory is computed on
MS-Windows/MS-DOS.
When printing a rust structure that contains a string GDB can
currently fail to read the fields that define the string. This is
because GDB mistakenly treats a value that is the parent structure as
though it is the structure that defines the string, and then fails to
find the fields needed to extract a string.
The solution is to create a new value to represent the string field of
the parent value.
gdb/ChangeLog:
* rust-lang.c (val_print_struct): Handle printing structures
containing strings.
gdb/testsuite/ChangeLog:
* gdb.rust/simple.exp: Add new test case.
* gdb.rust/simple.rs (struct StringAtOffset): New struct.
(main): Initialise an instance of the new struct.
I noticed that _initialize_valarith is empty. This patch removes it.
Because init.c is constructed at build time, there's no reason to keep
empty initialization functions around, because there's no overhead to
reintroducing them when needed.
gdb/ChangeLog
2019-05-02 Tom Tromey <tromey@adacore.com>
* valarith.c (_initialize_valarith): Remove.
A user at AdaCore found a case where assignment to a nested packed
structure would fail. The bug is that ada_value_primitive_field
doesn't account for the situation where a field is not packed relative
to its containing structure, but where the structure itself is packed
in its parent.
gdb/ChangeLog
2019-05-01 Tom Tromey <tromey@adacore.com>
* ada-lang.c (ada_value_primitive_field): Treat more fields as
bitfields.
gdb/testsuite/ChangeLog
2019-05-01 Tom Tromey <tromey@adacore.com>
* gdb.ada/packed_array_assign/aggregates.ads (Nested_Packed): New
record.
(NPR): New variable.
* gdb.ada/packed_array_assign.exp: Add nested packed assignment
test.
A bug internal to AdaCore notes that assigning a non-scalar value to
an element of a packed array will sometimes fail.
The bug turns out to be that ada_value_assign incorrectly computes the
starting point for the assignment. This patch fixes the problem.
gdb/ChangeLog
2019-05-01 Tom Tromey <tromey@adacore.com>
* ada-lang.c (ada_value_assign): Correctly compute starting offset
for big-endian copies.
gdb/testsuite/ChangeLog
2019-05-01 Tom Tromey <tromey@adacore.com>
* gdb.ada/packed_array_assign.exp: Add packed assignment
regression test.
When running fullpath-expand.exp with target_board=dwarf4-gdb-index, we run
into:
...
$ make check-gdb RUNTESTFLAGS="--target_board=dwarf4-gdb-index fullpath-expand.exp"
Running src/gdb/testsuite/gdb.base/fullpath-expand.exp ...
gdb compile failed, cc-with-tweaks.sh: unable to find usable gdb
=== gdb Summary ===
nr of untested testcases 1
...
The same happens with fullname.exp.
The dwarf4-gdb-index.exp board file includes cc-with-tweaks.exp, which uses
cc-with-tweaks.sh, which calls gdb-add-index.sh.
The gdb-add-index.sh script uses a gdb executable, defaulting to gdb:
...
GDB=${GDB:=gdb}
...
The cc-with-tweaks.sh script tries to ensure that the build gdb executable is
used by gdb-add-index.sh:
...
if [ -z "$GDB" ]
then
if [ -f ./gdb ]
then
GDB="./gdb -data-directory data-directory"
elif [ -f ../gdb ]
then
GDB="../gdb -data-directory ../data-directory"
elif [ -f ../../gdb ]
then
GDB="../../gdb -data-directory ../../data-directory"
else
echo "$myname: unable to find usable gdb" >&2
exit 1
fi
fi
...
So, if the current directory is build/gdb/testsuite, then a gdb executable
build/gdb/testsuite/../gdb will be used.
However, in the case of fullpath-expand.exp the test cd's into the sources:
...
set saved_pwd [pwd]
cd $srcdir
set err [gdb_compile "${subdir}/${srcfile} ${subdir}/${srcfile2}" $binfile \
executable {debug}]
cd $saved_pwd
...
and cc-with-tweaks.sh generates the "unable to find usable gdb" error.
The same error occurs if we use --target_board=cc-with-dwz instead (only in
this case we actually don't need gdb, we just need the GDB variable to be set
in cc-with-tweaks.sh, which arguably is a bug in cc-with-tweaks.sh).
Fix both errors in cc-with-tweaks.exp by generating a gdb script gdb.sh using
$GDB, $GDBFLAGS and $INTERNAL_GDBFLAGS and passing this script to
cc-with-tweaks.sh by setting env(GDB).
Tested on x86_64-linux for gdb.base.
gdb/testsuite/ChangeLog:
2019-05-01 Tom de Vries <tdevries@suse.de>
* boards/cc-with-tweaks.exp: Generate gdb.sh, and pass it in env(GDB).
Board file dwarf4-gdb-index.exp contains all the commands from
cc-with-tweaks.exp (with CC_WITH_TWEAKS_FLAGS set to "-i").
Make dwarf4-gdb-index.exp smaller by including cc-with-tweaks.exp.
Tested on x86_64-linux for gdb.base.
gdb/testsuite/ChangeLog:
2019-05-01 Tom de Vries <tdevries@suse.de>
* boards/dwarf4-gdb-index.exp: Use cc-with-tweaks.exp.
Dwarf5 defines DW_FORM_strx1 and others, which are similar
to DW_FORM_strx but uses 1-4 bytes unsigned integers. This is
a small step towards supporting dwarf5 in gdb.
This global is meant to point to the "main" thread of execution of
the program we are debugging. It is set when attaching to a process
or when receiving a CREATE_PROCESS_DEBUG_EVENT event. The theory at
the time was that this was also going to be the thread receiving
the EXIT_PROCESS_DEBUG_EVENT event.
Unfortunately, we have discovered since then that this is actually
not guaranteed. What this means in practice is that there is moderate
risk that main_thread_id refers to a thread which no longer exists.
This global is used in 3 situations:
- OUTPUT_DEBUG_STRING_EVENT
- LOAD_DLL_DEBUG_EVENT
- UNLOAD_DLL_DEBUG_EVENT
It's not clear why we would need to use the main_thread_id in those cases
instead of using the thread ID provided by the kernel events itself.
So this patch implements this approach, which then allows us to delete
the main_thread_id global.
gdb/testsuite:
* windows-nat.c (main_thread_id): Delete.
(handle_output_debug_string): Replace main_thread_id by
current_event.dwThreadId.
(fake_create_process): Likewise.
(get_windows_debug_event) <CREATE_PROCESS_DEBUG_EVENT>:
Do not set main_thread_id.
<LOAD_DLL_DEBUG_EVENT>: Replace main_thread_id by
current_event.dwThreadId.
<UNLOAD_DLL_DEBUG_EVENT>: Likewise.
We have observed that GDB would randomly trip the following
assertion failure when debugging on Windows. When allowing
the program to run until the inferior exits, we occasionally see:
(gdb) cont
Continuing.
[Thread 48192.0xd100 exited with code 1]
[Thread 48192.0x10ad8 exited with code 1]
[Thread 48192.0x36e28 exited with code 0]
[Thread 48192.0x52be4 exited with code 0]
[Thread 48192.0x5aa40 exited with code 0]
../../src/gdb/thread.c:453: internal-error: void delete_thread_1(thread_inf
o*, bool): Assertion `thr != nullptr' failed.
Running the same scenario with some additional traces enabled...
(gdb) set verbose
(gdb) set debugevents
... allows us to understand what the issue is. To understand, we need
to first look at the events received when starting the program, and
in particular which threads got created how. First, we get a
CREATE_PROCESS_DEBUG_EVENT for tid=0x442a8:
gdb: kernel event for pid=317536 tid=0x442a8 code=CREATE_PROCESS_DEBUG_EVENT)
Shortly after, we get some CREATE_THREAD_DEBUG_EVENT events,
one of them being for tid=0x4010c:
gdb: kernel event for pid=317536 tid=0x4010c code=CREATE_THREAD_DEBUG_EVENT)
Fast forward a bit of debugging, and we do a "cont" as above,
at which point the programs reaches the end, and the system reports
"exit" events. The first interesting one is the following:
gdb: kernel event for pid=317536 tid=0x442a8 code=EXIT_THREAD_DEBUG_EVENT)
This is reporting a thread-exit event for a thread whose tid
is the TID of what we call the "main thread". That's the thread
that was created when we received the CREATE_PROCESS_DEBUG_EVENT
notification, and whose TID is actually stored in a global variable
named main_thread_id. This is not something we expected, as
the assumption we made was that the main thread would exit last,
and we would be notified of it via an EXIT_PROCESS_DEBUG_EVENT.
But apparently, this is not always true, at least on Windows Server
2012 and 2016 where this issue has been observed happening randomly.
The consequence of the above notification is that we call
windows_delete_thread for that thread, which removes it from
our list of known threads.
And a little bit later, then we then get the EXIT_PROCESS_DEBUG_EVENT,
and we can see that the associated tid is not the main_thread_id,
but rather the tid of one of the threads that was created during
the lifetime of the program, in this case tid=0x4010c:
gdb: kernel event for pid=317536 tid=0x4010c code=EXIT_PROCESS_DEBUG_EVENT)
And the debug trace printed right after shows why we're crashing:
[Deleting Thread 317536.0x442a8]
We are trying to delete the thread whose tid=0x442a8, which is
the main_thread_id! As we have already deleted that thread before,
the search for it returns a nullptr, which then trips the assertion
check in delete_thread_1.
This commit fixes this issue. It ignores the open question of
what to do with the main_thread_id global, particularly after
that thread has been removed from our list of threads. This will
be dealt with as a separate patch, to allow cherry-picking
this patch into a release branch.
For now, we fix the code so as to avoid this crash.
gdb/ChangeLog:
* windows-nat.c (get_windows_debug_event) <EXIT_PROCESS_DEBUG_EVENT>:
Use current_event.dwThreadId instead of main_thread_id.
When an Ada program is dynamically linked against libgnat, and when
one of the standard exceptions is used, the exception object may be
referenced by the main executable using a copy relocation.
In this situation, a "catch exception" for those exceptions will not
manage to stop. This happens because, under the hood, "catch
exception" creates an expression object that examines the object
addresses -- but in this case, the address will be incorrect.
This patch fixes the problem by arranging for these filter expressions
to examine all the relevant minimal symbols. This way, the object
from libgnat will be found as well.
Tested on x86-64 Fedora 29.
gdb/ChangeLog
2019-04-30 Tom Tromey <tromey@adacore.com>
* ada-lang.c (ada_lookup_simple_minsyms): New function.
(create_excep_cond_exprs): Iterate over program spaces.
(ada_exception_catchpoint_cond_string): Examine all minimal
symbols for exception types.
gdb/testsuite/ChangeLog
2019-04-30 Tom Tromey <tromey@adacore.com>
* lib/ada.exp (find_ada_tool): New proc.
* lib/gdb.exp (gdb_compile_shlib): Allow .o files as inputs.
* gdb.ada/catch_ex_std.exp: New file.
* gdb.ada/catch_ex_std/foo.adb: New file.
* gdb.ada/catch_ex_std/some_package.adb: New file.
* gdb.ada/catch_ex_std/some_package.ads: New file.
PR c++/24470 concerns a crash in dwarf2read.c that occurs with a
particular test case.
The issue turns out to be that process_structure_scope will pass NULL
to symbol_symtab. This happens because new_symbol decided not to
create a symbol for the particular DIE.
This patch fixes the problem by finding another reasonably-appropriate
symtab to use instead; issuing a complaint if one cannot be found for
some reason.
As mentioned in the bug, I think there are other bugs here. For
example, when using "ptype" on the "l" object in the test case, I
think I would expect to see the template parameter. I didn't research
this too closely, since it seemed more important to fix the crash.
Tested on x86-64 Fedora 29.
I'd like to check this in to the 8.3 branch as well.
2019-04-30 Tom Tromey <tromey@adacore.com>
PR c++/24470:
* dwarf2read.c (process_structure_scope): Handle case where type
has template parameters but no symbol was created.
gdb/testsuite/ChangeLog
2019-04-30 Tom Tromey <tromey@adacore.com>
PR c++/24470:
* gdb.cp/temargs.cc: Add test code from PR.
Types in Fortran can have the 'allocatable' qualifier attached to
indicate that memory needs to be explicitly allocated by the user.
This patch extends GDB to show this qualifier when printing types.
Lots of tests results are then updated to include this new qualifier
in the expected results.
gdb/ChangeLog:
* f-typeprint.c (f_type_print_base): Print 'allocatable' type
qualifier.
* gdbtypes.h (TYPE_IS_ALLOCATABLE): Define.
gdb/testsuite/ChangeLog:
* gdb.fortran/vla-datatypes.exp: Update expected results.
* gdb.fortran/vla-ptype.exp: Likewise.
* gdb.fortran/vla-type.exp: Likewise.
* gdb.fortran/vla-value.exp: Likewise.
The whitespace produced as types are printed seems inconsistent. This
commit updates the rules in an attempt to make whitespace more
balanced and consistent. Expected results are updated.
gdb/ChangeLog:
* f-typeprint.c (f_print_type): Update rules for printing
whitespace.
(f_type_print_varspec_suffix): Likewise.
gdb/testsuite/ChangeLog:
* gdb.fortran/ptr-indentation.exp: Update expected results.
* gdb.fortran/ptype-on-functions.exp: Likewise.
* gdb.fortran/vla-ptr-info.exp: Likewise.
* gdb.fortran/vla-value.exp: Likewise.
Before this commit using ptype on a Fortran function will include
information about the functions return type, but not the expected
arguments as it would for C or C++. After this commit argument types
are included in the ptype output.
For example, before GDB prints:
(gdb) ptype fun1
type = integer(kind=4) ()
(gdb) ptype is_bigger
type = logical(kind=4) ()
and after GDB prints:
(gdb) ptype fun1
type = integer(kind=4) (integer(kind=4))
(gdb) ptype is_bigger
type = logical(kind=4) (integer(kind=4), integer(kind=4))
gdb/ChangeLog:
* f-typeprint.c (f_type_print_varspec_suffix): Handle printing
function arguments.
gdb/testsuite/ChangeLog:
* gdb.fortran/ptype-on-functions.exp: New file.
* gdb.fortran/ptype-on-functions.f90: New file.
For a program compiled with gfortran the base type names are written
as lower cases in the DWARF, and so GDB will display them as lower
case. Additionally, in most places where GDB supplies its own type
names (for example all of the types defined in f-lang.c in
`build_fortran_types`), the type names are all lower case.
An exception to this is where GDB prints the void type for Fortran.
In this case GDB uses upper case.
I'm not aware of any reason why this type should merit special
attention, and it looks our of place when printing types, so this
commit changes from 'VOID' to 'void' to match all the other types.
gdb/ChangeLog:
* f-lang.c (build_fortran_types): Change name of void type to
lower case.
* f-typeprint.c (f_type_print_base): Print the name of the void
type, rather than a fixed string.
* f-valprint.c (f_decorations): Use lower case void string.
gdb/testsuite/ChangeLog:
* gdb.fortran/exprs.exp (test_convenience_variables): Expect lower
case void string.
Currently when using $_creal and $_cimag to access the components of a
complex number the types of these components will have C type names
'float', 'double', etc. This is because the components of a complex
number are not given type names in DWARF, so GDB has to pick some
suitable names, and currently we always use the C names.
This commit changes the type names used based on the language, so for
Fortran we will now use the Fortran float types, and so will get the
Fortran float type names 'real', 'real*8', etc.
gdb/ChangeLog:
* dwarf2read.c (dwarf2_init_complex_target_type): Use different
types for Fortran.
gdb/testsuite/ChangeLog:
* gdb.fortran/complex.exp: Expand.
* gdb.fortran/complex.f: Renamed to...
* gdb.fortran/complex.f90: ...this, and extended to add more
complex values.
Future commits will add more Fortran specific expression operators.
In preparation for these new operators, this commit adds a new
fortran-operator.def file similar to how GDB already has
ada-operator.def.
I've moved UNOP_KIND the Fortran specific operator I introduced in
commit 4d00f5d8f6 into this file, and renamed it to make it clearer
that the operator is Fortran specific. I've then updated the Fortran
exp_descriptor table (exp_descriptor_f) to use entirely Fortran
specific functions that now handle UNOP_FORTRAN_KIND (the new name for
UNOP_KIND).
There should be no visible changes for standard users after this
commit, though for developers, the output when 'set debug expression
1' is now better, before:
(gdb) p kind (l1)
Dump of expression @ 0x2ccc7a0, before conversion to prefix form:
Language fortran, 5 elements, 16 bytes each.
Index Opcode Hex Value String Value
0 OP_VAR_VALUE 42 *...............
1 OP_NULL 47730176 .N..............
2 BINOP_INTDIV 47729184 J..............
3 OP_VAR_VALUE 42 *...............
4 UNOP_KIND 78 N...............
Dump of expression @ 0x2ccc7a0, after conversion to prefix form:
Expression: `Invalid expression
(gdb)
and after:
(gdb) p kind (l1)
Dump of expression @ 0x294d0b0, before conversion to prefix form:
Language fortran, 5 elements, 16 bytes each.
Index Opcode Hex Value String Value
0 OP_VAR_VALUE 40 (...............
1 unknown opcode: 224 44088544 ................
2 unknown opcode: 208 44087504 ................
3 OP_VAR_VALUE 40 (...............
4 UNOP_FORTRAN_KIND 119 w...............
Dump of expression @ 0x294d0b0, after conversion to prefix form:
Expression: `KIND(test::l1)'
Language fortran, 5 elements, 16 bytes each.
0 UNOP_FORTRAN_KIND
1 OP_VAR_VALUE Block @0x2a0bce0, symbol @0x2a0b8d0 (l1)
$1 = 1
(gdb)
gdb/ChangeLog:
* gdb/expprint.c (dump_subexp_body_standard): Remove use of
UNOP_KIND.
* gdb/expression.h (exp_opcode): Include 'fortran-operator.def'.
* gdb/f-exp.y (exp): Rename UNOP_KIND to UNOP_FORTRAN_KIND.
* gdb/f-lang.c (evaluate_subexp_f): Likewise.
(operator_length_f): New fuction.
(print_subexp_f): New function.
(op_name_f): New function.
(dump_subexp_body_f): New function.
(operator_check_f): New function.
(exp_descriptor_f): Replace standard expression handling functions
with new functions.
* gdb/fortran-operator.def: New file.
* gdb/parse.c (operator_length_standard): Remove use of UNOP_KIND.
* gdb/std-operator.def: Remove UNOP_KIND.
What appears to be a stray double quote character in std-operator.def
causes incorrect highlighting in my editor.
The quote was introduced in this commit:
commit 858be34c5a
Date: Mon Sep 4 20:21:15 2017 +0100
Handle "p S::method()::static_var" in the C++ parser
I can't see any reason why the quote should be there, so this commit
removes it.
gdb/ChangeLog:
* std-operator.def: Remove unbalanced, stray double quote
character.
Introduce a new print setting max-depth which can be set with 'set
print max-depth DEPTH'. The default value of DEPTH is 20, but this
can also be set to unlimited.
When GDB is printing a value containing nested structures GDB will
stop descending at depth DEPTH. Here is a small example:
typedef struct s1 { int a; } s1;
typedef struct s2 { s1 b; } s2;
typedef struct s3 { s2 c; } s3;
typedef struct s4 { s3 d; } s4;
s4 var = { { { { 3 } } } };
The following table shows how various depth settings affect printing
of 'var':
| Depth Setting | Result of 'p var' |
|---------------+--------------------------------|
| Unlimited | $1 = {d = {c = {b = {a = 3}}}} |
| 4 | $1 = {d = {c = {b = {a = 3}}}} |
| 3 | $1 = {d = {c = {b = {...}}}} |
| 2 | $1 = {d = {c = {...}}} |
| 1 | $1 = {d = {...}} |
| 0 | $1 = {...} |
Only structures, unions, and arrays are replaced in this way, scalars
and strings are not replaced.
The replacement is counted from the level at which you print, not from
the top level of the structure. So, consider the above example and
this GDB session:
(gdb) set print max-depth 2
(gdb) p var
$1 = {d = {c = {...}}}
(gdb) p var.d
$2 = {c = {b = {...}}}
(gdb) p var.d.c
$3 = {b = {a = 3}}
Setting the max-depth to 2 doesn't prevent the user from exploring
deeper into 'var' by asking for specific sub-fields to be printed.
The motivation behind this feature is to try and give the user more
control over how much is printed when examining large, complex data
structures.
The default max-depth of 20 means that there is a change in GDB's
default behaviour. Someone printing a data structure with 20 levels
of nesting will now see '{...}' instead of their data, they would need
to adjust the max depth, or call print again naming a specific field
in order to dig deeper into their data structure. If this is
considered a problem then we could increase the default, or even make
the default unlimited.
This commit relies on the previous commit, which added a new field to
the language structure, this new field was a string that contained the
pattern that should be used when a structure/union/array is replaced
in the output, this allows languages to use a syntax that is more
appropriate, mostly this will be selecting the correct types of
bracket '(...)' or '{...}', both of which are currently in use.
This commit should have no impact on MI output, expressions are
printed through the MI using -var-create and then -var-list-children.
As each use of -var-list-children only ever displays a single level of
an expression then the max-depth setting will have no impact.
This commit also adds the max-depth mechanism to the scripting
language pretty printers following basically the same rules as for the
built in value printing.
One quirk is that when printing a value using the display hint 'map',
if the keys of the map are structs then GDB will hide the keys one
depth level after it hides the values, this ensures that GDB produces
output like this:
$1 = map_object = {[{key1}] = {...}, [{key2}] = {...}}
Instead of this less helpful output:
$1 = map_object = {[{...}] = {...}, [{...}] = {...}}
This is covered by the new tests in gdb.python/py-nested-maps.exp.
gdb/ChangeLog:
* cp-valprint.c (cp_print_value_fields): Allow an additional level
of depth when printing anonymous structs or unions.
* guile/scm-pretty-print.c (gdbscm_apply_val_pretty_printer):
Don't print either the top-level value, or the children if the
max-depth is exceeded.
(ppscm_print_children): When printing the key of a map, allow one
extra level of depth.
* python/py-prettyprint.c (gdbpy_apply_val_pretty_printer): Don't
print either the top-level value, or the children if the max-depth
is exceeded.
(print_children): When printing the key of a map, allow one extra
level of depth.
* python/py-value.c (valpy_format_string): Add max_depth keyword.
* valprint.c: (PRINT_MAX_DEPTH_DEFAULT): Define.
(user_print_options): Initialise max_depth field.
(val_print_scalar_or_string_type_p): New function.
(val_print): Check to see if the max depth has been reached.
(val_print_check_max_depth): Define new function.
(show_print_max_depth): New function.
(_initialize_valprint): Add 'print max-depth' option.
* valprint.h (struct value_print_options) <max_depth>: New field.
(val_print_check_max_depth): Declare new function.
* NEWS: Document new feature.
gdb/doc/ChangeLog:
* gdb.texinfo (Print Settings): Document 'print max-depth'.
* guile.texi (Guile Pretty Printing API): Document that 'print
max-depth' can effect the display of a values children.
* python.texi (Pretty Printing API): Likewise.
(Values From Inferior): Document max_depth keyword.
gdb/testsuite/ChangeLog:
* gdb.base/max-depth.c: New file.
* gdb.base/max-depth.exp: New file.
* gdb.python/py-nested-maps.c: New file.
* gdb.python/py-nested-maps.exp: New file.
* gdb.python/py-nested-maps.py: New file.
* gdb.python/py-format-string.exp (test_max_depth): New proc.
(test_all_common): Call test_max_depth.
* gdb.fortran/max-depth.exp: New file.
* gdb.fortran/max-depth.f90: New file.
* gdb.go/max-depth.exp: New file.
* gdb.go/max-depth.go: New file.
* gdb.modula2/max-depth.exp: New file.
* gdb.modula2/max-depth.c: New file.
* lib/gdb.exp (get_print_expr_at_depths): New proc.
This commit is preparation work for the next commit, and by itself
makes no user visible change to GDB. I've split this work into a
separate commit in order to make code review easier.
This commit adds a new field 'la_is_string_type_p' to the language
struct, this predicate will return true if a type is a string type for
the given language.
Some languages already have a "is this a string" predicate that I was
able to reuse, while for other languages I've had to add a new
predicate. In this case I took inspiration from the value printing
code for that language - what different conditions would result in
printing something as a string.
A default "is this a string" method has also been added that looks for
TYPE_CODE_STRING, this is the fallback I've used for a couple of
languages.
In this commit I add the new field and initialise it for each
language, however at this stage the new field is never used.
gdb/ChangeLog:
* ada-lang.c (ada_language_defn): Initialise new field.
* c-lang.c (c_is_string_type_p): New function.
(c_language_defn): Initialise new field.
(cplus_language_defn): Initialise new field.
(asm_language_defn): Initialise new field.
(minimal_language_defn): Initialise new field.
* c-lang.h (c_is_string_type_p): Declare new function.
* d-lang.c (d_language_defn): Initialise new field.
* f-lang.c (f_is_string_type_p): New function.
(f_language_defn): Initialise new field.
* go-lang.c (go_is_string_type_p): New function.
(go_language_defn): Initialise new field.
* language.c (default_is_string_type_p): New function.
(unknown_language_defn): Initialise new field.
(auto_language_defn): Initialise new field.
* language.h (struct language_defn) <la_is_string_type_p>: New
member variable.
(default_is_string_type_p): Declare new function.
* m2-lang.c (m2_language_defn): Initialise new field.
* objc-lang.c (objc_language_defn): Initialise new field.
* opencl-lang.c (opencl_language_defn): Initialise new field.
* p-lang.c (pascal_is_string_type_p): New function.
(pascal_language_defn): Initialise new field.
* rust-lang.c (rust_is_string_type_p): New function.
(rust_language_defn): Initialise new field.
This commit is preparation work for a later commit, and by itself
makes no user visible change to GDB. I've split this work into a
separate commit in order to make code review easier.
This commit adds a new field 'la_struct_too_deep_ellipsis' to the
language struct, this string will be used in the next commit to print
a language specific string from within the generic value printing
code.
In this commit I add the new field and initialise it for each
language, however at this stage the new field is never used.
gdb/ChangeLog:
* language.h (struct language_defn) <la_struct_too_deep_ellipsis>:
New field.
* ada-lang.c (ada_language_defn): Initialise new field.
* c-lang.c (c_language_defn): Likewise.
(cplus_language_defn): Likewise.
(asm_language_defn): Likewise.
(minimal_language_defn): Likewise.
* d-lang.c (d_language_defn): Likewise.
* f-lang.c (f_language_defn): Likewise.
* go-lang.c (go_language_defn): Likewise.
* language.c (unknown_language_defn): Likewise.
(auto_language_defn): Likewise.
* m2-lang.c (m2_language_defn): Likewise.
* objc-lang.c (objc_language_defn): Likewise.
* opencl-lang.c (opencl_language_defn): Likewise.
* p-lang.c (pascal_language_defn): Likewise.
* rust-lang.c (rust_language_defn): Likewise.
A later commit would like to make use of a pointer to the function
ada_is_string_type, however, this will require the function to return
a bool (so the signature matches).
As the ada_is_string_type is a predicate function, and its return
value is only ever used as either true or false, then this commit
updates the function to return a bool.
As a consequence ada_is_character_type needs to change too.
There should be no user visible changes after this commit.
gdb/ChangeLog:
* ada-lang.c (ada_is_character_type): Change return type to bool.
(ada_is_string_type): Likewise.
* ada-lang.h (ada_is_character_type): Update declaration
(ada_is_string_type): Likewise.
When running gdb-caching-proc.exp, if skip_opencl_tests fails like this:
...
(gdb) run
Starting program: \
build/gdb/testsuite/outputs/gdb.base/gdb-caching-proc/opencltest13530.x
CHK_ERR (clGetPlatformIDs (1, &platform, NULL), -1001)
src/gdb/testsuite/lib/opencl_hostapp.c:73 error: Unknown
[Inferior 1 (process 13600) exited with code 01]
(gdb)
skip_opencl_tests: OpenCL support not detected
...
then this regexp in skip_opencl_tests fails to match:
...
-re ".*$inferior_exited_re code.*${gdb_prompt} $" {
...
so instead we hit the default clause after a 30 seconds timeout. With the
iteration count set at 10, we end up taking 6 minutes to run this test-case.
Fix this by adding the missing "with" in the regexp, bring back the runtime to
half a minute.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-04-29 Tom de Vries <tdevries@suse.de>
* lib/opencl.exp (skip_opencl_tests): Add missing "with" in regexp.
'thread|frame apply CMD' launches CMD so that CMD output goes to a string_file.
This patch ensures that string_file for such CMD output contains
style escape sequences that 'thread|frame apply' will later on
output on the real terminal, so as to have CMD output properly styled.
The idea is to have the class ui_file having overridable methods
to indicate that the output to this ui_file should be done using
'terminal' behaviour such as styling.
Then these methods are overriden in string_file so that a specially
constructed string_file will get output with style escape sequences.
After this patch, the output of CMD by thread|frame apply CMD is styled
similarly as when CMD is launched directly.
Note that string_file (term_out true) could also support wrapping,
but this is not done (yet?).
Tested on debian/amd64.
gdb/ChangeLog
2019-04-27 Philippe Waroquiers <philippe.waroquiers@skynet.be>
Support style in 'frame|thread apply'
* gdbcmd.h (execute_command_to_string): New term_out parameter.
* record.c (record_start, record_stop): Update callers of
execute_command_to_string with false.
* ui-file.h (class ui_file): New term_out and can_emit_style_escape
methods.
(class string_file): New constructor with term_out parameter.
Override methods term_out and can_emit_style_escape. New member
term_out.
(class stdio_file): Override can_emit_style_escape.
(class tee_file): Override term_out and can_emit_style_escape.
* utils.h (can_emit_style_escape): Remove.
* utils.c (can_emit_style_escape): Likewise.
Update all callers of can_emit_style_escape (SOMESTREAM) to
SOMESTREAM->can_emit_style_escape.
* source-cache.c (source_cache::get_source_lines): Likewise.
* stack.c (frame_apply_command_count): Call execute_command_to_string
passing the term_out characteristic of the current gdb_stdout.
* thread.c (thr_try_catch_cmd): Likewise.
* top.c (execute_command_to_string): pass term_out parameter
to construct the string_file for the command output.
* ui-file.c (term_cli_styling): New function (most code moved
from utils.c can_emit_style_escape).
(string_file::string_file, string_file::can_emit_style_escape,
stdio_file::can_emit_style_escape, tee_file::term_out,
tee_file::can_emit_style_escape): New functions.
Inferior function calls are powerful but might lead to undesired
results such as crashes when calling nested functions (frequently
used in particular in Ada).
This implements a GDB setting to disable calling inferior functions.
Note: the idea is that if/when the 'slash command' patch is pushed,
that this setting can be changed e.g. by using the shortcut /c.
This is version 2 of the patch. It handles all the received comments,
mostly replace 'can-call' by 'may-call', and avoid using
'inferior function call' in factor of 'calling function in the program'.
2019-04-26 Philippe Waroquiers <philippe.waroquiers@skynet.be>
gdb/ChangeLog
* NEWS: Mention the new set|show may-call-functions.
* infcall.c (may_call_functions_p): New variable.
(show_may_call_functions_p): New function.
(call_function_by_hand_dummy): Throws an error if not
may-call-functions.
(_initialize_infcall): Call add_setshow_boolean_cmd for
may-call-functions.
gdb/testsuite/ChangeLog
* gdb.base/callexit.exp: Test may-call-functions off.
gdb/doc/ChangeLog
* gdb.texinfo (Calling): Document the new
set|show may-call-functions.
This bug finds another usage where we end up segfaulting while
normalizing user input. inspect_type and replace_type recurse,
attempting to substitute the "real" symbol name for the typedef name.
However, since the both these names are the same, they keep calling
each other until the stack overflows.
A simple reproducer for it is given by
typedef struct foo foo;
int qux (foo *f) { return 0; }
(gdb) b qux(foo*)
Segmentation fault
inspect_type already contains some special handling to prevent a
similar situation from occurring with namespaces. I wonder, however,
whether we need be so pedantic about the exact nature of the substitution.
This patch implements this rather more aggressive assumption that these
substitutions should be avoided whenever the replacement symbol's name is
exactly the same as the one we're trying to substitute. [In the above
example, we're trying to substitute the tyepdef named "foo" with the symbol
named "foo" (a struct).]
gdb/ChangeLog:
PR c++/24367
* cp-support.c (inspect_type): Don't attempt substitutions
of symbol with the same name.
gdb/testsuite/ChangeLog:
PR c++/24367
* gdb.cp/meth-typedefs.cc (incomplete_struct)
(another_incomplete_struct, test_incomplete): New definitions.
(main): Use new definitions.
* gdb.cp/meth-typedefs.exp: Add new tests for `test_incomplete'
functions.
PR gdb/24475 concerns a memory leak coming from gdb's exception
handling code.
The leak occurs because throw_exception_sjlj does not arrange to
destroy the exception object it is passed. However, because
gdb_exception has a destructor, it's undefined to longjmp in this
situation.
This patch fixes the problem by avoiding the need to run any
destructors in gdb_rl_callback_handler, by making the gdb_exception
"static".
gdb/ChangeLog
2019-04-25 Tom Tromey <tromey@adacore.com>
PR gdb/24475:
* event-top.c (gdb_rl_callback_handler): Make "gdb_rl_expt"
static.
This makes exception handling more efficient in a few spots, through
the use of const- and rvalue-references.
I wrote this patch by commenting out the gdb_exception copy
constructor and then examining the resulting error messages one by
one, introducing the use of std::move where appropriate.
gdb/ChangeLog
2019-04-25 Tom Tromey <tromey@adacore.com>
* xml-support.c (struct gdb_xml_parser) <set_error>: Take an
rvalue reference.
(gdb_xml_start_element_wrapper, gdb_xml_end_element_wrapper)
(gdb_xml_parser::parse): Use std::move.
* python/python-internal.h (gdbpy_convert_exception): Take a const
reference.
* python/py-value.c (valpy_getitem, valpy_nonzero): Use
std::move.
* python/py-utils.c (gdbpy_convert_exception): Take a const
reference.
* python/py-inferior.c (infpy_write_memory, infpy_search_memory):
Use std::move.
* python/py-breakpoint.c (bppy_set_condition, bppy_set_commands):
Use std::move.
* mi/mi-main.c (mi_print_exception): Take a const reference.
* main.c (handle_command_errors): Take a const reference.
* linespec.c (parse_linespec): Use std::move.
* infcall.c (run_inferior_call): Use std::move.
(call_function_by_hand_dummy): Use std::move.
* exec.c (try_open_exec_file): Use std::move.
* exceptions.h (exception_print, exception_fprintf)
(exception_print_same): Update.
* exceptions.c (print_exception, exception_print)
(exception_fprintf, exception_print_same): Change parameters to
const reference.
* event-top.c (gdb_rl_callback_read_char_wrapper): Update.
* common/new-op.c: Use std::move.
* common/common-exceptions.h (struct gdb_exception): Add move
constructor.
(struct gdb_exception_error, struct gdb_exception_quit, struct
gdb_quit_bad_alloc): Change constructor to move constructor.
(throw_exception): Change parameter to rvalue reference.
* common/common-exceptions.c (throw_exception): Take rvalue
reference.
* cli/cli-interp.c (safe_execute_command): Use std::move.
* breakpoint.c (insert_bp_location, location_to_sals): Use
std::move.
The Guile code will longjmp (via scm_throw) when an object requiring
destruction is on the stack. This is undefined behavior.
This changes this code to run any destructors in inner scopes, and to
pass a POD to gdbscm_throw_gdb_exception.
gdb/ChangeLog
2019-04-25 Tom Tromey <tromey@adacore.com>
* guile/scm-exception.c (gdbscm_scm_from_gdb_exception)
(gdbscm_throw_gdb_exception): Take a gdbscm_gdb_exception.
* guile/scm-block.c, guile/scm-breakpoint.c, guile/scm-cmd.c,
guile/scm-disasm.c, guile/scm-frame.c, guile/scm-lazy-string.c,
guile/scm-math.c, guile/scm-param.c, guile/scm-ports.c,
guile/scm-symbol.c, guile/scm-symtab.c, guile/scm-type.c,
guile/scm-value.c: Use unpack.
* guile/guile-internal.h (gdbscm_scm_from_gdb_exception): Take a
gdbscm_gdb_exception.
(gdbscm_throw_gdb_exception): Likewise.
(struct gdbscm_gdb_exception): New.
(unpack): New function.
(gdbscm_wrap): Use unpack.
This changes the SJLJ exception handling code to be a bit more
efficient, by using rvalue references and move assignment when
possible.
Tested by the buildbot.
gdb/ChangeLog
2019-04-25 Tom Tromey <tromey@adacore.com>
* event-top.c (gdb_rl_callback_read_char_wrapper_noexcept)
(gdb_rl_callback_handler): Use std::move.
* common/common-exceptions.h (struct gdb_exception): Add move
assignment operator.
(throw_exception_sjlj): Change "exception" to const reference.
* common/common-exceptions.c (exceptions_state_mc_catch): Update.
(throw_exception_sjlj): Change "exception" to const reference.
This patch has a long story, but it all started back in 2015, with
commit df8411da08 ("Implement support
for checking /proc/PID/coredump_filter"). The purpose of that commit
was to bring GDB's corefile generation closer to what the Linux kernel
does. However, back then, I did not implement the full support for
the dumping of memory mappings containing ELF headers (like mappings
of DSOs or executables). These mappings were being dumped most of
time, though, because the default value of /proc/PID/coredump_filter
is 0x33, which would cause anonymous private mappings (DSOs/executable
code mappings have this type) to be dumped. Well, until something
happened on binutils...
A while ago, I noticed something strange was happening with one of our
local testcases on Fedora GDB: it was failing due to some strange
build-id problem. On Fedora GDB, we (unfortunately) carry a bunch of
"local" patches, and some of these patches actually extend upstream's
build-id support in order to generate more useful information for the
user of a Fedora system (for example, when the user loads a corefile
into GDB, we detect whether the executable that generated that
corefile is present, and if it's not we issue a warning suggesting
that it should be installed, while also providing the build-id of the
executable). A while ago, Fedora GDB stopped printing those warnings.
I wanted to investigate this right away, and spent some time trying to
determine what was going on, but other things happened and I got
sidetracked. Meanwhile, the bug started to be noticed by some of our
users, and its priority started changing. Then, someone on IRC also
mentioned the problem, and when I tried helping him, I noticed he
wasn't running Fedora. Hm... So maybe the bug was *also* present
upstream.
After "some" time investigating, and with a lot of help from Keith and
others, I was finally able to determine that yes, the bug is also
present upstream, and that even though it started with a change in ld,
it is indeed a GDB issue.
So, as I said, the problem started with binutils, more specifically
after the following commit was pushed:
commit f6aec96dce
Author: H.J. Lu <hjl.tools@gmail.com>
Date: Tue Feb 27 11:34:20 2018 -0800
ld: Add --enable-separate-code
This commit makes ld use "-z separate-code" by default on x86-64
machines. What this means is that code pages and data pages are now
separated in the binary, which is confusing GDB when it tries to decide
what to dump.
BTW, Fedora 28 binutils doesn't have this code, which means that
Fedora 28 GDB doesn't have the problem. From Fedora 29 on, binutils
was rebased and incorporated the commit above, which started causing
Fedora GDB to fail.
Anyway, the first thing I tried was to pass "-z max-page-size" and
specify a bigger page size (I saw a patch that did this and was
proposed to Linux, so I thought it might help). Obviously, this
didn't work, because the real "problem" is that ld will always use
separate pages for code and data. So I decided to look into how GDB
dumped the pages, and that's where I found the real issue.
What happens is that, because of "-z separate-code", the first two pages
of the ELF binary are (from /proc/PID/smaps):
00400000-00401000 r--p 00000000 fc:01 799548 /file
Size: 4 kB
KernelPageSize: 4 kB
MMUPageSize: 4 kB
Rss: 4 kB
Pss: 4 kB
Shared_Clean: 0 kB
Shared_Dirty: 0 kB
Private_Clean: 4 kB
Private_Dirty: 0 kB
Referenced: 4 kB
Anonymous: 0 kB
LazyFree: 0 kB
AnonHugePages: 0 kB
ShmemPmdMapped: 0 kB
Shared_Hugetlb: 0 kB
Private_Hugetlb: 0 kB
Swap: 0 kB
SwapPss: 0 kB
Locked: 0 kB
THPeligible: 0
VmFlags: rd mr mw me dw sd
00401000-00402000 r-xp 00001000 fc:01 799548 /file
Size: 4 kB
KernelPageSize: 4 kB
MMUPageSize: 4 kB
Rss: 4 kB
Pss: 4 kB
Shared_Clean: 0 kB
Shared_Dirty: 0 kB
Private_Clean: 0 kB
Private_Dirty: 4 kB
Referenced: 4 kB
Anonymous: 4 kB
LazyFree: 0 kB
AnonHugePages: 0 kB
ShmemPmdMapped: 0 kB
Shared_Hugetlb: 0 kB
Private_Hugetlb: 0 kB
Swap: 0 kB
SwapPss: 0 kB
Locked: 0 kB
THPeligible: 0
VmFlags: rd ex mr mw me dw sd
Whereas before, we had only one:
00400000-00401000 r-xp 00000000 fc:01 798593 /file
Size: 4 kB
KernelPageSize: 4 kB
MMUPageSize: 4 kB
Rss: 4 kB
Pss: 4 kB
Shared_Clean: 0 kB
Shared_Dirty: 0 kB
Private_Clean: 0 kB
Private_Dirty: 4 kB
Referenced: 4 kB
Anonymous: 4 kB
LazyFree: 0 kB
AnonHugePages: 0 kB
ShmemPmdMapped: 0 kB
Shared_Hugetlb: 0 kB
Private_Hugetlb: 0 kB
Swap: 0 kB
SwapPss: 0 kB
Locked: 0 kB
THPeligible: 0
VmFlags: rd ex mr mw me dw sd
Notice how we have "Anonymous" data mapped into the page. This will be
important.
So, the way GDB decides which pages it should dump has been revamped
by my patch in 2015, and now it takes the contents of
/proc/PID/coredump_filter into account. The default value for Linux
is 0x33, which means:
Dump anonymous private, anonymous shared, ELF headers and HugeTLB
private pages.
Or:
filter_flags filterflags = (COREFILTER_ANON_PRIVATE
| COREFILTER_ANON_SHARED
| COREFILTER_ELF_HEADERS
| COREFILTER_HUGETLB_PRIVATE);
Now, it is important to keep in mind that GDB doesn't always have *all*
of the necessary information to exactly determine the type of a page, so
the whole algorithm is based on heuristics (you can take a look at
linux-tdep.c:dump_mapping_p and
linux-tdep.c:linux_find_memory_regions_full for more info).
Before the patch to make ld use "-z separate-code", the (single) page
containing data and code was being flagged as an anonymous (due to the
non-zero "Anonymous:" field) private (due to the "r-xp" permission),
which means that it was being dumped into the corefile. That's why it
was working fine.
Now, as you can imagine, when "-z separate-code" is used, the *data*
page (which is where the ELF notes are, including the build-id one) now
doesn't have any "Anonymous:" mapping, so the heuristic is flagging it
as file-backed private, which is *not* dumped by default.
The next question I had to answer was: how come a corefile generated by
the Linux kernel was correct? Well, the answer is that GDB, unlike
Linux, doesn't actually implement the COREFILTER_ELF_HEADERS support.
On Linux, even though the data page is also treated as a file-backed
private mapping, it is also checked to see if there are any ELF headers
in the page, and then, because we *do* have ELF headers there, it is
dumped.
So, after more time trying to think of ways to fix this, I was able to
implement an algorithm that reads the first few bytes of the memory
mapping being processed, and checks to see if the ELF magic code is
present. This is basically what Linux does as well, except that, if
it finds the ELF magic code, it just dumps one page to the corefile,
whereas GDB will dump the whole mapping. But I don't think that's a
big issue, to be honest.
It's also important to explain that we *only* perform the ELF magic
code check if:
- The algorithm has decided *not* to dump the mapping so far, and;
- The mapping is private, and;
- The mapping's offset is zero, and;
- The user has requested us to dump mappings with ELF headers.
IOW, we're not going to blindly check every mapping.
As for the testcase, I struggled even more trying to write it. Since
our build-id support on upstream GDB is not very extensive, it's not
really possible to determine whether a corefile contains build-id
information or not just by using GDB. So, after thinking a lot about
the problem, I decided to rely on an external tool, eu-unstrip, in
order to verify whether the dump was successful. I verified the test
here on my machine, and everything seems to work as expected (i.e., it
fails without the patch, and works with the patch applied). We are
working hard to upstream our "local" Fedora GDB patches, and we intend
to submit our build-id extension patches "soon", so hopefully we'll be
able to use GDB itself to perform this verification.
I built and regtested this on the BuildBot, and no problems were
found.
gdb/ChangeLog:
2019-04-25 Sergio Durigan Junior <sergiodj@redhat.com>
PR corefiles/11608
PR corefiles/18187
* linux-tdep.c (dump_mapping_p): Add new parameters ADDR and
OFFSET. Verify if current mapping contains an ELF header.
(linux_find_memory_regions_full): Adjust call to
dump_mapping_p.
gdb/testsuite/ChangeLog:
2019-04-25 Sergio Durigan Junior <sergiodj@redhat.com>
PR corefiles/11608
PR corefiles/18187
* gdb.base/coredump-filter-build-id.exp: New file.
Add both board option and environment variable which enables gdbserver
debug and sends it to the file gdbserver.debug, located in the output
directory for the current test. Document this.
Add support for the environment variable in the Makefile.
The testsuite can be run with gdbserver debug enabled in the following way:
make check GDBSERVER_DEBUG=all
Disable tspeed.exp when debugging to prevent the log file filling
many gigabytes then timing out.
gdb/testsuite/ChangeLog:
* Makefile.in: Pass through GDBSERVER_DEBUG.
* README (Testsuite Parameters): Add GDBSERVER_DEBUG.
(gdbserver,debug): Add board setting.
* gdb.trace/tspeed.exp: Skip when debugging.
* lib/gdb.exp (gdbserver_debug_enabled): New procedure.
* lib/gdbserver-support.exp: Likewise
GDB was failing to catch cases where a corrupt ELF or core file
contained an invalid length value in a Dwarf debug frame FDE header.
It was checking for buffer overflow but not cases where the length was
negative or caused pointer wrap-around.
In addition to the additional validity check, this patch cleans up the
multiple signed/unsigned conversions on the length field so that an
unsigned representation is used consistently throughout.
This patch fixes CVE-2017-9778 and PR gdb/21600.
2019-04-25 Sandra Loosemore <sandra@codesourcery.com>
Kang Li <kanglictf@gmail.com>
PR gdb/21600
* dwarf2-frame.c (read_initial_length): Be consistent about using
unsigned representation of length.
(decode_frame_entry_1): Likewise. Check for wraparound of
end pointer as well as buffer overflow.
This changes the gdb test suite to omit -fno-stack-protector when
compiling Rust code. This makes Rust testing work again.
I think I saw this patch somewhere already, but I couldn't find it
again just now, so I'm checking this version in.
gdb/testsuite/ChangeLog
2019-04-24 Tom Tromey <tromey@adacore.com>
* lib/gdb.exp (gdb_compile): Don't add -fno-stack-protector for
Rust.
While trying to build GDB on i686, I found the following error:
In file included from ../../gdb/common/common-defs.h:105,
from ../../gdb/defs.h:28,
from ../../gdb/aarch64-tdep.c:21:
../../gdb/aarch64-tdep.c: In function 'gdbarch* aarch64_gdbarch_init(gdbarch_info, gdbarch_list*)':
../../gdb/aarch64-tdep.c:3176:43: error: format '%ld' expects argument of type 'long int', but argument 4 has type 'uint64_t' {aka 'long long unsigned int'} [-Werror=format=]
3176 | internal_error (__FILE__, __LINE__, _("VQ out of bounds: %ld (max %d)"),
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../gdb/common/gdb_locale.h:28:29: note: in definition of macro '_'
28 | # define _(String) gettext (String)
| ^~~~~~
../../gdb/aarch64-tdep.c:3176:64: note: format string is defined here
3176 | internal_error (__FILE__, __LINE__, _("VQ out of bounds: %ld (max %d)"),
| ~~^
| |
| long int
| %lld
This happens because aarch64-tdep.c:aarch64_gdbarch_init prints a
"uint64_t" variable using "%ld". This patch fixes the build by using
"pulongest" instead. As explained in a similar fix (commit
495143533a), this should be safe because
if aarch64-tdep.c is included in the build, then ULONGEST must be a
64-bit type.
gdb/ChangeLog:
2019-04-24 Sergio Durigan Junior <sergiodj@redhat.com>
* aarch64-tdep.c (aarch64_gdbarch_init): Use "pulongest" to print
"vq".
Commit 4aa866af ("Fix AMD64 return value ABI in expression
evaluation") introduced a regression when calling a function with a
structure that contains bitfields.
Because the caller of amd64_has_unaligned_fields handles bitfields
already, it seemed to me that the simplest fix was to ignore bitfields
here.
gdb/ChangeLog
2019-04-24 Tom Tromey <tromey@adacore.com>
* amd64-tdep.c (amd64_has_unaligned_fields): Ignore bitfields.
gdb/testsuite/ChangeLog
2019-04-24 Tom Tromey <tromey@adacore.com>
* gdb.arch/amd64-eval.exp: Test bitfield return.
* gdb.arch/amd64-eval.cc (struct Bitfields): New.
(class Foo) <return_bitfields>: New method.
(main): Call it.
Make use of the default gdbarch methods for gdbarch_unwind_pc, and
gdbarch_unwind_sp where possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* s12z-tdep.c (s12z_unwind_pc): Delete.
(s12z_unwind_sp): Delete.
(s12z_gdbarch_init): Don't register deleted functions with
gdbarch.
Make use of the default gdbarch method gdbarch_unwind_sp where
possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* rl78-tdep.c (rl78_unwind_sp): Delete.
(rl78_gdbarch_init): Don't register deleted function with gdbarch.
Make use of the default gdbarch methods for gdbarch_dummy_id,
gdbarch_unwind_pc, and gdbarch_unwind_sp where possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* xstormy16-tdep.c (xstormy16_unwind_sp): Delete.
(xstormy16_unwind_pc): Delete.
(xstormy16_dummy_id): Delete.
(xstormy16_gdbarch_init): Don't register deleted functions with
gdbarch.
Make use of the default gdbarch method gdbarch_unwind_pc where
possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* vax-tdep.c (vax_unwind_pc): Delete.
(vax_gdbarch_init): Don't register deleted function with gdbarch.
Make use of the default gdbarch methods for gdbarch_dummy_id,
gdbarch_unwind_pc, and gdbarch_unwind_sp where possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* v850-tdep.c (v850_unwind_sp): Delete.
(v850_unwind_pc): Delete.
(v850_dummy_id): Delete.
(v850_gdbarch_init): Don't register deleted functions with
gdbarch.
Make use of the default gdbarch methods for gdbarch_dummy_id,
gdbarch_unwind_pc, and gdbarch_unwind_sp where possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* tilegx-tdep.c (tilegx_unwind_sp): Delete.
(tilegx_unwind_pc): Delete.
(tilegx_unwind_dummy_id): Delete.
(tilegx_gdbarch_init): Don't register deleted functions with
gdbarch.
Make use of the default gdbarch methods for gdbarch_dummy_id, and
gdbarch_unwind_sp where possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* tic6x-tdep.c (tic6x_unwind_sp): Delete.
(tic6x_dummy_id): Delete.
(tic6x_gdbarch_init): Don't register deleted functions with
gdbarch.
Make use of the default gdbarch method gdbarch_unwind_pc where
possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* sparc-tdep.c (sparc_unwind_pc): Delete.
(sparc32_gdbarch_init): Don't register deleted function with
gdbarch.
Make use of the default gdbarch methods for gdbarch_dummy_id,
gdbarch_unwind_pc, and gdbarch_unwind_sp where possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* sh-tdep.c (sh_unwind_sp): Delete.
(sh_unwind_pc): Delete.
(sh_dummy_id): Delete.
(sh_gdbarch_init): Don't register deleted functions with
gdbarch.
Make use of the default gdbarch methods for gdbarch_dummy_id,
gdbarch_unwind_pc, and gdbarch_unwind_sp where possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* score-tdep.c (score_unwind_sp): Delete.
(score_unwind_pc): Delete.
(score_dummy_id): Delete.
(score_gdbarch_init): Don't register deleted functions with
gdbarch.
Make use of the default gdbarch methods for gdbarch_dummy_id,
gdbarch_unwind_pc, and gdbarch_unwind_sp where possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* rx-tdep.c (rx_unwind_pc): Delete.
(rx_unwind_sp): Delete.
(rx_dummy_id): Delete.
(rx_gdbarch_init): Don't register deleted functions with
gdbarch. Update comment.
Make use of the default gdbarch methods for gdbarch_dummy_id,
gdbarch_unwind_pc where possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* rs6000-tdep.c (rs6000_unwind_pc): Delete.
(rs6000_dummy_id): Delete.
(rs6000_gdbarch_init): Don't register deleted functions with
gdbarch.
Make use of the default gdbarch method gdbarch_dummy_id where
possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
This commit leaves or1k_unwind_sp and or1k_unwind_pc in place. These
functions do match the default methods except that they add additional
debugging code. In order to preserve the debug I have left these
functions unchanged.
gdb/ChangeLog:
* or1k-tdep.c (or1k_dummy_id): Delete.
(or1k_gdbarch_init): Don't register deleted function with gdbarch.
Make use of the default gdbarch methods for gdbarch_dummy_id, and
gdbarch_unwind_sp where possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* nios2-tdep.c (nios2_dummy_id): Delete.
(nios2_unwind_sp): Delete.
(nios2_gdbarch_init): Don't register deleted functions with
gdbarch.
Make use of the default gdbarch methods for gdbarch_dummy_id,
gdbarch_unwind_pc, and gdbarch_unwind_sp where possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* nds32-tdep.c (nds32_dummy_id): Delete.
(nds32_unwind_pc): Delete.
(nds32_unwind_sp): Delete.
(nds32_gdbarch_init): Don't register deleted functions with
gdbarch.
Make use of the default gdbarch methods for gdbarch_dummy_id,
gdbarch_unwind_pc, and gdbarch_unwind_sp where possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* msp430-tdep.c (msp430_unwind_pc): Delete.
(msp430_unwind_sp): Delete.
(msp430_dummy_id): Delete.
(msp430_gdbarch_init): Don't register deleted functions with
gdbarch.
Make use of the default gdbarch methods for gdbarch_dummy_id,
gdbarch_unwind_pc, and gdbarch_unwind_sp where possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* moxie-tdep.c (moxie_unwind_sp): Delete.
(moxie_unwind_pc): Delete.
(moxie_dummy_id): Delete.
(moxie_gdbarch_init): Don't register deleted functions with
gdbarch.
Make use of the default gdbarch methods for gdbarch_dummy_id,
gdbarch_unwind_pc, and gdbarch_unwind_sp where possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* mn10300-tdep.c (mn10300_dummy_id): Delete.
(mn10300_unwind_pc): Delete.
(mn10300_unwind_sp): Delete.
(mn10300_push_dummy_call): Use gdbarch_unwind_sp not
mn10300_unwind_sp.
(mn10300_frame_unwind_init): Don't register deleted functions with
gdbarch.
Make use of the default gdbarch methods for gdbarch_dummy_id,
gdbarch_unwind_pc, and gdbarch_unwind_sp where possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* mep-tdep.c (mep_unwind_pc): Delete.
(mep_unwind_sp): Delete.
(mep_dummy_id): Delete.
(mep_gdbarch_init): Don't register deleted functions with
gdbarch.
Make use of the default gdbarch methods for gdbarch_unwind_pc, and
gdbarch_unwind_sp where possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* m68hc11-tdep.c (m68hc11_unwind_pc): Delete.
(m68hc11_unwind_sp): Delete.
(m68hc11_gdbarch_init): Don't register deleted functions with
gdbarch.
Make use of the default gdbarch methods for gdbarch_dummy_id,
gdbarch_unwind_pc, and gdbarch_unwind_sp where possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* m32r-tdep.c (m32r_unwind_sp): Delete.
(m32r_unwind_pc): Delete.
(m32r_dummy_id): Delete.
(m32r_gdbarch_init): Don't register deleted functions with
gdbarch.
Make use of the default gdbarch methods for gdbarch_dummy_id,
gdbarch_unwind_pc, and gdbarch_unwind_sp where possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* m32c-tdep.c (m32c_unwind_pc): Delete.
(m32c_unwind_sp): Delete.
(m32c_dummy_id): Delete.
(m32c_gdbarch_init): Don't register deleted functions with
gdbarch.
Make use of the default gdbarch methods for gdbarch_dummy_id,
gdbarch_unwind_pc, and gdbarch_unwind_sp where possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* gdb/lm32-tdep.c (lm32_unwind_sp): Delete.
(lm32_unwind_pc): Delete.
(lm32_dummy_id): Delete.
(lm32_gdbarch_init): Don't register deleted functions with
gdbarch.
Make use of the default gdbarch methods for gdbarch_dummy_id,
gdbarch_unwind_pc, and gdbarch_unwind_sp where possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* gdb/iq2000-tdep.c (iq2000_unwind_sp): Delete.
(iq2000_unwind_pc): Delete.
(iq2000_dummy_id): Delete.
(iq2000_gdbarch_init): Don't register deleted functions with
gdbarch.
The general type_align method should be a suitable alternative to
nds32_type_align, so switch to use that.
The only change this will introduce is related to static fields in a
struct or union, the existing code doesn't take account of static
fields when computing the alignment for structs of unions, though this
is probably a bug - which would probably be exposed by the test case
gdb.cp/many-args.exp, though I don't have any way to test this target
right now.
gdb/ChangeLog:
* nds32-tdep.c (nds32_type_align): Delete.
(nds32_push_dummy_call): Use type_align instead.
Replaces use of arm_type_align with common type_align function.
Doing this fixes a bug in arm_type_align where static fields are
considered as part of the alignment calculation of a struct, which
results in arguments passed on the stack being misaligned, this bug
was causing a failure in gdb.cp/many-args.exp.
Part of the old arm_type_align is retained and used as the gdbarch
type align callback in order to correctly align vectors.
gdb/ChangeLog:
* arm-tdep.c (arm_type_align): Only handle vector override case.
(arm_push_dummy_call): Use type_align.
(arm_gdbarch_init): Register arm_type_align gdbarch function.
Replaces use of aarch64_type_align with common type_align function.
Doing this fixes a bug in aarch64_type_align where static fields are
considered as part of the alignment calculation of a struct, which
results in arguments passed on the stack being misaligned. This bug
is exposed in the new test gdb.cp/many-args.exp.
Part of the old aarch64_type_align is retained and used as the gdbarch
type align callback in order to correctly align vectors.
gdb/ChangeLog:
* aarch64-tdep.c (aarch64_type_align): Only handle vector override
case.
(pass_on_stack): Use type_align.
(aarch64_gdbarch_init): Register aarch64_type_align gdbarch
function.
gdb/testsuite/ChangeLog:
* gdb.cp/many-args.cc: New file.
* gdb.cp/many-args.exp: New file.
I noticed that one of the overloads of line_header::file_name_at is
unused. This patch removes it.
gdb/ChangeLog
2019-04-23 Tom Tromey <tromey@adacore.com>
* dwarf2read.c (line_header::file_name_at): Remove unused
overload.
When running gdb.btrace/reconnect.exp with native-gdbserver, we run into:
...
FAIL: gdb.btrace/reconnect.exp: first: stepi 19
...
due to the fact that we're trying to match:
...
stepi 19^M
0x00007ffff7dd8b57 in _dl_start () from /lib64/ld-linux-x86-64.so.2^M
...
using pattern:
...
gdb_test "stepi 19" "0x.* in .* from target.*"
...
Fix this by changing the pattern to:
...
gdb_test "stepi 19" "0x.* in .* from .*"
...
Tested on x86_64-linux with native and native-gdbserver.
gdb/testsuite/ChangeLog:
2019-04-23 Tom de Vries <tdevries@suse.de>
PR gdb/24433
* gdb.btrace/reconnect.exp: Fix stepi 19 pattern.
The -m option of cc-with-tweaks.sh sets want_multi to true, invoking dwz like
this:
...
elif [ "$want_multi" = true ]; then
cp $output_file ${output_file}.alt
$DWZ -m ${output_file}.dwz "$output_file" ${output_file}.alt \
> /dev/null 2>&1
fi
...
The problem that is being solved here, is that we want to test dwz in
multifile mode, which requires more than one input file, while we only have
(at the scope of cc-with-tweaks.sh) one executable. We handle this by copying
the executable and offering this as a second input (and using a copy has the
additional benefit that it maximally enables dwz transformation).
However, after the dwz invocation, the copy is no longer used, and the
presence of the file actually causes a test regression:
...
FAIL: gdb.base/jit-so.exp: test jit-reader-load filename completion
...
Fix this by removing the superflous copy after dwz invocation.
Tested on x86_64-linux.
gdb/ChangeLog:
2019-04-23 Tom de Vries <tdevries@suse.de>
PR gdb/24438
* contrib/cc-with-tweaks.sh: Remove superfluous .alt file after dwz
invocation.
Ubuntu/Debian defaults PIE to enabled. This causes the trace tests
to fall over due to variables being returned as "unavailable". The
tests were never designed to work with pie.
Simply ensure the nopie flag is always used for the failing tests.
This removes 100+ failures when running native-gdbserver on Ubuntu 18.04.
gdb/testsuite/ChangeLog:
* gdb.trace/backtrace.exp: Use nopie flag.
* gdb.trace/circ.exp: Likewise.
* gdb.trace/collection.exp: Likewise.
* gdb.trace/ftrace.exp: Likewise.
* gdb.trace/mi-trace-unavailable.exp: Likewise.
* gdb.trace/mi-traceframe-changed.exp: Likewise.
* gdb.trace/qtro.exp: Likewise.
* gdb.trace/read-memory.exp: Likewise.
* gdb.trace/report.exp: Likewise.
* gdb.trace/tfile.exp: Likewise.
* gdb.trace/tfind.exp: Likewise.
* gdb.trace/unavailable.exp: Likewise.
DW_OP_addrx is the new name of DW_OP_GNU_addr_index, and DW_FORM_addrx
is the name of DW_FORM_addr_index in the Dwarf 5 standard. This is a small
step towards supporting Dwarf 5 in gdb.
Note: I could not find any tests specifically for *_GNU_addr_index, and
I did not add any new tests, please advise.
While reviewing
https://sourceware.org/ml/gdb-patches/2019-04/msg00141.html
I noticed that we relied heavily on global state through the
get_svr4_info function, which uses current_program_space. I thought we
could improve this (make things more explicit and easier to follow) by
- Making get_svr4_info accept a program_space parameter, making it
return the SVR4 info for that program space.
- Passing down the svr4_info object from callers as much as possible.
This means looking up the svr4_info for the appropriate program space at
the entry points of the solib-svr4.c file and passing it down. For now,
these entry points (most of them are "methods" of svr4_so_ops) rely on
current_program_space, but we can later try to change the target_so_ops
interface to pass down the program space.
gdb/ChangeLog:
* solib-svr4.c (get_svr4_info): Add pspace parameter.
(svr4_keep_data_in_core): Pass current_program_space to get_svr4_info.
(open_symbol_file_object): Likewise.
(svr4_default_sos): Add info parameter.
(svr4_read_so_list): Likewise.
(svr4_current_sos_direct): Adjust functions calls to pass down
info.
(svr4_current_sos_1): Add info parameter.
(svr4_current_sos): Call get_svr4_info, pass info down to
svr4_current_sos_1.
(svr4_fetch_objfile_link_map): Pass objfile->pspace to
get_svr4_info.
(svr4_in_dynsym_resolve_code): Pass current_program_space to
get_svr4_info.
(probes_table_htab_remove_objfile_probes): Pass objfile->pspace
to get_svr4_info.
(probes_table_remove_objfile_probes): Likewise.
(register_solib_event_probe): Add info parameter.
(solist_update_incremental): Pass info parameter down to
svr4_read_so_list.
(disable_probes_interface): Add info parameter.
(svr4_handle_solib_event): Pass current_program_space to
get_svr4_info. Adjust disable_probes_interface cleanup.
(svr4_create_probe_breakpoints): Add info parameter, pass it
down to register_solib_event_probe.
(svr4_create_solib_event_breakpoints): Add info parameter,
pass it down to svr4_create_probe_breakpoints.
(enable_break): Pass info down to
svr4_create_solib_event_breakpoints.
(svr4_solib_create_inferior_hook): Pass current_program_space to
get_svr4_info.
(svr4_clear_solib): Likewise.
On systems that use the probes-based solib interface, GDB misbehaves
if you run the "nosharelibrary" command, continue execution, and then
the program hits the shared library event breakpoint. On my system it
aborts like this:
(gdb) nosharedlibrary
(gdb) c
Continuing.
pure virtual method called
terminate called without an active exception
Aborted (core dumped)
Though it's really undefined behavior territory, caused by deferencing
a dangling solib event probe pointer.
I've observed this by running "nosharedlibrary" when stopped at the
entry point, but it should happen at any other point, if the program
does a dlopen/dlclose after.
The fix is to discard an objfile's probes from the svr4 probes table
when an objfile is about to be released.
New test included, works with both native and gdbserver testing.
Valgrind log:
(gdb) starti
(gdb) nosharedlibrary
(gdb) c
Continuing.
==24895== Invalid read of size 8
==24895== at 0x89E5FB: solib_event_probe_action(probe_and_action*) (solib-svr4.c:1735)
==24895== by 0x89E95A: svr4_handle_solib_event() (solib-svr4.c:1872)
==24895== by 0x8A7198: handle_solib_event() (solib.c:1274)
==24895== by 0x4E3407: bpstat_stop_status(address_space const*, unsigned long, thread_info*, target_waitstatus const*, bpstats*) (breakpoint.c:5407)
==24895== by 0x721F41: handle_signal_stop(execution_control_state*) (infrun.c:5685)
==24895== by 0x720B11: handle_inferior_event(execution_control_state*) (infrun.c:5129)
==24895== by 0x71DD93: fetch_inferior_event(void*) (infrun.c:3748)
==24895== by 0x7059C3: inferior_event_handler(inferior_event_type, void*) (inf-loop.c:43)
==24895== by 0x874DF0: remote_async_serial_handler(serial*, void*) (remote.c:14039)
==24895== by 0x894101: run_async_handler_and_reschedule(serial*) (ser-base.c:137)
==24895== by 0x8941E6: fd_event(int, void*) (ser-base.c:188)
==24895== by 0x67AFEF: handle_file_event(file_handler*, int) (event-loop.c:732)
==24895== Address 0x18b63860 is 0 bytes inside a block of size 136 free'd
==24895== at 0x4C2E616: operator delete(void*, unsigned long) (vg_replace_malloc.c:585)
==24895== by 0x8C6A12: stap_probe::~stap_probe() (stap-probe.c:124)
==24895== by 0x66F7DB: probe_key_free(bfd*, void*) (elfread.c:1382)
==24895== by 0x69B705: bfdregistry_callback_adaptor(void (*)(registry_container*, void*), registry_container*, void*) (gdb_bfd.c:131)
==24895== by 0x855A57: registry_clear_data(registry_data_registry*, void (*)(void (*)(registry_container*, void*), registry_container*, void*), registry_container*, registry_fields*) (registry.c:79)
==24895== by 0x855B01: registry_container_free_data(registry_data_registry*, void (*)(void (*)(registry_container*, void*), registry_container*, void*), registry_container*, registry_fields*) (registry.c:92)
==24895== by 0x69B783: bfd_free_data(bfd*) (gdb_bfd.c:131)
==24895== by 0x69C4BA: gdb_bfd_unref(bfd*) (gdb_bfd.c:609)
==24895== by 0x7CC33F: objfile::~objfile() (objfiles.c:651)
==24895== by 0x7CD559: objfile_purge_solibs() (objfiles.c:1021)
==24895== by 0x8A7132: no_shared_libraries(char const*, int) (solib.c:1252)
==24895== by 0x548E3D: do_const_cfunc(cmd_list_element*, char const*, int) (cli-decode.c:106)
==24895== Block was alloc'd at
==24895== at 0x4C2D42A: operator new(unsigned long) (vg_replace_malloc.c:334)
==24895== by 0x8C527C: handle_stap_probe(objfile*, sdt_note*, std::vector<probe*, std::allocator<probe*> >*, unsigned long) (stap-probe.c:1561)
==24895== by 0x8C5535: stap_static_probe_ops::get_probes(std::vector<probe*, std::allocator<probe*> >*, objfile*) const (stap-probe.c:1656)
==24895== by 0x66F71B: elf_get_probes(objfile*) (elfread.c:1365)
==24895== by 0x7EDD85: find_probes_in_objfile(objfile*, char const*, char const*) (probe.c:227)
==24895== by 0x4DF382: create_longjmp_master_breakpoint() (breakpoint.c:3275)
==24895== by 0x4F6562: breakpoint_re_set() (breakpoint.c:13828)
==24895== by 0x8A66AA: solib_add(char const*, int, int) (solib.c:1010)
==24895== by 0x89F7C6: enable_break(svr4_info*, int) (solib-svr4.c:2360)
==24895== by 0x8A104C: svr4_solib_create_inferior_hook(int) (solib-svr4.c:2992)
==24895== by 0x8A70B9: solib_create_inferior_hook(int) (solib.c:1215)
==24895== by 0x70C073: post_create_inferior(target_ops*, int) (infcmd.c:467)
==24895==
pure virtual method called
terminate called without an active exception
==24895==
==24895== Process terminating with default action of signal 6 (SIGABRT): dumping core
==24895== at 0x7CF3750: raise (raise.c:51)
==24895== by 0x7CF4D30: abort (abort.c:79)
==24895== by 0xB008F4: __gnu_cxx::__verbose_terminate_handler() (in build/gdb/gdb)
==24895== by 0xAFF845: __cxxabiv1::__terminate(void (*)()) (in build/gdb/gdb)
==24895== by 0xAFF890: std::terminate() (in build/gdb/gdb)
==24895== by 0xAFF95E: __cxa_pure_virtual (in build/gdb/gdb)
==24895== by 0x89E610: solib_event_probe_action(probe_and_action*) (solib-svr4.c:1735)
==24895== by 0x89E95A: svr4_handle_solib_event() (solib-svr4.c:1872)
==24895== by 0x8A7198: handle_solib_event() (solib.c:1274)
==24895== by 0x4E3407: bpstat_stop_status(address_space const*, unsigned long, thread_info*, target_waitstatus const*, bpstats*) (breakpoint.c:5407)
==24895== by 0x721F41: handle_signal_stop(execution_control_state*) (infrun.c:5685)
==24895== by 0x720B11: handle_inferior_event(execution_control_state*) (infrun.c:5129)
==24895==
Note, this little bit in the patch is just a cleanup that I noticed:
- lookup.prob = prob;
lookup.address = address;
That line isn't necessary because hashing/comparison only looks at the
address.
gdb/ChangeLog:
2019-04-22 Pedro Alves <palves@redhat.com>
* solib-svr4.c (svr4_free_objfile_observer): New.
(probe_and_action::objfile): New field.
(probes_table_htab_remove_objfile_probes)
(probes_table_remove_objfile_probes): New functions.
(register_solib_event_probe): Add 'objfile' parameter. Store it
in the new probe_and_action. Don't store the probe in 'lookup'.
(svr4_create_probe_breakpoints): Pass objfile to
register_solib_event_probe.
(_initialize_svr4_solib): Register a free_objfile observer.
gdb/testsuite/ChangeLog:
2019-04-22 Pedro Alves <palves@redhat.com>
* gdb.base/solib-probes-nosharedlibrary.c,
gdb.base/solib-probes-nosharedlibrary.exp: New files.
gdb/doc/ChangeLog:
2019-04-22 Pedro Alves <palves@redhat.com>
* gdb.texinfo (Reverse Execution): Mention and xref process record
and replay. Mention remote and system emulators.
(Process Record and Replay): List supported architectures.
Mention that "record btrace" is only supported on Intel
processors.
This crash was detected when using GDB with the valgrind gdbserver.
To reproduce:
valgrind sleep 10000
In another window:
gdb
target remote | vgdb
p printf("make sleep print something\n")
=>
terminate called after throwing an instance of 'gdb_exception_error'
Aborted
The problem is that the valgrind gdbserver does not allow to change
registers when the inferior is blocked in a system call.
GDB then raises an exception. The exception causes the destructor
of
typedef std::unique_ptr<infcall_suspend_state, infcall_suspend_state_deleter>
infcall_suspend_state_up;
to be called. This destructor itself tries to restore the value of
the registers, and fails similarly. We must catch the exception in
the destructor to avoid crashing GDB.
If the destructor encounters a problem, no warning is produced if
there is an uncaught exception, as in this case, the user will already
be informed of a problem via this exception.
With this change, no crash anymore, and all the valgrind 3.15 tests
pass succesfully.
gdb/ChangeLog
2019-04-19 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* inferior.h (struct infcall_suspend_state_deleter):
Catch exception in destructor to avoid crash.
event-loop.c does not need to include common/queue.h, so this removes
it.
gdb/ChangeLog
2019-04-19 Tom Tromey <tom@tromey.com>
* event-loop.c: Don't include "common/queue.h".
This changes remote_notif_state::notif_queue to be a std::list and
updates all the uses.
gdb/ChangeLog
2019-04-19 Tom Tromey <tom@tromey.com>
* remote.c (remote_target): Use delete.
* remote-notif.h: Include <list>, not "common/queue.h".
(notif_client_p): Remove typedef.
(remote_notif_state): Add constructor, destructor, initializer.
<notif_queue>: Now a std::list.
(remote_notif_state_xfree): Don't declare.
* remote-notif.c (remote_notif_process, handle_notification)
(remote_notif_state_allocate): Update.
(~remote_notif_state): Rename from remote_notif_state_xfree.
This changes objfile::static_links to be an htab_up, so that ~objfile
no longer has to explicitly destroy it.
Tested by the buildbot.
gdb/ChangeLog
2019-04-19 Tom Tromey <tom@tromey.com>
* symfile.c (reread_symbols): Update.
* objfiles.c (objfile_register_static_link)
(objfile_lookup_static_link): Update
(~objfile) Don't delete static_links.
* objfiles.h (struct objfile) <static_links>: Now an htab_up.
Allow disabling source-highlight dependency autodetection even
it exists in the system. More details on problem of automatic
dependencies:
https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Automagic_dependencies
Noticed by Jeroen Roovers in https://bugs.gentoo.org/680238
* configure.ac: add --enable-source-highlight switch.
* configure: Regenerate.
* top.c (print_gdb_version): plumb --enable-source-highlight
status to "show configuration".
gdb/ChangeLog
2019-04-19 Sergei Trofimovich <siarheit@google.com>
* configure.ac: add --enable-source-highlight switch.
* configure: Regenerate.
* top.c (print_gdb_version): plumb --enable-source-highlight
status to "show configuration".
ada-lang.c is a bit too eager trying to decode unions in the Ada style
-- looking for discriminants and such. This causes crashes when
printing a non-Ada union in Ada mode, something that can easily happen
when printing a value from history or certain registers on AArch64.
This patch fixes the bug by changing ada-lang.c to only apply special
Ada treatment to types coming from an Ada CU. This in turn required a
couple of surprising changes.
First, some of the Ada code was already using HAVE_GNAT_AUX_INFO to
decide whether a type had already been fixed -- such types had
INIT_CPLUS_SPECIFIC called on them. This patch changes these spots to
use the "none" identifier instead.
This then required changing value_rtti_type to avoid changing the
language-specific object attached to an Ada type, which seems like a
good change regardless.
Tested on x86-64 Fedora 29.
gdb/ChangeLog
2019-04-19 Tom Tromey <tromey@adacore.com>
* ada-lang.c (ada_is_variant_part, ada_to_fixed_type_1):
Check ADA_TYPE_P.
(empty_record, ada_template_to_fixed_record_type_1)
(template_to_static_fixed_type)
(to_record_with_fixed_variant_part): Use INIT_NONE_SPECIFIC.
* cp-abi.c (value_rtti_type): Check HAVE_CPLUS_STRUCT.
* gdbtypes.h (INIT_NONE_SPECIFIC, ADA_TYPE_P): New
macros.
gdb/testsuite/ChangeLog
2019-04-19 Tom Tromey <tromey@adacore.com>
* gdb.ada/ptype_union.c: New file.
* gdb.ada/ptype_union.exp: New file.
PR symtab/24423 points out that control characters in a source file
cause a hang in the "list" command, a regression introduced by the
styling changes.
This patch, from the PR, fixes the bug. I've included a minimal
change to the "list" test that exercises this code.
I recall that this bug was discussed on gdb-patches, and I thought
there was a patch there as well, but I was unable to find it.
gdb/ChangeLog
2019-04-19 Ilya Yu. Malakhov <malakhov@mcst.ru>
PR symtab/24423:
* source.c (print_source_lines_base): Advance "iter" when a
control character is seen.
gdb/testsuite/ChangeLog
2019-04-19 Tom Tromey <tromey@adacore.com>
PR symtab/24423:
* gdb.base/list0.h (foo): Add a control-l character.
This crash was detected when using GDB with the valgrind gdbserver.
To reproduce:
valgrind sleep 10000
In another window:
gdb
target remote | vgdb
p printf("make sleep print something\n")
=>
terminate called after throwing an instance of 'gdb_exception_error'
Aborted
The problem is that the valgrind gdbserver does not allow to change
registers when the inferior is blocked in a system call.
GDB then raises an exception. The exception causes the destructor
of
typedef std::unique_ptr<infcall_suspend_state, infcall_suspend_state_deleter>
infcall_suspend_state_up;
to be called. This destructor itself tries to restore the value of
the registers, and fails similarly. We must catch the exception in
the destructor to avoid crashing GDB.
If the destructor encounters a problem, no warning is produced if
there is an uncaught exception, as in this case, the user will already
be informed of a problem via this exception.
With this change, no crash anymore, and all the valgrind 3.15 tests
pass succesfully.
gdb/ChangeLog
2019-04-19 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* inferior.h (struct infcall_suspend_state_deleter):
Catch exception in destructor to avoid crash.
gdb/ChangeLog
2019-04-19 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* cli/cli-cmds.c (_initialize_cli_cmds): Move "shell" "!" alias
close to the add_com "shell".
When running break-probes.exp with native-gdbserver, we run into:
...
FAIL: gdb.base/break-probes.exp: run til our library loads (the program exited)
FAIL: gdb.base/break-probes.exp: call (int) foo(23)
...
due to the fact that we're trying to match:
...
Inferior loaded /data/gdb_versions/devel/build/gdb/testsuite/outputs/gdb.base\
/break-probes/break-probes-solib.so
...
using pattern:
...
Inferior loaded $sysroot$binfile_lib
...
which expands into:
...
Inferior loaded //data/gdb_versions/devel/build/gdb/testsuite/outputs/gdb.base\
/break-probes/break-probes-solib.so
...
Fix by setting sysroot to "" in local-board.exp.
Tested on x86_64-linux with native-gdbserver.
gdb/testsuite/ChangeLog:
2019-04-18 Tom de Vries <tdevries@suse.de>
PR gdb/24433
* boards/local-board.exp: Set sysroot to "".
It seemed to me that process_stratum_target::stratum ought to be
"final".
Tested by rebuilding, let me know what you think.
gdb/ChangeLog
2019-04-18 Tom Tromey <tromey@adacore.com>
* process-stratum-target.h (class process_stratum_target)
<stratum>: Add "final".
When debugging any of the testcases added by this commit, which do a
vfork in a thread with "set follow-fork-mode child" + "set
detach-on-fork on", we run into this assertion:
...
src/gdb/nat/x86-linux-dregs.c:146: internal-error: \
void x86_linux_update_debug_registers(lwp_info*): \
Assertion `lwp_is_stopped (lwp)' failed.
...
The assert is caused by the following: the vfork-child exit or exec
event is handled by handle_vfork_child_exec_or_exit, which calls
target_detach to detach from the vfork parent. During target_detach
we call linux_nat_target::detach, which:
#1 - stops all the threads
#2 - waits for all the threads to be stopped
#3 - detaches all the threads
However, during the second step we run into this code in
stop_wait_callback:
...
/* If this is a vfork parent, bail out, it is not going to report
any SIGSTOP until the vfork is done with. */
if (inf->vfork_child != NULL)
return 0;
...
and we don't wait for the threads to be stopped, which results in this
assert in x86_linux_update_debug_registers triggering during the third
step:
...
gdb_assert (lwp_is_stopped (lwp));
...
The fix is to reset the vfork parent's vfork_child field before
calling target_detach in handle_vfork_child_exec_or_exit. There's
already similar code for the other paths handled by
handle_vfork_child_exec_or_exit, so this commit refactors the code a
bit so that all paths share the same code.
The new tests cover both a vfork child exiting, and a vfork child
execing, since both cases would trigger the assertion.
The new testcases also exercise following the vfork children with "set
detach-on-fork off", since it doesn't seem to be tested anywhere.
Tested on x86_64-linux, using native and native-gdbserver.
gdb/ChangeLog:
2019-04-18 Tom de Vries <tdevries@suse.de>
Pedro Alves <palves@redhat.com>
PR gdb/24454
* infrun.c (handle_vfork_child_exec_or_exit): Reset vfork parent's
vfork_child field before calling target_detach.
gdb/testsuite/ChangeLog:
2019-04-18 Tom de Vries <tdevries@suse.de>
Pedro Alves <palves@redhat.com>
PR gdb/24454
* gdb.threads/vfork-follow-child-exec.c: New file.
* gdb.threads/vfork-follow-child-exec.exp: New file.
* gdb.threads/vfork-follow-child-exit.c: New file.
* gdb.threads/vfork-follow-child-exit.exp: New file.
After commit 35add35 ("gdb: Fix failure in gdb.base/complex-parts.exp
for x86-32"), dwarf2_init_complex_target_type can crash if "tt" is
nullptr. This patch avoids the problem by checking for this case.
No test case because I don't know a good way to write one; it was
found by an internal AdaCore test case that apparently uses a 16 bit
floating point type.
gdb/ChangeLog:
* dwarf2read.c (dwarf2_init_complex_target_type): Check "tt"
against nullptr before use.
gdb/ChangeLog
2019-04-17 Tom Tromey <tromey@adacore.com>
* dwarf2read.c (dwarf2_init_complex_target_type): Check "tt"
against nullptr before use.
All debug output needs to go via debug functions to ensure it writes to the
correct output stream.
gdb/ChangeLog:
* nat/linux-waitpid.c (linux_debug): Call debug_vprintf.
gdb/gdbserver/ChangeLog:
* ax.c (ax_vdebug): Call debug_printf.
* debug.c (debug_write): New function.
* debug.h (debug_write): New declaration.
* linux-low.c (sigchld_handler): Call debug_write.
A comment in debug.h (written in 2014) states: "We declare debug format
variables here, and debug_threads but no other debug content variables
(e.g., not remote_debug) because while this file is not currently used by
IPA it may be some day, and IPA may have its own set of debug content
variables".
This has resulted in remote_debug being declared in many .c/.h files
throughout gdbserver.
It would be much simplier to define it one place. The most logical place to
define it is in debug.h, surrounded by #define guards. If IPA is changed,
then at that point the variable can be moved elsewhere.
gdb/gdbserver/ChangeLog:
* debug.c (remote_debug): Add definition.
* debug.h (remote_debug): Add declaration.
* hostio.c (remote_debug): Remove declaration.
* remote-utils.c (struct ui_file): Likewise.
(remote_debug): Likewise.
* remote-utils.h (remote_debug): Likewise,
* server.c (remote_debug): Remove definition.
Some testsuite cases (gdb.cp/nsalias.exp for example) construct dwarf2
debug info for fake functions to test that this debug info is handled
correctly.
We currently get an error trying to read from an invalid address while
creating breakpoints for these fake functions.
Other targets allow creating breakpoints on invalid addresses, and
only error when GDB actually tries to insert the breakpoints.
In order to make RISC-V behave in the same way as other targets, this
commit makes the failure to read memory during breakpoint creation
non-fatal, we then expect to see a failure when GDB tries to insert
the breakpoint, just like other targets.
Tested with a riscv64-linux native testsuite run.
gdb/ChangeLog:
* riscv-tdep.c (riscv_breakpoint_kind_from_pc): Hanndle case where
code read might fail, assume 4-byte breakpoint in that case.
The AMD64 System V ABI specifies that when a function has a return type
classified as MEMORY, the caller provides space for the value and passes
the address to this space as the first argument to the function (before
even the "this" pointer). The classification of MEMORY is applied to
struct that are sufficiently large, or ones with unaligned fields.
The expression evaluator uses call_function_by_hand to call functions,
and the hand-built frame has to push arguments in a way that matches the
ABI of the called function. call_function_by_hand supports ABI-based
struct returns, based on the value of gdbarch_return_value, however on
AMD64 the implementation of the classifier incorrectly assumed that all
non-POD types (implemented as "all types with a base class") should be
classified as MEMORY and use the struct return.
This ABI mismatch resulted in issues when calling a function that returns
a class of size <16 bytes which has a base class, including issues such
as the "this" pointer being incorrect (as it was passed as the second
argument rather than the first).
This is now fixed by checking for field alignment rather than POD-ness,
and a testsuite is added to test expression evaluation for AMD64.
gdb/ChangeLog:
* amd64-tdep.c (amd64_classify_aggregate): Use cp_pass_by_reference
rather than a hand-rolled POD check when checking for forced MEMORY
classification.
gdb/testsuite/ChangeLog:
* gdb.arch/amd64-eval.cc: New file.
* gdb.arch/amd64-eval.exp: New file.
When writing registers to the kernel, check if regcache VG has been changed. If
so then update the thread's vector length, then write back the registers.
When reading registers from the kernel, ensure regcache VG register is updated.
The regcache registers should already be of the correct length.
Remove all the checks that error if the vector length has changed.
gdb/ChangeLog:
* aarch64-linux-nat.c (store_sveregs_to_thread): Set vector length.
* nat/aarch64-sve-linux-ptrace.c (aarch64_sve_set_vq): New function.
(aarch64_sve_regs_copy_to_reg_buf): Remove VG checks.
(aarch64_sve_regs_copy_from_reg_buf): Likewise.
* nat/aarch64-sve-linux-ptrace.h (aarch64_sve_set_vq): New declaration.
Override the thread_architecture method, similar to SPU. If the vector
length has changed, then find the arch using info, making sure the vector
length is passed down to the init routine.
In the init routine, ensure the arch has the correct vector length.
Example output. Program is stopped in thread 2, just before it calls prctl
to change the vector length
(gdb) info threads
Id Target Id Frame
1 Thread 0xffffbf6f4000 (LWP 3188) "sve_change" 0x0000ffffbf6ae130 in pthread_join ()
* 2 Thread 0xffffbf55e200 (LWP 3189) "sve_change" thread1 (arg=0xfeedface) at sve_change_size.c:28
(gdb) print $vg
$1 = 8
(gdb) print $z0.s.u
$2 = {623191333, 623191333, 623191333, 623191333, 0 <repeats 12 times>}
(gdb) n
29 int ret = prctl(PR_SVE_SET_VL, vl/2);
(gdb) n
30 printf ("Changed: ret\n", ret);
(gdb) print $vg
$4 = 4
(gdb) print $z0.s.u
$5 = {623191333, 623191333, 623191333, 623191333, 0, 0, 0, 0}
(gdb) thr 1
[Switching to thread 1 (Thread 0xffffbf6f4000 (LWP 3181))]
(gdb) print $vg
$6 = 8
(gdb) print $z0.s.u
$7 = {623191333, 623191333, 623191333, 623191333, 0 <repeats 12 times>}
gdb/ChangeLog:
* aarch64-linux-nat.c
(aarch64_linux_nat_target::thread_architecture): Add override.
* aarch64-tdep.c (aarch64_gdbarch_init): Ensure different tdesc for
each VQ.
Move the lookup_by_info to the top of the function to avoid unnecessarily
creating a new feature when the gdbarch already exists.
Add some additional cleanups that have no functional effect.
gdb/ChangeLog:
* aarch64-tdep.c (aarch64_gdbarch_init): Move gdbarch lookup.
The x86-32 ABI specifies 96-bit long double, this was causing a
failure on the test gdb.base/complex-parts.exp.
The problem is that GDB tries to find a builtin floating point type of
the correct size in order to reuse the name of that type as the name
for the components of the complex type being built.
Previously GDB was only aware of floating point types sized 32, 64, or
128 bits. This patch teaches GDB how to handle 96 bit floating point
type.
gdb/ChangeLog:
* dwarf2read.c (dwarf2_init_complex_target_type): Handle complex
target types of size 96-bits, add some additional comments, and
check that the builtin type we found was the correct size.
gdb/ChangeLog:
2019-04-12 Eli Zaretskii <eliz@gnu.org>
* utils.c (prompt_for_continue): Don't restore the styling at the
end, as applied_style has the wrong value. This fixes styling in
long lists of file names that are interrupted by the "Continue?"
prompt.
The local board file ensures that the sysroot is always set to load
files from the local filesystem.
Add a gdbserver test to explicitly test the sysroot set to both the
remote target and the local filesystem.
gdb/testsuite/ChangeLog:
* gdb.server/sysroot.c: New test.
* gdb.server/sysroot.exp: New file.
* lib/gdbserver-support.exp (gdb_target_cmd): Add additional text
matching param.
The language_defn structure has an la_magic field, this used to be
used as a basic check that the language_defn structure had the
expected layout - at least the end of the structure was where we
expected it to be.
This feature only really makes sense if we imagine GDB dynamically
loading language support from dynamic libraries, where a version
mismatch might cause problems.
However, in current GDB language support is statically built into GDB,
and since this commit:
commit 47e77640be
Date: Thu Jul 20 18:28:01 2017 +0100
Make language_def O(1)
the existing (if pointless) check of the la_magic field was removed.
There now appears to be no use of the la_magic field, and I propose
that we delete it.
There should be no user visible changes after this commit.
gdb/ChangeLog:
* ada-lang.c (ada_language_defn): Remove use of LANG_MAGIC.
* c-lang.c (c_language_defn): Likewise.
(cplus_language_defn): Likewise.
(asm_language_defn): Likewise.
(minimal_language_defn): Likewise.
* d-lang.c (d_language_defn): Likewise.
* f-lang.c (f_language_defn): Likewise.
* go-lang.c (go_language_defn): Likewise.
* language.c (unknown_language_defn): Likewise.
(auto_language_defn): Likewise.
* language.h (struct language_defn): Remove la_magic field.
(LANG_MAGIC): Delete.
* m2-lang.c (m2_language_defn): Remove use of LANG_MAGIC.
* objc-lang.c (objc_language_defn): Likewise.
* opencl-lang.c (opencl_language_defn): Likewise.
* p-lang.c (pascal_language_defn): Likewise.
* rust-lang.c (rust_language_defn): Likewise.
Make use of the type_align function and remove riscv_type_alignment as
it is no longer needed. I tested this against a number of RV32 and
RV64 targets, and I also ran the tests with an assertion in place
checking that the old riscv_type_alignment function gives the same
answer as the common type_align function - it does, and all the tests
still pass.
gdb/ChangeLog:
* riscv-tdep.c (riscv_type_align): New function.
(riscv_type_alignment): Delete.
(riscv_arg_location): Use 'type_align'.
(riscv_gdbarch_init): Register riscv_type_align gdbarch function.
The current code in gdbtypes.c:type_align incorrectly returns 0 as the
alignment for a structure containing only static fields. After this
patch the correct value of 1 is returned. The gdb.base/align.exp test
is extended to cover this case.
gdb/ChangeLog:
* gdbtypes.c (type_align): A struct with no non-static fields also
has alignment of 1.
gdb/testsuite/ChangeLog:
* gdb.base/align.exp: Extend test to cover structures containing
only static fields.
This commit resolves a large number of failures in the test script
gdb.base/infcall-nested-structs.exp which were caused by GDB (for
RISC-V) incorrectly handling empty C++ structures when preparing
arguments for a dummy call, or collecting a return value.
The issue is further complicated in that there was a bug in GCC, such
that in some cases GCC would generate incorrect code when passing a
small structure that contained empty sub-structures. This was fixed
in GCC trunk on 5-March-2019, so in order to see the best results with
this patch you'll need a recent version of GCC.
Anything that used to work should continue to work after this patch,
regardless of GCC version being used.
The fix in this commit is that GDB now pays more attention to the
offset of fields within a structure when preparing arguments as in C++
an empty structure has a non-zero size, this is an example:
struct s1 { struct s2 { } empty; int f; };
We previously assumed that 'f' was at offset 0 inside type 's1',
however this is not the case in C++ as 's2' has size 1, and with
alignment 'f' is likely at some even bigger offset inside 's1'.
gdb/ChangeLog:
* riscv-tdep.c (riscv_call_arg_complex_float): Fix offset of first
component to 0.
(riscv_struct_info::riscv_struct_info): Initialise m_offsets
member.
(riscv_struct_info::analyse): New implementation using new
analyse_inner member function.
(riscv_struct_info::field_offset): New member function.
(riscv_struct_info::m_offsets): New member variable.
(riscv_struct_info::analyse_inner): New private member function,
takes the old implementation of riscv_struct_info::analyse but
extended to track field offsets.
(riscv_call_arg_struct): Update the struct folding special cases
to handle cases where empty C++ structs, which are non-zero
length, are found.
(riscv_arg_location): Initialise the length of each location, a
non-zero length now indicates the location is in use.
(riscv_push_dummy_call): Allow for the first location having a
non-zero offset when setting up arguments.
(riscv_return_value): Likewise, but for return values.
I noticed that the "msg" variable in internal_vproblem could be
"const". This seems like an improvement because it can wind up in
rodata.
Tested by rebuilding.
gdb/ChangeLog
2019-04-11 Tom Tromey <tromey@adacore.com>
* utils.c (internal_vproblem): Make "msg" const.
We can use CC_WITH_TWEAKS_FLAGS when cd-ing into the gdb build subdir and
invoking make check:
...
$ cd $objdir/gdb
$ make check \
RUNTESTFLAGS='--target_board=cc-with-tweaks' \
CC_WITH_TWEAKS_FLAGS='-z'
...
But when cd-ing into the top-level build dir and invoking make check-gdb
instead:
...
$ cd $objdir
$ make check-gdb \
RUNTESTFLAGS='--target_board=cc-with-tweaks' \
CC_WITH_TWEAKS_FLAGS='-z'
...
using CC_WITH_TWEAKS_FLAGS has no effect, because CC_WITH_TWEAKS_FLAGS is not
passed down from the top level Makefile.
Add cc-with-dwz.exp and cc-with-dwz-m.exp, that don't require
CC_WITH_TWEAKS_FLAGS to be set in the make invocation, allowing us to run these
test configurations from the toplevel build dir:
...
$ cd $objdir
$ make check-gdb \
RUNTESTFLAGS='--target_board=cc-with-dwz'
...
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-04-11 Tom de Vries <tdevries@suse.de>
* boards/cc-with-dwz-m.exp: New file.
* boards/cc-with-dwz.exp: New file.
* boards/cc-with-tweaks.exp: Note that check-gdb doesn't work.
A recent change made the AArch64 self tests resuse the saved regs
cache, rather than creating a new one. Ensure it is reset to default
values between tests.
Do this by splitting the reset functionality from trad_frame_alloc_saved_regs
into a new function.
Fixes selftest on AArch64.
gdb/ChangeLog:
* aarch64-tdep.c (aarch64_analyze_prologue_test): Reset saved regs.
* trad-frame.c (trad_frame_reset_saved_regs): New function.
(trad_frame_alloc_saved_regs): Call trad_frame_reset_saved_regs.
* trad-frame.h (trad_frame_reset_saved_regs): New declaration.
This commit fixes some failures in gdb.base/interrupt.exp
when debugging a 32-bit i386 linux inferior from an amd64 host.
When running the following test...
make check RUNTESTFLAGS="--target_board unix/-m32 interrupt.exp"
... without this commit, I see the following output:
FAIL: gdb.base/interrupt.exp: continue (the program exited)
FAIL: gdb.base/interrupt.exp: echo data
FAIL: gdb.base/interrupt.exp: Send Control-C, second time
FAIL: gdb.base/interrupt.exp: signal SIGINT (the program is no longer running)
ERROR: Undefined command "".
ERROR: GDB process no longer exists
=== gdb Summary ===
When the test is run with this commit in place, we see 12 passes
instead. This is the desired behavior.
Analysis:
On Linux, when a syscall is interrupted by a signal, the syscall
may return -ERESTARTSYS when a signal occurs. Doing so indicates that
the syscall is restartable. Then, depending on settings associated
with the signal handler, and after the signal handler is called, the
kernel can then either return -EINTR or can cause the syscall to be
restarted. In this discussion, we are concerned with the latter
case.
On i386, the kernel returns this status via the EAX register.
When debugging a 32-bit (i386) process from a 64-bit (amd64)
GDB, the debugger fetches 64-bit registers even though the
process being debugged is 32-bit. Since we're debugging a 32-bit
target, only 32 bits are being saved in the register cache.
Now, ideally, GDB would save all 64-bits in the regcache and
then would be able to restore those same values when it comes
time to continue the target. I've looked into doing this, but
it's not easy and I don't see many benefits to doing so. One
benefit, however, would be that EAX would appear as a negative
value for doing syscall restarts.
At the moment, GDB is setting the high 32 bits of RAX (and other
registers too) to 0. So, when GDB restores EAX just prior to
a syscall restart, the high 32 bits of RAX are zeroed, thus making
it look like a positive value. For this particular purpose, we
need to sign extend EAX so that RAX will appear as a negative
value when EAX is set to -ERESTARTSYS. This in turn will cause
the signal handling code in the kernel to recognize -ERESTARTSYS
which will in turn cause the syscall to be restarted.
This commit is based on work by Jan Kratochvil from 2009:
https://sourceware.org/ml/gdb-patches/2009-11/msg00592.html
Jan's patch had the sign extension code in amd64-nat.c. Several
other native targets make use of this code, so it seemed better
to move the sign extension code to a linux specific file. I
also added similar code to gdbserver.
Another approach is to fix the problem in the kernel. Hui Zhu
tried to get a fix into the kernel back in 2014, but it was not
accepted. Discussion regarding this approach may be found here:
https://lore.kernel.org/patchwork/patch/457841/
Even if a fix were to be put into the kernel, we'd still need
some kind of fix in GDB in order to support older kernels.
Finally, I'll note that Fedora has been carrying a similar patch for
at least nine years. Other distributions, including RHEL and CentOS
have picked up this change and have been using it too.
gdb/ChangeLog:
* amd64-linux-nat.c (amd64_linux_collect_native_gregset): New
function.
(fill_gregset): Call amd64_linux_collect_native_gregset instead
of amd64_collect_native_gregset.
(amd64_linux_nat_target::store_registers): Likewise.
gdb/gdbserver/ChangeLog:
* linux-x86-low.c (x86_fill_gregset): Sign extend EAX value
when using a 64-bit gdbserver.
This introduces a new iterator and range adapter for iteration over
the separate debug files of a given objfile. As in the current
approach, the requested objfile is returned first, followed by the
separate debug objfiles.
gdb/ChangeLog
2019-04-10 Tom Tromey <tom@tromey.com>
* symtab.c (lookup_global_symbol_from_objfile)
(lookup_symbol_in_objfile_from_linkage_name): Use the iterator.
* objfiles.h (class separate_debug_iterator): New.
(class separate_debug_range): New.
(struct objfile) <separate_debug_objfiles>: New method.
(objfile_separate_debug_iterate): Don't declare.
* objfiles.c (separate_debug_iterator::operator++): Rename from
objfile_separate_debug_iterate.
(objfile_relocate, objfile_rebase, objfile_has_symbols): Use the
iterator.
* minsyms.c (lookup_minimal_symbol_by_pc_section): Use the
iterator.
While working on objfiles I noticed a typo in one comment, and another
comment that, as far as I can tell, has been obsolete for a very long
time.
gdb/ChangeLog
2019-04-10 Tom Tromey <tom@tromey.com>
* symfile.c (reread_symbols): Remove old comment.
* objfiles.c (free_all_objfiles): Fix a typo.
The "object_files" macro is sometimes used when iterating over
objfiles. This patch removes a few such uses in favor of the new
range adapter.
gdb/ChangeLog
2019-04-10 Tom Tromey <tom@tromey.com>
* ia64-tdep.c (ia64_get_dyn_info_list): Use foreach.
* minsyms.c (lookup_minimal_symbol): Use foreach.
(lookup_minimal_symbol_text, lookup_minimal_symbol_by_pc_name)
(lookup_minimal_symbol_solib_trampoline): Likewise.
* symfile.c (reread_symbols): Use foreach.
PR rust/24414 points out that the Rust lexer uses strtoul when lexing
an integer, and that this can give the wrong results in some
situations.
This patch changes it to use strtoulst, like most of the rest of gdb.
It also adds a self test.
Tested on x86-64 Fedora 29 using an i686 build.
gdb/ChangeLog
2019-04-09 Ivan Begert <ivanbegert@gmail.com>
Tom Tromey <tromey@adacore.com>
PR rust/24414:
* rust-exp.y (rust_parser::lex_number): Use strtoulst.
(rust_lex_int_test): Change "value" to be LONGEST.
(rust_lex_tests): Add test for long integer literal.
I noticed that find_thread_in_random duplicates the code in
find_thread_in_random, so this patch changes the latter to use the
former.
There are two other spots in gdb that do this, but to unify all of
them would require switching some code from using the "iterate over"
idiom to using iterators.
Another possible improvement is that find_thread_in_random could be
made single-pass using reservoir sampling.
Tested by the buildbot.
gdb/gdbserver/ChangeLog
2019-04-09 Tom Tromey <tromey@adacore.com>
* linux-low.c (select_event_lwp): Use find_thread_in_random.
I noticed a few spots where fake_pid_p is handled as an int, whereas
the field in struct inferior has type bool. This patch changes the
remaining places to use bool as well.
Tested by the buildbot.
gdb/ChangeLog
2019-04-09 Tom Tromey <tromey@adacore.com>
* remote.c (remote_target::remote_add_inferior): Change fake_pid_p
to bool.
(extended_remote_target::attach): Update.
(remote_target::remote_notice_new_inferior): Update.
(remote_target::add_current_inferior_and_thread): Update.
* inferior.c (exit_inferior_1): Use "false".
* corelow.c (add_to_thread_list): Make fake_pid_p bool.
When using the "start" command, GDB puts a temporary breakpoint on the
"main" symbol (we literally invoke the tbreak command). However, since
it does wild matching by default, it also puts a breakpoint on any C++
method or "main" function in a namespace. For example, when debugging
GDB, it creates a total of 24 locations:
(gdb) start
Temporary breakpoint 1 at 0x198c1e9: main. (24 locations)
as there are a bunch of methods called main in the selftests, such as
selftests::string_view::capacity_1::main()
If such method was called in the constructor of a global object, or a
function marked with the attribute "constructor", then we would stop at
the wrong place. Also, this causes a few extra symtabs (those that
contain the "wrong" mains) to be expanded for nothing.
The dummiest, most straightforward solution is to add -qualified when
invoking tbreak. With this patch, "start" creates a single-location
breakpoint, as expected.
I copied the start.exp test to start-cpp.exp and made it use a C++ test
file, which contains two main functions. The new test verifies that the
output of "start" is the output we get when we set a single-location
breakpoint.
gdb/ChangeLog:
* infcmd.c (run_command_1): Pass -qualified to tbreak when usind
the "start" command.
gdb/testsuite/ChangeLog:
* gdb.base/start-cpp.exp: New file.
* gdb.base/start-cpp.cc: New file.
This renaming was done to stay consistent with the naming of the new
gdb.InferiorThread.handle method. I had initially named it "thread_handle"
but Tom Tromey suggested just "handle".
The old name (thread_from_thread_handle) still works, but is marked as
deprecated in comments in the code as well as in the documentation.
I have some code which uses these functions. I very much like the
brevity of the new names.
gdb/doc/ChangeLog:
* python.texi (Inferiors In Python): Rename
Inferior.thread_from_thread_handle to Inferior.thread_from_handle.
Add note about the former being deprecated.
gdb/ChangeLog:
* python/py-inferior.c (infpy_thread_from_thread_handle):
Adjust comments to reflect renaming of thread_from_thread_handle
to thread_from_handle. Adjust keywords. Fix type error message.
(inferior_object_methods): Add thread_from_handle. Retain
thread_from_thread_handle, but mark it as deprecated.
testsuite/ChangeLog:
* gdb.python/py-thrhandle.exp: Adjust tests to call
thread_from_handle instead of thread_from_thread_handle.
InferiorThread.handle() returns a python bytes object. We'd like to
be able to pass the output of this function, a thread handle, to
Inferior.thread_from_thread_handle(). Up to now,
thread_from_thread_handle() expects to receive a gdb.Value input.
This commit adds support to also allow a python buffer object to be
passed as the handle.
infpy_thread_from_thread_handle() calls find_thread_by_handle() which
has the obvious functionality. It used to pass the thread handle via
a struct value pointer. I've revised this interface to instead pass a
gdb::array_view<const gdb_byte> object. (Thanks to Tom Tromey for
suggesting this data structure over an earlier version which passed a
gdb_byte pointer and length.)
gdb/ChangeLog:
* gdbthread.h (find_thread_by_handle): Revise declaration.
* thread.c (find_thread_by_handle): Likewise. Adjust
implementation too.
* python/py-inferior.c (infpy_thread_from_thread_handle): Add
support for buffer objects as handles.
- Explicitly include <string> for std::string.
- Use std::make_shared to construct gdb_exception::message instead of
operator new, avoiding one heap allocation (2 instead of 3). Add
'const char *fmt, va_list ap' parameters to
gdb_exception{,error,quit}'s ctors, and do the std::make_shared in
the gdb_exception ctor.
- gdb_exception_error's constructor does not need to have an 'enum
return_reason' parameter, since it is always RETURN_ERROR, by
definition.
- Similarly, gdb_exception_quit's contructor does not need to have
'enum return_reason'/'enum errors' parameters.
- In the gdb_exception_{quit,_error} ctors that take a gdb_exception
as argument, assert that they're being passed a gdb_exception object
of the right 'reason'.
gdb/ChangeLog:
2019-04-08 Pedro Alves <palves@redhat.com>
* common/common-exceptions.c (throw_exception): Don't create
named object to throw; throw directly.
(throw_it): Likewise. Don't initialize gdb_exception::message
here, with new; pass FMT and AP to the ctor instead.
* common/common-exceptions.h: Include <string>.
(gdb_exception::gdb_exception(enum return_reason, enum errors,
const char *, va_list)): New ctor. Use std::make_shared.
(gdb_exception_error::gdb_exception_error(enum return_reason, enum
errors)): Delete.
(gdb_exception_error::gdb_exception_error(enum errors, const char
*, va_list)): New.
(gdb_exception_error::gdb_exception_error(const gdb_exception &)):
Add assertion.
(gdb_exception_quit::gdb_exception_quit(enum return_reason, enum
errors)): Delete.
(gdb_exception_quit::gdb_exception_quit(const char *, va_list)): New.
(gdb_exception_quit::gdb_exception_quit(const gdb_exception &)):
Add assertion.
This makes exception throwing a bit more efficient, by removing some
copies.
gdb/ChangeLog
2019-04-08 Tom Tromey <tom@tromey.com>
* common/common-exceptions.c (throw_exception): Rename from
throw_exception_cxx. Remove old copy. Make argument const.
(throw_it): Create and throw exception objects directly.
* common/common-exceptions.h (throw_exception): Make argument
const.
(struct gdb_exception_error): Add constructor.
(struct gdb_exception_quit): Add constructor.
After the rewriting to use try/catch, some of the exception code is
now unused. This patch removes that code.
gdb/ChangeLog
2019-04-08 Tom Tromey <tom@tromey.com>
* common/common-exceptions.h (exception_rethrow): Don't declare.
(TRY_SJLJ): Update comment.
(TRY, CATCH, END_CATCH): Remove.
* common/common-exceptions.c (exception_rethrow): Remove.
This rewrites gdb's TRY/CATCH to plain C++ try/catch. The patch was
largely written by script, though one change (to a comment in
common-exceptions.h) was reverted by hand.
gdb/ChangeLog
2019-04-08 Tom Tromey <tom@tromey.com>
* xml-support.c: Use C++ exception handling.
* x86-linux-nat.c: Use C++ exception handling.
* windows-nat.c: Use C++ exception handling.
* varobj.c: Use C++ exception handling.
* value.c: Use C++ exception handling.
* valprint.c: Use C++ exception handling.
* valops.c: Use C++ exception handling.
* unittests/parse-connection-spec-selftests.c: Use C++ exception
handling.
* unittests/cli-utils-selftests.c: Use C++ exception handling.
* typeprint.c: Use C++ exception handling.
* tui/tui.c: Use C++ exception handling.
* tracefile-tfile.c: Use C++ exception handling.
* top.c: Use C++ exception handling.
* thread.c: Use C++ exception handling.
* target.c: Use C++ exception handling.
* symmisc.c: Use C++ exception handling.
* symfile-mem.c: Use C++ exception handling.
* stack.c: Use C++ exception handling.
* sparc64-linux-tdep.c: Use C++ exception handling.
* solib.c: Use C++ exception handling.
* solib-svr4.c: Use C++ exception handling.
* solib-spu.c: Use C++ exception handling.
* solib-frv.c: Use C++ exception handling.
* solib-dsbt.c: Use C++ exception handling.
* selftest-arch.c: Use C++ exception handling.
* s390-tdep.c: Use C++ exception handling.
* rust-lang.c: Use C++ exception handling.
* rust-exp.y: Use C++ exception handling.
* rs6000-tdep.c: Use C++ exception handling.
* rs6000-aix-tdep.c: Use C++ exception handling.
* riscv-tdep.c: Use C++ exception handling.
* remote.c: Use C++ exception handling.
* remote-fileio.c: Use C++ exception handling.
* record-full.c: Use C++ exception handling.
* record-btrace.c: Use C++ exception handling.
* python/python.c: Use C++ exception handling.
* python/py-value.c: Use C++ exception handling.
* python/py-utils.c: Use C++ exception handling.
* python/py-unwind.c: Use C++ exception handling.
* python/py-type.c: Use C++ exception handling.
* python/py-symbol.c: Use C++ exception handling.
* python/py-record.c: Use C++ exception handling.
* python/py-record-btrace.c: Use C++ exception handling.
* python/py-progspace.c: Use C++ exception handling.
* python/py-prettyprint.c: Use C++ exception handling.
* python/py-param.c: Use C++ exception handling.
* python/py-objfile.c: Use C++ exception handling.
* python/py-linetable.c: Use C++ exception handling.
* python/py-lazy-string.c: Use C++ exception handling.
* python/py-infthread.c: Use C++ exception handling.
* python/py-inferior.c: Use C++ exception handling.
* python/py-gdb-readline.c: Use C++ exception handling.
* python/py-framefilter.c: Use C++ exception handling.
* python/py-frame.c: Use C++ exception handling.
* python/py-finishbreakpoint.c: Use C++ exception handling.
* python/py-cmd.c: Use C++ exception handling.
* python/py-breakpoint.c: Use C++ exception handling.
* python/py-arch.c: Use C++ exception handling.
* printcmd.c: Use C++ exception handling.
* ppc-linux-tdep.c: Use C++ exception handling.
* parse.c: Use C++ exception handling.
* p-valprint.c: Use C++ exception handling.
* objc-lang.c: Use C++ exception handling.
* mi/mi-main.c: Use C++ exception handling.
* mi/mi-interp.c: Use C++ exception handling.
* mi/mi-cmd-stack.c: Use C++ exception handling.
* mi/mi-cmd-break.c: Use C++ exception handling.
* main.c: Use C++ exception handling.
* linux-thread-db.c: Use C++ exception handling.
* linux-tdep.c: Use C++ exception handling.
* linux-nat.c: Use C++ exception handling.
* linux-fork.c: Use C++ exception handling.
* linespec.c: Use C++ exception handling.
* language.c: Use C++ exception handling.
* jit.c: Use C++ exception handling.
* infrun.c: Use C++ exception handling.
* infcmd.c: Use C++ exception handling.
* infcall.c: Use C++ exception handling.
* inf-loop.c: Use C++ exception handling.
* i386-tdep.c: Use C++ exception handling.
* i386-linux-tdep.c: Use C++ exception handling.
* guile/scm-value.c: Use C++ exception handling.
* guile/scm-type.c: Use C++ exception handling.
* guile/scm-symtab.c: Use C++ exception handling.
* guile/scm-symbol.c: Use C++ exception handling.
* guile/scm-pretty-print.c: Use C++ exception handling.
* guile/scm-ports.c: Use C++ exception handling.
* guile/scm-param.c: Use C++ exception handling.
* guile/scm-math.c: Use C++ exception handling.
* guile/scm-lazy-string.c: Use C++ exception handling.
* guile/scm-frame.c: Use C++ exception handling.
* guile/scm-disasm.c: Use C++ exception handling.
* guile/scm-cmd.c: Use C++ exception handling.
* guile/scm-breakpoint.c: Use C++ exception handling.
* guile/scm-block.c: Use C++ exception handling.
* guile/guile-internal.h: Use C++ exception handling.
* gnu-v3-abi.c: Use C++ exception handling.
* gdbtypes.c: Use C++ exception handling.
* frame.c: Use C++ exception handling.
* frame-unwind.c: Use C++ exception handling.
* fbsd-tdep.c: Use C++ exception handling.
* f-valprint.c: Use C++ exception handling.
* exec.c: Use C++ exception handling.
* event-top.c: Use C++ exception handling.
* event-loop.c: Use C++ exception handling.
* eval.c: Use C++ exception handling.
* dwarf2read.c: Use C++ exception handling.
* dwarf2loc.c: Use C++ exception handling.
* dwarf2-frame.c: Use C++ exception handling.
* dwarf2-frame-tailcall.c: Use C++ exception handling.
* dwarf-index-write.c: Use C++ exception handling.
* dwarf-index-cache.c: Use C++ exception handling.
* dtrace-probe.c: Use C++ exception handling.
* disasm-selftests.c: Use C++ exception handling.
* darwin-nat.c: Use C++ exception handling.
* cp-valprint.c: Use C++ exception handling.
* cp-support.c: Use C++ exception handling.
* cp-abi.c: Use C++ exception handling.
* corelow.c: Use C++ exception handling.
* completer.c: Use C++ exception handling.
* compile/compile-object-run.c: Use C++ exception handling.
* compile/compile-object-load.c: Use C++ exception handling.
* compile/compile-cplus-symbols.c: Use C++ exception handling.
* compile/compile-c-symbols.c: Use C++ exception handling.
* common/selftest.c: Use C++ exception handling.
* common/new-op.c: Use C++ exception handling.
* cli/cli-script.c: Use C++ exception handling.
* cli/cli-interp.c: Use C++ exception handling.
* cli/cli-cmds.c: Use C++ exception handling.
* c-varobj.c: Use C++ exception handling.
* btrace.c: Use C++ exception handling.
* breakpoint.c: Use C++ exception handling.
* break-catch-throw.c: Use C++ exception handling.
* arch-utils.c: Use C++ exception handling.
* amd64-tdep.c: Use C++ exception handling.
* ada-valprint.c: Use C++ exception handling.
* ada-typeprint.c: Use C++ exception handling.
* ada-lang.c: Use C++ exception handling.
* aarch64-tdep.c: Use C++ exception handling.
gdb/gdbserver/ChangeLog
2019-04-08 Tom Tromey <tom@tromey.com>
* server.c: Use C++ exception handling.
* linux-low.c: Use C++ exception handling.
* gdbreplay.c: Use C++ exception handling.
Tom Tromey
Andrew Burgess
Xavier Roirand
Tom Tromey
Tom de Vries
Kevin Buettner
Raul Tambre
Philippe Waroquiers
Dilyan Palauzov
Eli Zaretskii
Ali Tamur
Joel Brobecker
Keith Seitz
Sergio Durigan Junior
Alan Hayward
Sandra Loosemore
Simon Marchi
Pedro Alves
Sergei Trofimovich
Leszek Swirski