This changes gdb and gdbserver to use the same calling convention for
the "thread_rec" helper function. Fully merging these is difficult
due to differences in how threads are managed by the enclosing
applications; but sharing a declaration makes it possible for future
shared code to call this method.
gdb/ChangeLog
2020-04-08 Tom Tromey <tromey@adacore.com>
* windows-nat.c (enum thread_disposition_type): Move to
nat/windows-nat.h.
(windows_nat::thread_rec): Rename from thread_rec. No longer
static.
(windows_add_thread, windows_nat_target::fetch_registers)
(windows_nat_target::store_registers, handle_exception)
(windows_nat_target::resume, get_windows_debug_event)
(windows_nat_target::get_tib_address)
(windows_nat_target::thread_name)
(windows_nat_target::thread_alive): Update.
* nat/windows-nat.h (enum thread_disposition_type): Move from
windows-nat.c.
(thread_rec): Declare.
gdbserver/ChangeLog
2020-04-08 Tom Tromey <tromey@adacore.com>
* win32-low.c (windows_nat::thread_rec): Rename from thread_rec.
No longer static. Change parameters.
(child_add_thread, child_fetch_inferior_registers)
(child_store_inferior_registers, win32_resume)
(win32_get_tib_address): Update.
PR gdb/22992 concerns an assertion failure in gdb when debugging a
certain inferior:
int finish_step_over(execution_control_state*): Assertion `ecs->event_thread->control.trap_expected' failed.
Initially the investigation centered on the discovery that gdb was not
suspending other threads when attempting to single-step. This
oversight is corrected in this patch: now, when stepping a thread, gdb
will call SuspendThread on all other threads.
However, the bug persisted even after this change. In particular,
WaitForDebugEvent could see a stop for a thread that was ostensibly
suspended. Our theory of what is happening here is that there are
actually simultaneous breakpoint hits, and the Windows kernel queues
the events, causing the second stop to be reported on a suspended
thread.
In Windows 10 or later gdb could use the DBG_REPLY_LATER flag to
ContinueDebugEvent to request that such events be re-reported later.
However, relying on that did not seem advisable, so this patch instead
arranges to queue such "pending" stops, and then to report them later,
once the step has completed.
In the PR, Pedro pointed out that it's best in this scenario to
implement the stopped_by_sw_breakpoint method, so this patch does this
as well.
gdb/ChangeLog
2020-04-08 Tom Tromey <tromey@adacore.com>
PR gdb/22992
* windows-nat.c (current_event): Update comment.
(last_wait_event, desired_stop_thread_id): New globals.
(struct pending_stop): New.
(pending_stops): New global.
(windows_nat_target) <stopped_by_sw_breakpoint>
<supports_stopped_by_sw_breakpoint>: New methods.
(windows_fetch_one_register): Add assertions. Adjust PC.
(windows_continue): Handle pending stops. Suspend other threads
when stepping. Use last_wait_event
(wait_for_debug_event): New function.
(get_windows_debug_event): Use wait_for_debug_event. Handle
pending stops. Queue spurious stops.
(windows_nat_target::wait): Set stopped_at_software_breakpoint.
(windows_nat_target::kill): Use wait_for_debug_event.
* nat/windows-nat.h (struct windows_thread_info)
<stopped_at_software_breakpoint>: New field.
* nat/windows-nat.c (windows_thread_info::resume): Clear
stopped_at_software_breakpoint.
windows-nat.c:thread_rec accepts an integer parameter whose
interpretation depends on whether it is less than, equal to, or
greater than zero. I found this confusing at times, so this patch
replaces it with an enum instead.
gdb/ChangeLog
2020-04-08 Tom Tromey <tromey@adacore.com>
* windows-nat.c (enum thread_disposition_type): New.
(thread_rec): Replace "get_context" parameter with "disposition";
change type.
(windows_add_thread, windows_nat_target::fetch_registers)
(windows_nat_target::store_registers, handle_exception)
(windows_nat_target::resume, get_windows_debug_event)
(windows_nat_target::get_tib_address)
(windows_nat_target::thread_name)
(windows_nat_target::thread_alive): Update.
This adds "suspend" and "resume" methods to windows_thread_info, and
changes gdb and gdbserver to share this code.
gdb/ChangeLog
2020-04-08 Tom Tromey <tromey@adacore.com>
* windows-nat.c (thread_rec): Use windows_thread_info::suspend.
(windows_continue): Use windows_continue::resume.
* nat/windows-nat.h (struct windows_thread_info) <suspend,
resume>: Declare new methods.
* nat/windows-nat.c: New file.
* configure.nat (NATDEPFILES): Add nat/windows-nat.o when needed.
gdbserver/ChangeLog
2020-04-08 Tom Tromey <tromey@adacore.com>
* win32-low.c (win32_require_context, suspend_one_thread): Use
windows_thread_info::suspend.
(continue_one_thread): Use windows_thread_info::resume.
* configure.srv (srv_tgtobj): Add windows-nat.o when needed.
This changes windows-nat.c to put the Windows thread id into the "lwp"
field of ptid_t, not the "tid" field. This is done for two reasons.
First, ptid.h has this to say:
process_stratum targets that handle threading themselves should
prefer using the ptid.lwp field, leaving the ptid.tid field for any
thread_stratum target that might want to sit on top.
Second, this change brings gdb and gdbserver into sync here, which
makes sharing code simpler.
gdb/ChangeLog
2020-04-08 Tom Tromey <tromey@adacore.com>
* windows-nat.c (windows_add_thread, windows_delete_thread)
(windows_nat_target::fetch_registers)
(windows_nat_target::store_registers, fake_create_process)
(windows_nat_target::resume, windows_nat_target::resume)
(get_windows_debug_event, windows_nat_target::wait)
(windows_nat_target::pid_to_str)
(windows_nat_target::get_tib_address)
(windows_nat_target::get_ada_task_ptid)
(windows_nat_target::thread_name)
(windows_nat_target::thread_alive): Use lwp, not tid.
This changes windows_thread_info::name to be a unique_xmalloc_ptr,
removing some manual memory management.
gdb/ChangeLog
2020-04-08 Tom Tromey <tromey@adacore.com>
* windows-nat.c (handle_exception)
(windows_nat_target::thread_name): Update.
* nat/windows-nat.h (windows_thread_info): Remove destructor.
<name>: Now unique_xmalloc_ptr.
This changes a couple of fields of windows_thread_info to have type
"bool". It also updates the comment of another field, to clarify the
possible values it can hold.
gdb/ChangeLog
2020-04-08 Tom Tromey <tromey@adacore.com>
* windows-nat.c (thread_rec)
(windows_nat_target::fetch_registers): Update.
* nat/windows-nat.h (struct windows_thread_info) <suspended>:
Update comment.
<debug_registers_changed, reload_context>: Now bool.
gdbserver/ChangeLog
2020-04-08 Tom Tromey <tromey@adacore.com>
* win32-i386-low.c (update_debug_registers)
(i386_prepare_to_resume, i386_thread_added): Update.
This adds a constructor, destructor, and member initializers to
windows_thread_info, and changes gdb and gdbserver to use new and
delete.
gdb/ChangeLog
2020-04-08 Tom Tromey <tromey@adacore.com>
* windows-nat.c (windows_add_thread): Use new.
(windows_init_thread_list, windows_delete_thread): Use delete.
(get_windows_debug_event): Update.
* nat/windows-nat.h (struct windows_thread_info): Add constructor,
destructor, and initializers.
gdbserver/ChangeLog
2020-04-08 Tom Tromey <tromey@adacore.com>
* win32-low.c (child_add_thread): Use new.
(delete_thread_info): Use delete.
This introduces a new file, nat/windows-nat.h, which holds the
definition of windows_thread_info. This is now shared between gdb and
gdbserver.
Note that the two implementations different slightly. gdb had a
couple of fields ("name" and "reload_context") that gdbserver did not;
while gdbserver had one field ("base_context") that gdb did not, plus
better comments. The new file preserves all the fields, and the
comments.
gdb/ChangeLog
2020-04-08 Tom Tromey <tromey@adacore.com>
* windows-nat.c (struct windows_thread_info): Remove.
* nat/windows-nat.h: New file.
gdbserver/ChangeLog
2020-04-08 Tom Tromey <tromey@adacore.com>
* win32-low.h (struct windows_thread_info): Remove.
This changes the name of a field in windows_thread_info, bringing gdb
and gdbserver closer into sync.
gdb/ChangeLog
2020-04-08 Tom Tromey <tromey@adacore.com>
* windows-nat.c (struct windows_thread_info) <tid>: Rename from "id".
(thread_rec, windows_add_thread, windows_delete_thread)
(windows_continue): Update.
This changes windows_thread_info to remove the "next" field, replacing
the linked list of threads with a vector. This is a prerequisite to
sharing this structure with gdbserver, which manages threads
differently.
gdb/ChangeLog
2020-04-08 Tom Tromey <tromey@adacore.com>
* windows-nat.c (struct windows_thread_info): Remove typedef.
(thread_head): Remove.
(thread_list): New global.
(thread_rec, windows_add_thread, windows_init_thread_list)
(windows_delete_thread, windows_continue): Update.
The signal enumeration in windows-tdep.c is defined differently whether
it is compiled on Cygwin or not. This is problematic, since the code in
tdep files is not supposed to be influenced by the host platform (the
platform GDB itself runs on).
This makes a difference in windows_gdb_signal_to_target. An obvious
example of clash is SIGABRT. Let's pretend we are cross-debugging a
Cygwin process from a MinGW (non-Cygwin Windows) GDB. If GDB needs to
translate the gdb signal number GDB_SIGNAL_ABRT into a target
equivalent, it would obtain the MinGW number (22), despite the target
being a Cygwin process. Conversely, if debugging a MinGW process from a
Cygwin-hosted GDB, GDB_SIGNAL_ABRT would be converted to a Cygwin signal
number (6) despite the target being a MinGW process. This is wrong,
since we want the result to depend on the target's platform, not GDB's
platform.
This known flaw was accepted because at the time we had a single OS ABI
(called Cygwin) for all Windows binaries (Cygwin ones and non-Cygwin
ones). This limitation is now lifted, as we now have separate Windows
and Cygwin OS ABIs. This means we are able to detect at runtime whether
the binary we are debugging is a Cygwin one or non-Cygwin one.
This patch splits the signal enum in two, one for the MinGW flavors and
one for Cygwin, removing all the ifdefs that made it depend on the host
platform. It then makes two separate gdb_signal_to_target gdbarch
methods, that are used according to the OS ABI selected at runtime.
There is a bit of re-shuffling needed in how the gdbarch'es are
initialized, but nothing major.
gdb/ChangeLog:
* windows-tdep.h (windows_init_abi): Add comment.
(cygwin_init_abi): New declaration.
* windows-tdep.c: Split signal enumeration in two, one for
Windows and one for Cygwin.
(windows_gdb_signal_to_target): Only deal with signal of the
Windows OS ABI.
(cygwin_gdb_signal_to_target): New function.
(windows_init_abi): Rename to windows_init_abi_common, don't set
gdb_signal_to_target gdbarch method. Add new new function with
this name.
(cygwin_init_abi): New function.
* amd64-windows-tdep.c (amd64_windows_init_abi_common): Add
comment. Don't call windows_init_abi.
(amd64_windows_init_abi): Add comment, call windows_init_abi.
(amd64_cygwin_init_abi): Add comment, call cygwin_init_abi.
* i386-windows-tdep.c (i386_windows_init_abi): Rename to
i386_windows_init_abi_common, don't call windows_init_abi. Add
a new function of this name.
(i386_cygwin_init_abi): New function.
(_initialize_i386_windows_tdep): Bind i386_cygwin_init_abi to
OS ABI Cygwin.
I noticed this was unused, so remove it.
gdb/ChangeLog:
* dwarf2/read.c (read_gdb_index_from_buffer): Remove objfile
parameter.c.
(dwarf2_read_gdb_index): Update.
The test-case gdb.dwarf2/imported-unit.exp contains a test testing partial
symbols, so when we run the test-case using either target board readnow,
cc-with-gdb-index or cc-with-debug-names, we run into:
...
FAIL: gdb.dwarf2/imported-unit.exp: no static partial symbols in importing unit
...
Fix this by marking the test unsupported if there are no partial symbols.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-04-08 Tom de Vries <tdevries@suse.de>
* lib/gdb.exp (psymtabs_p): New proc.
* gdb.dwarf2/imported-unit.exp: Mark "no static partial symbols in
importing unit" unsupported if there are no partial symbols.
When running test-case gdb.ada/call_pn.exp with target board
unix/-flto/-O0/-flto-partition=none/-ffat-lto-objects, we run into:
...
(gdb) print last_node_id^M
Multiple matches for last_node_id^M
[0] cancel^M
[1] pck.last_node_id at gdb/testsuite/gdb.ada/call_pn/pck.adb:17^M
[2] pck.last_node_id at gdb/testsuite/gdb.ada/call_pn/foo.adb:17^M
> FAIL: gdb.ada/call_pn.exp: print last_node_id after calling pn (timeout)
...
This failure is due to a gcc bug that declares two instead of one symbols,
filed as PR gcc/94469.
Add an xfail at this test. Also add a similar xfail at an earlier test, that
only triggers with -readnow. Stabilize test results by making sure the
earlier xfail is always triggered, using "maint expand-symtabs".
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-04-08 Tom de Vries <tdevries@suse.de>
PR testsuite/25760
* gdb.ada/call_pn.exp: Call "maint expand-symtabs". Add xfails.
GDB throws the error 'Unrecognized DWARF opcode 0x02 at 2' when running
Info address command with the executable file compiled with -gdwarf-5 flag.
This patch fixes this error.
Tested by running the testsuite before and after the patch and there is
no increase in the number of test cases that fails. Tested with both
-gdwarf-4 and -gdwarf-5 flags. Also tested -gslit-dwarf along with
-gdwarf-4 as well as -gdwarf-5 flags. Used clang version 10.0.0.
This is the test case used-
void bar(int arr[], int l, int m, int r) {
int i, j, k, n1= m - l + 1, n2= r - m, L[n1], R[n2];
for (i = 0; i < n1; i++)
L[i] = arr[l + i];
for (j = 0; j < n2; j++)
R[j] = arr[m + 1+ j];
}
int main()
{
int arr[] = {12, 11};
bar(arr,0,1,2);
return 0;
}
clang -gdwarf-5 test.c -o test.out
gdb test.out
gdb> start
gdb> step
gdb> step
gdb> step
gdb> step
gdb> info address L
Symbol "L" is multi-location:
Range 0x7c04007902bc5084-0x67fb876440700: a complex DWARF expression:
0: DW_OP_breg16 1 [$rip]
Unrecognized DWARF opcode 0x02 at 2
gdb/ChangeLog:
2020-04-07 Nitika Achra <Nitika.Achra@amd.com>
* dwarf2/loc.c (loclist_describe_location): Call the function decode_debug_loclists_
addresses if DWARF version is 5 or more because DW_LLE_start* or DW_LLE_offset_pair
with DW_LLE_base_addressx are being emitted in DWARFv5.
Add the newly added kind DW_LOC_OFFSET_PAIR also.
The length of location description is an unsigned ULEB integer in DWARFv5 instead of
unsigned integer.
GDB throws the error '<error reading variable: dwarf2_find_location_
expression: Corrupted DWARF expression.>' while printing the variable
value with executable file compiled with -gdwarf-5 and -gdwarf-split
flags. This is because DW_LLE_start* or DW_LLE_offset_pair with
DW_LLE_base_addressx are being emitted in DWARFv5 location list instead of
DW_LLE_GNU*. This patch fixes this error.
Tested by running the testsuite before and after the patch and there is no
increase in the number of test cases that fails. Tested with both -gdwarf-4
and -gdwarf-5 flags. Also tested -gslit-dwarf along with -gdwarf-4 as well as
-gdwarf-5 flags. Used clang version 10.0.0. This is the test case used-
void bar(int arr[], int l, int m, int r) {
int i, j, k, n1= m - l + 1, n2= r - m, L[n1], R[n2];
for (i = 0; i < n1; i++)
L[i] = arr[l + i];
for (j = 0; j < n2; j++)
R[j] = arr[m + 1+ j];
}
int main()
{
int arr[] = {12, 11};
bar(arr,0,1,2);
return 0;
}
clang -gdwarf-5 -gsplit-dwarf test.c -o test.out
gdb test.out
gdb> start
gdb> step
gdb> step
gdb> step
gdb> step
gdb> p L[0]
dwarf2_find_location_expression: Corrupted DWARF expression.
gdb/ChangeLog:
2020-04-07 Nitika Achra <Nitika.Achra@amd.com>
* dwarf2/loc.c (enum debug_loc_kind): Add a new kind DEBUG_LOC_OFFSET_PAIR.
(dwarf2_find_location_expression): Call the function decode_debug_loclists_
addresses if DWARF version is 5 or more. DW_LLE_start* or DW_LLE_offset_pair
with DW_LLE_base_addressx are being emitted in DWARFv5 instead of DW_LLE_GNU*.
Add applicable base address if the entry is DW_LLE_offset_pair from DWO.
(decode_debug_loclists_addresses): Return DEBUG_LOC_OFFSET_PAIR instead of
DEBUG_LOC_START_END in case of DW_LLE_offset_pair.
I noticed that only one of the two dwarf2_psymtab constructors are
actually used. The one that is used accepts an `addr` parameter (the
base text offset), but its sole caller passes a constant, 0. We want to
keep calling the three-arguments standard_psymtab constructor form,
however, since it differs from the two-arguments form in subtle ways.
Also, I believe the dwarf2_per_cu_data associated to the created
dwarf2_psymtab should be passed as a constructor argument. That will
help me in a future patchset, to convince myself that the `per_cu_data`
field can't be NULL.
So this patch:
- Removes the two-parameters constructor of dwarf2_psymtab, as it is
unused.
- Removes the `addr` parameter of the remaining constructor, passing 0
directly to the base class' constructor.
- Adds a `per_cu` parameter, to assign the `per_cu_data` field at
construction.
gdb/ChangeLog:
* dwarf2/read.h (struct dwarf2_psymtab): Remove two-parameters
constructor. Remove `addr` parameter from other constructor and
add `per_cu` parameter.
* dwarf2/read.c (create_partial_symtab): Update.
Consider the test-case added in this patch, with resulting dwarf (related to
variable aaa):
...
<0><d2>: Abbrev Number: 2 (DW_TAG_partial_unit)
<1><eb>: Abbrev Number: 4 (DW_TAG_variable)
<ec> DW_AT_name : aaa
<f0> DW_AT_type : <0xe4>
<f4> DW_AT_const_value : 1
<0><10c>: Abbrev Number: 2 (DW_TAG_compile_unit)
<10e> DW_AT_name : <artificial>
<1><11b>: Abbrev Number: 3 (DW_TAG_variable)
<11c> DW_AT_abstract_origin: <0xeb>
...
When running the test-case, we see:
...
(gdb) p aaa^M
No symbol "aaa" in current context.^M
(gdb) FAIL: gdb.dwarf2/imported-unit-abstract-const-value.exp: p aaa
...
while with target board readnow.exp, we have:
...
(gdb) p aaa^M
$1 = 1^M
...
This is due to the fact that there's no aaa symbol in the partial symtabs:
...
Partial symtab for source file <artificial>@0x101 (object 0x351cf40)^M
...
Global partial symbols:^M
`main', function, 0x4004a7^M
^M
...
which is due to the fact that when attempting to add the symbol corresponding
to DIE 0x11b in add_partial_symbol:
...
(gdb) p /x pdi->sect_off
$4 = 0x11b
(gdb) p pdi.has_const_value
$5 = 0
...
it seems the DW_AT_const_value was not inherited from DIE 0xeb, and
consequently we leave without adding a partial symbol.
Fix this by making sure that partial_die_info::has_const_value is inherited
in partial_die_info::fixup.
Build and reg-tested on x86_64-linux.
Tested test-case with target boards readnow, cc-with-gdb-index and
cc-with-debug-names. The "print aaa" test fails for cc-with-gdb-index, that's
PR25791, the test passes when applying the corresponding proposed patch.
gdb/ChangeLog:
2020-04-07 Tom de Vries <tdevries@suse.de>
PR symtab/25796
* dwarf2/read.c (can_have_DW_AT_const_value_p): New function.
(partial_die_info::fixup): Inherit has_const_value.
gdb/testsuite/ChangeLog:
2020-04-07 Tom de Vries <tdevries@suse.de>
PR symtab/25796
* gdb.dwarf2/imported-unit-abstract-const-value.exp: New file.
Consider test-case inline.c, containing an inline function foo:
...
static inline int foo (void) { return 0; }
int main (void) { return foo (); }
...
And the test-case compiled with -O2 and debug info:
...
$ gcc -g inline.c -O2
...
This results in a DWARF entry for foo without pc info:
...
<1><114>: Abbrev Number: 4 (DW_TAG_subprogram)
<115> DW_AT_name : foo
<119> DW_AT_decl_file : 1
<11a> DW_AT_decl_line : 2
<11b> DW_AT_prototyped : 1
<11b> DW_AT_type : <0x10d>
<11f> DW_AT_inline : 3 (declared as inline and inlined)
...
When loading the executable in gdb, we create a partial symbol for foo, but
after expansion into a full symbol table no actual symbol is created,
resulting in a maint check-psymtab failure:
...
(gdb) maint check-psymtab
Static symbol `foo' only found in inline.c psymtab
...
Fix this by skipping this type of partial symbol during the check.
Note that we're not fixing this by not creating the partial symbol, because
this breaks setting a breakpoint on an inlined inline function in a CU for
which the partial symtab has not been expanded (test-case
gdb.dwarf2/break-inline-psymtab.exp).
Tested on x86_64-linux.
gdb/ChangeLog:
2020-04-07 Tom de Vries <tdevries@suse.de>
* psymtab.c (maintenance_check_psymtabs): Skip static LOC_BLOCK
symbols without address.
gdb/testsuite/ChangeLog:
2020-04-07 Tom de Vries <tdevries@suse.de>
* gdb.base/check-psymtab.c: New test.
* gdb.base/check-psymtab.exp: New file.
Use sysctl(3) as the portable interface to prompt NetBSD threads on
all supported NetBSD versions. In future newer versions could switch
to PT_LWPSTATUS ptrace(2) API that will be supported on NetBSD 10.0
and newer.
Implement as part of nbsd_nat_target:
- thread_name() - read descriptive thread name
- thread_alive() - check whether a thread is alive
- post_attach() - updates the list of threads after attach
- update_thread_list() - updates the list of threads
- pid_to_str() - translates ptid to a descriptive string
There are two local static functions:
- nbsd_thread_lister() - generic LWP lister for a specified pid
- nbsd_add_threads() - utility to update the list of threads
Now, GDB on NetBSD can attach to a multithreaded process, spawn
a multithreaded process, list threads, print their LWP+PID numbers
and descriptive thread names.
gdb/ChangeLog:
* nbsd-nat.h (struct thread_info): Add forward declaration.
(nbsd_nat_target::thread_alive): Add.
(nbsd_nat_target::thread_name): Likewise.
(nbsd_nat_target::update_thread_list): Likewise.
(update_thread_list::post_attach): Likewise.
(post_attach::pid_to_str): Likewise.
* nbsd-nat.c: Include "gdbthread.h" and "inferior.h".
(nbsd_thread_lister): Add.
(nbsd_nat_target::thread_alive): Likewise.
(nbsd_nat_target::thread_name): Likewise.
(nbsd_add_threads): Likewise.
(update_thread_list::post_attach): Likewise.
(nbsd_nat_target::update_thread_list): Likewise.
(post_attach::pid_to_str): Likewise.
When I updated the Ada variant-printing code to be value-based, I
neglected a couple of issues. First, print_variant_part must first
extract the variant field before finding the active component; second,
print_field_values should pass in the field value as the outer value
when recursing.
This patch fixes both of these issues.
gdb/ChangeLog
2020-04-06 Tom Tromey <tromey@adacore.com>
* ada-valprint.c (print_variant_part): Extract the variant field.
(print_field_values): Use the field as the outer value when
recursing.
gdb/testsuite/ChangeLog
2020-04-06 Tom Tromey <tromey@adacore.com>
* gdb.ada/variant-record/proc.adb: New file.
* gdb.ada/variant-record/value.adb: New file.
* gdb.ada/variant-record/value.s: New file.
* gdb.ada/variant-record.exp: New file.
A recent patch caused some build failures in NetBSD tdep files. I saw
this failure in my --enable-target=all build.
This patch fixes the problems. Tested by rebuilding.
I am going to check this in.
gdb/ChangeLog
2020-04-06 Tom Tromey <tromey@adacore.com>
* sh-nbsd-tdep.c: Include nbsd-tdep.h.
* ppc-nbsd-tdep.c: Include nbsd-tdep.h.
* mips-nbsd-tdep.c (mipsnbsd_init_abi): Add missing ";".
* arm-nbsd-tdep.c: Include nbsd-tdep.h.
* hppa-nbsd-tdep.c: Include nbsd-tdep.h.
It turns out there was one more bug in the earlier complex series:
read_base_type could cause an assertion failure on some platforms. I
found this running the AdaCore internal test suite, but you can also
see it by running gdb's "gdb.cp" tests for x86 (not x86-64).
In particular, the DW_ATE_complex_float case calls
dwarf2_init_complex_target_type, which calls dwarf2_init_float_type,
which can return a type using TYPE_CODE_ERROR.
This patch changes the DWARF reader to handle this case, the same way
that the f-lang.c patch did. Perhaps init_complex_type really should
be changed to allow TYPE_CODE_ERROR? I was not sure.
Tested on x86-64 Fedora 30, using an x86 build. I'm checking this in.
gdb/ChangeLog
2020-04-06 Tom Tromey <tromey@adacore.com>
* dwarf2/read.c (read_base_type) <DW_ATE_complex_float>: Handle
TYPE_CODE_ERROR.
For this enum:
typedef unsigned char byte;
enum byte_enum : byte
{
byte_val = 128
};
The unsigned attribute is not set:
(gdb) p byte_val
$1 = -128
That's because it uses the attributes of the 'byte' typedef for the enum.
So this changes it to use the attributes of the underlying 'unsigned char'
instead.
gdb/ChangeLog:
2020-04-03 Hannes Domani <ssbssa@yahoo.de>
PR gdb/25325
* dwarf2/read.c (read_enumeration_type): Fix typed enum attributes.
gdb/testsuite/ChangeLog:
2020-04-03 Hannes Domani <ssbssa@yahoo.de>
PR gdb/25325
* gdb.cp/typed-enum.cc: New test.
* gdb.cp/typed-enum.exp: New file.
While debugging another issue, I noticed that disassembling a DWARF
expression using DW_OP_const_type did not work.
disassemble_dwarf_expression was not properly decoding this operation.
This patch fixes the problem. Tested by re-debugging gdb.
I didn't write a test case because that seemed like overkill for
what's essentially a maintainer's helper.
The expression evaluator does decode this properly, so no other change
was needed.
gdb/ChangeLog
2020-04-03 Tom Tromey <tromey@adacore.com>
* dwarf2/loc.c (disassemble_dwarf_expression) <DW_OP_const_type>:
Read constant block.
The function is_linked_with_cygwin_dll currently uses
gdb_bfd_map_section to get some section contents. This is not ideal
because that memory, which is only used in this function, can't be
released. Instead, it was suggested to use
bfd_get_full_section_contents.
However, bfd_get_full_section_contents returns a newly allocated buffer,
which is not very practical to use with C++ automatic memory management
constructs. I decided to make gdb_bfd_get_full_section_contents, a
small alternative to bfd_get_full_section_contents. It is a small
wrapper around bfd_get_section_contents which returns the full contents
of the section in a gdb::byte_vector.
gdb_bfd_get_full_section_contents could be used at many places that
already allocate a vector of the size of the section and then call
bfd_get_section_contents. I think these call sites can be updated over
time.
gdb/ChangeLog:
* gdb_bfd.h: Include gdbsupport/byte-vector.h.
(gdb_bfd_get_full_section_contents): New declaration.
* gdb_bfd.c (gdb_bfd_get_full_section_contents): New function.
* windows-tdep.c (is_linked_with_cygwin_dll): Use
gdb_bfd_get_full_section_contents.
There are a few spots using the pattern:
if (condition)
internal_error (__FILE__, __LINE__,
_("failed internal consistency check"));
The message brings no value, since it's pretty the description of a
failed assertion. Replace a few of these that are obvious with
gdb_assert.
gdb/ChangeLog:
* exec.c (build_section_table): Replace internal_error with
gdb_assert.
(section_table_xfer_memory_partial): Likewise.
* mdebugread.c (parse_partial_symbols): Likewise.
* psymtab.c (lookup_partial_symbol): Likewise.
* utils.c (wrap_here): Likewise.
Tankut Baris Aktemur pointed out that the recent series to change how
complex types are handled introduced a regression.
This assert in init_complex_type was firing:
gdb_assert (TYPE_CODE (target_type) == TYPE_CODE_INT
|| TYPE_CODE (target_type) == TYPE_CODE_FLT);
The problem was that f-lang.c could call init_complex_type with a type
whose code was TYPE_CODE_ERROR.
It seemed best to me to fix this in f-lang.c, rather than to change
init_complex_type to accept error types.
Tested on x86-64 Fedora 30. I'm checking this in.
gdb/ChangeLog
2020-04-02 Tom Tromey <tromey@adacore.com>
* f-lang.c (build_fortran_types): Use arch_type to initialize
builtin_complex_s32 in the TYPE_CODE_ERROR case.
While profiling the DWARF reader, I noticed that
partial_die_info::read creates a vector to store attributes. However,
the vector is not needed, as this code only processes a single
attribute at a time.
This patch removes the vector. On my machine, this improves the time
of "./gdb ./gdb" from 2.22 seconds to 1.92 seconds (mean times over 10
runs).
Note that the attribute is initialized by read_attribute, so it does
not need any special initialization. Avoiding this also improves
performance a bit.
Tested on x86-64 Fedora 30. I'm checking this in.
gdb/ChangeLog
2020-04-02 Tom Tromey <tromey@adacore.com>
* dwarf2/read.c (partial_die_info::read): Do not create a vector
of attributes.
In this commit:
commit 8c95582da8
Date: Mon Dec 30 21:04:51 2019 +0000
gdb: Add support for tracking the DWARF line table is-stmt field
A change was made in buildsym_compunit::record_line to remove
duplicate line table entries in some cases. This was an invalid
change, as these duplicate line table entries are used in _some_ cases
as part of prologue detection (see skip_prologue_using_sal).
It might be possible to identify those line table entries that are
required by skip_prologue_using_sal and only keep those duplicates
around, however, I have not done this here. The original duplicate
removal was done because (a) it was easy to implement, and (b) it
seemed obviously harmless.
As (b) is now known to be false, and implementation would be more
complex, and so (a) is also false. As such, it seems better to keep
all duplicates until an actual reason presents itself for why we
should remove any.
The original regression was spotted on RISC-V, which makes use of
skip_prologue_using_sal as part of riscv_skip_prologue. Originally I
created the test gdb.dwarf2/dw2-inline-small-func.exp, however, this
test will not compile on RISC-V as this target doesn't support
.uleb128 or .sleb128 assembler directives containing complex
expressions. As a result I added the gdb.opt/inline-small-func.exp
test, which exposes the bug on RISC-V, but obviously depends on the
compiler to produce specific DWARF information in order to expose the
bug. Still this test does ensure we always get the desired result,
even if the DWARF changes.
Originally the gdb.dwarf2/dw2-inline-small-func.exp test passed on
x86-64 even with the duplicate line table entries incorrectly
removed. The reason for this is that when a compilation unit doesn't
have a 'producer' string then skip_prologue_using_sal is not used,
instead the prologue is always skipped using analysis of the assembler
code.
However, for Clang on x86-64 skip_prologue_using_sal is used, so I
modified the gdb.dwarf2/dw2-inline-small-func.exp test to include a
'producer' string that names the Clang compiler. With this done the
test would fail on x86-64.
One thing to note is that the gdb.opt/inline-small-func.exp test might
fail on some targets. For example, if we compare sparc to risc-v by
looking at sparc32_skip_prologue we see that this function doesn't use
skip_prologue_using_sal, but instead uses find_pc_partial_function
directly. I don't know the full history behind why the code is like
it is, but it feels like sparc32_skip_prologue is an attempt to
duplicate some of the functionality of skip_prologue_using_sal, but
without all of the special cases. If this is true then the new test
could easily fail on this target, this would suggest that sparc should
consider switching to use skip_prologue_using_sal like risc-v does.
gdb/ChangeLog:
* buildsym.c (buildsym_compunit::record_line): Remove
deduplication code.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/dw2-inline-small-func-lbls.c: New file.
* gdb.dwarf2/dw2-inline-small-func.c: New file.
* gdb.dwarf2/dw2-inline-small-func.exp: New file.
* gdb.dwarf2/dw2-inline-small-func.h: New file.
* gdb.opt/inline-small-func.c: New file.
* gdb.opt/inline-small-func.exp: New file.
* gdb.opt/inline-small-func.h: New file.
Extend the Dejagnu DWARF compiler to support DW_LNS_set_file opcode.
This will be used in a later commit. There should be no change in the
testsuite after this commit.
gdb/testsuite/ChangeLog:
* lib/dwarf.exp (Dwarf::lines::program::DW_LNS_set_file): New
function.
When using the Dejagnu DWARF compiler tests will often use the
function_range helper function to extract the extents of a function.
If the plan is to compiler the file with non-default compiler flags
then we must pass those same compiler flags through to the
function_range helper function.
This will be used in a later commit, there should be no change in the
testsuite behaviour after this commit.
gdb/testsuite/ChangeLog:
* lib/dwarf.exp (function_range): Allow compiler options to be
specified.
In test-case gdb.dwarf2/break-inline-psymtab.exp we use O2 to enable inlining
of bar into foo in break-inline-psymtab-2.c.
Instead, enforce inlining using __attribute__((always_inline)), to avoid any
optimization-related test issues.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-04-02 Tom de Vries <tdevries@suse.de>
* gdb.dwarf2/break-inline-psymtab-2.c (bar): Add
__attribute__((always_inline)).
* gdb.dwarf2/break-inline-psymtab.exp: Don't use -O2.
While running test-case gdb.multi/multi-target.exp, I observed a silent
timeout related to "monitor exit".
By making the timeout explicit in an expect clause in gdbserver_gdb_exit:
...
+ timeout {
+ warning "Timed out waiting for EOF in server after $monitor_exit"
+ }
...
we get in the log:
...
monitor exit^M
"monitor" command not supported by this target.^M
(gdb) WARNING: Timed out waiting for EOF in server after monitor exit
...
What happens is the following:
- the inferior 5 is selected
- a breakpoint is set in inferior 1
- the breakpoint triggers and we switch to inferior 1
- setup is called by test_continue, which calls clean_restart, which calls
gdbserver_gdb_exit (due to load_lib gdbserver-support.exp)
- gdbserver_gdb_exit issues "monitor exit"
- gdb responds with "not supported by this target" because inferior 1 is
native
Fix this by keeping a list of server_spawn_id, and cleaning those up before
calling gdbserver_gdb_exit.
This reduces testing time from 1m22s to 32s.
gdb/testsuite/ChangeLog:
2020-04-02 Tom de Vries <tdevries@suse.de>
* lib/gdbserver-support.exp (gdbserver_exit): Factor out of ...
(gdbserver_gdb_exit): ... here. Add timeout warning.
* gdb.multi/multi-target.exp (server_spawn_ids): New global var.
(connect_target_extended_remote): Append new server_spawn_id to
server_spawn_ids.
(cleanup): New proc.
(setup, <toplevel>): Call cleanup.
When running test-case gdb.ada/access_to_packed_array we have:
...
(gdb) print pack.a^M
$1 = (0 => 1, 2, 3, 4, 5, 6, 7, 8, 9, 10)^M
...
but with target board readnow.exp, we have instead:
...
(gdb) print pack.a^M
'pack.a' has unknown type; cast it to its declared type^M
...
The symbol is normally found by the map_matching_symbols call in
ada-lang.c:add_nonlocal_symbols:
...
for (objfile *objfile : current_program_space->objfiles ())
{
data.objfile = objfile;
objfile->sf->qf->map_matching_symbols (objfile, lookup_name,
domain, global, callback,
(is_wild_match
? NULL : compare_names));
...
which maps onto psym_map_matching_symbols.
Function psym_map_matching_symbols iterates over all the partial symtabs,
and:
- if not expanded, searches in the partial symtab:
- if not found, continues to the next
- if found, expands into full symtab
- searches in the full symtab
However, with -readnow the call maps onto dw2_map_matching_symbols instead,
which is unimplemented, and consequently no symbol is found.
Fix this by detecting -readnow in dw2_map_matching_symbols, and handling that
appropriately given that partial symtabs are not present, and full symtabs
are: iterate over all the symtabs and search them.
Tested on x86_64-linux, with native and target board -readnow.
This removes 217 FAILs with board -readnow.
gdb/ChangeLog:
2020-04-02 Tom de Vries <tdevries@suse.de>
PR ada/24671
* dwarf2/read.c (dw2_map_matching_symbols): Handle -readnow.
When language is set to auto, part of loading an executable is to update the
language accordingly. This is implemented by set_initial_language.
The implementation of set_initial_language works as follows:
- check if any objfile in the progspace has name_of_main/language_of_main
set, and if so, use the first one found. [ This is what you get f.i. when
using dwarf with DW_AT_main_subprogram. ]
- otherwise, check for known names in the minimal symbols, and either:
- use the associated language if any (f.i. for ada), or
- lookup the symbol in the symtab for the name and use the symbol language
(f.i. for c/c++).
The symbol lookup can be slow though.
In the case of the cc1 binary from PR23710 comment 1, getting to the initial
prompt takes ~8s:
...
$ time.sh gdb cc1 -batch -ex "show language"
The current source language is "auto; currently c++".
maxmem: 1272260
real: 8.05
user: 7.73
system: 0.38
...
but if we skip guessing the initial language by setting it instead, it takes
only ~4s:
...
$ time.sh gdb -iex "set language c++" cc1 -batch -ex "show language"
The current source language is "c++".
maxmem: 498272
real: 3.99
user: 3.90
system: 0.15
...
In both cases, we load the partial symbols for the executable, but in the
first case only we also do a lookup of main, which causes the corresponding
partial symtab to be expanded into a full symtab.
Ideally, we'd like to get the language of the symbol without triggering
expansion into a full symtab, and get the speedup without having to set the
language manually.
There's a related fixme in the header comment of set_initial_language:
...
/* Set the initial language.
FIXME: A better solution would be to record the language in the
psymtab when reading partial symbols, and then use it (if known) to
set the language. This would be a win for formats that encode the
language in an easily discoverable place, such as DWARF. For
stabs, we can jump through hoops looking for specially named
symbols or try to intuit the language from the specific type of
stabs we find, but we can't do that until later when we read in
full symbols. */
void
set_initial_language (void)
...
Since we're already tracking the language of partial symbols, use this to set
the language for the main symbol.
Note that this search in partial symbol tables is not guaranteed to yield the
same result as the lookup_symbol_in_language call currently done in
set_initial_language.
Build and reg-tested on x86_64-linux.
gdb/ChangeLog:
2020-04-02 Tom de Vries <tdevries@suse.de>
* dwarf2/read.c (dwarf2_gdb_index_functions,
dwarf2_debug_names_functions): Init lookup_global_symbol_language with
NULL.
* psymtab.c (psym_lookup_global_symbol_language): New function.
(psym_functions): Init psym_lookup_global_symbol_language with
psym_lookup_global_symbol_language.
* symfile-debug.c (debug_sym_quick_functions): Init
lookup_global_symbol_language with NULL.
* symfile.c (set_initial_language): Remove fixme comment.
* symfile.h (struct quick_symbol_functions): Add
lookup_global_symbol_language.
* symtab.c (find_quick_global_symbol_language): New function.
(find_main_name): Use find_quick_global_symbol_language.
gdb/testsuite/ChangeLog:
2020-04-02 Tom de Vries <tdevries@suse.de>
* gdb.base/main-psymtab.exp: New file.
Since commit 981c08ce72 "Change how complex types are printed in C", we see
these FAILs:
...
FAIL: gdb.fortran/mixed-lang-stack.exp: lang=auto: info args in frame #6
FAIL: gdb.fortran/mixed-lang-stack.exp: lang=c: info args in frame #6
FAIL: gdb.fortran/mixed-lang-stack.exp: lang=c: info args in frame #7
FAIL: gdb.fortran/mixed-lang-stack.exp: lang=c++: info args in frame #6
FAIL: gdb.fortran/mixed-lang-stack.exp: lang=c++: info args in frame #7
...
The problem is that printing of complex types has changed from:
...
d = 4 + 5 * I
...
to:
...
d = 4 + 5i
...
but the test-case still checks for the old printing style.
Fix this by updating the test-case to check for the new style.
gdb/testsuite/ChangeLog:
2020-04-02 Tom de Vries <tdevries@suse.de>
* gdb.fortran/mixed-lang-stack.exp: Accept new complex printing style.
Additionally do not completely remove symbols
at the same PC than the end marker, instead
make them non-is-stmt breakpoints.
2020-04-01 Bernd Edlinger <bernd.edlinger@hotmail.de>
* buildsym.c (record_line): Fix undefined behavior and preserve
lines at eof.
Christian pointed out that the value_literal_complex was still a bit
weird; this patch rewrites it and moves it to value.h.
gdb/ChangeLog
2020-04-01 Tom Tromey <tom@tromey.com>
* value.h (value_literal_complex): Add comment.
* valops.c (value_literal_complex): Refer to value.h.
This changes the C parser to add support for complex types in casts.
gdb/ChangeLog
2020-04-01 Tom Tromey <tom@tromey.com>
* c-exp.y (FLOAT_KEYWORD, COMPLEX): New tokens.
(scalar_type): New rule, from typebase.
(typebase): Use scalar_type. Recognize complex types.
(field_name): Handle FLOAT_KEYWORD.
(ident_tokens): Add _Complex and __complex__.
gdb/testsuite/ChangeLog
2020-04-01 Tom Tromey <tom@tromey.com>
* gdb.base/complex-parts.exp: Add type tests.
This adds support for complex arithmetic to gdb. Now something like
"print 23 + 7i" will work.
Addition, subtraction, multiplication, division, and equality testing
are supported binary operations.
Unary +, negation, and complement are supported. Following GCC, the ~
operator computes the complex conjugate.
gdb/ChangeLog
2020-04-01 Tom Tromey <tom@tromey.com>
PR exp/25299:
* valarith.c (promotion_type, complex_binop): New functions.
(scalar_binop): Handle complex numbers. Use promotion_type.
(value_pos, value_neg, value_complement): Handle complex numbers.
gdb/testsuite/ChangeLog
2020-04-01 Tom Tromey <tom@tromey.com>
* gdb.base/complex-parts.exp: Add arithmetic tests.
This changes the C parser to allow complex constants. Now something
like "print 23i" will work.
There are no tests in this patch; they come later.
gdb/ChangeLog
2020-04-01 Tom Tromey <tom@tromey.com>
* c-exp.y (COMPLEX_INT, COMPLEX_FLOAT): New tokens.
(exp) <COMPLEX_INT, COMPLEX_FLOAT>: New rules.
(parse_number): Handle complex numbers.
GCC accepts the "i" suffix for complex numbers. I think this is nicer
to read than the current output, so this patch changes the C code to
print complex numbers this way.
gdb/ChangeLog
2020-04-01 Tom Tromey <tom@tromey.com>
* c-valprint.c (c_decorations): Change complex suffix to "i".
gdb/testsuite/ChangeLog
2020-04-01 Tom Tromey <tom@tromey.com>
* gdb.compile/compile.exp: Update.
* gdb.compile/compile-cplus.exp: Update.
* gdb.base/varargs.exp: Update.
* gdb.base/floatn.exp: Update.
* gdb.base/endianity.exp: Update.
* gdb.base/callfuncs.exp (do_function_calls): Update.
* gdb.base/funcargs.exp (complex_args, complex_integral_args)
(complex_float_integral_args): Update.
* gdb.base/complex.exp: Update.
* gdb.base/complex-parts.exp: Update.
This introduces two new functions that make it simpler to access the
components of a complex number.
gdb/ChangeLog
2020-04-01 Tom Tromey <tom@tromey.com>
* valprint.c (generic_value_print_complex): Use accessors.
* value.h (value_real_part, value_imaginary_part): Declare.
* valops.c (value_real_part, value_imaginary_part): New
functions.
* value.c (creal_internal_fn, cimag_internal_fn): Use accessors.
This patch changes how complex types are created. init_complex_type
and arch_complex_type are unified, and complex types are reused, by
attaching them to the underlying scalar type.
gdb/ChangeLog
2020-04-01 Tom Tromey <tom@tromey.com>
* stabsread.c (rs6000_builtin_type, read_sun_floating_type)
(read_range_type): Update.
* mdebugread.c (basic_type): Update.
* go-lang.c (build_go_types): Use init_complex_type.
* gdbtypes.h (struct main_type) <complex_type>: New member.
(init_complex_type): Update.
(arch_complex_type): Don't declare.
* gdbtypes.c (init_complex_type): Remove "objfile" parameter.
Make name if none given. Use alloc_type_copy. Look for cached
complex type.
(arch_complex_type): Remove.
(gdbtypes_post_init): Use init_complex_type.
* f-lang.c (build_fortran_types): Use init_complex_type.
* dwarf2/read.c (read_base_type): Update.
* d-lang.c (build_d_types): Use init_complex_type.
* ctfread.c (read_base_type): Update.
I wanted to run the gdb.rust tests against older versions of the Rust
compiler, to ensure that changes I am making don't break debugging
when using older compilers.
However, this did not work because simple.rs now uses unchecked
unions, which were only added in Rust 1.19.
This patch splits the union code into its own file, so that simple.exp
can continue to work. I tested this with selected rust versions back
to 1.12.
gdb/testsuite/ChangeLog
2020-04-01 Tom Tromey <tromey@adacore.com>
* gdb.rust/union.rs: New file.
* gdb.rust/union.exp: New file.
* gdb.rust/simple.rs (Union, Union2): Move to union.rs.
(main): Update.
* gdb.rust/simple.exp: Move union tests to union.exp.
This removes the "y0" variable from simple.rs:main. This variable
isn't needed by the test case, and it uses a form of initialization
that was added in rust 1.17. Removing this makes it simpler to run
the gdb.rust tests against older versions of rustc.
gdb/testsuite/ChangeLog
2020-04-01 Tom Tromey <tromey@adacore.com>
* gdb.rust/simple.rs (main): Remove "y0".
Stop all threads not only if the current target is non-stop, but also
if there exists a non-stop target.
The multi-target patch (5b6d1e4fa4 "Multi-target support") made the
following change to gdb/inf-child.c:
void
inf_child_target::maybe_unpush_target ()
{
- if (!inf_child_explicitly_opened && !have_inferiors ())
+ if (!inf_child_explicitly_opened)
unpush_target (this);
}
If we are in all-stop mode with multiple inferiors, and an exit event
is received from an inferior, target_mourn_inferior() gets to this
point and without the have_inferiors() check, the target is unpushed.
This leads to having exec_ops as the top target.
Here is a test scenario. Two executables, ./a.out returns
immediately; ./sleepy just sleeps.
$ gdb ./sleepy
(gdb) start
...
(gdb) add-inferior -exec ./a.out
...
(gdb) inferior 2
[Switching to inferior 2..
(gdb) start
...
(gdb) set schedule-multiple on
(gdb) set debug infrun 1
(gdb) continue
At this point, the exit event is received from ./a.out. Normally,
this would lead to stop_all_threads() to also stop ./sleepy, but this
doesn't happen, because target_is_non_stop_p() returns false. And it
returns false because the top target is no longer the process target;
it is the exec_ops.
This patch modifies 'stop_waiting' to call 'stop_all_threads' if there
exists a non-stop target, not just when the current top target is
non-stop.
Tested on X86_64 Linux.
gdb/ChangeLog:
2020-04-01 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* infrun.c (stop_all_threads): Update assertion, plus when
stopping threads, take into account that we might be trying
to stop an all-stop target.
(stop_waiting): Call 'stop_all_threads' if there exists a
non-stop target.
gdb/testsuite/ChangeLog:
2020-04-01 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* gdb.multi/stop-all-on-exit.c: New test.
* gdb.multi/stop-all-on-exit.exp: New file.
Define a predicate function that returns true if there exists an
inferior with a non-stop target.
gdb/ChangeLog:
2020-04-01 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* target.h (exists_non_stop_target): New function declaration.
* target.c (exists_non_stop_target): New function.
Considering these variables:
int i = 3;
int &iref = i;
It's not possible to do any pointer arithmetic with iref:
(gdb) p &i+iref
Argument to arithmetic operation not a number or boolean.
So this adds checks for references to integers in pointer arithmetic.
gdb/ChangeLog:
2020-04-01 Hannes Domani <ssbssa@yahoo.de>
PR gdb/24789
* eval.c (is_integral_or_integral_reference): New function.
(evaluate_subexp_standard): Allow integer references in
pointer arithmetic.
gdb/testsuite/ChangeLog:
2020-04-01 Hannes Domani <ssbssa@yahoo.de>
PR gdb/24789
* gdb.cp/misc.cc: Add integer reference variable.
* gdb.cp/misc.exp: Add test.
A gdbserver does not report a ptid in a 'W' or 'X' packet if multi-process
extensions are not supported or turned off. See
https://sourceware.org/gdb/current/onlinedocs/gdb/General-Query-Packets.html#multiprocess-extensionshttps://sourceware.org/gdb/current/onlinedocs/gdb/Stop-Reply-Packets.html#Stop-Reply-Packets
GDB's remote packet parser checks for whether a stop-reply packet
contains a ptid if the target is non-stop, and issues an error if no
ptid is included:
if (target_is_non_stop_p () && event->ptid == null_ptid)
error (_("No process or thread specified in stop reply: %s"), buf);
This leads to the following error when the non-stop
mode is turned on but multi-process extensions are off:
$ gdb
(gdb) set non-stop on
(gdb) set remote multiprocess-feature-packet off
(gdb) target remote | gdbserver - ./foo
Remote debugging using | gdbserver - ./foo
stdin/stdout redirected
Process ./foo created; pid = 3712
...
(gdb) continue
Continuing.
...
No process or thread specified in stop reply: W2a
(gdb)
Because the check is done for stop reply packets in general, a similar
situation occurs if the 'T' or 'Tthread' packet is disabled in
gdbserver (i.e. via --disable-packet=T). E.g:
$ gdb
(gdb) set non-stop on
(gdb) target remote | gdbserver --disable-packet=Tthread - ./foo
...
No process or thread specified in stop reply: T0506:0000000000000000;07:10e2ffffff7f0000;10:9060ddf7ff7f0000;
or
$ gdb
(gdb) set non-stop on
(gdb) target remote | gdbserver --disable-packet=T - ./foo
...
No process or thread specified in stop reply: S05
The commit
commit cada5fc921
Date: Wed Mar 11 12:30:13 2020 +0000
gdb: Handle W and X remote packets without giving a warning
and its predecessor
commit 24ed6739b6
Date: Thu Jan 30 14:35:40 2020 +0000
gdb/remote: Restore support for 'S' stop reply packet
added warnings for when GDB has to make a guess for a missing ptid in
case of multiple threads/inferiors. These warnings should suffice.
So, the simple solution is to remove the check completely.
Regression-tested on X86_64 Linux.
gdb/ChangeLog:
2020-04-01 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* remote.c (remote_target::remote_parse_stop_reply): Remove the
check for no ptid in the stop reply when the target is non-stop.
gdb/testsuite/ChangeLog:
2020-04-01 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* gdb.server/stop-reply-no-thread.exp: Enhance the test
scenario to cover execution until the end and also the case
when no packet is disabled when starting gdbserver.
lookup_name_info always copies the name that is passed in. However,
normally a copy is not needed. This patch changes this class to avoid
copying. This required changing the "name" method to return something
else; I chose a gdb::string_view, to avoid excessive calls to strlen
in the code using the lookup_name_info. However, as this class does
not allow an arbitrary string_view, I've also added a c_str method
that guarantees a \0-terminated result -- a pedantic difference but
one that respects the string_view contract, IMO.
gdb/ChangeLog
2020-04-01 Tom Tromey <tromey@adacore.com>
* symtab.h (class lookup_name_info) <lookup_name_info>: Change
"name" parameter to rvalue reference. Initialize m_name_holder.
<lookup_name_info>: New overloads.
<name>: Return gdb::string_view.
<c_str>: New method.
<make_ignore_params>: Update.
<search_name_hash>: Update.
<language_lookup_name>: Return const char *.
<m_name>: Change type.
* symtab.c (demangle_for_lookup_info::demangle_for_lookup_info)
(demangle_for_lookup_info::demangle_for_lookup_info): Update.
(lookup_name_info::match_any): Update.
* psymtab.c (match_partial_symbol, lookup_partial_symbol):
Update.
* minsyms.c (linkage_name_str): Update.
* language.c (default_symbol_name_matcher): Update.
* dwarf2/read.c (mapped_index_base::find_name_components_bounds):
Update.
* ada-lang.c (ada_fold_name): Change parameter to string_view.
(ada_lookup_name_info::ada_lookup_name_info): Update.
(literal_symbol_name_matcher): Update.
I noticed that psymtab.c was always copying the search string in
psymtab_search_name, even when it wasn't necessary. This patch
removes this function in favor of using the make_ignore_params feature
of lookup_name_info.
Once I had done that, I noticed that lookup_partial_symbol was
creating a lookup_name_info. However, this function called in loops,
causing even more excess allocation. This patch further fixes this by
hosting the creation of the lookup_name_info into the callers.
gdb/ChangeLog
2020-04-01 Tom Tromey <tromey@adacore.com>
* psymtab.c (psymtab_search_name): Remove function.
(psym_lookup_symbol): Create search name and lookup name here.
(lookup_partial_symbol): Remove "name" parameter; add
lookup_name.
(psym_expand_symtabs_for_function): Update.
py-tui.c can fail to build if the ncurses development headers are not
installed, but if Python was built against ncurses. In this case, the
Python headers will define HAVE_NCURSES_H, confusing gdb_curses.h.
This patch fixes the problem by moving this include inside
"#ifdef TUI".
gdb/ChangeLog
2020-03-31 Joel Jones <joelkevinjones@gmail.com>
PR tui/25597:
* python/py-tui.c: Include gdb_curses.h inside of #ifdef TUI.
I compiled gdb with -fsanitize=undefined and ran the test suite.
A couple of reports came from passing NULL to memcpy, e.g.:
[...]btrace-common.cc:176:13: runtime error: null pointer passed as argument 2, which is declared to never be null
While it would be better to fix this in the standard, in the meantime
it seems easy to avoid this error.
gdb/ChangeLog
2020-03-31 Tom Tromey <tromey@adacore.com>
* dwarf2/abbrev.c (abbrev_table::read): Conditionally call
memcpy.
gdbsupport/ChangeLog
2020-03-31 Tom Tromey <tromey@adacore.com>
* btrace-common.cc (btrace_data_append): Conditionally call
memcpy.
When running test-case gdb.base/c-linkage-name.exp with target board
unix/-flto/-O0/-flto-partition=none/-ffat-lto-objects, I run into:
...
PASS: gdb.base/c-linkage-name.exp: maint info psymtab: c-linkage-name-2.c: no
FAIL: gdb.base/c-linkage-name.exp: print symada__cS before partial symtab \
expansion
...
The test-case tries to print a symbol before and after symtab expansion.
And it tries to ensure (since commit 13c3a74afb) that the symtab containing
the symbol is not yet expanded when doing the 'before' print, by placing the
symbol in a different CU (c-linkage-name-2.c) from the one containing main
(c-linkage-name.c), such that when we load the exec and expand the symtab
containing main, the symtab containing the symbol isn't.
The generated debug info for the test-case when using mentioned target board
however is structured like this:
...
<0><d2>: Abbrev Number: 1 (DW_TAG_compile_unit)
<d8> DW_AT_name : <artificial>
<1><f4>: Abbrev Number: 2 (DW_TAG_imported_unit)
<f5> DW_AT_import : <0x16b> [Abbrev Number: 1]
<1><f9>: Abbrev Number: 2 (DW_TAG_imported_unit)
<fa> DW_AT_import : <0x19c> [Abbrev Number: 1]
<1><fe>: Abbrev Number: 3 (DW_TAG_subprogram)
<ff> DW_AT_abstract_origin: <0x17d>
<1><115>: Abbrev Number: 4 (DW_TAG_variable)
<116> DW_AT_abstract_origin: <0x1ce>
<0><16b>: Abbrev Number: 1 (DW_TAG_compile_unit)
<171> DW_AT_name : c-linkage-name.c
<1><17d>: Abbrev Number: 2 (DW_TAG_subprogram)
<17e> DW_AT_name : main
<0><19c>: Abbrev Number: 1 (DW_TAG_compile_unit)
<1a2> DW_AT_name : c-linkage-name-2.c
<1><1ce>: Abbrev Number: 5 (DW_TAG_variable)
<1cf> DW_AT_name : mundane
<1d6> DW_AT_linkage_name: symada__cS
...
So, the CU named <artificial> contains both the concrete main and the concrete
symbol, which explains the FAIL.
The first test should fail, but passes for two reasons.
First of all, due to PR symtab/25700, we have two regular partial symtabs
c-linkage-name-2.c instead of one, and one of them is expanded, the other one
not:
...
{ psymtab c-linkage-name-2.c ((struct partial_symtab *) 0x38d6f60)
readin yes
{ psymtab c-linkage-name-2.c ((struct partial_symtab *) 0x38d6fe0)
readin no
...
And then there's the include symtab, which is also not expanded:
...
{ psymtab c-linkage-name-2.c ((struct partial_symtab *) 0x38143e0)
readin no
...
Fix the FAIL by explicitly setting the language before load, changing the
language setting from auto/c to manual/c, such that the symtab containing main
is no longer expanded.
And make the symtab expansion testing more robust by using the output of
"maint info symtabs" instead of "maint info psymtabs".
Tested on x86_64-linux, using native and target boards cc-with-gdb-index.exp,
cc-with-debug-names.exp, readnow.exp and
unix/-flto/-O0/-flto-partition=none/-ffat-lto-objects.
gdb/testsuite/ChangeLog:
2020-03-31 Tom de Vries <tdevries@suse.de>
* gdb.base/c-linkage-name.exp: Fix test-case comment. Set language to
c. Use "maint info symtabs" to check symtab expansion.
While debugging an Ada regression, I noticed that all the callers of
ada_which_variant_applies desconstruct a value, only to have it be
reconstructed by this function.
This patch removes this inefficiency in favor of simply passing in the
value directly.
Tested on x86-64 Fedora 30.
gdb/ChangeLog
2020-03-30 Tom Tromey <tromey@adacore.com>
* ada-valprint.c (print_variant_part): Update.
* ada-lang.h (ada_which_variant_applies): Update.
* ada-lang.c (ada_which_variant_applies): Remove outer_type and
outer_valaddr parameters; replace with "outer" value parameter.
(to_fixed_variant_branch_type): Update.
This patch fixes some issues with debug register handling for the powerpc
linux native target.
Currently, the target methods for installing and removing hardware
breakpoints and watchpoints in ppc-linux-nat.c affect all threads known to
linux-nat, including threads of different processes.
This patch changes ppc-linux-nat.c so that only the process of
inferior_ptid is affected by these target methods, as GDB expects.
This is done in the same way as various other architectures. The
install/remove target methods only register a hardware breakpoint or
watchpoint, and then send a stop signal to the threads. The debug
registers are only changed with ptrace right before each thread is next
resumed, using low_prepare_to_resume.
There are two interfaces to modify debug registers for linux running on
powerpc, with different sets of ptrace requests:
- PPC_PTRACE_GETHWDBGINFO, PPC_PTRACE_SETHWDEBUG, and
PPC_PTRACE_DELHWDEBUG.
Or
- PTRACE_SET_DEBUGREG and PTRACE_GET_DEBUGREG
The first set (HWDEBUG) is the more flexible one and allows setting
watchpoints with a variable watched region length and, for certain
embedded processors, multiple types of debug registers (e.g. hardware
breakpoints and hardware-assisted conditions for watchpoints).
Currently, server processors only provide one watchpoint. The second one
(DEBUGREG) only allows setting one debug register, a watchpoint, so we
only use it if the first one is not available.
The HWDEBUG interface handles debug registers with slot numbers. Once a
hardware watchpoint or breakpoint is installed (with
PPC_PTRACE_SETHWDEBUG), ptrace returns a slot number. This slot number
can then be used to remove the watchpoint or breakpoint from the inferior
(with PPC_PTRACE_DELHWDEBUG). The first interface also provides a
bitmask of available debug register features, which can be obtained with
PPC_PTRACE_GETHWDBGINFO.
When GDB first tries to use debug registers, we try the first interface
with a ptrace call, and if it isn't available, we fall back to the second
one, if available. We use EIO as an indicator that an interface is not
available in the kernel. For simplicity, with any other error we
immediately assume no interface is available. Unfortunately this means
that if a process is killed by a signal right before we try to detect the
interface, we might get an ESRCH, which would prevent debug registers to
be used in the GDB session. However, it isn't clear that we can safely
raise an exception and try again in the future in all the contexts where
we try to detect the interface.
If the HWDEBUG interface works but provides no feature bits, the target
falls back to the DEBUGREG interface. When the kernel is configured
without CONFIG_HW_BREAKPOINTS (selected by CONFIG_PERF_EVENTS), there is
a bug that causes watchpoints installed with the HWDEBUG interface not to
trigger. When this is the case, the feature bits will be zero, which is
used as the indicator to fall back to the DEBUGREG interface. This isn't
ideal, but has always been the behavior of GDB before this patch, so I
decided not to change it.
A flag indicates for each thread if its debug registers need to be
updated the next time it is resumed. The flag is set whenever the upper
layers request or remove a hardware watchpoint or breakpoint, or when a
new thread is detected. Because some kernel configurations disable
watchpoints after they are hit, we also use the last stop reason of the
LWP to determine whether we should update the debug registers. It isn't
clear that this is also true of BookE hardware breakpoints, but we also
check their stop reason to be on the safe side, since it doesn't hurt.
A map from process numbers to hardware watchpoint or breakpoint objects
keeps track of what has been requested by the upper layers of GDB, since
for GDB installing a hardware watchpoint or breakpoint means doing so for
the whole process.
When using the HWDEBUG interface we also have to keep track of which
slots were last installed in each thread with a map from threads to the
slots, so that they can be removed when needed. When resuming a thread,
we remove all the slots using this map, then we install all the hardware
watchpoints and breakpoints from the per-process map of requests, and
then update the per-thread map accordingly.
This per-thread state is also used for copying the debug register state
after a fork or a clone is detected. The kernel might do this depending
on the configuration. Recent kernels running on server processors that
were configured with CONFIG_PERF_EVENTS (and therefore
CONFIG_HW_BREAKPOINTS) don't copy debug registers across forks and
clones. Recent kernels without CONFIG_HW_BREAKPOINTS copy this state. I
believe that on embedded processors (e.g. a ppc440) the debug register
state is copied, but I haven't been able to test this. To handle both
cases, the per-thread state is always copied when forks and clones are
detected, and when we resume the thread and delete the debug register
slots before updating them, we ignore ENOENT errors.
We don't need to handle this when using the DEBUGREG interface since it
only allows one hardware watchpoint and doesn't return slot numbers, we
just set or clear this watchpoint when needed.
Since we signal running threads to stop after a request is processed, so
that we can update their debug registers when they are next resumed,
there will be a time between signalling the threads and their stop during
which the debug registers haven't been updated, even if the target
methods completed.
The tests in gdb.threads/watchpoint-fork.exp no longer fail with this
patch.
gdb/ChangeLog:
2020-03-30 Pedro Franco de Carvalho <pedromfc@linux.ibm.com>
* ppc-linux-nat.c: Include <algorithm>, <unordered_map>, and
<list>. Remove inclusion of observable.h.
(PPC_DEBUG_CURRENT_VERSION): Move up define.
(struct arch_lwp_info): New struct.
(class ppc_linux_dreg_interface): New class.
(struct ppc_linux_process_info): New struct.
(struct ppc_linux_nat_target) <low_delete_thread, low_new_fork>
<low_new_clone, low_forget_process, low_prepare_to_resume>
<copy_thread_dreg_state, mark_thread_stale>
<mark_debug_registers_changed, register_hw_breakpoint>
<clear_hw_breakpoint, register_wp, clear_wp>
<can_use_watchpoint_cond_accel, calculate_dvc, check_condition>
<num_memory_accesses, get_trigger_type>
<create_watchpoint_request, hwdebug_point_cmp>
<init_arch_lwp_info, get_arch_lwp_info>
<low_stopped_by_watchpoint, low_stopped_data_address>: Declare as
methods.
<struct ptid_hash>: New inner struct.
<m_dreg_interface, m_process_info, m_installed_hw_bps>: Declare
members.
(saved_dabr_value, hwdebug_info, max_slots_number)
(struct hw_break_tuple, struct thread_points, ppc_threads)
(have_ptrace_hwdebug_interface)
(hwdebug_find_thread_points_by_tid)
(hwdebug_insert_point, hwdebug_remove_point): Remove.
(ppc_linux_nat_target::can_use_hw_breakpoint): Use
m_dreg_interface, remove call to PTRACE_SET_DEBUGREG.
(ppc_linux_nat_target::region_ok_for_hw_watchpoint): Add comment,
use m_dreg_interface.
(hwdebug_point_cmp): Change to...
(ppc_linux_nat_target::hwdebug_point_cmp): ...this method. Use
reference arguments instead of pointers.
(ppc_linux_nat_target::ranged_break_num_registers): Use
m_dreg_interface.
(ppc_linux_nat_target::insert_hw_breakpoint): Add comment, use
m_dreg_interface. Call register_hw_breakpoint.
(ppc_linux_nat_target::remove_hw_breakpoint): Add comment, use
m_dreg_interface. Call clear_hw_breakpoint.
(get_trigger_type): Change to...
(ppc_linux_nat_target::get_trigger_type): ...this method. Add
comment.
(ppc_linux_nat_target::insert_mask_watchpoint): Update comment,
use m_dreg_interface. Call register_hw_breakpoint.
(ppc_linux_nat_target::remove_mask_watchpoint): Update comment,
use m_dreg_interface. Call clear_hw_breakpoint.
(can_use_watchpoint_cond_accel): Change to...
(ppc_linux_nat_target::can_use_watchpoint_cond_accel): ...this
method. Update comment, use m_dreg_interface and
m_process_info.
(calculate_dvc): Change to...
(ppc_linux_nat_target::calculate_dvc): ...this method. Use
m_dreg_interface.
(num_memory_accesses): Change to...
(ppc_linux_nat_target::num_memory_accesses): ...this method.
(check_condition): Change to...
(ppc_linux_nat_target::check_condition): ...this method.
(ppc_linux_nat_target::can_accel_watchpoint_condition): Update
comment, use m_dreg_interface.
(create_watchpoint_request): Change to...
(ppc_linux_nat_target::create_watchpoint_request): ...this
method. Use m_dreg_interface.
(ppc_linux_nat_target::insert_watchpoint): Add comment, use
m_dreg_interface. Call register_hw_breakpoint or register_wp.
(ppc_linux_nat_target::remove_watchpoint): Add comment, use
m_dreg_interface. Call clear_hw_breakpoint or clear_wp.
(ppc_linux_nat_target::low_forget_process)
(ppc_linux_nat_target::low_new_fork)
(ppc_linux_nat_target::low_new_clone)
(ppc_linux_nat_target::low_delete_thread)
(ppc_linux_nat_target::low_prepare_to_resume): New methods.
(ppc_linux_nat_target::low_new_thread): Remove previous logic,
only call mark_thread_stale.
(ppc_linux_thread_exit): Remove.
(ppc_linux_nat_target::stopped_data_address): Change to...
(ppc_linux_nat_target::low_stopped_data_address): This. Add
comment, use m_dreg_interface and m_thread_hw_breakpoints.
(ppc_linux_nat_target::stopped_by_watchpoint): Change to...
(ppc_linux_nat_target::stopped_by_watchpoint): This. Add
comment. Call low_stopped_data_address.
(ppc_linux_nat_target::watchpoint_addr_within_range): Use
m_dreg_interface.
(ppc_linux_nat_target::masked_watch_num_registers): Use
m_dreg_interface.
(ppc_linux_nat_target::copy_thread_dreg_state)
(ppc_linux_nat_target::mark_thread_stale)
(ppc_linux_nat_target::mark_debug_registers_changed)
(ppc_linux_nat_target::register_hw_breakpoint)
(ppc_linux_nat_target::clear_hw_breakpoint)
(ppc_linux_nat_target::register_wp)
(ppc_linux_nat_target::clear_wp)
(ppc_linux_nat_target::init_arch_lwp_info)
(ppc_linux_nat_target::get_arch_lwp_info): New methods.
(_initialize_ppc_linux_nat): Remove observer callback.
This patch adds a low_new_clone method to linux_nat_target, called after
a PTRACE_EVENT_CLONE is detected, similar to how low_new_fork is called
after PTRACE_EVENT_(V)FORK.
This is useful for targets that need to copy state associated with a
thread that is inherited across clones.
gdb/ChangeLog:
2020-03-30 Pedro Franco de Carvalho <pedromfc@linux.ibm.com>
* linux-nat.h (low_new_clone): New method.
* linux-nat.c (linux_handle_extended_wait): Call low_new_clone.
When running test-case gdb.base/c-linkage-name.exp with target board
cc-with-gdb-index.exp, I see:
...
FAIL: gdb.base/c-linkage-name.exp: maint info psymtab: c-linkage-name-2.c: no
FAIL: gdb.base/c-linkage-name.exp: maint info psymtab: c-linkage-name-2.c: yes
...
The FAILs are due to the fact that partial symbol tables are not generated for
indexed executables.
When running the same test-case with target board readnow.exp, I see:
...
FAIL: gdb.base/c-linkage-name.exp: maint info psymtab: c-linkage-name-2.c: no
FAIL: gdb.base/c-linkage-name.exp: print symada__cS before partial symtab \
expansion
FAIL: gdb.base/c-linkage-name.exp: maint info psymtab: c-linkage-name-2.c: yes
...
The "maint info psymtab" FAILs are also due to fact that the partial symbol
tables not generated, but in this case it's because the symtabs are fully
expanded upon load due to using -readnow. The "print symada__cS before
partial symtab expansion" test intends to test the state before symbol table
expansion, and with -readnow that's not possible.
Mark these FAILs as UNSUPPORTED.
Tested on x86_64-linux, with native, and target boards cc-with-gdb-index.exp,
cc-with-debug-names.exp and readnow.exp.
gdb/testsuite/ChangeLog:
2020-03-30 Tom de Vries <tdevries@suse.de>
* gdb.base/c-linkage-name.exp: Use readnow call to mark a test
unsupported.
(verify_psymtab_expanded): Move ...
* lib/gdb.exp (verify_psymtab_expanded): ... here. Add unsupported
test.
(readnow): New proc.
As I am trying to understand the dynamic of partial_symtab::read_symtab
and partial_symtab::expand_psymtab, I think that renaming these
functions helps make it clear that they are effectively implementations
of the partial_symtab::expand_psymtab method.
gdb/ChangeLog:
* dbxread.c (dbx_psymtab_to_symtab_1): Rename to...
(dbx_expand_psymtab): ... this.
(start_psymtab): Update.
* mdebugread.c (psymtab_to_symtab_1): Rename to...
(mdebug_expand_psymtab): ... this.
(parse_partial_symbols): Update.
(new_psymtab): Update.
* xcoffread.c (xcoff_psymtab_to_symtab_1): Rename to...
(xcoff_expand_psymtab): ... this.
(xcoff_start_psymtab): Update.
This method calls partial_symtab::expand_psymtab on all dependencies of
a psymtab. Given that there is also a partial_symtab::read_symtab
method, I think it would be clearer to name this function
expand_dependencies, rather than read_dependencies.
gdb/ChangeLog:
* psympriv.h (partial_symtab) <read_dependencies>: Rename to...
<expand_dependencies>: ... this.
* psymtab.c (partial_symtab::read_dependencies): Rename to...
(partial_symtab::expand_dependencies): ... this.
* dwarf2/read.c (dwarf2_include_psymtab) <expand_psymtab>:
Update.
(dwarf2_psymtab::expand_psymtab): Update.
* dbxread.c (dbx_psymtab_to_symtab_1): Update.
* mdebugread.c (psymtab_to_symtab_1): Update.
* xcoffread.c (xcoff_psymtab_to_symtab_1): Update.
This function does not add much value, compared to calling the method on
the psymtab_storage object directly.
gdb/ChangeLog:
* psympriv.h (discard_psymtab): Remove.
* dbxread.c (dbx_end_psymtab): Update.
* xcoffread.c (xcoff_end_psymtab): Update.
I noticed that a comment in dwarf2/attribute.h still referred to
dwarf2_get_attr_constant_value. However, this is now a method on
struct attribute.
gdb/ChangeLog
2020-03-28 Tom Tromey <tom@tromey.com>
* dwarf2/attribute.h (struct attribute) <form_is_constant>: Update
comment.
I noticed that the start of read_attribute_reprocess had the wrong
formatting. This patch fixes it.
gdb/ChangeLog
2020-03-28 Tom Tromey <tom@tromey.com>
* dwarf2/read.c (read_attribute_reprocess): Fix formatting.
GetModuleFileNameEx might also return the 64bit system directory for 32bit
programs even for a 32bit gdb:
(gdb) info sharedlibrary
From To Syms Read Shared Object Library
0x779d0000 0x77b34d20 Yes (*) C:\Windows\SysWOW64\ntdll.dll
0x76850000 0x7694ad9c Yes (*) C:\Windows\syswow64\kernel32.dll
0x75421000 0x75466a18 Yes (*) C:\Windows\syswow64\KernelBase.dll
0x6fbe1000 0x6fcca1c0 Yes (*) C:\Windows\system32\dbghelp.dll
0x76d31000 0x76ddb2c4 Yes (*) C:\Windows\syswow64\msvcrt.dll
So this makes the path conversion for all 32bit programs.
gdb/ChangeLog:
2020-03-27 Hannes Domani <ssbssa@yahoo.de>
* windows-nat.c (windows_add_all_dlls): Fix system dll paths.
FreeBSD's kernel recently added a new ELF auxiliary vector entry
holding a mask of software features provided by the kernel. This
change fixes 'info auxv' to report the name and description for this
vector entry instead of '???'.
include/ChangeLog:
* elf/common.h (AT_FREEBSD_BSDFLAGS): Define.
gdb/ChangeLog:
* fbsd-tdep.c (fbsd_print_auxv_entry): Handle AT_FREEBSD_BSDFLAGS.
This changes dwarf2_get_ref_die_offset and
dwarf2_get_attr_constant_value to be methods on struct attribute.
gdb/ChangeLog
2020-03-26 Tom Tromey <tom@tromey.com>
* dwarf2/read.c (handle_data_member_location, dwarf2_add_field)
(mark_common_block_symbol_computed, read_tag_string_type)
(attr_to_dynamic_prop, read_subrange_type): Update.
(dwarf2_get_ref_die_offset, dwarf2_get_attr_constant_value): Move
to be methods on struct attribute.
(skip_one_die, process_imported_unit_die, read_namespace_alias)
(read_call_site_scope, partial_die_info::read)
(partial_die_info::read, lookup_die_type, follow_die_ref):
Update.
* dwarf2/attribute.c (attribute::get_ref_die_offset): New method,
from dwarf2_get_ref_die_offset.
(attribute::constant_value): New method, from
dwarf2_get_attr_constant_value.
* dwarf2/attribute.h (struct attribute) <get_ref_die_offset>:
Declare method.
<constant_value>: New method.
This moves the DWARF debugging functions that stringify various
constants to a new file, dwarf2/stringify.c.
gdb/ChangeLog
2020-03-26 Tom Tromey <tom@tromey.com>
* dwarf2/read.c (dwarf_unit_type_name, dwarf_tag_name)
(dwarf_attr_name, dwarf_form_name, dwarf_bool_name)
(dwarf_type_encoding_name): Move to stringify.c.
* Makefile.in (COMMON_SFILES): Add dwarf2/stringify.c.
* dwarf2/stringify.c: New file.
* dwarf2/stringify.h: New file.
This rewrites the two new die_info methods to iterate over attributes
rather than to do two separate searches.
gdb/ChangeLog
2020-03-26 Tom Tromey <tom@tromey.com>
* dwarf2/die.h (struct die_info) <addr_base, ranges_base>:
Rewrite.
This changes lookup_addr_base and lookup_ranges_base to be methods on
die_info.
gdb/ChangeLog
2020-03-26 Tom Tromey <tom@tromey.com>
* dwarf2/die.h (struct die_info) <addr_base, ranges_base>: New
methods.
* dwarf2/read.c (lookup_addr_base): Move to die.h.
(lookup_ranges_base): Likewise.
(read_cutu_die_from_dwo, read_full_die_1): Update.
The sibling_die helper function does not seem to add much value,
considering that many other fields of die_info are directly accessed.
So, this removes it.
gdb/ChangeLog
2020-03-26 Tom Tromey <tom@tromey.com>
* dwarf2/read.c (read_import_statement, read_file_scope)
(read_type_unit_scope, inherit_abstract_dies, read_func_scope)
(read_lexical_block_scope, read_call_site_scope)
(dwarf2_get_subprogram_pc_bounds, get_scope_pc_bounds)
(handle_struct_member_die, process_structure_scope)
(update_enumeration_type_from_children)
(process_enumeration_scope, read_array_type, read_common_block)
(read_namespace, read_module, read_subroutine_type): Update.
(sibling_die): Remove.
This changes dwarf2_attr_no_follow to be a method on die_info.
gdb/ChangeLog
2020-03-26 Tom Tromey <tom@tromey.com>
* dwarf2/read.c (lookup_addr_base, lookup_ranges_base)
(build_type_psymtabs_reader, read_structure_type)
(read_enumeration_type, read_full_die_1): Update.
(dwarf2_attr_no_follow): Move to die.h.
* dwarf2/die.h (struct die_info) <attr>: New method.
This removes dwarf2_cu::base_known, changing base_address to be a
gdb::optional.
gdb/ChangeLog
2020-03-26 Tom Tromey <tom@tromey.com>
* dwarf2/read.c (struct dwarf2_cu) <base_known>: Remove.
<base_address>: Now an optional.
(dwarf2_find_base_address, dwarf2_rnglists_process)
(dwarf2_ranges_process, fill_in_loclist_baton)
(dwarf2_symbol_mark_computed): Update.
This moves struct die_info to a new header, dwarf2/die.h.
gdb/ChangeLog
2020-03-26 Tom Tromey <tom@tromey.com>
* dwarf2/read.c (struct die_info): Move to die.h.
* dwarf2/die.h: New file.
This moves some more code out of read.c and into line-header.c.
dwarf_decode_line_header is split into two -- the part remaining in
read.c handles interfacing to the dwarf2_cu; while the part in
line-header.c (more or less) purely handles the actual decoding.
gdb/ChangeLog
2020-03-26 Tom Tromey <tom@tromey.com>
* dwarf2/line-header.h (dwarf_decode_line_header): Declare.
* dwarf2/read.c
(dwarf2_statement_list_fits_in_line_number_section_complaint):
Move to line-header.c.
(read_checked_initial_length_and_offset, read_formatted_entries):
Likewise.
(dwarf_decode_line_header): Split into two.
* dwarf2/line-header.c
(dwarf2_statement_list_fits_in_line_number_section_complaint):
Move from read.c.
(read_checked_initial_length_and_offset, read_formatted_entries):
Likewise.
(dwarf_decode_line_header): New function, split from read.c.
This changes read_indirect_line_string to be a method on
dwarf2_per_objfile. This makes it a bit simpler to share between
files.
gdb/ChangeLog
2020-03-26 Tom Tromey <tom@tromey.com>
* dwarf2/read.h (struct dwarf2_per_objfile) <read_line_string>:
Declare method.
* dwarf2/read.c (read_attribute_value): Update.
(dwarf2_per_objfile::read_line_string): Rename from
read_indirect_line_string.
(read_formatted_entries): Update.
One spot in dwarf_decode_macro_bytes could use the existing "objfile"
local variable.
gdb/ChangeLog
2020-03-26 Tom Tromey <tom@tromey.com>
* dwarf2/macro.c (dwarf_decode_macro_bytes): Use objfile local
variable.
This changes the DWARF macro reader to use a const dwarf2_section_info.
gdb/ChangeLog
2020-03-26 Tom Tromey <tom@tromey.com>
* dwarf2/macro.h (dwarf_decode_macros): Make section parameter
const.
* dwarf2/macro.c (skip_form_bytes, skip_unknown_opcode)
(dwarf_decode_macro_bytes, dwarf_decode_macros): Make section
parameter const.
This changes a few line_header methods to be const. In some cases, a
const overload is added.
gdb/ChangeLog
2020-03-26 Tom Tromey <tom@tromey.com>
* dwarf2/line-header.h (struct line_header) <is_valid_file_index,
file_names_size, file_full_name, file_file_name>: Use const.
<file_name_at, file_names>: Add const overload.
* dwarf2/line-header.c (line_header::file_file_name)
(line_header::file_full_name): Update.
This moves some more code out of dwarf2/read.c, introducing new files
dwarf2/macro.c and dwarf2/macro.h.
gdb/ChangeLog
2020-03-26 Tom Tromey <tom@tromey.com>
* dwarf2/read.c (dwarf2_macro_malformed_definition_complaint)
(macro_start_file, consume_improper_spaces)
(parse_macro_definition, skip_form_bytes, skip_unknown_opcode)
(dwarf_parse_macro_header, dwarf_decode_macro_bytes)
(dwarf_decode_macros): Move to macro.c.
* dwarf2/macro.c: New file.
* dwarf2/macro.h: New file.
* Makefile.in (COMMON_SFILES): Add dwarf2/macro.c.
This moves a string-reading function to be a method on
dwarf2_section_info, and then updates the users.
gdb/ChangeLog
2020-03-26 Tom Tromey <tom@tromey.com>
* dwarf2/section.h (struct dwarf2_section_info) <read_string>: New
method.
* dwarf2/section.c: New method. From
read_indirect_string_at_offset_from.
* dwarf2/read.c (mapped_debug_names::namei_to_name): Update.
(read_indirect_string_at_offset_from): Move to section.c.
(read_indirect_string_at_offset): Rewrite.
(read_indirect_line_string_at_offset): Remove.
(read_indirect_string, read_indirect_line_string)
(dwarf_decode_macro_bytes): Update.
This splits dwarf_decode_macros into two overloads -- one that's
suitable for splitting into a separate file, and one that finds the
correct section and should remain in dwarf2/read.c.
gdb/ChangeLog
2020-03-26 Tom Tromey <tom@tromey.com>
* dwarf2/read.c (dwarf_decode_macros): Split into two overloads.
This changes dwarf_decode_macro_bytes to accept a buildsym_compunit
rather than a dwarf2_cu. This enables some subsequent changes; and
also makes the function accept a "more specific" parameter.
gdb/ChangeLog
2020-03-26 Tom Tromey <tom@tromey.com>
* dwarf2/read.c (macro_start_file): Change "cu" parameter to
"builder".
(dwarf_decode_macro_bytes): Likewise. Add dwarf2_per_objfile
parameter.
(dwarf_decode_macros): Update.
This changes read_indirect_string_from_dwz to be a method on the
dwz_file, and adds a new dwarf2/dwz.c file.
gdb/ChangeLog
2020-03-26 Tom Tromey <tom@tromey.com>
* dwarf2/read.c (read_attribute_value): Update.
(read_indirect_string_from_dwz): Move to dwz.c; change into
method.
(dwarf_decode_macro_bytes): Update.
* dwarf2/dwz.h (struct dwz_file) <read_string>: Declare method.
* dwarf2/dwz.c: New file.
* Makefile.in (COMMON_SFILES): Add dwz.c.
I noticed that an error message in compile-object-load.c mentions the
wrong symbol name. The loop just above the error is looking for
COMPILE_I_EXPR_VAL, but the error references COMPILE_I_EXPR_PTR_TYPE.
I'm checking this in as obvious. I don't have a test case -- I
noticed it because another patch I'm working on caused this error to
be thrown, but that was due to regression in my patch.
gdb/ChangeLog
2020-03-25 Tom Tromey <tom@tromey.com>
* compile/compile-object-load.c (get_out_value_type): Mention
correct symbol name in error message.
GetModuleFileNameEx returns for some DLLs of WOW64 processes
the path inside the 64bit system directory instead of the 32bit
syswow64 directory.
Problem happens e.g. with dbghelp.dll:
(gdb) start
Temporary breakpoint 1 at 0x415a00: file fiber.cpp, line 430.
Starting program: C:\src\tests\fiber.exe
warning: `C:\Windows\system32\dbghelp.dll': Shared library architecture i386:x86-64 is not compatible with target architecture i386.
Temporary breakpoint 1, main () at fiber.cpp:430
430 {
(gdb) info sharedlibrary
From To Syms Read Shared Object Library
0x77070000 0x771d4d20 Yes (*) C:\Windows\SysWOW64\ntdll.dll
0x74dc0000 0x74ebad9c Yes (*) C:\Windows\syswow64\kernel32.dll
0x75341000 0x75386a18 Yes (*) C:\Windows\syswow64\KernelBase.dll
0x6f6a1000 0x6f7c48fc Yes (*) C:\Windows\system32\dbghelp.dll
0x74d01000 0x74dab2c4 Yes (*) C:\Windows\syswow64\msvcrt.dll
(*): Shared library is missing debugging information.
This detects this situation and converts the DLL path to the
syswow64 equivalent.
gdb/ChangeLog:
2020-03-25 Hannes Domani <ssbssa@yahoo.de>
* windows-nat.c (windows_add_all_dlls): Fix system dll paths.
The type struct compunit_symtab contains two fields (disregarding field next)
that express relations with other compunit_symtabs: user and includes.
These fields are currently not printed with "maint info symtabs" and
"maint print symbols".
Fix this such that for "maint info symtabs" we print:
...
{ ((struct compunit_symtab *) 0x23e8450)
debugformat DWARF 2
producer (null)
dirname (null)
blockvector ((struct blockvector *) 0x23e8590)
+ user ((struct compunit_symtab *) 0x2336280)
+ ( includes
+ ((struct compunit_symtab *) 0x23e85e0)
+ ((struct compunit_symtab *) 0x23e8960)
+ )
{ symtab <unknown> ((struct symtab *) 0x23e85b0)
fullname (null)
linetable ((struct linetable *) 0x0)
}
}
...
And for "maint print symbols" we print:
...
-Symtab for file <unknown>
+Symtab for file <unknown> at 0x23e85b0
Read from object file /data/gdb_versions/devel/a.out (0x233ccf0)
Language: c
Blockvector:
block #000, object at 0x23e8530, 0 syms/buckets in 0x0..0x0
block #001, object at 0x23e84d0 under 0x23e8530, 0 syms/buckets in 0x0..0x0
+Compunit user: 0x2336300
+Compunit include: 0x23e8900
+Compunit include: 0x23dd970
...
Note: for user and includes we don't list the actual compunit_symtab address,
but instead the corresponding symtab address, which allows us to find that
symtab elsewhere in the output (given that we also now print the address of
symtabs).
gdb/ChangeLog:
2020-03-25 Tom de Vries <tdevries@suse.de>
* symtab.h (is_main_symtab_of_compunit_symtab): New function.
* symmisc.c (dump_symtab_1): Print user and includes fields.
(maintenance_info_symtabs): Same.
When setting up function parameters we already perform NaN boxing, as
required by the RISC-V ABI, however, we don't do this when writing
values into registers as part of setting up a return value.
This commit moves the NaN boxing code into a small helper function,
and then makes use of this function when setting up function
parameters, and also when setting up return values.
This should resolve this failure:
FAIL: gdb.base/return-nodebug.exp: float: full width of the returned result
gdb/ChangeLog:
PR gdb/25489
* riscv-tdep.c (riscv_arg_info::c_offset): Update comment.
(riscv_regcache_cooked_write): New function.
(riscv_push_dummy_call): Use new function.
(riscv_return_value): Likewise.
The type struct partial_symtab contains two fields (disregarding field next)
that express relations with other symtabs: user and dependencies.
When using "maint print psymbols", we see both the dependencies and the user
fields:
...
Partial symtab for source file (object 0x35ef270)
...
Depends on 0 other partial symtabs.
Shared partial symtab with user 0x35d5f40
...
But with "maint info psymtabs", we only see dependencies:
...
{ psymtab ((struct partial_symtab *) 0x35ef270)
...
dependencies (none)
}
...
Add printing of the user field for "maint info psymtabs", such that we have:
...
{ psymtab ((struct partial_symtab *) 0x35ef270)
...
+ user hello.c ((struct partial_symtab *) 0x35d5f40)
dependencies (none)
}
...
Tested on x86_64-linux.
gdb/ChangeLog:
2020-03-24 Tom de Vries <tdevries@suse.de>
* psymtab.c (maintenance_info_psymtabs): Print user field.
In commit:
commit 6b8c53f2f1
Date: Sat Feb 8 21:26:31 2020 +0000
gdb/testsuite/fortran: Add mixed language stack test
The test incorrectly included two hard coded addresses in the expected
output, this commit replaces them with the $hex pattern.
gdb/testsuite/ChangeLog:
* gdb.fortran/mixed-lang-stack.exp: Replace two hard coded address
with $hex.
dwarf2_evaluate_property should not modify its "addr_stack"
parameter's contents. This patch makes this part of the API, by
marking it const.
gdb/ChangeLog
2020-03-20 Tom Tromey <tromey@adacore.com>
* dwarf2/loc.h (dwarf2_evaluate_property): Make "addr_stack"
const.
* dwarf2/loc.c (dwarf2_evaluate_property): Make "addr_stack"
const.
When running test-case gdb.threads/omp-par-scope.exp, I get this XPASS:
...
XPASS: gdb.threads/omp-par-scope.exp: nested_parallel: outer_threads: \
outer stop: get valueof "num"
...
for test:
...
set thread_num [get_valueof "" "num" "unknown"]
...
The intention of the test is to get the value of local variable num, which
has been set to:
...
int num = omp_get_thread_num ();
...
but the actually printed value is 'num':
...
(gdb) print num^M
$76 = num^M
...
This is due to the fact that num is missing in the locals, so instead we find
the enum member 'num' of enum expression_operator in glibc/intl/plural-exp.h.
Fix this by getting the value using a new proc get_local_valueof, which uses
the "info locals" commands to get the value.
Tested on x86_64-linux, with gcc 7.5.0 (where the test xfails) and gcc
10.0.1 (where the test passes).
I stumbled on this snippet in nat/gdb_ptrace.h:
/* Some systems, in particular DEC OSF/1, Digital Unix, Compaq Tru64
or whatever it's called these days, don't provide a prototype for
ptrace. Provide one to silence compiler warnings. */
#ifndef HAVE_DECL_PTRACE
extern PTRACE_TYPE_RET ptrace();
#endif
I believe this is unnecessary today and should be removed. First, the
comment only mentions OSes we don't support (and to be honest, I had
never even heard of).
But most importantly, in C++, a declaration with empty parenthesis
declares a function that accepts no arguments, unlike in C. So if this
declaration was really used, GDB wouldn't build, since all ptrace call
sites pass some arguments. Since we haven't heard anything about this
causing some build failures since we have transitioned to C++, I
conclude that it's not used.
This patch removes it as well as the corresponding configure check.
gdb/ChangeLog:
* ptrace.m4: Don't check for ptrace declaration.
* config.in: Re-generate.
* configure: Re-generate.
* nat/gdb_ptrace.h: Don't declare ptrace if HAVE_DECL_PTRACE is
not defined.
gdbserver/ChangeLog:
* config.in: Re-generate.
* configure: Re-generate.
gdbsupport/ChangeLog:
* config.in: Re-generate.
* configure: Re-generate.
Linux returns long from ptrace(2) and BSDs int.
gdb/ChangeLog:
* amd64-bsd-nat.c (gdb_ptrace): Change return type from `int' to
`PTRACE_TYPE_RET'.
* i386-bsd-nat.c (gdb_ptrace): Likewise.
* sparc-nat.c (gdb_ptrace): Likewise.
* x86-bsd-nat.c (gdb_ptrace): Likewise.
The "restrict" patch added some asserts to c-exp.y, but one spot was
copy-pasted and referred to the wrong table. This was pointed out by
-fsanitize=address. This patch fixes the bug.
gdb/ChangeLog
2020-03-20 Tom Tromey <tromey@adacore.com>
* c-exp.y (lex_one_token): Fix assert.
I configured with -fsanitize=address and built gdb. linux-tdep.c and
ada-tasks.c failed to build due to some stringop-truncation errors,
e.g.:
In function ‘char* strncpy(char*, const char*, size_t)’,
inlined from ‘int linux_fill_prpsinfo(elf_internal_linux_prpsinfo*)’ at ../../binutils-gdb/gdb/linux-tdep.c:1742:11,
inlined from ‘char* linux_make_corefile_notes(gdbarch*, bfd*, int*)’ at ../../binutils-gdb/gdb/linux-tdep.c:1878:27:
/usr/include/bits/string_fortified.h:106:34: error: ‘char* __builtin_strncpy(char*, const char*, long unsigned int)’ specified bound 81 equals destination size [-Werror=stringop-truncation]
This patch fixes the problem by using "sizeof - 1" in the call to
strndup, as recommended in the GCC manual. This doesn't make a
difference here because the next line, in all cases, sets the final
element to '\0' anyway.
gdb/ChangeLog
2020-03-20 Tom Tromey <tromey@adacore.com>
* ada-tasks.c (read_atcb): Use smaller length in strncpy call.
* linux-tdep.c (linux_fill_prpsinfo): Use smaller length in
strncpy call.
Andrew Burgess pointed out on irc that "maint info line-table" doesn't
properly align the table headers. This patch fixes the problem by
switching the table to use ui-out.
This required a small tweak to one test case, as ui-out will pad a
field using spaces, even at the end of a line.
gdb/ChangeLog
2020-03-20 Tom Tromey <tromey@adacore.com>
* symmisc.c (maintenance_print_one_line_table): Use ui_out.
gdb/testsuite/ChangeLog
2020-03-20 Tom Tromey <tromey@adacore.com>
* gdb.dwarf2/dw2-ranges-base.exp: Update regular expressions.
The removal of val_print caused a regression in the Ada code. In one
scenario, a variant type would not be properly printed, because the
address of a component was lost. This patch fixes the bug by changing
this API to be value-based. This is cleaner and fixes the bug as a
side effect.
gdb/ChangeLog
2020-03-20 Tom Tromey <tromey@adacore.com>
* ada-valprint.c (print_variant_part): Remove parameters; switch
to value-based API.
(print_field_values): Likewise.
(ada_val_print_struct_union): Likewise.
(ada_value_print_1): Update.
gdb/testsuite/ChangeLog
2020-03-20 Tom Tromey <tromey@adacore.com>
* gdb.ada/sub_variant/subv.adb: New file.
* gdb.ada/sub_variant.exp: New file.
gdb/ChangeLog:
* ppc-nbsd-nat.c (ppc_nbsd_nat_target): Inherit from
nbsd_nat_target instead of inf_ptrace_target.
* ppc-nbsd-nat.c: Include "nbsd-nat.h", as we are now using
nbsd_nat_target.
NetBSD ptrace(2) accepts thread id (LWP) as the 4th argument for threads.
gdb/ChangeLog:
* hppa-nbsd-nat.c (fetch_registers): New variable lwp and pass
it to the ptrace call.
* (store_registers): Likewise.
When running test-cases gdb.threads/step-over-lands-on-breakpoint.exp and
gdb.threads/step-over-trips-on-watchpoint.exp with target board
unix/-flto/-O0/-flto-partition=none/-ffat-lto-objects, we run into timeouts
due not being able to set a breakpoint and then trying to continue to that
breakpoint.
In total, we run into 186 timeouts, which roughly corresponds to half an hour:
...
$ grep "FAIL.*(timeout)" gdb.sum \
| awk '{print $2}' \
| sort \
| uniq -c
66 gdb.threads/step-over-lands-on-breakpoint.exp:
120 gdb.threads/step-over-trips-on-watchpoint.exp:
...
Fix this by bailing out if the first break fails.
Tested on x86_64-linux, both with native and with target board mentioned above.
gdb/testsuite/ChangeLog:
2020-03-20 Tom de Vries <tdevries@suse.de>
* gdb.threads/step-over-lands-on-breakpoint.exp (do_test): Bail out if
first break fails.
* gdb.threads/step-over-trips-on-watchpoint.exp: (do_test): Same.
NetBSD ptrace(2) accepts thread id (LWP) as the 4th argument for threads.
gdb/ChangeLog:
* ppc-nbsd-nat.c (fetch_registers): New variable lwp and pass
it to the ptrace call.
* (store_registers): Likewise.
Unlike most other Operating Systems, NetBSD tracks both pid and lwp.
The process id on NetBSD is stored always in the pid field of ptid.
gdb/ChangeLog:
* inf-ptrace.h: Disable get_ptrace_pid on NetBSD.
* inf-ptrace.c: Likewise.
* (gdb_ptrace): Add.
* (inf_ptrace_target::resume): Update.
* (inf_ptrace_target::xfer_partial): Likewise.
* (inf_ptrace_peek_poke): Change argument `pid' to `ptid'.
* (inf_ptrace_peek_poke): Update.
I was doing some SVE tests on system QEMU and noticed quite a few failures
related to inferior function calls. Any attempt to do an inferior function
call would result in the following:
Unable to set VG register.: Success.
This happens because, after an inferior function call, GDB attempts to restore
the regcache state and updates the SVE register in order. Since the Z registers
show up before the VG register, VG is still INVALID by the time the first Z
register is being updated. So when executing the following code in
aarch64_sve_set_vq:
if (reg_buf->get_register_status (AARCH64_SVE_VG_REGNUM) != REG_VALID)
return false;
By returning false, we signal something is wrong, then we get to this:
/* First store vector length to the thread. This is done first to ensure the
ptrace buffers read from the kernel are the correct size. */
if (!aarch64_sve_set_vq (tid, regcache))
perror_with_name (_("Unable to set VG register."));
Ideally we'd always have a valid VG before attempting to set the Z registers,
but in this case the ordering of registers doesn't make that possible.
I considered reordering the registers to put VG before the Z registers, like
the DWARF numbering, but that would break backwards compatibility with
existing implementations. Also, the Z register numbering is pinned to the V
registers, and adding VG before Z would create a gap for non-SVE targets,
since we wouldn't be able to undefine VG for non-SVE targets.
As a compromise, it seems we can safely fetch the VG register value from
ptrace. The value in the kernel is likely the updated value anyway.
This patch fixed all the failures i saw in the testsuite and caused no further
regressions.
gdb/ChangeLog:
2020-03-19 Luis Machado <luis.machado@linaro.org>
* nat/aarch64-sve-linux-ptrace.c (aarch64_sve_set_vq): If vg is not
valid, fetch vg value from ptrace.
Add gdb_ptrace() that wraps the ptrace(2) API and correctly passes
the pid,lwp pair to the calls on NetBSD; and the result of
get_ptrace_pid() on other BSD Operating Systems.
gdb/ChangeLog:
* x86-bsd-nat.c (gdb_ptrace): New.
* (x86bsd_dr_set): Add new argument `ptid'.
* (x86bsd_dr_get, x86bsd_dr_set, x86bsd_dr_set_control,
x86bsd_dr_set_addr): Update.
In this commit:
commit 24ed6739b6
Date: Thu Jan 30 14:35:40 2020 +0000
gdb/remote: Restore support for 'S' stop reply packet
A regression was introduced such that the W and X packets would give a
warning in some cases. The warning was:
warning: multi-threaded target stopped without sending a thread-id, using first non-exited thread
This problem would arise when:
1. The multi-process extensions to the remote protocol were not
being used, and
2. The inferior has multiple threads.
In this case when the W (or X) packet arrives the ptid of the
stop_reply is set to null_ptid, then when we arrive in
process_stop_reply GDB spots that we have multiple non-exited theads,
but the stop event didn't specify a thread-id.
The problem with this is that the W (and X) packets are actually
process wide events, they apply to all threads. So not specifying a
thread-id is not a problem, in fact, the best these packets allow is
for the remote to specify a process-id, not a thread-id.
If we look at how the W (and X) packets deal with a specified
process-id, then what happens is GDB sets to stop_reply ptid to a
value which indicates all threads in the process, this is done by
creating a value `ptid_t (pid)`, which sets the pid field of the
ptid_t, but leaves the tid field as 0, indicating all threads.
So, this commit does the same thing for the case where there is not
process-id specified. In process_stop_reply we not distinguish
between stop events that apply to all threads, and those that apply to
only one. If the stop event applies to only one thread then we treat
it as before. If, however, the stop event applies to all threads,
then we find the first non-exited thread, and use the pid from this
thread to create a `ptid_t (pid)` value.
If the target has multiple inferiors, and receives a process wide
event without specifying a process-id GDB now gives this warning:
warning: multi-inferior target stopped without sending a process-id, using first non-exited inferior
gdb/ChangeLog:
* remote.c (remote_target::process_stop_reply): Handle events for
all threads differently.
gdb/testsuite/ChangeLog:
* gdb.server/exit-multiple-threads.c: New file.
* gdb.server/exit-multiple-threads.exp: New file.
This commit adds a test that builds a mixed language stack, the stack
contains frames of Fortran, C, and C++. The test prints the backtrace
and explores the stack printing arguments of different types in frames
of different languages.
The core of the test is repeated with GDB's language set to auto,
fortran, c, and c++ in turn to ensure that GDB is happy to print
frames and frame arguments when the language is set to a value that
doesn't match the frame language.
This test currently passes, and there are no known bugs in this area.
The aim of this commit is simply to increase test coverage, as I don't
believe this functionality is currently tested.
gdb/testsuite/ChangeLog:
* gdb.fortran/mixed-lang-stack.c: New file.
* gdb.fortran/mixed-lang-stack.cpp: New file.
* gdb.fortran/mixed-lang-stack.exp: New file.
* gdb.fortran/mixed-lang-stack.f90: New file.
Consider debugging the following C++ program:
struct object
{ int a; };
typedef object *object_p;
static int
get_value (object_p obj)
{
return obj->a;
}
int
main ()
{
object obj;
obj.a = 0;
return get_value (&obj);
}
Now in a GDB session:
(gdb) complete break get_value
break get_value(object*)
break get_value(object_p)
Or:
(gdb) break get_va<TAB>
(gdb) break get_value(object<RETURN>
Function "get_value(object" not defined.
Make breakpoint pending on future shared library load? (y or [n]) n
The reason this happens is that we add completions based on the
msymbol names and on the symbol names. For C++ both of these names
include the parameter list, however, the msymbol names have some
differences from the symbol names, for example:
+ typedefs are resolved,
+ whitespace rules are different around pointers,
+ the 'const' keyword is placed differently.
What this means is that the msymbol names and symbol names appear to
be completely different to GDB's completion tracker, and therefore to
readline when it offers the completions.
This commit builds on the previous commit which reworked the
completion_tracker class. It is now trivial to add a
remove_completion member function, this is then used along with
cp_canonicalize_string_no_typedefs to remove the msymbol aliases from
the completion tracker as we add the symbol names.
Now, for the above program GDB only presents a single completion for
'get_value', which is 'get_value(object_p)'.
It is still possible to reference the symbol using the msymbol name,
so a user can manually type out 'break get_value (object *)' if they
wish and will get the expected behaviour.
I did consider adding an option to make this alias exclusion optional,
in the end I didn't bother as I didn't think it would be very useful,
but I can easily add such an option if people think it would be
useful.
gdb/ChangeLog:
* completer.c (completion_tracker::remove_completion): Define new
function.
* completer.h (completion_tracker::remove_completion): Declare new
function.
* symtab.c (completion_list_add_symbol): Remove aliasing msymbols
when adding a C++ function symbol.
gdb/testsuite/ChangeLog:
* gdb.linespec/cp-completion-aliases.cc: New file.
* gdb.linespec/cp-completion-aliases.exp: New file.
Change-Id: Ie5c7c9fc8ecf973072cfb4a9650867104bf7f50c
In this commit I rewrite how the completion tracker tracks the
completions, and builds its lowest common denominator (LCD) string.
The LCD string is now built lazily when required, and we only track
the completions in one place, the hash table, rather than maintaining
a separate vector of completions.
The motivation for these changes is that the next commit will add the
ability to remove completions from the list, removing a completion
will invalidate the LCD string, so we need to keep hold of enough
information to recompute the LCD string as needed.
Additionally, keeping the completions in a vector makes removing a
completion expensive, so better to only keep the completions in the
hash table.
This commit doesn't add any new functionality itself, and there should
be no user visible changes after this commit.
For testing, I ran the testsuite as usual, but I also ran some manual
completion tests under valgrind, and didn't get any reports about
leaked memory.
gdb/ChangeLog:
* completer.c (completion_tracker::completion_hash_entry): Define
new class.
(advance_to_filename_complete_word_point): Call
recompute_lowest_common_denominator.
(completion_tracker::completion_tracker): Call discard_completions
to setup the hash table.
(completion_tracker::discard_completions): Allow for being called
from the constructor, pass new equal function, and element deleter
when constructing the hash table. Initialise new class member
variables.
(completion_tracker::maybe_add_completion): Remove use of
m_entries_vec, and store more information into m_entries_hash.
(completion_tracker::recompute_lcd_visitor): New function, most
content taken from...
(completion_tracker::recompute_lowest_common_denominator):
...here, this now just visits each item in the hash calling the
above visitor.
(completion_tracker::build_completion_result): Remove use of
m_entries_vec, call recompute_lowest_common_denominator.
* completer.h (completion_tracker::have_completions): Remove use
of m_entries_vec.
(completion_tracker::completion_hash_entry): Declare new class.
(completion_tracker::recompute_lowest_common_denominator): Change
function signature.
(completion_tracker::recompute_lcd_visitor): Declare new function.
(completion_tracker::m_entries_vec): Delete.
(completion_tracker::m_entries_hash): Initialize to NULL.
(completion_tracker::m_lowest_common_denominator_valid): New
member variable.
(completion_tracker::m_lowest_common_denominator_max_length): New
member variable.
Change-Id: I9d1db52c489ca0041b8959ca0d53b7d3af8aea72
When running test-case gdb.opt/inline-locals.exp, I get:
...
Running src/gdb/testsuite/gdb.opt/inline-locals.exp ...
KPASS: gdb.opt/inline-locals.exp: info locals above bar 2 (PRMS gdb/xyz)
KPASS: gdb.opt/inline-locals.exp: info locals above bar 3 (PRMS gdb/xyz)
...
I've opened PR25695 - 'abstract and concrete variable listed both with "info
locals"' to refer to in the PRMS field, and this patch adds that reference.
Furthermore, I noticed that while I see KPASSes, given the problem description
the tests should actually be KFAILs. This patch also fixes that.
Tested on x86_64-linux. With gcc 7.5.0, I get 2 KFAILs. With clang 5.0.2,
the tests pass.
gdb/testsuite/ChangeLog:
2020-03-19 Tom de Vries <tdevries@suse.de>
* gdb.opt/inline-locals.exp: Add kfail PR number. Make kfail matching
more precise.
Add a test-case that tests whether we can set a breakpoint on an inlined
inline function in CU for which the partial symtab has not yet been expanded.
Tested on x86_64-linux, with gcc 4.8.5, gcc-7.5.0, gcc-10.0.1, and clang
5.0.2.
gdb/testsuite/ChangeLog:
2020-03-18 Tom de Vries <tdevries@suse.de>
* gdb.dwarf2/break-inline-psymtab-2.c: New test.
* gdb.dwarf2/break-inline-psymtab.c: New test.
* gdb.dwarf2/break-inline-psymtab.exp: New file.
NetBSD ptrace(2) accepts thread id (LWP) as the 4th argument for threads.
Define gdb_ptrace() a wrapper function for ptrace(2) that properly passes
the pid,lwp pair on NetBSD and the result of get_ptrace_pid() for others.
gdb/ChangeLog:
* i386-bsd-nat.c (gdb_ptrace): New.
* (i386bsd_fetch_inferior_registers,
i386bsd_store_inferior_registers) Switch from pid_t to ptid_t.
* (i386bsd_fetch_inferior_registers,
i386bsd_store_inferior_registers) Use gdb_ptrace.
NetBSD ptrace(2) accepts thread id (LWP) as the 4th argument for threads.
Define gdb_ptrace() a wrapper function for ptrace(2) that properly passes
the pid,lwp pair on NetBSD and the result of get_ptrace_pid() for others.
gdb/ChangeLog:
* amd64-bsd-nat.c (gdb_ptrace): New.
* (amd64bsd_fetch_inferior_registers,
amd64bsd_store_inferior_registers) Switch from pid_t to ptid_t.
* (amd64bsd_fetch_inferior_registers,
amd64bsd_store_inferior_registers) Use gdb_ptrace.
NetBSD ptrace(2) accepts thread id (LWP) as the 4th argument for threads.
Define gdb_ptrace() a wrapper function for ptrace(2) that properly passes
the pid,lwp pair on NetBSD and the result of get_ptrace_pid() for others.
gdb/ChangeLog:
* sparc-nat.c (gdb_ptrace): New.
* sparc-nat.c (sparc_fetch_inferior_registers)
(sparc_store_inferior_registers) Remove obsolete comment.
* sparc-nat.c (sparc_fetch_inferior_registers)
(sparc_store_inferior_registers) Switch from pid_t to ptid_t.
* sparc-nat.c (sparc_fetch_inferior_registers)
(sparc_store_inferior_registers) Use gdb_ptrace.
NetBSD ptrace(2) accepts thread id (LWP) as the 4th argument for threads.
gdb/ChangeLog:
* sh-nbsd-nat.c (fetch_registers): New variable lwp and pass
it to the ptrace call.
* sh-nbsd-nat.c (store_registers): Likewise.
gdb/ChangeLog:
* sh-nbsd-nat.c (sh_nbsd_nat_target): Inherit from
nbsd_nat_target instead of inf_ptrace_target.
* sh-nbsd-nat.c: Include "nbsd-nat.h", as we are now using
nbsd_nat_target.
procfs on NetBSD is optional and not recommended.
* nbsd-nat.c: Include <sys/types.h>, <sys/ptrace.h> and
<sys/sysctl.h>.
* nbsd-nat.c (nbsd_nat_target::pid_to_exec_file): Rewrite.
The DWARF standard appendix E.1 describes techniques that can be used for
compression and deduplication: DIEs can be factored out into a new compilation
unit, and referenced using DW_FORM_ref_addr.
Such a new compilation unit can either use a DW_TAG_compile_unit or
DW_TAG_partial_unit. If a DW_TAG_compile_unit is used, its contents is
evaluated by consumers as though it were an ordinary compilation unit. If a
DW_TAG_partial_unit is used, it's only considered by consumers in the context
of a DW_TAG_imported_unit.
An example of when DW_TAG_partial_unit is required is when the factored out
DIEs are not top-level, f.i. because they were children of a namespace. In
such a case the corresponding DW_TAG_imported_unit will occur as child of the
namespace.
In the case of factoring out DIEs from c++ compilation units, we can factor
out into a new DW_TAG_compile_unit, and no DW_TAG_imported_unit is required.
This begs the question how to interpret a top-level DW_TAG_imported_unit of a
c++ DW_TAG_compile_unit compilation unit. The semantics of
DW_TAG_imported_unit describe that the imported unit logically appears at the
point of the DW_TAG_imported_unit entry. But it's not clear what the effect
should be in this case, since all the imported DIEs are already globally
visible anyway, due to the use of DW_TAG_compile_unit.
So, skip top-level imports of c++ DW_TAG_compile_unit compilation units in
process_imported_unit_die.
Using the cc1 binary from PR23710 comment 1 and setting a breakpoint on do_rpo_vn:
...
$ gdb \
-batch \
-iex "maint set dwarf max-cache-age 316" \
-iex "set language c++" \
-ex "b do_rpo_vn" \
cc1
...
we get a 8.1% reduction in execution time, due to reducing the number of
partial symtabs expanded into full symtabs from 212 to 175.
Build and reg-tested on x86_64-linux.
gdb/ChangeLog:
2020-03-17 Tom de Vries <tdevries@suse.de>
PR gdb/23710
* dwarf2/read.h (struct dwarf2_per_cu_data): Add unit_type and lang
fields.
* dwarf2/read.c (process_psymtab_comp_unit): Initialize unit_type and lang
fields.
(process_imported_unit_die): Skip import of c++ CUs.
When running test-case gdb.linespec/cpcompletion.exp with target board
unix/-flto/-O0/-flto-partition=none/-ffat-lto-objects, we run into lots of
timeouts, in particular with this pattern:
...
FAIL: gdb.linespec/cpcompletion.exp: template-ret-type: \
cmd complete "b template2_"
FAIL: gdb.linespec/cpcompletion.exp: template-ret-type: \
tab complete "b template2_st" (timeout)
FAIL: gdb.linespec/cpcompletion.exp: template-ret-type: \
cmd complete "b template2_st"
FAIL: gdb.linespec/cpcompletion.exp: template-ret-type: \
tab complete "b template2_str" (timeout)
FAIL: gdb.linespec/cpcompletion.exp: template-ret-type: \
cmd complete "b template2_str"
FAIL: gdb.linespec/cpcompletion.exp: template-ret-type: \
tab complete "b template2_stru" (timeout)
...
Fix this by detecting timeouts in test_complete_prefix_range_re and giving up
after 3 consecutive timeouts.
This reduces testing time from ~39m to ~9m.
Tested on x86_64-linux.
The val_print removal series introduced a new possibly-uninitialized
warning in p-valprint.c. Examination of the code shows that the
warning does not indicate a real bug, so this patch silences the
warning by setting the variable in the catch clause of a try/catch.
(The obvious initialization did not work due to a "goto" in this
function.)
gdb/ChangeLog
2020-03-16 Tom Tromey <tom@tromey.com>
* p-valprint.c (pascal_object_print_value): Initialize
base_value.
This patch replaces usage of target descriptions in ARC, where the whole
description is fixed in XML, with new target descriptions where XML describes
individual features, and GDB assembles those features into actual target
description.
v2:
Removed arc.c from ALLDEPFILES in gdb/Makefile.in.
Removed vim modeline from arc-tdep.c to have it in a separate patch.
Removed braces from one line "if/else".
Undid the type change for "jb_pc" (kept it as "int").
Joined the unnecessary line breaks into one line.
No more moving around arm targets in gdb/features/Makefile.
Changed pattern checking for ARC features from "arc/{aux,core}" to "arc/".
v3:
Added include gaurds to arc.h.
Added arc_read_description to _create_ target descriptions less.
v4:
Got rid of ARC_SYS_TYPE_NONE.
Renamed ARC_SYS_TYPE_INVALID to ARC_SYS_TYPE_NUM.
Fixed a few indentations/curly braces.
Converted arc_sys_type_to_str from a macro to an inline function.
gdb/ChangeLog:
2020-03-16 Anton Kolesov <anton.kolesov@synopsys.com>
Shahab Vahedi <shahab@synopsys.com>
* Makefile.in: Add arch/arc.o
* configure.tgt: Likewise.
* arc-tdep.c (arc_tdesc_init): Use arc_read_description.
(_initialize_arc_tdep): Don't initialize old target descriptions.
(arc_read_description): New function to cache target descriptions.
* arc-tdep.h (arc_read_description): Add proto type.
* arch/arc.c: New file.
* arch/arc.h: Likewise.
* features/Makefile: Replace old target descriptions with new.
* features/arc-arcompact.c: Remove.
* features/arc-arcompact.xml: Likewise.
* features/arc-v2.c: Likewise
* features/arc-v2.xml: Likewise
* features/arc/aux-arcompact.xml: New file.
* features/arc/aux-v2.xml: Likewise.
* features/arc/core-arcompact.xml: Likewise.
* features/arc/core-v2.xml: Likewise.
* features/arc/aux-arcompact.c: Generate.
* features/arc/aux-v2.c: Likewise.
* features/arc/core-arcompact.c: Likewise.
* features/arc/core-v2.c: Likewise.
* target-descriptions (maint_print_c_tdesc_cmd): Support ARC features.
PR gdb/25663 points out that dwarf2_name will cache a value in the
bcache and then return a substring. However, this substring return is
only done on the branch that caches the value -- so if the function is
called twice with the same arguments, it will return different values.
This patch fixes this problem.
This area is strange. We cache the entire demangled string, but only
return the suffix. I looked at caching just the suffix, but it turns
out that anonymous_struct_prefix assumes that the entire string is
stored. Also weird is that this code is demangling the linkage name
and then storing the demangled form back into the linkage name
attribute -- that seems bad, because what if some code wants to find
the actual linkage name?
Fixing these issues was non-trivial, though; and in the meantime this
patch seems like an improvement. Regression tested on x86-64
Fedora 30.
gdb/ChangeLog
2020-03-16 Tom Tromey <tromey@adacore.com>
PR gdb/25663:
* dwarf2/read.c (dwarf2_name): Strip leading namespaces after
putting value into bcache.
On Windows x86-64 (when building with MinGW), the size of the "long"
type is 32 bits. amd64_windows_init_abi therefore does:
set_gdbarch_long_bit (gdbarch, 32);
This is also used when the chosen OS ABI is Cygwin, where the "long"
type is 64 bits. GDB therefore gets sizeof(long) wrong when using the
builtin long type:
$ ./gdb -nx --data-directory=data-directory -batch -ex "set architecture i386:x86-64" -ex "set osabi Cygwin" -ex "print sizeof(long)"
The target architecture is assumed to be i386:x86-64
$1 = 4
This patch makes GDB avoid setting the size of the long type to 32 bits
when using the Cygwin OS ABI. it will inherit the value set in
amd64_init_abi.
With this patch, I get:
$ ./gdb -nx --data-directory=data-directory -batch -ex "set architecture i386:x86-64" -ex "set osabi Cygwin" -ex "print sizeof(long)"
The target architecture is assumed to be i386:x86-64
$1 = 8
gdb/ChangeLog:
PR gdb/21500
* amd64-windows-tdep.c (amd64_windows_init_abi): Rename
to...
(amd64_windows_init_abi_common): ... this. Don't set size of
long type.
(amd64_windows_init_abi): New function.
(amd64_cygwin_init_abi): New function.
(_initialize_amd64_windows_tdep): Use amd64_cygwin_init_abi for
the Cygwin OS ABI.
* i386-windows-tdep.c (_initialize_i386_windows_tdep): Clarify
comment.
Before this patch, the "Windows" OS ABI is selected for all Windows
executables, including Cygwin ones. This patch makes GDB differentiate
Cygwin binaries from non-Cygwin ones, and selects the "Cygwin" OS ABI
for the Cygwin ones.
To check whether a Windows PE executable is a Cygwin one, we check the
library list in the .idata section, see if it contains "cygwin1.dll".
I had to add code to parse the .idata section, because BFD doesn't seem
to expose this information. BFD does parse this information, but only
to print it in textual form (function pe_print_idata):
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=bfd/peXXigen.c;h=e42d646552a0ca1e856e082256cd3d943b54ddf0;hb=HEAD#l1261
Here's the relevant portion of the PE format documentation:
https://docs.microsoft.com/en-us/windows/win32/debug/pe-format#the-idata-section
This page was also useful:
https://blog.kowalczyk.info/articles/pefileformat.html#9ccef823-67e7-4372-9172-045d7b1fb006
With this patch applied, this is what I get:
(gdb) file some_mingw_x86_64_binary.exe
Reading symbols from some_mingw_x86_64_binary.exe...
(gdb) show osabi
The current OS ABI is "auto" (currently "Windows").
The default OS ABI is "GNU/Linux".
(gdb) file some_mingw_i386_binary.exe
Reading symbols from some_mingw_i386_binary.exe...
(gdb) show osabi
The current OS ABI is "auto" (currently "Windows").
The default OS ABI is "GNU/Linux".
(gdb) file some_cygwin_x86_64_binary.exe
Reading symbols from some_cygwin_x86_64_binary.exe...
(gdb) show osabi
The current OS ABI is "auto" (currently "Cygwin").
The default OS ABI is "GNU/Linux".
gdb/ChangeLog:
* windows-tdep.h (is_linked_with_cygwin_dll): New declaration.
* windows-tdep.c (CYGWIN_DLL_NAME): New.
(pe_import_directory_entry): New struct type.
(is_linked_with_cygwin_dll): New function.
* amd64-windows-tdep.c (amd64_windows_osabi_sniffer): Select
GDB_OSABI_CYGWIN if the BFD is linked with the Cygwin DLL.
* i386-windows-tdep.c (i386_windows_osabi_sniffer): Likewise.
i386-cygwin-tdep.c has just been renamed to i386-windows-tdep.c, this
patch now renames everything in it that is not Cygwin-specific to
replace "cygwin" with "windows".
Note that I did not rename i386_cygwin_core_osabi_sniffer, since that
appears to be Cygwin-specific.
gdb/ChangeLog:
* i386-windows-tdep.c: Mass-rename "cygwin" to "windows", except
i386_cygwin_core_osabi_sniffer.
Since this file contains things that apply not only to Cygwin binaries,
but also to non-Cygwin Windows binaries, I think it would make more
sense for it to be called i386-windows-tdep.c. It is analogous to
amd64-windows-tdep.c, which we already have.
gdb/ChangeLog:
* i386-cygwin-tdep.c: Rename to...
* i386-windows-tdep.c: ... this.
* Makefile.in (ALL_TARGET_OBS): Rename i386-cygwin-tdep.c to
i386-windows-tdep.c.
* configure.tgt: Likewise.
GDB currently uses the "Cygwin" OS ABI (GDB_OSABI_CYGWIN) for everything
related to Windows. If you build a GDB for a MinGW or Cygwin target, it
will have "Cygwin" as the default OS ABI in both cases (see
configure.tgt). If you load either a MinGW or Cygwin binary, the
"Cygwin" OS ABI will be selected in both cases.
This is misleading, because Cygwin binaries are a subset of the binaries
running on Windows. When building something with MinGW, the resulting
binary has nothing to do with Cygwin. Cygwin binaries are only special
in that they are Windows binaries that link to the cygwin1.dll library
(if my understanding is correct).
Looking at i386-cygwin-tdep.c, we can see that GDB does nothing
different when dealing with Cygwin binaries versus non-Cygwin Windows
binaries. However, there is at least one known bug which would require
us to make a distinction between the two OS ABIs, and that is the size
of the built-in "long" type on x86-64. On native Windows, this is 4,
whereas on Cygwin it's 8.
So, this patch adds a new OS ABI, "Windows", and makes GDB use it for
i386 and x86-64 PE executables, instead of the "Cygwin" OS ABI. A
subsequent patch will improve the OS ABI detection so that GDB
differentiates the non-Cygwin Windows binaries from the Cygwin Windows
binaries, and applies the "Cygwin" OS ABI for the latter.
The default OS ABI remains "Cygwin" for the GDBs built with a Cygwin
target.
I've decided to split the i386_cygwin_osabi_sniffer function in two,
I think it's cleaner to have a separate sniffer for Windows binaries and
Cygwin cores, each checking one specific thing.
gdb/ChangeLog:
* osabi.h (enum gdb_osabi): Add GDB_OSABI_WINDOWS.
* osabi.c (gdb_osabi_names): Add "Windows".
* i386-cygwin-tdep.c (i386_cygwin_osabi_sniffer): Return
GDB_OSABI_WINDOWS when the binary's target is "pei-i386".
(i386_cygwin_core_osabi_sniffer): New function, extracted from
i386_cygwin_osabi_sniffer.
(_initialize_i386_cygwin_tdep): Register OS ABI
GDB_OSABI_WINDOWS for i386.
* amd64-windows-tdep.c (amd64_windows_osabi_sniffer): Return
GDB_OSABI_WINDOWS when the binary's target is "pei-x86-64".
(_initialize_amd64_windows_tdep): Register OS ABI GDB_OSABI_WINDOWS
for x86-64.
* configure.tgt: Use GDB_OSABI_WINDOWS as the default OS ABI
when the target matches '*-*-mingw*'.
I think it makes sense to have it there instead of in the catch-all
defs.h.
gdb/ChangeLog:
* defs.h (enum gdb_osabi): Move to...
* osabi.h (enum gdb_osabi): ... here.
* gdbarch.sh: Include osabi.h in gdbarch.h.
* gdbarch.h: Re-generate.
If I generate two Windows PE executables, one 32 bits and one 64 bits:
$ x86_64-w64-mingw32-gcc test.c -g3 -O0 -o test_64
$ i686-w64-mingw32-gcc test.c -g3 -O0 -o test_32
$ file test_64
test_64: PE32+ executable (console) x86-64, for MS Windows
$ file test_32
test_32: PE32 executable (console) Intel 80386, for MS Windows
When I load the 32 bits binary in my GNU/Linux-hosted GDB, the osabi is
correctly recognized as "Cygwin":
$ ./gdb --data-directory=data-directory -nx test_32
(gdb) show osabi
The current OS ABI is "auto" (currently "Cygwin").
When I load the 64 bits binary in GDB, the osabi is incorrectly
recognized as "GNU/Linux":
$ ./gdb --data-directory=data-directory -nx test_64
(gdb) show osabi
The current OS ABI is "auto" (currently "GNU/Linux").
The 32 bits one gets recognized by the i386_cygwin_osabi_sniffer
function, by its target name:
if (strcmp (target_name, "pei-i386") == 0)
return GDB_OSABI_CYGWIN;
The target name for the 64 bits binaries is "pei-x86-64". It doesn't
get recognized by any osabi sniffer, so GDB falls back on its default
osabi, "GNU/Linux".
This patch adds an osabi sniffer function for the Windows 64 bits
executables in amd64-windows-tdep.c. With it, the osabi is recognized
as "Cygwin", just like with the 32 bits binary.
Note that it may seems strange to have a binary generated by MinGW
(which has nothing to do with Cygwin) be recognized as a Cygwin binary.
This is indeed not accurate, but at the moment GDB uses the Cygwin for
everything Windows. Subsequent patches will add a separate "Windows" OS
ABI for Windows binaries that are not Cygwin binaries.
gdb/ChangeLog:
* amd64-windows-tdep.c (amd64_windows_osabi_sniffer): New
function.
(_initialize_amd64_windows_tdep): Register osabi sniffer.
Test-case gdb.base/gdb-caching-proc.exp tests whether procs declared using
gdb_caching_proc give the same results when called more than once.
While this tests consistency of the procs in the context of that test-case, it
doesn't test consistency across the call sites.
Add a local variable cache_verify to proc gdb_do_cache, that can be set to 1
to verify gdb_caching_proc consistency across the call sites.
Likewise, add a local variable cache_verify_proc to set to the name of the
gdb_caching_proc to verify. This can f.i. be used when changing an existing
proc into a gdb_caching_proc.
Tested on x86_64-linux, with cache_verify set to both 0 and 1.
gdb/testsuite/ChangeLog:
2020-03-16 Tom de Vries <tdevries@suse.de>
* lib/cache.exp (gdb_do_cache): Add and handle local variables
cache_verify and cache_verify_proc.
Since commit a2fedca99c "Implement 'set/show exec-file-mismatch'.", I see the
following regression on openSUSE Leap 15.1:
...
FAIL: gdb.server/solib-list.exp: non-stop 0: target remote \
(got interactive prompt)
FAIL: gdb.server/solib-list.exp: non-stop 1: target remote \
(got interactive prompt)
...
The first FAIL in more detail:
...
(gdb) PASS: gdb.server/solib-list.exp: non-stop 0: file binfile
target remote localhost:2346
Remote debugging using localhost:2346
warning: Mismatch between current exec-file /data/gdb_versions/devel/build/\
gdb/testsuite/outputs/gdb.server/solib-list/solib-list
and automatically determined exec-file /lib64/ld-2.26.so
exec-file-mismatch handling is currently "ask"
Load new symbol table from "/lib64/ld-2.26.so"? (y or n) n
warning: loading /lib64/ld-2.26.so Not confirmed.
Reading /lib64/ld-linux-x86-64.so.2 from remote target...
warning: File transfers from remote targets can be slow. \
Use "set sysroot" to access files locally instead.
Reading /lib64/ld-linux-x86-64.so.2 from remote target...
Reading symbols from target:/lib64/ld-linux-x86-64.so.2...
Reading /lib64/ld-2.26.so-2.26-lp151.18.7.x86_64.debug from remote target...
Reading /lib64/.debug/ld-2.26.so-2.26-lp151.18.7.x86_64.debug from remote \
target...
Reading /data/gdb_versions/devel/install/lib64/debug//lib64/\
ld-2.26.so-2.26-lp151.18.7.x86_64.debug from remote target...
Reading /data/gdb_versions/devel/install/lib64/debug/lib64/\
/ld-2.26.so-2.26-lp151.18.7.x86_64.debug from remote target...
Reading target:/data/gdb_versions/devel/install/lib64/debug/lib64/\
/ld-2.26.so-2.26-lp151.18.7.x86_64.debug from remote target...
(No debugging symbols found in target:/lib64/ld-linux-x86-64.so.2)
0x00007ffff7dd7ea0 in ?? ()
(gdb) FAIL: gdb.server/solib-list.exp: non-stop 0: target remote (got \
interactive prompt)
...
The commit introduces the "Load new symbol table from" question, and
gdb_test_multiple defaults to answering "no" and reporting the
"got interactive prompt" FAIL.
This FAIL is not seen on f.i. debian 10.2. The difference originates from the
fact that the solib-list executable has debug-info in the openSUSE case, while
it doesn't in the debian case.
We can prevent the failure on openSUSE by stripping the executable from
debug-info:
...
+ exec strip --strip-debug ${binfile}
...
The difference in behaviour is a bug or improvement opportunity in the
exec-file-mismatch, filed as PR25475.
This patch fixes the FAIL by handling the question in the test-case.
Tested on x86_64-linux.
Tested on x86_64-linux with the gdbserver part of the patch introducing the
test-case reverted to ensure that this still FAILs.
gdb/testsuite/ChangeLog:
2020-03-15 Tom de Vries <tdevries@suse.de>
* gdb.server/solib-list.exp: Handle
'Load new symbol table from "/lib64/ld-2.26.so"? (y or n)'.
When running test-case gdb.base/maint.exp with check-read1, I run into:
...
FAIL: gdb.base/maint.exp: (timeout) maint print objfiles
...
The FAIL happens because command output contains long lines like this:
...
file1 at $hex, file2 at $hex, ..., $file$n at $hex,
...
F.i., such a line for libc.so.debug contains 82000 chars.
Fix this this by reading long lines bit by bit.
Also, replace the testing of the command output formulated using a gdb_send
combined with gdb_expect-in-a-loop, with a regular gdb_test_multiple with
exp_continue.
Tested on x86_64-linux, with make targets check and check-read1.
gdb/testsuite/ChangeLog:
2020-03-15 Tom de Vries <tdevries@suse.de>
* gdb.base/maint.exp: Use exp_continue in long lines for "maint print
objfiles".
A user noticed that "watch -location" would fail with a "restrict"
pointer. The issue here is that if the DWARF mentions "restrict", gdb
will put this into the type name -- but then the C parser will not be
able to parse this type.
This patch adds support for "restrict" and "_Atomic" to the C parser.
C++ doesn't have "restrict", but does have some GCC extensions. The
type printer is changed to handle this difference as well, so that
watch expressions will work properly.
gdb/ChangeLog
2020-03-14 Tom Tromey <tom@tromey.com>
* c-typeprint.c (cp_type_print_method_args): Print "__restrict__"
for C++.
(c_type_print_modifier): Likewise. Add "language" parameter.
(c_type_print_varspec_prefix, c_type_print_base_struct_union)
(c_type_print_base_1): Update.
* type-stack.h (enum type_pieces) <tp_atomic, tp_restrict>: New
constants.
* type-stack.c (type_stack::insert): Handle tp_atomic and
tp_restrict.
(type_stack::follow_type_instance_flags): Likewise.
(type_stack::follow_types): Likewise. Merge type-following code.
* c-exp.y (RESTRICT, ATOMIC): New tokens.
(space_identifier, cv_with_space_id)
(const_or_volatile_or_space_identifier_noopt)
(const_or_volatile_or_space_identifier): Remove.
(single_qualifier, qualifier_seq_noopt, qualifier_seq): New
rules.
(ptr_operator, typebase): Update.
(enum token_flag) <FLAG_C>: New constant.
(ident_tokens): Add "restrict", "__restrict__", "__restrict", and
"_Atomic".
(lex_one_token): Handle FLAG_C.
gdb/testsuite/ChangeLog
2020-03-14 Tom Tromey <tom@tromey.com>
* gdb.base/cvexpr.exp: Add test for _Atomic and restrict.
When running test-case gdb.mi/mi-fortran-modules.exp with check-read1, I run
into:
...
FAIL: gdb.mi/mi-fortran-modules.exp: -symbol-info-module-functions (timeout)
FAIL: gdb.mi/mi-fortran-modules.exp: -symbol-info-module-functions \
--name _all (unexpected output)
FAIL: gdb.mi/mi-fortran-modules.exp: -symbol-info-module-functions \
--module mod[123] (unexpected output)
FAIL: gdb.mi/mi-fortran-modules.exp: -symbol-info-module-variables \
(unexpected output)
...
Fix this by using exp_continue.
Tested on x86_64, using make target check and check-read1.
gdb/testsuite/ChangeLog:
2020-03-14 Tom de Vries <tdevries@suse.de>
* gdb.mi/mi-fortran-modules.exp: Use exp_continue.
NetBSD ptrace(2) accepts thread id (LWP) as the 4th argument for threads.
gdb/ChangeLog:
* m68k-bsd-nat.c (fetch_registers): New variable lwp and pass
it to the ptrace call.
* m68k-bsd-nat.c (store_registers): Likewise.
gdb/ChangeLog:
* m68k-bsd-nat.c (m68k_bsd_nat_target): Inherit from
nbsd_nat_target instead of inf_ptrace_target.
* m68k-bsd-nat.c: Include "nbsd-nat.h", as we are now using
nbsd_nat_target.
Fixes build on NetBSD. types.h does not define register_t by default.
gdb/ChangeLog:
* m68k-bsd-nat.c: Define _KERNTYPES to get the declaration of
register_t.
NetBSD ptrace(2) accepts thread id (LWP) as the 4th argument for threads.
gdb/ChangeLog:
* alpha-bsd-nat.c (fetch_registers): New variable lwp and pass
it to the ptrace call.
* alpha-bsd-nat.c (store_registers): Likewise.
gdb/ChangeLog:
* alpha-bsd-nat.c (alpha_netbsd_nat_target): Inherit from
nbsd_nat_target instead of inf_ptrace_target.
* alpha-bsd-nat.c: Include "nbsd-nat.h", as we are now using
nbsd_nat_target.
Fixes build on NetBSD. types.h does not define register_t by default.
gdb/ChangeLog:
* alpha-bsd-nat.c: Define _KERNTYPES to get the declaration of
register_t.
When running test-case gdb.threads/attach-many-short-lived-threads.exp with
check-read1, I ran into:
...
FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 1: \
no new threads (timeout)
...
Fix this by rewriting the gdb_test_multiple call using -lbl and exp_continue.
Tested on x86_64-linux, with make targets check and check-read1.
gdb/testsuite/ChangeLog:
2020-03-14 Tom de Vries <tdevries@suse.de>
* gdb.threads/attach-many-short-lived-threads.exp: Read "info threads"
result in line-by-line fashion.
gdb/ChangeLog:
* arm-nbsd-nat.c (arm_netbsd_nat_target): Inherit from
nbsd_nat_target instead of inf_ptrace_target.
* arm-nbsd-nat.c: Include "nbsd-nat.h", as we are now using
nbsd_nat_target.
NetBSD ptrace(2) PT_GETDBREGS/PT_SETDBREGS accepts thread id (LWP)
as the 4th argument for threads.
gdb/ChangeLog:
* x86-bsd-nat.c (x86bsd_dr_get): New variable lwp and pass
it to the ptrace call.
* x86-bsd-nat.c (x86bsd_dr_set): Likewise.
ptrace(2) PT_GETREGS/PT_SETREGS accepts thread id (LWP) as the 4th
argument for threads.
gdb/ChangeLog:
* vax-bsd-nat.c (vaxbsd_supply_gregset): New variable lwp and pass
it to the ptrace call.
* vax-bsd-nat.c (vaxbsd_collect_gregset): Likewise.
gdb/ChangeLog:
* vax-bsd-nat.c (vax_bsd_nat_target): Inherit from nbsd_nat_target
instead of inf_ptrace_target.
* vax-bsd-nat.c: Include "nbsd-nat.h", as we are now using
nbsd_nat_target.
Fixes build on NetBSD. types.h does not define register_t by default.
gdb/ChangeLog:
* mips-nbsd-nat.c: Define _KERNTYPES to get the declaration of
register_t.
Fixes build on NetBSD. types.h does not define register_t by default.
gdb/ChangeLog:
* ppc-nbsd-nat.c: Define _KERNTYPES to get the declaration of
register_t.
Fixes build on NetBSD. types.h does not define register_t by default.
gdb/ChangeLog:
* vax-bsd-nat.c: Define _KERNTYPES to get the declaration of
register_t.
When running testcase gdb.cp/step-and-next-inline.exp, I get:
...
Running src/gdb/testsuite/gdb.cp/step-and-next-inline.exp ...
gdb compile failed, g++: error: unrecognized debug output level \
'statement-frontiers'
gdb compile failed, g++: error: unrecognized debug output level \
'statement-frontiers'
=== gdb Summary ===
# of untested testcases 2
...
Fix this by using a new gdb_caching_proc supports_statement_frontiers.
Tested on x86_64-linux, with gcc 7.5.0 (which does not support
-gstatement-frontiers) and with gcc 8.4.0 (which does support
-gstatement-frontiers).
gdb/testsuite/ChangeLog:
2020-03-14 Tom de Vries <tdevries@suse.de>
* lib/gdb.exp (supports_statement_frontiers): New proc.
* gdb.cp/step-and-next-inline.exp: Use supports_statement_frontiers.
With test-case gdb.base/printcmds.exp, I run into:
...
(gdb) print teststring2^M
$563 = (charptr) "more contents"^M
(gdb) FAIL: gdb.base/printcmds.exp: print teststring2
...
The corresponding test is:
...
gdb_test "print teststring2" " = (charptr) \"more contents\""
...
Fix the FAIL by adding the missing quoting for the parentheses around charptr.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-03-14 Tom de Vries <tdevries@suse.de>
* gdb.base/printcmds.exp: Add missing quoting for "print
teststring2".
This changes the extension language pretty-printers to use the value
API.
Note that new functions were needed, for both Guile and Python.
Currently both languages always wrap values by removing the values
from the value chain. This makes sense to avoid strange behavior with
watchpoints, and to avoid excessive memory use. However, when
printing, it's important to leave the passed-in value untouched, in
case pretty-printing does nothing -- that way the caller can still
access it.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* valprint.c (do_val_print): Update.
* python/python-internal.h (gdbpy_apply_val_pretty_printer): Take
a struct value.
(value_to_value_object_no_release): Declare.
* python/py-value.c (value_to_value_object_no_release): New
function.
* python/py-prettyprint.c (gdbpy_apply_val_pretty_printer): Take a
struct value.
* guile/scm-value.c (vlscm_scm_from_value_no_release): New
function.
* guile/scm-pretty-print.c (gdbscm_apply_val_pretty_printer): Take
a struct value.
* guile/guile-internal.h (vlscm_scm_from_value_no_release):
Declare.
(gdbscm_apply_val_pretty_printer): Take a struct value.
* extension.h (apply_ext_lang_val_pretty_printer): Take a struct
value.
* extension.c (apply_ext_lang_val_pretty_printer): Take a struct
value.
* extension-priv.h (struct extension_language_ops)
<apply_val_pretty_printer>: Take a struct value.
* cp-valprint.c (cp_print_value): Create a struct value.
(cp_print_value): Update.
This converts print_field_values to use the value-based API, by having
it call common_val_print rather than val_print.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* ada-valprint.c (print_field_values): Call common_val_print.
This adds ada_value_print_array, a value-based analogue of
ada_val_print_array. It also removes some unused parameters from a
couple of helper functions.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* ada-valprint.c (val_print_packed_array_elements): Remove
bitoffset and val parameters. Call common_val_print.
(ada_val_print_string): Remove offset, address, and original_value
parameters.
(ada_val_print_array): Update.
(ada_value_print_array): New function.
(ada_value_print_1): Call it.
This converts ada_value_print to the value-based API by using
common_val_print rather than val_print.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* ada-valprint.c (ada_value_print): Use common_val_print.
This converts ada_val_print_ref to the value-based API by using
common_val_print rather than val_print.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* ada-valprint.c (ada_val_print_ref): Use common_val_print.
This adds ada_value_print_num, a value-based analogue of
ada_val_print_num.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* ada-valprint.c (ada_value_print_num): New function.
(ada_value_print_1): Use it.
This rewrites the TYPE_CODE_FLT case in ada_value_print_1 to be purely
value-based.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* ada-valprint.c (ada_value_print_1) <TYPE_CODE_FLT>: Rewrite.
This adds ada_value_print_ptr, a value-based analogue of
ada_val_print_ptr.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* ada-valprint.c (ada_value_print_ptr): New function.
(ada_value_print_1): Use it.
This rewrites ada_value_print_inner, introducing a new
ada_value_print_1, an analogue of ada_val_print_1. Because it was
simple to do, this also converts ada_val_print_gnat_array to be
valued-based and updates the uses.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* ada-valprint.c (ada_val_print_gnat_array): Take a struct value;
call common_val_print.
(ada_val_print_1): Update.
(ada_value_print_1): New function.
(ada_value_print_inner): Rewrite.
This adds cp_print_value, a value-based analogue of cp_print_val, and
changes cp_print_value_fields to use it.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* cp-valprint.c (cp_print_value_fields): Update.
(cp_print_value): New function.
This adds cp_print_value_fields and c_value_print_struct, value-based
analogues of the corresponding val-printing functions. Note that the
Modula-2 printing code also calls cp_print_val_fields, and so is
updated to call the function function.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* m2-valprint.c (m2_value_print_inner): Use
cp_print_value_fields.
* cp-valprint.c (cp_print_value_fields): New function.
* c-valprint.c (c_value_print_struct): New function.
(c_value_print_inner): Use c_value_print_struct.
* c-lang.h (cp_print_value_fields): Declare.
This adds c_value_print_array, a value-based analogue of
c_val_print_array.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* c-valprint.c (c_value_print_array): New function.
(c_value_print_inner): Use it.
This adds c_value_print_memberptr, a value-based analogue of
c_val_print_memberptr.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* c-valprint.c (c_value_print_memberptr): New function.
(c_value_print_inner): Use it.
This adds c_value_print_int, a value-based analogue of
c_val_print_int.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* c-valprint.c (c_value_print_int): New function.
(c_value_print_inner): Use it.
This adds c_value_print_ptr, a value-based analogue of
c_val_print_ptr.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* c-valprint.c (c_value_print_ptr): New function.
(c_value_print_inner): Use it.
This rewrites c_value_print_inner, copying in the body of
c_val_print_inner and adusting as needed. This will form the base of
future changes to fully convert this to using the value-based API
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* c-valprint.c (c_value_print_inner): Rewrite.
This adds generic_value_print_complex, a value-based analogue of
generic_val_print_complex.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* valprint.c (generic_value_print_complex): New function.
(generic_value_print): Use it.
This changes generic_val_print_float not to call
val_print_scalar_formatted. This lets generic_value_print then use
value_print_scalar_formatted instead.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* valprint.c (generic_val_print_float): Don't call
val_print_scalar_formatted.
(generic_val_print, generic_value_print): Update.
This adds generic_value_print_char, a value-based analogue of
generic_val_print_char.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* valprint.c (generic_value_print_char): New function
(generic_value_print): Use it.
This adds generic_value_print_int, a value-based analogue of
generic_val_print_int.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* valprint.c (generic_value_print_int): New function.
(generic_value_print): Use it.
This adds generic_value_print_bool, a value-based analogue of
generic_val_print_bool.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* valprint.c (generic_value_print_bool): New function.
(generic_value_print): Use it.
This removes the call to val_print_scalar_formatted from
generic_val_print_func, allowing generic_value_print to call the
value-based variant instead.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* valprint.c (generic_val_print_func): Simplify.
(generic_val_print, generic_value_print): Update.
This remove generic_val_print_flags in favor of using the value-based
API where possible.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* valprint.c (generic_val_print_flags): Remove.
(generic_val_print, generic_value_print): Update.
(val_print_type_code_flags): Add original_value parameter.
This removes a call to val_print_scalar_formatted from
generic_val_print_enum, preferring to do the work in the callers.
This lets generic_value_print use the value-based API.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* valprint.c (generic_val_print): Update.
(generic_value_print): Update.
* valprint.c (generic_val_print_enum): Don't call
val_print_scalar_formatted.
This introduces generic_value_print_ptr, a value-based analogue of
generic_val_print_ptr, and changes generic_value_print to use it.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* valprint.c (generic_value_print): Call generic_value_print_ptr.
* valprint.c (generic_value_print_ptr): New function.
This rewrites generic_value_print, by copying in the body of
generic_val_print and making the needed adjustments.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* valprint.c (generic_value_print): Rewrite.
This finishes the conversion of Pascal to the value-based API, by
introducing two more value-based analogues of existing val-print
functions.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* p-valprint.c (pascal_object_print_value_fields)
(pascal_object_print_value): New functions.
This rewrites pascal_value_print_inner, copying in the body of
pascal_val_print_inner and adusting as needed. This will form the
base of future changes to fully convert this to using the value-based
API.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* p-valprint.c (pascal_value_print_inner): Rewrite.
This finishes the conversion of the Fortran printing code to the
value-based API. The body of f_val_print is copied into
f_value_print_innner, and then modified as needed to use the value
API.
Note that not all calls must be updated. For example, f77_print_array
remains "val-like", because it does not result in any calls to
val_print (f77_print_array_1 calls common_val_print, which is
nominally value-based).
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* f-valprint.c (f_value_print_innner): Rewrite.
This finishes the conversion of Modula-2 printing to the value-based
API. It does so by copying the body of m2_val_print into
m2_value_print_inner, and then introducing new functions as needed to
use the value API.
The "val_" API code continues to exist, because it's still possible
for it to be called via some paths. This code will all be removed at
the end of the series.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* m2-valprint.c (m2_print_unbounded_array): New overload.
(m2_print_unbounded_array): Update.
(m2_print_array_contents): Take a struct value.
(m2_value_print_inner): Rewrite.
As with Rust and Go, it was straightforward to convert D to the
value-based API directly.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* d-valprint.c (dynamic_array_type): Call d_value_print_inner.
(d_value_print_inner): New function.
* d-lang.h (d_value_print_inner): Declare.
* d-lang.c (d_language_defn): Use d_value_print_inner.
This introduces go_value_print_inner, a modified copy of go_val_print.
Unlike some of the other languages, Go was straightforward to convert
to the value-based API all at once, so this patch takes that approach.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* go-valprint.c (go_value_print_inner): New function.
* go-lang.h (go_value_print_inner): Declare.
* go-lang.c (go_language_defn): Use go_value_print_inner.
For Rust, it was simple to convert the printing code to the
value-based API all at once.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* rust-lang.c (val_print_struct, rust_print_enum): Use the value
API.
(rust_val_print): Rewrite.
(rust_value_print_inner): New function, from rust_val_print.
(rust_language_defn): Use rust_value_print_inner.
This introduces c_value_print_inner, which implements the
la_value_print_inner method for the C family of languages. In this
patch, it is just a simple wrapper of c_val_print. However,
subsequent patches will convert it to use the value API. The
transformation is done this way to make each patch easier to review.
Future patches will apply this same treatment to other languages as
well.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* opencl-lang.c (opencl_language_defn): Use c_value_print_inner.
* objc-lang.c (objc_language_defn): Use c_value_print_inner.
* c-valprint.c (c_value_print_inner): New function.
* c-lang.h (c_value_print_inner): Declare.
* c-lang.c (c_language_defn, cplus_language_defn)
(asm_language_defn, minimal_language_defn): Use
c_value_print_inner.
pascal_object_print_value_fields is only needed in p-valprint.c, so
make it static.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* p-valprint.c (pascal_object_print_value_fields): Now static.
* p-lang.h (pascal_object_print_value_fields): Don't declare.
This slightly simplifies c_val_print_array by moving a variable to a
more inner scope and removing a dead assignment.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* c-valprint.c (c_val_print_array): Simplify.
This introduces value_print_array_elements, which is an analogue of
val_print_array_elements that uses the value API.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* valprint.c (value_print_array_elements): New function.
* valprint.h (value_print_array_elements): Declare.
A couple of spots could be easily converted to use
value_print_scalar_formatted. This patch makes this change.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* printcmd.c (print_formatted): Use value_print_scalar_formatted.
* mips-tdep.c (mips_print_register): Use
value_print_scalar_formatted.
This introduces a value_print_scalar_formatted, which is an analogue
of val_print_scalar_formatted that uses the value API.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* valprint.h (value_print_scalar_formatted): Declare.
* valprint.c (value_print_scalar_formatted): New function.
This introduces generic_value_print, which is a value-based analogue
to generic_val_print. For now this is unused and simply calls
generic_val_print, but subsequent patches will both change this
function to work using the value API directly, and convert callers of
generic_val_print to call this instead.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* valprint.h (generic_value_print): Declare.
* valprint.c (generic_value_print): New function.
The plan for removing val_print is, essentially, to first duplicate
printing code as needed to use the value API; and then remove the
val_print code. This makes it possible to do the changes
incrementally while keeping everything working.
This adds a new la_value_print_inner function pointer to struct
language_defn. Eventually this will replace la_val_print. This patch
also changes printing to prefer this API, when available -- but no
language defines it yet.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* valprint.c (do_val_print): Call la_value_print_inner, if
available.
* rust-lang.c (rust_language_defn): Update.
* p-lang.c (pascal_language_defn): Update.
* opencl-lang.c (opencl_language_defn): Update.
* objc-lang.c (objc_language_defn): Update.
* m2-lang.c (m2_language_defn): Update.
* language.h (struct language_defn) <la_value_print_inner>: New
member.
* language.c (unknown_language_defn, auto_language_defn): Update.
* go-lang.c (go_language_defn): Update.
* f-lang.c (f_language_defn): Update.
* d-lang.c (d_language_defn): Update.
* c-lang.c (c_language_defn, cplus_language_defn)
(asm_language_defn, minimal_language_defn): Update.
* ada-lang.c (ada_language_defn): Update.
This changes c_value_print to call common_val_print. This is more
complicated than the usual sort of common_val_print change, due to the
handling of RTTI.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* c-valprint.c (c_value_print): Use common_val_print.
gdb/testsuite/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* gdb.base/printcmds.exp (test_print_strings): Add regression
test.
* gdb.base/printcmds.c (charptr): New typedef.
(teststring2): New global.
This changes a spot in cp-valprint.c to use common_val_print rather
than val_print.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* cp-valprint.c (cp_print_static_field): Use common_val_print.
This changes a couple spots in f-valprint.c to use common_val_print
rather than val_print.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* f-valprint.c (f77_print_array_1, f_val_print): Use
common_val_print.
This changes some spots in riscv-tdep.c to use common_val_print rather
than val_print.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* riscv-tdep.c (riscv_print_one_register_info): Use
common_val_print.
This changes a spot in mi-main.c to use common_val_print rather than
val_print.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* mi/mi-main.c (output_register): Use common_val_print.
This changes some spots in infcmd.c to use common_val_print (which,
despite its name, is a value-based API) rather than val_print.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* infcmd.c (default_print_one_register_info): Use
common_val_print.
A (much) later patch will remove the call to value_check_printable
from common_val_print. This will needed to preserve some details of
how optimized-out structures are printed.
However, doing this will also break dw2-op-out-param.exp. Making the
change causes "bt" to print:
However, the test wants to see:
... operand2=<optimized out>
That is, a wholly-optimized out structure should not print its fields.
So, this patch introduces a new common_val_print_checked, which calls
value_check_printable first, and then arranges to use it in the one
spot that affects the test suite.
I was not completely sure if it would be preferable to change the
test. However, I reasoned that, assuming this output was intentional
in the first place, in a backtrace space is at a premium and so this
is a reasonable approach. In other spots calling common_val_print,
this behavior is probably unintended, or at least a "don't care".
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* valprint.h (common_val_print_checked): Declare.
* valprint.c (common_val_print_checked): New function.
* stack.c (print_frame_arg): Use common_val_print_checked.
This changes val_print and common_val_print to use a new helper
function. A theme in the coming patches is that calls to val_print
itself should be removed. This is the first such patch; at the end of
the series, we'll remove val_print and simplify do_val_print.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* valprint.c (do_val_print): New function, from val_print.
(val_print): Use do_val_print.
(common_val_print): Use do_val_print.
Switching the low-level printing to use the value API means we will be
using more temporary values. This adds a scoped_value_mark to
value_print, so that these intermediates are destroyed in a timely
way.
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* valprint.c (value_print): Use scoped_value_mark.
Removes paths from some test names, and make the test names unique in
the gdb.base/break-interp.exp test file.
gdb/testsuite/ChangeLog:
* gdb.base/break-interp.exp: Use the tail of the filename, not the
full path in the test name.
(test_ld): Add some with_test_prefix blocks to make test names
unique.
With debug info packages for system libs installed, I run into buffer full
errors with test-case gdb.mi/mi-sym-info.exp. Fix these using exp_continue.
This exposes timeouts due to gdb taking a long time before starting to print
output. Fix these using with_timeout_factor.
Tested on x86_64-linux, with make targets check and check-read1.
gdb/testsuite/ChangeLog:
2020-03-13 Tom de Vries <tdevries@suse.de>
* gdb.mi/mi-sym-info.exp: Fix buffer full errors, and timeouts.
With debug info packages for system libraries installed, I currently run into
some "internal buffer is full" errors with test-case gdb.mi/mi-sym-info.exp,
but if I disable the corresponding tests, I get further-on:
...
FAIL: gdb.mi/mi-sym-info.exp: List all functions matching pattern f3 \
(unexpected output)
FAIL: gdb.mi/mi-sym-info.exp: List all functions matching type void \
(unexpected output)
FAIL: gdb.mi/mi-sym-info.exp: List all variables matching type float \
(unexpected output)
FAIL: gdb.mi/mi-sym-info.exp: -symbol-info-functions --max-results 1 \
(unexpected output)
FAIL: gdb.mi/mi-sym-info.exp: -symbol-info-functions --max-results 2 \
(unexpected output)
...
Fix this by making the matching more precise.
Tested on x86_64-linux.
Also tested with an extra:
...
mi_gdb_test "set debug-file-directory"
...
to prevent gdb from finding the debug info for system libraries.
gdb/testsuite/ChangeLog:
2020-03-13 Tom de Vries <tdevries@suse.de>
* gdb.mi/mi-sym-info.exp: Make matching more precise.
Consider test-case gdb.dwarf2/imported-unit.exp.
It contains a CU with type int:
...
<0><129>: Abbrev Number: 2 (DW_TAG_compile_unit)
<12a> DW_AT_language : 4 (C++)
<12b> DW_AT_name : imported_unit.c
<1><13b>: Abbrev Number: 3 (DW_TAG_base_type)
<13c> DW_AT_byte_size : 4
<13d> DW_AT_encoding : 5 (signed)
<13e> DW_AT_name : int
...
which is imported in another CU:
...
<0><d2>: Abbrev Number: 2 (DW_TAG_compile_unit)
<d3> DW_AT_language : 4 (C++)
<d4> DW_AT_name : <artificial>
<1><e1>: Abbrev Number: 3 (DW_TAG_imported_unit)
<e2> DW_AT_import : <0x129> [Abbrev Number: 2]
...
However, if we print the partial symbols:
...
$ gdb -batch imported-unit -ex "maint print psymbols"
...
we see type int both in the importing CU:
...
Partial symtab for source file <artificial>@0xc7 (object 0x29f9b80)
...
Depends on 1 other partial symtabs.
0 0x2a24240 imported_unit.c
Global partial symbols:
`main', function, 0x4004b2
Static partial symbols:
`int', type, 0x0
...
and in the imported CU:
...
Partial symtab for source file imported_unit.c (object 0x2a24240)
...
Depends on 0 other partial symtabs.
Shared partial symtab with user 0x29f9b80
Static partial symbols:
`int', type, 0x0
...
This is an artefact resulting from the fact that all CUs in an objfile
share the same storage array for static partial symbols (and another array for
global partial symbols), using a range to describe their symbols.
Then when scanning the partial symbols of a CU and encountering an import, either:
- the referred CU has not been parsed yet, and will be parsed, and the range of
static partial symbols of the referred CU will be a subrange of the range of
static partial symbols of this CU, or
- the referred CU has already been parsed, and the range of static partial
symbols of the referred CU will not be a subrange of the range of static
partial symbols of this CU.
This is inconsistent handling, and confuses the notion of a symbol belonging to
a single symtab.
Furthermore, it might slow down searches, given that the symbol needs to be
skipped twice.
Finally, the same issue holds for global partial symbols, where the range of a
CU is sorted after parsing is finished. Obviously sorting the range of a CU
may invalidate subranges, effectively moving symbols in and out of imported
CUs.
Fix this for both static and global partial symbols, by gathering partial
symbols in a per-CU vector, and adding those symbols to the per-objfile
storage only once complete.
Tested on x86_64-linux, with native and board cc-with-dwz and cc-with-dwz-m.
gdb/ChangeLog:
2020-03-13 Tom de Vries <tdevries@suse.de>
PR symtab/25646
* psymtab.c (partial_symtab::partial_symtab): Don't set
globals_offset and statics_offset. Push element onto
current_global_psymbols and current_static_psymbols stacks.
(concat): New function.
(end_psymtab_common): Set globals_offset and statics_offset. Pop
element from current_global_psymbols and current_static_psymbols
stacks. Concat popped elements to global_psymbols and
static_symbols.
(add_psymbol_to_list): Use current_global_psymbols and
current_static_psymbols stacks.
* psymtab.h (class psymtab_storage): Add current_global_psymbols and
current_static_psymbols fields.
gdb/testsuite/ChangeLog:
2020-03-13 Tom de Vries <tdevries@suse.de>
PR symtab/25646
* gdb.dwarf2/imported-unit.exp: Add test.
When running gdb.mi/mi-sym-info.exp on openSUSE Leap 15.1, I get:
...
FAIL: gdb.mi/mi-sym-info.exp: List all functions matching type void \
(unexpected output)
FAIL: gdb.mi/mi-sym-info.exp: -symbol-info-variables --max-results 3 \
(unexpected output)
FAIL: gdb.mi/mi-sym-info.exp: -symbol-info-types --max-results 4 \
(unexpected output)
...
The executable contains debug info from files other than the source files:
...
$ readelf -wi mi-sym-info | grep "DW_AT_name.*\.[cS]$" | awk '{print $8}'
../sysdeps/x86_64/start.S
init.c
../sysdeps/x86_64/crti.S
src/gdb/testsuite/gdb.mi/mi-sym-info-1.c
src/gdb/testsuite/gdb.mi/mi-sym-info-2.c
elf-init.c
../sysdeps/x86_64/crtn.S
...
The test does not expect this extra info, resulting in matching failures.
Fix this by restricting the failing commands using --name.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-03-13 Tom de Vries <tdevries@suse.de>
* gdb.mi/mi-sym-info-2.c (another_char_t, another_short_t): New typedef.
(var1, var2): New variable.
* gdb.mi/mi-sym-info.exp: Add --name to various commands to restrict
matching symbols.
With test-case gdb.tui/corefile-run.exp and make target check-read1, I run
into:
...
FAIL: gdb.tui/corefile-run.exp: run until the end
...
In more detail, using -v:
...
PASS: gdb.tui/corefile-run.exp: load corefile
^M+++ _ctl_0x0d
^[[17d+++ _csi_d <<<17>>>
^[[M+++ _csi_M <<<>>>
^[[24d+++ _csi_d <<<24>>>
(INSERT <<(>>
gINSERT <<g>>
dINSERT <<d>>
bINSERT <<b>>
)INSERT <<)>>
INSERT << >>
FAIL: gdb.tui/corefile-run.exp: run until the end
...
With some debugging code added in wait_for, what happens becomes more clear:
...
if {[regexp -- $wait_for $prev]} {
+ verbose -log "\nwait_for: MATCHED line ($_cur_y): \"$prev\""
+ verbose -log "wait_for: AGAINST regexp: \"$wait_for\""
...
In corefile-run.exp, we execute:
...
Term::command "run"
...
and in proc Term::command, we send the command, and then call wait_for:
...
proc command {cmd} {
send_gdb "$cmd\n"
wait_for [string_to_regexp $cmd]
}
...
which first waits for the command string, and then for the prompt.
In this case however, the matching of the command string triggers on a
previous line:
...
wait_for: MATCHED line (16): \
"(gdb) core-file corefile-run.core[New LWP 6426] <lots-of-spaces>"
wait_for: AGAINST regexp: "run"
...
and from there on things go out of sync, eventually resulting in the FAIL.
Fix this in proc command by more precisely specifying the expected pattern:
adding a ^$gdb_prompt prefix.
Add a command_no_prompt_prefix variant to use for initial terminal commands
where there's no prompt yet.
Tested gdb.tui/*.exp on x86_64-linux, with make target check and check-read1.
gdb/testsuite/ChangeLog:
2020-03-13 Tom de Vries <tdevries@suse.de>
* lib/tuiterm.exp (Term::command_no_prompt_prefix): New proc.
(Term::command): Use prompt prefix.
(Term::enter_tui): Use command_no_prompt_prefix instead of prefix.
* gdb.tui/tui-layout-asm-short-prog.exp: Use
command_no_prompt_prefix instead of prefix.
* gdb.tui/tui-layout-asm.exp: Same.
There are no more callers to deprecated_add_core_fns, now that I have
removed the usage from CRIS and ARM/NetBSD. So this patch cleans up
all the related code and makes corelow.c a lot more readable.
gdb/ChangeLog:
2020-03-12 Christian Biesinger <cbiesinger@google.com>
* corelow.c (sniff_core_bfd): Remove.
(class core_target) <m_core_vec>: Remove.
(core_target::core_target): Update.
(core_file_fns): Remove.
(deprecated_add_core_fns): Remove.
(default_core_sniffer): Remove.
(sniff_core_bfd): Remove.
(default_check_format): Remove.
(gdb_check_format): Remove.
(core_target_open): Update.
(core_target::get_core_register_section): Update.
(get_core_registers_cb): Update.
(core_target::fetch_registers): Update.
* gdbcore.h (struct core_fns): Remove.
(deprecated_add_core_fns): Remove.
(default_core_sniffer): Remove.
(default_check_format): Remove.
Some arm-tdep.c data structures use a bfd_vma. A couple of spots will
warn about an implicit narrowing cast when building a gdb where
CORE_ADDR is 64-bit but bfd_vma is 32-bit.
This patch silences these warnings by changing the types in question
to CORE_ADDR.
gdb/ChangeLog
2020-03-12 Tom Tromey <tom@tromey.com>
* arm-tdep.c (struct arm_mapping_symbol) <value>: Now a
CORE_ADDR.
(struct arm_exidx_entry) <addr>: Now a CORE_ADDR.
A few spots in gdb use sprintf_vma to print a CORE_ADDR. This will
fail on a 32-bit build once CORE_ADDR is always a 64-bit type.
This patch replaces these calls with phex instead.
gdb/ChangeLog
2020-03-12 Tom Tromey <tom@tromey.com>
* remote.c (remote_target::download_tracepoint)
(remote_target::enable_tracepoint)
(remote_target::disable_tracepoint): Use phex, not sprintf_vma.
* breakpoint.c (print_recreate_masked_watchpoint): Use phex, not
sprintf_vma.
symfile-mem.c has some assertions about the size of various types, to
ensure that gdb and BFD don't get out of sync in a way that would
cause bugs.
Once CORE_ADDR is always 64-bit, one of these assertions can fail for
a 32-bit BFD build. However, the real requirement here is just that
CORE_ADDR is wider -- because this code promotes a bfd_vma to a
CORE_ADDR.
This patch corrects the assert.
gdb/ChangeLog
2020-03-12 Tom Tromey <tom@tromey.com>
* symfile-mem.c: Update CORE_ADDR size assert.
Use foreach_with_prefix, instead of foreach and with_test_prefix
separately. Since allows removing some indentation levels, and formats
the test names a bit nicer, in my opinion (or at least, it's more
consistent with the rest of the testsuite):
- PASS: gdb.base/break-interp.exp: LDprelinkNOdebugNO: BINprelinkNOdebugNOpieNO: INNER: core: set verbose on
+ PASS: gdb.base/break-interp.exp: ldprelink=NO: ldsepdebug=NO: binprelink=NO: binsepdebug=NO: binpie=NO: INNER: set verbose on
Note: this patch is better viewed with "git show -w" to ignore
whitespace changes.
gdb/testsuite/ChangeLog:
* gdb.base/break-interp.exp: Use foreach_with_prefix.
The test gdb.arch/amd64-disp-step-avx.exp is meant to test that doing a
displaced step of an AVX instruction works correctly. However, I found
(by pure coincidence) that the test instructions are not actually
displaced stepped. Rather, they are inline-stepped, so the test is not
actually testing what it's meant to test.
This is what a portion of the test binary looks like:
0000000000400180 <_start>:
400180: 90 nop
0000000000400181 <main>:
400181: 90 nop
0000000000400182 <test_rip_vex2>:
400182: c5 fb 10 05 0e 00 00 vmovsd 0xe(%rip),%xmm0 # 400198 <ro_var>
400189: 00
000000000040018a <test_rip_vex2_end>:
40018a: 90 nop
The instruction at 0x400182 is the one we want to test a displaced step
for. A breakpoint is placed at 0x400182 and ran to. The execution is
then resumed from there, forcing a step-over (which should normally be a
displaced step) of the breakpoint.
However, the displaced stepping buffer is at the _start label, and that
means a breakpoint is present in the displaced stepping buffer. The
breakpoint_in_range_p check in displaced_step_prepare_throw evaluates to
true, which makes displaced_step_prepare_throw fail, forcing GDB to fall
back on an in-line step.
This can be easily observed by placing a `gdb_assert (false)` inside the
breakpoint_in_range_p condition, in displaced_step_prepare_throw, and
running gdb.arch/amd64-disp-step-avx.exp. The assertion will make the
test fail.
The proposed fix is to pad `_start` with a bunch of nops so that the
test instruction is out of the displaced step buffer.
I also think it would be good to enhance the test to make sure that we
are testing displaced stepping as intended. I did that by enabling "set
debug displaced on" while we step over the interesting instruction, and
matching a message printed only when a displaced step is executed.
gdb/testsuite/ChangeLog:
* gdb.arch/amd64-disp-step-avx.S: Add nops after _start.
* gdb.arch/amd64-disp-step-avx.exp: Enable "set debug displaced
on" while stepping over the test instruction, match printed
message.
The selftest.m4 file is used by gdb, gdbserver and gdbsupport, I think
it belongs in gdbsupport.
gdb/ChangeLog:
* selftest.m4: Move to gdbsupport/.
* acinclude.m4: Update path to selftest.m4.
gdbserver/ChangeLog:
* acinclude.m4: Update path to selftest.m4.
gdbsupport/ChangeLog:
* selftest.m4: Moved from gdb/.
* acinclude.m4: Update path to selftest.m4.
While working on the preceding selftests patches, I noticed that some
selftests-specific files are included in the build even when selftests
are disabled, namely disasm-selftest.c and gdbarch-selftests.c. These
files are entirely #if'ed out when building with selftests disabled.
This is not a huge problem, but I think it would make more sense if
these files were simply not built.
With this patch, I propose to put all the selftests-specific source
files into a SELFTESTS_SRCS Makefile variable (even selftest-arch.c,
which is currently added by the configure script).
gdb/ChangeLog:
* Makefile.in (SUBDIR_UNITTESTS_SRCS): Rename to...
(SELFTESTS_SRCS): ... this. Add disasm-selftests.c,
gdbarch-selfselftests.c and selftest-arch.c.
(SUBDIR_UNITTESTS_OBS): Rename to...
(SELFTESTS_OBS): ... this.
(COMMON_SFILES): Remove disasm-selftests.c and
gdbarch-selftests.c.
* configure.ac: Don't add selftest-arch.{c,o} to
CONFIG_{SRCS,OBS}.
* disasm-selftests.c, gdbarch-selftests.c: Remove GDB_SELF_TEST
preprocessor conditions.
The same is done for gdb, gdbserver and gdbsupport. I therefore think
it makes sense to move that to GDB_AC_COMMON.
It is required to move the call to GDB_AC_COMMON so it is before
GDB_AC_SELFTEST in gdbserver/configure.ac, otherwise the $development
variable isn't set when the code behind GDB_AC_SELFTEST executes.
gdb/ChangeLog:
* configure.ac: Don't source bfd/development.sh.
* selftest.m4: Modify comment.
* configure: Re-generate.
gdbserver/ChangeLog:
* configure.ac: Don't source bfd/development.sh, move
GDB_AC_COMMON higher.
* configure: Re-generate.
gdbsupport/ChangeLog:
* configure.ac: Don't source bfd/development.sh.
* common.m4: Source bfd/development.sh.
* configure: Re-generate.
Before commit 3d1e5a43cb ("gdbsupport/configure.ac: source
development.sh"), the GDB build in non-development mode (turn
development to false in bfd/development.sh if you want to try) was
broken because the gdbsupport configure script didn't source
bfd/development.sh to set the development variable.
Since the GDB_AC_SELFTEST macro relies on the `development` variable, I
propose to modify it such that it errors out if $development does not
have an expected value of "true" or "false". This could prevent a
future similar problem from happening while refactoring the configure
scripts. It would have caught the problem fixed by the patch mentioned
earlier.
gdb/ChangeLog:
* selftest.m4 (GDB_AC_SELFTEST): Error out if $development is
not "true" or "false".
* configure: Re-generate.
gdbserver/ChangeLog:
* configure: Re-generate.
gdbsupport/ChangeLog:
* configure: Re-generate.
This is in preparation for deleting deprecated_add_core_fns and
related code.
As a side-effect, this makes it possible to read NetBSD/ARM
core files on non-NetBSD/ARM platforms, subject to PR corefiles/25638.
I have removed this comment:
- /* This is ok: we're running native... */
Since we are using the gdbarch from the regcache, we should be
guaranteed to be calling the right function here, so it shouldn't
matter whether we are running native.
Tested by reading a NetBSD/ARM core file on Linux/x86-64 and NetBSD/ARM;
the "info registers" output matches the one from the system GDB.
gdb/ChangeLog:
2020-03-12 Christian Biesinger <cbiesinger@google.com>
* Makefile.in (HFILES_NO_SRCDIR): Add new arm-nbsd-tdep.h file.
* arm-nbsd-nat.c (arm_supply_gregset): Moved to arm-nbsd-tdep and
renamed to arm_nbsd_supply_gregset.
(fetch_register): Update to call arm_nbsd_supply_gregset.
(fetch_regs): Remove in favor of fetch_register with a -1 regno.
(arm_netbsd_nat_target::fetch_registers): Update.
(fetch_elfcore_registers): Removed.
(_initialize_arm_netbsd_nat): Removed call to deprecated_add_core_fns.
* arm-nbsd-tdep.c (struct arm_nbsd_reg): New struct.
(arm_nbsd_supply_gregset): Moved from arm-nbsd-nat.c and updated to
not require NetBSD system headers.
(arm_nbsd_regset): New struct.
(arm_nbsd_iterate_over_regset_sections): New function.
(arm_netbsd_init_abi_common): Updated to call
set_gdbarch_iterate_over_regset_sections.
* arm-nbsd-tdep.h: New file.
With test-case gdb.base/info-types.exp, I run into:
...
ERROR: internal buffer is full.
UNRESOLVED: gdb.base/info-types.exp: l=c: info types
ERROR: internal buffer is full.
UNRESOLVED: gdb.base/info-types.exp: l=c++: info types
...
Fix this by using exp_continue while matching the output of "info types".
Tested on x86_64-linux, using make targets check and check-read1.
gdb/testsuite/ChangeLog:
2020-03-12 Tom de Vries <tdevries@suse.de>
* gdb.base/info-types.exp: Use exp_continue during matching of output
of "info types".
When running the gdb.threads/execl.exp test-case, we run into this FAIL:
...
(gdb) continue^M
Continuing.^M
^M
Thread 1 "execl" hit Breakpoint 2, __GI_execl (path=0x6024a0 \
"build/gdb/testsuite/outputs/gdb.threads/execl/execl1", \
arg=<optimized out>) at execl.c:51^M
51 if (execl (new_image, new_image, NULL) == -1) \
/* set breakpoint here */^M
(gdb) FAIL: gdb.threads/execl.exp: continue across exec
...
The fail is due to the continue command hitting a breakpoint in __GI_execl
rather than main.
This problem originates from where we execute the "b 51" command, and get two
breakpoint locations:
...
(gdb) run ^M
Starting program: build/gdb/testsuite/outputs/gdb.threads/execl/execl ^M
[Thread debugging using libthread_db enabled]^M
Using host libthread_db library "/lib64/libthread_db.so.1".^M
^M
Breakpoint 1, main (argc=1, argv=0x7fffffffd3f8) at gdb.threads/execl.c:44^M
44 pthread_create (&thread1, NULL, thread_function, NULL);^M
(gdb) b 51^M
Breakpoint 2 at 0x400787: gdb.threads/execl.c:51. (2 locations)^M
(gdb) PASS: gdb.threads/execl.exp: set breakpoint at execl
...
Adding a "info breakpoints" command, we can see the locations:
...
(gdb) info breakpoints^M
Num Type Disp Enb Address What^M
1 breakpoint keep y 0x00000000004006ee in main at \
gdb.threads/execl.c:44^M
breakpoint already hit 1 time^M
2 breakpoint keep y <MULTIPLE> ^M
2.1 y 0x0000000000400787 in main at \
gdb.threads/execl.c:51^M
2.2 y 0x00007ffff758d925 in __GI_execl at \
execl.c:51^M
(gdb) PASS: gdb.threads/execl.exp: info breakpoints
...
The fact that the __GI_execl breakpoint location is there, is a bug, filed as
PR25656. Without debug info for GLIBC though, the bug is not triggered.
Fix the FAIL by working around the bug, and deleting the breakpoint after
hitting the first breakpoint location.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-03-12 Tom de Vries <tdevries@suse.de>
* gdb.threads/execl.exp: Delete breakpoint after hitting it.
With test-case gdb.fortran/module.exp, I run into:
...
PASS: gdb.fortran/module.exp: fully qualified name of DW_TAG_constant
ERROR: internal buffer is full.
UNRESOLVED: gdb.fortran/module.exp: info variables -n
...
Fix this by using exp_continue while matching the output of "info variable
-n".
Tested on x86_64-linux, using make targets check and check-read1.
gdb/testsuite/ChangeLog:
2020-03-12 Tom de Vries <tdevries@suse.de>
* gdb.fortran/module.exp: Use exp_continue during matching of output
of "info variable -n".
When running test-case gdb.dwarf2/dw2-ranges-base.exp with debuginfo for
various libs installed, I run into:
...
(gdb) maint info line-table^M
...
objfile: /usr/lib/debug/lib64/ld-2.26.so-2.26-lp151.18.7.x86_64.debug \
((struct objfile *) 0x1a9d7f0)^M
compunit_symtab: ((struct compunit_symtab *) 0x2061090)^M
symtab: /usr/src/debug/glibc-2.26-lp151.18.7.x86_64/sysdeps/generic/\
dl-fcntl.h ((struct symtab *) 0x2182660)^M
linetable: ((struct linetable *) 0x0):^M
No line table.^M
(gdb) FAIL: gdb.dwarf2/dw2-ranges-base.exp: count END markers in line table
...
The test-case intends to count 3 END markers in the line table for
gdb.dwarf2/dw2-ranges-base.c:
...
symtab: /data/gdb_versions/devel/binutils-gdb.git/gdb/testsuite/gdb.dwarf2/\
dw2-ranges-base.c ((struct symtab *) 0x2a7e8c0)^M
linetable: ((struct linetable *) 0x2a7ea60):^M
INDEX LINE ADDRESS IS-STMT^M
0 31 0x00000000004004a7 Y^M
1 21 0x00000000004004ae Y^M
2 END 0x00000000004004ae Y^M
3 11 0x00000000004004ba Y^M
4 END 0x00000000004004ba Y^M
5 END 0x00000000004004c6 Y^M
...
but ends up counting 70+ END markers for all line tables.
Fix this by limiting the line tables emitted by the maint info line-table
command.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-03-12 Tom de Vries <tdevries@suse.de>
* gdb.dwarf2/dw2-ranges-base.exp: Limit "maint info line-table" to
gdb.dwarf2/dw2-ranges-base.c.
When running test-case gdb.linespec/explicit.exp with GLIBC debuginfo
installed, I run into:
...
(gdb) break -source exp^GlFAIL: gdb.linespec/explicit.exp: complete \
non-unique file name (timeout)
...
The regexp that times out is:
...
-re "break -source exp\\\x07licit" {
...
and the reason it times out is that gdb only outputs an "l" after the tab, while
the regexp expect a futher "icit".
This is a regression since commit 507dd60e28 "[gdb/testsuite, 1/2] Fix
gdb.linespec/explicit.exp with check-read1", where I merged the matching for
the two cases where GLIBC debuginfo is either installed or not, as it turns
out incorrectly, presumably because even though I tested with GLIBC debuginfo
info installed and deinstalled, that didn't make a difference because I didn't
use configure flag --with-separate-debug-dir=/usr/lib/debug.
Fix this by not explictly matching the "icit" part.
Tested on x86_64-linux, with and without GLIBC debuginfo installed, both with
make targets check and check-read1.
gdb/testsuite/ChangeLog:
2020-03-12 Tom de Vries <tdevries@suse.de>
* gdb.linespec/explicit.exp: Fix "complete non-unique file name" test
in presence of GLIBC debuginfo.