Aaron Merey [Thu, 10 Mar 2022 20:31:33 +0000 (15:31 -0500)]
gdb/auto-load: Remove repeating "auto-load" from debug message
Remove "auto-load:" from a format string passed to auto_load_debug_printf.
It is unnecessary since this function will prefix the string with "[auto-load]"
when printing it.
Tom Tromey [Thu, 17 Feb 2022 20:43:59 +0000 (13:43 -0700)]
Change how "print/x" displays floating-point value
Currently, "print/x" will display a floating-point value by first
casting it to an integer type. This yields weird results like:
(gdb) print/x 1.5
$1 = 0x1
This has confused users multiple times -- see PR gdb/16242, where
there are several dups. I've also seen some confusion from this
internally at AdaCore.
The manual says:
'x'
Regard the bits of the value as an integer, and print the integer
in hexadecimal.
... which seems more useful. So, perhaps what happened is that this
was incorrectly implemented (or maybe correctly implemented and then
regressed, as there don't seem to be any tests).
This patch fixes the bug.
There was a previous discussion where we agreed to preserve the old
behavior:
Tom Tromey [Fri, 4 Mar 2022 18:40:49 +0000 (11:40 -0700)]
Simplify the ui-out progress API
I noticed that 'progress' is a method on ui-out, but it seems to me
that it would be better if the only API were via the progress_meter
class. This patch makes this change, changing progress to be a method
on the meter itself.
Lancelot SIX [Fri, 18 Feb 2022 15:05:51 +0000 (10:05 -0500)]
Process exit status is leader exit status testcase
This adds a multi-threaded testcase that has all threads in the
process exit with a different exit code, and ensures that GDB reports
the thread group leader's exit status as the whole-process exit
status. Before this set of patches, this would randomly report the
exit code of some other thread, and thus fail.
Tested on Linux-x86_64, native and gdbserver.
Co-Authored-By: Pedro Alves <pedro@palves.net>
Change-Id: I30cba2ff4576fb01b5169cc72667f3268d919557
Pedro Alves [Tue, 22 Feb 2022 10:15:07 +0000 (10:15 +0000)]
Re-add zombie leader on exit, gdbserver/linux
Same as the previous patch, but for GDBserver.
In summary, the current zombie leader detection code in linux-low.cc
has a race -- if a multi-threaded inferior exits just before
check_zombie_leaders finds that the leader is now zombie via checking
/proc/PID/status, check_zombie_leaders deletes the leader, assuming we
won't get an event for that exit (which we won't in some scenarios,
but not in this one), which is a false-positive scenario, where the
whole process is simply exiting. Later when we see the last LWP in
our list exit, we report that LWP's exit status as exit code, even
though for the (real) parent process, the exit code that counts is the
child's leader thread's exit code.
Like for GDB, the solution here is to:
- only report whole-process exit events for the leader.
- re-add the leader back to the LWP list when we finally see it
exit.
Pedro Alves [Mon, 21 Feb 2022 20:07:20 +0000 (20:07 +0000)]
Re-add zombie leader on exit, gdb/linux
The current zombie leader detection code in linux-nat.c has a race --
if a multi-threaded inferior exits just before check_zombie_leaders
finds that the leader is now zombie via checking /proc/PID/status,
check_zombie_leaders deletes the leader, assuming we won't get an
event for that exit (which we won't in some scenarios, but not in this
one). That might seem mostly harmless, but it has some downsides:
- later when we continue pulling events out of the kernel, we will
collect the exit event of the non-leader threads, and once we see
the last lwp in our list exit, we return _that_ lwp's exit code as
whole-process exit code to infrun, instead of the leader's exit
code.
- this can cause a hang in stop_all_threads in infrun.c. Say there
are 2 threads in the process. stop_all_threads stops each of those
threads, and then waits for two stop or exit events, one for each
thread. If the whole process exits, and check_zombie_leaders hits
the false-positive case, linux-nat.c will only return one event to
GDB (the whole-process exit returned when we see the last thread,
the non-leader thread, exit), making stop_all_threads hang forever
waiting for a second event that will never come.
However, in this false-positive scenario, where the whole process is
exiting, as opposed to just the leader (with pthread_exit(), for
example), we _will_ get an exit event shortly for the leader, after we
collect the exit event of all the other non-leader threads. Or put
another way, we _always_ get an event for the leader after we see it
become zombie.
I tried a number of approaches to fix this:
#1 - My first thought to address the race was to make GDB always
report the whole-process exit status for the leader thread, not for
whatever is the last lwp in the list. We _always_ get a final exit
(or exec) event for the leader, and when the race triggers, we're not
collecting it.
#2 - My second thought was to try to plug the race in the first place.
I thought of making GDB call waitpid/WNOHANG for all non-leader
threads immediately when the zombie leader is detected, assuming there
would be an exit event pending for each of them waiting to be
collected. Turns out that that doesn't work -- you can see the leader
become zombie _before_ the kernel kills all other threads. Waitpid in
that small time window returns 0, indicating no-event. Thankfully we
hit that race window all the time, which avoided trading one race for
another. Looking at the non-leader thread's status in /proc doesn't
help either, the threads are still in running state for a bit, for the
same reason.
#3 - My next attempt, which seemed promising, was to synchronously
stop and wait for the stop for each of the non-leader threads. For
the scenario in question, this will collect all the exit statuses of
the non-leader threads. Then, if we are left with only the zombie
leader in the lwp list, it means we either have a normal while-process
exit or an exec, in which case we should not delete the leader. If
_only_ the leader exited, like in gdb.threads/leader-exit.exp, then
after pausing threads, we will still have at least one live non-leader
thread in the list, and so we delete the leader lwp. I got this
working and polished, and it was only after staring at the kernel code
to convince myself that this would really work (and it would, for the
scenario I considered), that I realized I had failed to account for
one scenario -- if any non-leader thread is _already_ stopped when
some thread triggers a group exit, like e.g., if you have some threads
stopped and then resume just one thread with scheduler-locking or
non-stop, and that thread exits the process. I also played with
PTRACE_EVENT_EXIT, see if it would help in any way to plug the race,
and I couldn't find a way that it would result in any practical
difference compared to looking at /proc/PID/status, with respect to
having a race.
So I concluded that there's no way to plug the race, we just have to
deal with it. Which means, going back to approach #1. That is the
approach taken by this patch.
Pedro Alves [Thu, 24 Feb 2022 11:35:43 +0000 (11:35 +0000)]
gdbserver: Reindent check_zombie_leaders
This fixes the indentation of
linux_process_target::check_zombie_leaders, which will help with
keeping its comments in sync with the gdb/linux-nat.c counterpart.
Reorganize linux-low.cc:linux_process_target::filter_event such that
all the handling for events for LWPs not in the LWP list is together.
This helps make a following patch clearer. The comments and debug
messages have also been tweaked to have them synchronized with the GDB
counterpart.
Pedro Alves [Mon, 21 Feb 2022 20:07:20 +0000 (20:07 +0000)]
gdb: Reorganize linux_nat_filter_event
Reorganize linux-nat.c:linux_nat_filter_event such that all the
handling for events for LWPs not in the LWP list is together. This
helps make a following patch clearer. The comments and debug messages
have also been tweaked - the end goal is to have them synchronized
with the gdbserver counterpart.
Pedro Alves [Wed, 23 Feb 2022 11:17:26 +0000 (11:17 +0000)]
Fix gdb.threads/current-lwp-dead.exp race
If we make GDB report the process EXIT event for the leader thread, as
will be done in a latter patch of this series, then
gdb.threads/current-lwp-dead.exp starts failing:
(gdb) break fn_return
Breakpoint 2 at 0x5555555551b5: file /home/pedro/rocm/gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.threads/current-lwp-dead.c, line 45.
(gdb) continue
Continuing.
[New LWP 2138466]
[Inferior 1 (process 2138459) exited normally]
(gdb) FAIL: gdb.threads/current-lwp-dead.exp: continue to breakpoint: fn_return (the program exited)
The inferior exit reported is actually correct. The main thread has
indeed exited, and that's the thread that has the right exit code to
report to the user, as that's the exit code that is reported to the
program's parent. In this case, GDB managed to collect the exit code
for the leader thread before reaping the other thread, because in
reality, the testcase isn't creating standard threads, it is using raw
clone, and the new clones are put in their own thread group.
Fix it by making the main "thread" not exit until the scenario we're
exercising plays out. Also, run the program to completion for
completeness.
The original program really wanted the leader thread to exit before
the fn_return function was reached -- it was important that the
current thread as pointed by inferior_ptid was gone when infrun got
the breakpoint event. I've tweaked the testcase to ensure that that
condition is still held, though it is no longer the main thread that
exits. This required a bit of synchronization between the threads,
which required using CLONE_VM unconditionally. The #ifdef guards were
added as a fix for
https://sourceware.org/bugzilla/show_bug.cgi?id=11214, though I don't
think they were necessary because the program is not using TLS. If it
turns out they were necessary, we can link the testcase with "-z now"
instead, which was mentioned as an alternative workaround in that
Bugzilla.
Pedro Alves [Wed, 23 Feb 2022 11:17:26 +0000 (11:17 +0000)]
Fix gdb.threads/clone-new-thread-event.exp race
If we make GDB report the process EXIT event for the leader thread,
instead of whatever is the last thread in the LWP list, as will be
done in a latter patch of this series, then
gdb.threads/current-lwp-dead.exp starts failing:
(gdb) FAIL: gdb.threads/clone-new-thread-event.exp: catch SIGUSR1 (the program exited)
This is a testcase race -- the main thread does not wait for the
spawned clone "thread" to finish before exiting, so the main program
may exit before the second thread is scheduled and reports its
SIGUSR1. With the change to make GDB report the EXIT for the leader,
the race is 100% reproducible by adding a sleep(), like so:
Breakpoint 1, main (argc=1, argv=0x7fffffffd418) at gdb.threads/clone-new-thread-event.c:65
65 stack = malloc (STACK_SIZE);
(gdb) continue
Continuing.
[New LWP 3715562]
[Inferior 1 (process 3715555) exited normally]
(gdb) FAIL: gdb.threads/clone-new-thread-event.exp: catch SIGUSR1 (the program exited)
That inferior exit reported is actually correct. The main thread has
indeed exited, and that's the thread that has the right exit code to
report to the user, as that's the exit code that is reported to the
program's parent. In this case, GDB managed to collect the exit code
for the leader thread before reaping the other thread, because in
reality, the testcase isn't creating standard threads, it is using raw
clone, and the new clones are put in their own thread group.
Fix it by making the main thread wait for the child to exit. Also,
run the program to completion for completeness.
Turning on debug output in gdbserver leads to an assertion failure if
gdbserver reports a non-signal event:
[threads] wait_1: LWP 3273770: extended event with waitstatus status->kind = EXECD, execd_pathname = gdb.threads/non-ldr-exc-1/non-ldr-exc-1
[threads] wait_1: Hit a non-gdbserver trap event.
../../src/gdbserver/../gdb/target/waitstatus.h:365: A problem internal to GDBserver has been detected.
sig: Assertion `m_kind == TARGET_WAITKIND_STOPPED || m_kind == TARGET_WAITKIND_SIGNALLED' failed.
Fix it in the obvious way, using target_waitstatus::to_string(),
resulting in, for example:
[threads] wait_1: ret = LWP 1542412.1542412, status->kind = STOPPED, sig = GDB_SIGNAL_TRAP
Nick Clifton [Thu, 10 Mar 2022 09:11:40 +0000 (09:11 +0000)]
Add option to objdump/readelf to disable access to debuginfod servers.
* dwarf.c (use_debuginfod): New variable. Set to 1.
(load_separate_debug_info): Only call
debuginfod_fetch_separate_debug_info is use_debuginfod is true.
(dwarf_select_sections_by_names): Add do-not-use-debuginfod and
use-debuginfod options.
(dwarf_select_sections_by_letters): Add D and E options.
* dwarf.h (use_debuginfod): New extern.
* objdump.c (usage): Mention the new options.
* readelf.c (usage): Likewise.
* doc/binutils.texi: Document the new options.
* doc/debug-options.texi: Describe the new options.
* NEWS: Mention the new feature.
* testsuite/binutils-all/debuginfod.exp: Add tests of the new
options.
H.J. Lu [Wed, 2 Feb 2022 22:40:03 +0000 (14:40 -0800)]
ld: Add a before_plugin_all_symbols_read hook
Add a before_plugin_all_symbols_read hook to load symbol references from
DT_NEEDED entries, included from --copy-dt-needed-entries, before reading
plugin symbols to properly resolve plugin symbol references.
bfd/
PR ld/28849
* elf-bfd.h (elf_link_hash_table): Add handling_dt_needed.
* elflink.c (_bfd_elf_merge_symbol): Don't set non_ir_ref_dynamic
before plugin 'all symbols read' hook is called.
toplevel: Makefile.def: Make configure-sim depend on all-readline
Without this, a "make all-sim" without the equivalent of
libreadline-dev installed on the build system, won't
properly pick up the in-tree readline build, and you'll see:
mkdir -p -- ./sim
Configuring in ./sim
configure: creating cache ./config.cache
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking target system type... cris-axis-elf
checking for x86_64-pc-linux-gnu-gcc... gcc
checking whether the C compiler works... yes
...
checking for library containing tgetent... -ltermcap
checking for readline in -lreadline... no
configure: error: the required "readline" library is missing
make[1]: *** [Makefile:11188: configure-sim] Error 1
make[1]: Leaving directory '/home/hp/sim/b'
The sim dependency on readline is apparently (nominally)
valid as there's a readline call in sim/erc32/sis.c.
2022-02-21 Hans-Peter Nilsson <hp@axis.com>
* Makefile.def (dependencies): Make configure-sim depend on
all-readline.
GDB/testsuite: Remove a stray backslash from gdb.base/settings.exp
Remove a stray trailing backslash from `test-integer' in settings.exp.
It is harmless as only white space follows in the next line before the
closing brace, so it merely swallows the newline character, but it may
look confusing to the reader.
Alan Modra [Tue, 8 Mar 2022 12:19:52 +0000 (22:49 +1030)]
Reduce duplicated symbol_clone_if_forward_ref work
* symbol.c (struct symbol_flags): Add forward_resolved.
(symbol_entry_find): Update needle initialisation.
(symbol_clone_if_forward_ref): Do no work when forward_resolved
is already set. Set forward_resolved.
Aaron Merey [Tue, 8 Mar 2022 22:32:35 +0000 (17:32 -0500)]
gdb: Try searching for auto-load script using .gnu_debuglink
If an auto-load script cannot be found and objfile is a separate
debuginfo whose filename does not match the name found in the parent
file's .gnu_debuglink section, then repeat the search using the
parent's filename where the last component is replaced with the
.gnu_debuglink name.
For example if the parent's filename is "/usr/lib/libxyz.so" and the
name in its .gnu_debuglink section is "libxyz.so.debug", then
if no auto-load script is otherwise found the search will be
repeated with the filename "/usr/lib/libxyz.so.debug".
This helps gdb locate auto-load scripts when debuginfo files do not have
the expected filename, such as when they are aquired from debuginfod.
Aaron Merey [Sat, 20 Nov 2021 00:41:40 +0000 (19:41 -0500)]
PR gdb/27876 - debuginfod-downloaded source files don't pass proper fullname across mi / (gdb)info source
Source files downloaded from debuginfod currently use their original DWARF
filename as their "fullname". This causes a mismatch between the fullname
and the actual location of the source file in the debuginfod client cache.
MI consumers such as VSCode will fail to open debuginfod-downloaded
source files due to this. Also 'info source' will fail to include the
true paths of these files.
To fix this, use the debuginfod cache path as the fullname for debuginfod-
downloaded source files.
Jan Vrany [Wed, 2 Mar 2022 13:23:30 +0000 (13:23 +0000)]
gdb/mi: preserve user selected thread and frame when invoking MI commands
Fix for PR gdb/20684. When invoking MI commands with --thread and/or
--frame, the user selected thread and frame was not preserved:
(gdb)
info thread
&"info thread\n"
~" Id Target Id Frame \n"
~"* 1 Thread 0x7ffff7c30740 (LWP 19302) \"user-selected-c\" main () at /home/uuu/gdb/gdb/testsuite/gdb.mi/user-selected-context-sync.c:60\n"
~" 2 Thread 0x7ffff7c2f700 (LWP 19306) \"user-selected-c\" child_sub_function () at /home/uuu/gdb/gdb/testsuite/gdb.mi/user-selected-context-sync.c:30\n"
~" 3 Thread 0x7ffff742e700 (LWP 19307) \"user-selected-c\" child_sub_function () at /home/uuu/gdb/gdb/testsuite/gdb.mi/user-selected-context-sync.c:30\n"
^done
(gdb)
info frame
&"info frame\n"
~"Stack level 0, frame at 0x7fffffffdf90:\n"
~" rip = 0x555555555207 in main (/home/uuu/gdb/gdb/testsuite/gdb.mi/user-selected-context-sync.c:60); saved rip = 0x7ffff7c5709b\n"
~" source language c.\n"
~" Arglist at 0x7fffffffdf80, args: \n"
~" Locals at 0x7fffffffdf80, Previous frame's sp is 0x7fffffffdf90\n"
~" Saved registers:\n "
~" rbp at 0x7fffffffdf80, rip at 0x7fffffffdf88\n"
^done
(gdb)
-stack-info-depth --thread 3
^done,depth="4"
(gdb)
info thread
&"info thread\n"
~" Id Target Id Frame \n"
~" 1 Thread 0x7ffff7c30740 (LWP 19302) \"user-selected-c\" main () at /home/uuu/gdb/gdb/testsuite/gdb.mi/user-selected-context-sync.c:60\n"
~" 2 Thread 0x7ffff7c2f700 (LWP 19306) \"user-selected-c\" child_sub_function () at /home/uuu/gdb/gdb/testsuite/gdb.mi/user-selected-context-sync.c:30\n"
~"* 3 Thread 0x7ffff742e700 (LWP 19307) \"user-selected-c\" child_sub_function () at /home/uuu/gdb/gdb/testsuite/gdb.mi/user-selected-context-sync.c:30\n"
^done
(gdb)
info frame
&"info frame\n"
~"Stack level 0, frame at 0x7ffff742dee0:\n"
~" rip = 0x555555555169 in child_sub_function (/home/uuu/gdb/gdb/testsuite/gdb.mi/user-selected-context-sync.c:30); saved rip = 0x555555555188\n"
~" called by frame at 0x7ffff742df00\n"
~" source language c.\n"
~" Arglist at 0x7ffff742ded0, args: \n"
~" Locals at 0x7ffff742ded0, Previous frame's sp is 0x7ffff742dee0\n"
~" Saved registers:\n "
~" rbp at 0x7ffff742ded0, rip at 0x7ffff742ded8\n"
^done
(gdb)
This caused problems for frontends that provide access to CLI because UI
may silently change the context for CLI commands (as demonstrated above).
This commit fixes the problem by restoring thread and frame in
mi_cmd_execute (). With this change, there are only two GDB/MI commands
that can change user selected context: -thread-select and -stack-select-frame.
This allows us to remove all and rather complicated logic of notifying
about user selected context change from mi_execute_command (), leaving it
to these two commands themselves to notify.
Andrew Burgess [Fri, 25 Feb 2022 11:03:03 +0000 (11:03 +0000)]
gdb/testsuite: add new test for comparing char types in Python
There's an interesting property of the 'char' type in C and C++, the
three types 'char', 'unsigned char', and 'signed char', are all
considered distinct.
In contrast, and 'int' is signed by default, and so 'int' and 'signed
int' are considered the same type.
This commit adds a test to ensure that this edge case is visible to a
user from Python.
It is worth noting that for any particular compiler implementation (or
the flags a compiler was invoked with), a 'char' will be either signed
or unsigned; it has to be one or the other, and a user can access this
information by using the Type.is_signed property. However, for
something like function overload resolution, the 'char' type is
considered distinct from the signed and unsigned variants.
There's no change to GDB with this commit, this is just adding a new
test to guard some existing functionality.
Andrew Burgess [Tue, 30 Nov 2021 14:35:44 +0000 (14:35 +0000)]
gdb/python: add Type.is_signed property
Add a new read-only property, Type.is_signed, which is True for signed
types, and False otherwise.
This property should only be read on types for which Type.is_scalar is
true, attempting to read this property for non-scalar types will raise
a ValueError.
I chose 'is_signed' rather than 'is_unsigned' in order to match the
existing Architecture.integer_type method, which takes a 'signed'
parameter. As far as I could find, that was the only existing
signed/unsigned selector in the Python API, so it seemed reasonable to
stay consistent.
Andrew Burgess [Wed, 2 Mar 2022 11:11:47 +0000 (11:11 +0000)]
gdb/mi: add --no-connection to MI -add-inferior command
Following on from the previous commit, where the -add-inferior command
now uses the same connection as the current inferior, this commit adds
a --no-connection option to -add-inferior.
This new option matches the existing option of the same name for the
CLI version of add-inferior; the new inferior is created with no
connection.
I've added a new 'connection' field to the MI output of -add-inferior,
which includes the connection number and short name. I haven't
included the longer description field, this is the MI after all. My
expectation would be that if the frontend wanted to display all the
connection details then this would be looked up from 'info
connection' (or the MI equivalent if/when such a command is added).
The existing -add-inferior tests are updated, as are the docs.
When a new inferior was added using the MI -add-inferior command, the
new inferior would be using the same target as all the other
inferiors. This makes sense, GDB only supported a single target stack
at a time.
After the above commit, each inferior has its own target stack.
To maintain backward compatibility, for the CLI add-inferior command,
when a new inferior is added the above commit has the new inferior
inherit a copy of the target stack from the current inferior.
Unfortunately, this same backward compatibility is missing for the MI.
This commit fixes this oversight.
Now, when the -add-inferior MI command is used, the new inferior will
inherit a copy of the target stack from the current inferior.
Tom Tromey [Thu, 3 Mar 2022 16:47:00 +0000 (09:47 -0700)]
Deprecate dbx mode
GDB has a dbx emulation mode that adds a few aliases and helper
commands. This mode is barely documented and is very superficial
besides. I suspect it is rarely used, and I would like to propose
deprecating it for GDB 12, and then removing it in GDB 13.
Pedro Alves [Mon, 7 Mar 2022 16:09:41 +0000 (16:09 +0000)]
Remove unnecessary inferior lookup in infrun:handle_one
infrun.c:handle_one calls find_inferior_ptid unnecessarily, since we
already have a thread pointer handy, and the thread has a pointer to
the inferior. This commit removes the unnecessary lookup.
Tom Tromey [Wed, 16 Feb 2022 19:33:45 +0000 (12:33 -0700)]
Fix bug in ada_print_floating
ada_print_floating rewrites a floating-point string representation to
conform to Ada syntax. However, if you managed to get a floating
point error, you might see:
(gdb) print whatever
$2 = <invalid float valu.0e>
What's happening here is that ada_print_floating doesn't recognize
this error case, and proceeds to modify the error text.
Tom Tromey [Wed, 16 Feb 2022 17:07:18 +0000 (10:07 -0700)]
Implement real literal extension for Ada
Sometimes it is convenient to be able to specify the exact bits of a
floating-point literal. For example, you may want to set a
floating-point register to a denormalized value, or to a particular
NaN.
In C, you can do this by combining the "{}" cast with an array
literal, like:
This patch adds a somewhat similar idea to Ada. It extends the lexer
to allow "l" and "f" suffixes in a based literal. The "f" indicates a
floating-point literal, and the "l"s control the size of the
floating-point type.
Note that this differs from Ada's based real literals. I believe
those can also be used to control the bits of a floating-point value,
but they are a bit more cumbersome to use (simplest is binary but
that's also very lengthy). Also, these aren't implemented in GDB.
I chose not to allow this extension to work with based integer
literals with exponents. That didn't seem very useful.
Tom Tromey [Mon, 28 Feb 2022 20:42:03 +0000 (13:42 -0700)]
Fix gdb.ada/arrayptr.exp results
PR ada/28115 points out that gdb.ada/arrayptr.exp works with GNAT 12,
but fails with minimal encodings in earlier versions.
This patch updates the test to try to report the results correctly. I
tried this with the Fedora 34 system gcc (GCC 11) and with a GCC 12
built from git trunk sometime relatively recently.
Tom Tromey [Thu, 3 Feb 2022 17:42:07 +0000 (10:42 -0700)]
Handle non-ASCII identifiers in Ada
Ada allows non-ASCII identifiers, and GNAT supports several such
encodings. This patch adds the corresponding support to gdb.
GNAT encodes non-ASCII characters using special symbol names.
For character sets like Latin-1, where all characters are a single
byte, it uses a "U" followed by the hex for the character. So, for
example, thorn would be encoded as "Ufe" (0xFE being lower case
thorn).
For wider characters, despite what the manual says (it claims
Shift-JIS and EUC can be used), in practice recent versions only
support Unicode. Here, characters in the base plane are represented
using "Wxxxx" and characters outside the base plane using
"WWxxxxxxxx".
GNAT has some further quirks here. Ada is case-insensitive, and GNAT
emits symbols that have been case-folded. For characters in ASCII,
and for all characters in non-Unicode character sets, lower case is
used. For Unicode, however, characters that fit in a single byte are
converted to lower case, but all others are converted to upper case.
Furthermore, there is a bug in GNAT where two symbols that differ only
in the case of "Y WITH DIAERESIS" (and potentially others, I did not
check exhaustively) can be used in one program. I chose to omit
handling this case from gdb, on the theory that it is hard to figure
out the logic, and anyway if the bug is ever fixed, we'll regret
having a heuristic.
This patch introduces a new "ada source-charset" setting. It defaults
to Latin-1, as that is GNAT's default. This setting controls how "U"
characters are decoded -- W/WW are always handled as UTF-32.
The ada_tag_name_from_tsd change is needed because this function will
read memory from the inferior and interpret it -- and this caused an
encoding failure on PPC when running a test that tries to read
uninitialized memory.
This patch implements its own UTF-32-based case folder. This avoids
host platform quirks, and is relatively simple. A short Python
program to generate the case-folding table is included. It simply
relies on whatever version of Unicode is used by the host Python,
which seems basically acceptable.
Test cases for UTF-8, Latin-1, and Latin-3 are included. This
exercises most of the new code paths, aside from Y WITH DIAERESIS as
noted above.
Tom Tromey [Thu, 3 Feb 2022 19:04:36 +0000 (12:04 -0700)]
Define HOST_UTF32 in charset.h
rust-parse.c has a #define for the host-specific UTF-32 charset name.
A later patch needs the same thing, so this patch moves the definition
to charset.h for easier reuse.
Tom Tromey [Thu, 3 Feb 2022 20:18:25 +0000 (13:18 -0700)]
Let phex and phex_nz handle sizeof_l==1
Currently, neither phex nor phex_nz handle sizeof_l==1 -- they let
this case fall through to the default case. However, a subsequent
patch in this series needs this case to work correctly.
I looked at all calls to these functions that pass a 1 for the
sizeof_l parameter. The only such case seems to be correct with this
change.
Tom Tromey [Thu, 3 Feb 2022 19:24:12 +0000 (12:24 -0700)]
Don't pre-size result string in ada_decode
Currently, ada_decode pre-sizes the output string, filling it with 'X'
characters. However, it's a bit simpler and more flexible to let
std::string do the work here, and simply append characters to the
string as we go. This turns out to be useful for a subsequent patch.
MIPS/opcodes: Fix alias annotation for branch instructions
Correct issues with INSN2_ALIAS annotation for branch instructions:
- regular MIPS BEQZ/L and BNEZ/L assembly instructions are idioms for
BEQ/L and BNE/L respectively with the `rs' operand equal to $0,
- microMIPS 32-bit BEQZ and BNEZ assembly instructions are idioms for
BEQ and BNE respectively with the `rt' operand equal to $0,
- regular MIPS BAL assembly instruction is an idiom for architecture
levels of up to the MIPSr5 ISA and a machine instruction on its own
from the MIPSr6 ISA up.
Add missing annotation to BEQZ/L and BNEZ/L accordingly then and add a
new entry for BAL for the MIPSr6 ISA, correcting a disassembly bug:
Parts for regular MIPS BEQZ/L and BNEZ/L instructions from Sagar Patel.
2022-03-06 Maciej W. Rozycki <macro@orcam.me.uk>
binutils/
* testsuite/binutils-all/mips/mips1-branch-alias.d: New test.
* testsuite/binutils-all/mips/mips1-branch-noalias.d: New test.
* testsuite/binutils-all/mips/mips2-branch-alias.d: New test.
* testsuite/binutils-all/mips/mips2-branch-noalias.d: New test.
* testsuite/binutils-all/mips/mips32r6-branch-alias.d: New test.
* testsuite/binutils-all/mips/mips32r6-branch-noalias.d: New
test.
* testsuite/binutils-all/mips/micromips-branch-alias.d: New
test.
* testsuite/binutils-all/mips/micromips-branch-noalias.d: New
test.
* testsuite/binutils-all/mips/mips-branch-alias.s: New test
source.
* testsuite/binutils-all/mips/micromips-branch-alias.s: New test
source.
* testsuite/binutils-all/mips/mips.exp: Run the new tests.
2022-03-06 Sagar Patel <sagarmp@cs.unc.edu>
Maciej W. Rozycki <macro@orcam.me.uk>
opcodes/
* mips-opc.c (mips_builtin_opcodes): Fix INSN2_ALIAS annotation
for "bal", "beqz", "beqzl", "bnez" and "bnezl" instructions.
* micromips-opc.c (micromips_opcodes): Likewise for "beqz" and
"bnez" instructions.
Tom Tromey [Fri, 4 Mar 2022 03:25:32 +0000 (20:25 -0700)]
Use function view when iterating over block symbols
This changes iterate_over_block_local_vars and
iterate_over_block_arg_vars to take a gdb::function_view rather than a
function pointer and a user-data. In one spot, this allows us to
remove a helper structure and helper function. In another spot, this
looked more complicated, so I changed the helper function to be an
"operator()" -- also a simplification, just not as big.
Tom Tromey [Sat, 5 Mar 2022 00:14:44 +0000 (17:14 -0700)]
Simplify hppa-tdep.c use of objfile_key
I happened to notice a couple of unnecessary casts in hppa-tdep.c, and
then I saw that the use of objfile_key could be simplified -- removing
some code and using the default deleter rather than noop_deleter.
Simon Marchi [Mon, 31 Jan 2022 20:57:58 +0000 (15:57 -0500)]
gdb: constify parameter of value_copy
In a following patch, I have a const value I want to copy using a
value_copy. However, value_copy takes a non-const source value, at the
moment. Change the paramter to be const,
If the source value is not lazy, we currently call
value_contents_all_raw, which calls allocate_value_contents, to get a
view on the contents. They both take a non-const value, that's a
problem. My first attempt at solving it was to add a const version of
value_contents_all_raw, make allocate_value_contents take a const value,
and either:
- make value::contents mutable
- make allocate_value_contents cast away the const
The idea being that allocating the value contents buffer does modify the
value at the bit level, but logically that doesn't change its state.
That was getting a bit complicated, so what I ended up doing is make
value_copy not call value_contents_all_raw. We know at this point that
the value is not lazy, so value::contents must have been allocate
already.
Simon Marchi [Mon, 31 Jan 2022 20:23:32 +0000 (15:23 -0500)]
gdb: remove internalvar_funcs::destroy
No kind of internal var uses it remove it. This makes the transition to
using a variant easier, since we don't need to think about where this
should be called (in a destructor or not), if it can throw, etc.
gdb: Use a typedef's scoped type name to identify local typedefs
GDB prints the wrong type for typedefs in case there is another typedef
available for the same raw type (gdb/16040). The reason is that the
current hashmap based substitution mechanism always compares the target
type of a typedef and not its scoped name.
Roland McGrath [Wed, 2 Mar 2022 00:03:58 +0000 (16:03 -0800)]
Avoid conflict with gnulib open/close macros.
On some systems, the gnulib configuration will decide to define open
and/or close as macros to replace the POSIX C functions. This
interferes with using those names in C++ class or namespace scopes.
Tiezhu Yang [Thu, 3 Mar 2022 03:15:10 +0000 (11:15 +0800)]
gdb: testsuite: fix failed testcases in gdb.base/gdb-caching-proc.exp
When execute the following command:
make check-gdb TESTS="gdb.base/gdb-caching-proc.exp"
we can see there exist some failed testcases:
FAIL: gdb.base/gdb-caching-proc.exp: can_spawn_for_attach: 0: can spawn for attach (got interactive prompt)
FAIL: gdb.base/gdb-caching-proc.exp: can_spawn_for_attach: 1: can spawn for attach (got interactive prompt)
FAIL: gdb.base/gdb-caching-proc.exp: can_spawn_for_attach: 2: can spawn for attach (got interactive prompt)
FAIL: gdb.base/gdb-caching-proc.exp: can_spawn_for_attach: 3: can spawn for attach (got interactive prompt)
FAIL: gdb.base/gdb-caching-proc.exp: can_spawn_for_attach: 4: can spawn for attach (got interactive prompt)
FAIL: gdb.base/gdb-caching-proc.exp: can_spawn_for_attach: 5: can spawn for attach (got interactive prompt)
FAIL: gdb.base/gdb-caching-proc.exp: can_spawn_for_attach: 6: can spawn for attach (got interactive prompt)
FAIL: gdb.base/gdb-caching-proc.exp: can_spawn_for_attach: 7: can spawn for attach (got interactive prompt)
FAIL: gdb.base/gdb-caching-proc.exp: can_spawn_for_attach: 8: can spawn for attach (got interactive prompt)
FAIL: gdb.base/gdb-caching-proc.exp: can_spawn_for_attach: 9: can spawn for attach (got interactive prompt)
here are the detailed messages in gdb/testsuite/gdb.log:
attach 873776
A program is being debugged already. Kill it? (y or n) n
Not killed.
(gdb) FAIL: gdb.base/gdb-caching-proc.exp: can_spawn_for_attach: 0: can spawn for attach (got interactive prompt)
so handle the case "A program is being debugged already. Kill it" in
can_spawn_for_attach to fix the failed testcases.
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Alan Modra [Wed, 2 Mar 2022 13:34:57 +0000 (00:04 +1030)]
PowerPC64 DT_RELR relative reloc addresses
Section addresses can change between ppc64_elf_size_stubs and
ppc64_elf_build_stubs due to .eh_frame editing. The idea of stashing
r_offset final addresses calculated in ppc64_elf_size_stubs for use by
ppc64_elf_build_stubs was never a good idea. Instead, we need to keep
section/offset pairs.
* elf64-ppc.c (struct ppc_link_hash_table): Delete relr_addr.
Add relr section/offset array.
(append_relr_off): Rewrite. Update all callers.
(sort_relr): New function.
(ppc64_elf_size_stubs): Adjust to suit new relative reloc stash.
(ppc64_elf_build_stubs): Likewise.
John Baldwin [Wed, 2 Mar 2022 22:09:55 +0000 (14:09 -0800)]
configure: Stop checking for PT_GETXMMREGS.
This request is present on all modern *BSD/i386 systems (those
released since mid-2006), and the *BSD/i386 targets now assume it is
present unconditionally.
John Baldwin [Wed, 2 Mar 2022 22:00:36 +0000 (14:00 -0800)]
fbsd-tdep: Implement the vsyscall_range gdbarch hook.
FreeBSD recently added a real vDSO in its shared page for the amd64
architecture. The vDSO is mapped at the address given by the
AT_KPRELOAD ELF auxiliary vector entry. To find the end of the
mapping range, parse the list of virtual map entries used by 'info
proc mappings' either from the NT_PROCSTAT_VMMAP core dump note, or
via the kinfo_getvmmap function for native targets (fetched from the
native target as the TARGET_OBJECT_FREEBSD_VMMAP object).
This silences warnings on recent FreeBSD/amd64 kernels due to not
finding symbols for the vdso:
warning: Could not load shared library symbols for [vdso].
Do you need "set solib-search-path" or "set sysroot"?
Tom Tromey [Mon, 14 Feb 2022 17:19:06 +0000 (10:19 -0700)]
Rewrite make-target-delegates in Python
I think gdb is probably better off having fewer languages involved
when generating code. 'sh' is unavoidable for build-time generation,
but for other things, let's use Python.
This rewrites make-target-delegates in Python. I've stuck pretty
closely to the original code in this rewrite, so it may look slightly
weird from a Python perspective.
The only output difference is that a copyright header is now
generated, using the code introduced in the previous patch.
make-target-delegates.py is simpler to invoke, as it knows the correct
input file to scan and it creates the output file itself.
Tom Tromey [Mon, 14 Feb 2022 15:26:32 +0000 (08:26 -0700)]
Move copyright code from gdbarch.py to new file
This moves the copyright code from gdbarch.py to a new Python source
file, gdbcopyright.py. The function in this file will find the
copyright dates by scanning the calling script. This will be reused
in a future patch.
This involved minor changes to the output of gdbarch.py. Also, I've
updated copyright.py to remove the reference to gdbarch.sh. We don't
need to mention gdbarch.py there, either.
Tom Tromey [Mon, 28 Feb 2022 00:31:54 +0000 (17:31 -0700)]
Some "distclean" fixes in gdb
PR build/12440 points out that "make distclean" is broken in gdb.
Most of the breakage comes from other projects in the tree, but we can
fix some of the issues, which is what this patch does.
Note that the yacc output files, like c-exp.c, are left alone. In a
source distribution, these are included in the tarball, and if the
user builds in-tree, we would not want to remove them.
While that seems a bit obscure, it seems to me that "distclean" is
only really useful for in-tree builds anyway -- out-of-tree I simply
delete the entire build directory and start over.
Tom Tromey [Tue, 1 Mar 2022 23:50:39 +0000 (16:50 -0700)]
Fix typo in the "alias" example
PR cli/17332, filed around 8 years ago, points out a typo in the docs
-- in one example, the command and its output are obviously out of
sync. This patch fixes it. I'm checking this in as obvious.
Nick Clifton [Tue, 1 Mar 2022 09:51:59 +0000 (09:51 +0000)]
Prevent an assertion from being triggered when linking an ARM object file with incorrectly set build attributes.
PR 28848
PR 28859
* elf32-arm.c (elf32_arm_merge_eabi_attributes): If the first
input bfd has a Tag_ABI_HardFP_use set to 3 but does not also have
TAG_FP_arch set then reset the TAG_ABI_HardFP_use.
Tiezhu Yang [Tue, 1 Mar 2022 07:05:00 +0000 (15:05 +0800)]
gdb: testsuite: fix wrong expected result in attach-pie-noexec.exp
If /proc/sys/kernel/yama/ptrace_scope is 1, when execute the test case
gdb.base/attach-pie-noexec.exp without superuser, the gdb.log shows the
following info:
(gdb) attach 6500
Attaching to process 6500
ptrace: Operation not permitted.
(gdb) PASS: gdb.base/attach-pie-noexec.exp: attach
It is obviously wrong, the expected result should be UNSUPPORTED in such
a case.
It is better to make can_spawn_for_attach to return false for this case.
It would have to setup a small test program, compile it to exec, spawn it
and try to attach to it.
With this patch, we can see "Operation not permitted" in the log info,
and then we can do the following processes to test:
(1) set ptrace_scope as 0
$ echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope
$ make check-gdb TESTS="gdb.base/attach-pie-noexec.exp"
(2) use sudo
$ sudo make check-gdb TESTS="gdb.base/attach-pie-noexec.exp"
Additionally, handle the other cases when test with RUNTESTFLAGS=
"--target_board=native-extended-gdbserver".
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Tiezhu Yang [Tue, 1 Mar 2022 07:03:00 +0000 (15:03 +0800)]
gdb: testsuite: print explicit test result in can_spawn_for_attach
In the current code, there is no test result when execute the following
commands:
$ make check-gdb TESTS="gdb.base/attach-pie-noexec.exp" RUNTESTFLAGS="--target_board=remote-gdbserver-on-localhost"
$ make check-gdb TESTS="gdb.base/attach-pie-noexec.exp" RUNTESTFLAGS="--target_board=native-gdbserver"
It is better to print explicit test result in can_spawn_for_attach.
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Keith Seitz [Mon, 28 Feb 2022 19:55:51 +0000 (11:55 -0800)]
Fix "spawn id XYZ not open" errors in gdb.mi/mi-exec-run.exp
Running mi-exec-run.exp on native-extended-gdbserver/-m{32,64}
causes several Tcl errors to appear. For example,
(gdb)
ERROR: : spawn id exp20 not open
while executing
"expect {
-i exp11 -timeout 10
-i "$inferior_spawn_id"
-re ".*Cannot exec.*Permission denied" {
set saw_perm_error 1
verbose -log "saw..."
("uplevel" body line 1)
invoked from within
"uplevel $body" NONE : spawn id exp20 not open
UNRESOLVED: gdb.mi/mi-exec-run.exp: inferior-tty=separate: mi=separate: force-fail=1: run failure detected (eof)
This is happening because of the way this test is implemented:
while {1} {
gdb_expect {
-i "$inferior_spawn_id"
-re ".*Cannot exec.*Permission denied" {
set saw_perm_error 1
verbose -log "saw mi error"
}
-i "$gdb_spawn_id"
-re "\\^error,msg=\"During startup program exited with code 127" {
set saw_mi_error 1
verbose -log "saw mi error"
}
# and so on
}
}
The first time this loop is executed, `inferior_spawn_id' is valid. When the
first branch of the expect statement is reached, gdbserver has exited, closing
the spawn_id. Since we haven't seen the gdb-side error yet, the loop is executed
again. The first branch now refers to a non-existent spawn_id, leading to the error.
This can be fixed by using exp_continue to loop in expect instead of looping around
expect, which is the approach I have used[1]. Note I've had to update the expected
message for the "During startup..." error message when running with gdbserver.
One other small change I've made is to add a log entry which spills the values of
the two variables, saw_mi_error and saw_perm_error (and updated the log output
for the later). This should make the log output clearer about why the test failed.
With this patch installed, all the ERRORs disappear, leaving previously masked
FAILs (which I have not attempted to fix).
[1] Anyone know why this test doesn't simply use gdb_test_multiple? I can only
assume that it was intentionally written this way, and I've modified the code with
that assumption. I have tested a version using gdb_test_multiple, and that appears
to work fine, too, if that is preferred. [It still employs exp_continue to fix the
spawn_id errors.]
Tom Tromey [Mon, 28 Feb 2022 17:53:13 +0000 (10:53 -0700)]
Fix maybe-uninitialized warning in py-infthread.c
I got this warning from py-infthread.c using the Fedora 34 system GCC:
../../binutils-gdb/gdb/python/py-infthread.c:102:30: warning: ‘extra_info’ may be used uninitialized in this function [-Wmaybe-uninitialized]
I think this happens because GDB_PY_HANDLE_EXCEPTION expands to an
'if' whose condition is always true -- but GCC can't know this. This
patch avoids the warning by adding a harmless initialization.
Tom Tromey [Wed, 26 Jan 2022 14:11:18 +0000 (07:11 -0700)]
Handle multi-byte bracket sequences in Ada lexer
As noted in an earlier patch, the Ada lexer does not handle multi-byte
bracket sequences. This patch adds support for these for character
literals. gdb does not generally seem to handle the Ada wide string
types, so for the time being these continue to be excluded -- but an
explicit error is added to make this more clear.
Tom Tromey [Tue, 25 Jan 2022 18:26:15 +0000 (11:26 -0700)]
Handle 'QWW' encoding case in Ada enums
In Ada, an enum can contain character literals. GNAT encodes these
values in a special way. For example, the Unicode character U+0178
would be represented as 'QW0178' in the DWARF:
gdb handles this reasonably well, but failed to handle the 'QWW'
encoding, which is used for characters outside the base plane.
Also, while working on this, I noticed that gdb will print the decimal
value for an enum character constant:
(gdb) print Char_X
$2 = 1 'x'
This is a nice feature, IMO, because in this situation the 'x' enum
constant does not have its usual decimal value -- it has the value
that's assigned based on the enumeration type.
However, gdb did not do this when it decided to print the constant
using the bracket notation:
(gdb) print Char_Thorn
$3 = ["de"]
This patch changes gdb to print the decimal value here as well, and to
put the bracket notation in single quotes -- otherwise gdb will be
printing something that it can't then read. Now it looks like:
(gdb) print Char_Thorn
$3 = 4 '["de"]'
Note that gdb can't read longer bracket notations, like the other ones
printed in this test case:
(gdb) print Char_King
$4 = 3 '["01fa00"]'
While I think this is a bug, I plan to fix it separately.
Finally, in the new test case, the copyright dates are chosen this way
because this all started as a copy of an existing test.
This adds a new read-only attribute gdb.InferiorThread.details, this
attribute contains a string, the results of target_extra_thread_info
for the thread, or None, if target_extra_thread_info returns nullptr.
As the string returned by target_extra_thread_info is unstructured,
this attribute is only really useful for echoing straight through to
the user, but, if a user wants to write a command that displays the
same, or a similar 'Thread Id' to the one seen in 'info threads', then
they need access to this string.
Given that the string produced by target_extra_thread_info varies by
target, there's only minimal testing of this attribute, I check that
the attribute can be accessed, and that the return value is either
None, or a string.
Keith Seitz [Mon, 28 Feb 2022 15:40:23 +0000 (07:40 -0800)]
Error when gdb_is_target_1 is called without running gdb instance
This is a snafu that I encountered while implementing the previous
patch, which attempted to use gdb_is_target_native. This proc and
gdb_is_target_remote both rely on gdb_is_target_1, which actually
cannot be called without gdb already running.
This patch adds appropriate warning comments to these procs and
causes gdb_is_target_1 to issue a Tcl error if it is called without a
gdb instance already running. This should prevent unwitting callers
from using this at the wrong time.
Keith Seitz [Mon, 28 Feb 2022 15:31:32 +0000 (07:31 -0800)]
Fix gdb.fortran "failed to extract expected results" errors
When running the gdb.fortran tests array-slices.exp and lbound-ubound.exp,
the test suite throws several ERRORs on native-gdbserver/-m{32,64},
and native-extended-gdbsever/-m{32,64}:
[on native-extended-gdbserver/-m64]
Running /home/keiths/work/gdb/branches/testsuite-errors/linux/gdb/testsuite/../../../src/gdb/testsuite/gdb.fortran/array-slices.exp ...
ERROR: failed to extract expected results
ERROR: failed to extract expected results
Running /home/keiths/work/gdb/branches/testsuite-errors/linux/gdb/testsuite/../../../src/gdb/testsuite/gdb.fortran/lbound-ubound.exp ...
ERROR: failed to extract expected results for lbound
This occurs because the tests require inferior I/O which we do not have
access to while using these targets.
This patch skips these tests when running on non-native targets.
Kevin Buettner [Sat, 26 Feb 2022 20:35:10 +0000 (13:35 -0700)]
Handle recursive internal problem in gdb_internal_error_resync
I came across this problem when testing gdb.base/gdb-sigterm.exp
on a machine with a pre-release version of glib-2.34 installed:
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) Recursive internal problem.
FAIL: gdb.base/gdb-sigterm.exp: expect eof #0 (GDB internal error)
Resyncing due to internal error.
ERROR: : spawn id exp11 not open
while executing
"expect {
-i exp11 -timeout 10
-re "Quit this debugging session\\? \\(y or n\\) $" {
send_gdb "n\n" answer
incr count
}
-re "Create..."
("uplevel" body line 1)
invoked from within
"uplevel $body" NONE : spawn id exp11 not open
ERROR: Could not resync from internal error (timeout)
gdb.base/gdb-sigterm.exp: expect eof #0: stepped 9 times
UNRESOLVED: gdb.base/gdb-sigterm.exp: 50 SIGTERM passes
I don't have a problem with the latter ERROR nor the UNRESOLVED
messages. However the first ERROR regarding the exp11 spawn id
not being open is not especially useful.
This commit handles the "Recursive internal problem" case, avoiding
the problematic ERROR shown above.
With this commit in place, the log messages look like this instead:
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) Recursive internal problem.
FAIL: gdb.base/gdb-sigterm.exp: expect eof #15 (GDB internal error)
Resyncing due to internal error.
ERROR: Could not resync from internal error (recursive internal problem)
gdb.base/gdb-sigterm.exp: expect eof #15: stepped 12 times
UNRESOLVED: gdb.base/gdb-sigterm.exp: 50 SIGTERM passes
projects / thirdparty / binutils-gdb.git / log
