Nelson Chu [Mon, 11 Dec 2023 03:07:35 +0000 (11:07 +0800)]
RISC-V/gas: Clarify the definition of `relaxable' in md_apply_fix
The `relaxable' in md_apply_fix means if the relocation can be relaxed or not
in link-time generally. We can use `.option relax/norelax' to enable/disable
relaxations for some specific areas, so the value of `riscv_opts.relax'
will be changed dynamically. The `fixP->fx_tcbit' records the correct value
of `riscv_opts.relax' for every relocation. Therefore, set `relaxable' to
`riscv_opts.relax' will cause unexpected behavior for the following case,
For the current assembler, the final value of `riscv_opts.relax' is false, so
the second `lla a2, foo2' won't have R_RISCV_RELAX relocation, but should have.
gas/
* config/tc-riscv.c (md_apply_fix): Set the value of `relaxable' to
`riscv_opts.relax' is wrong. It should be `true' generally.
Alan Modra [Wed, 18 Oct 2023 22:21:47 +0000 (08:51 +1030)]
R_MICROMIPS_GPREL7_S2
This reloc is meant for the 16-bit LWGP instruction, 0x6400/0xfc00
match/mask encoding in `micromips_opcodes'. It is correctly specified
to operate on a half-word by the howtos in elf32-mips.c, elfn32-mips.c
and elf64-mips.c, but is incorrectly subject to shuffle/unshuffle in
code like _bfd_mips_elf32_gprel16_reloc.
Current behaviour when applying the reloc to .byte 0x11,0x22,0x33,0x44
is to apply the reloc to byte 0x22 when big-endian, and to byte 0x33
when little-endian. Big-endian behaviour is unchanged after this
patch and little-endian correctly applies the reloc to byte 0x11.
The patch also corrects REL addend extraction from section contents,
and overflow checking. gold had all of the bfd problems with this
reloc and additionally did not apply the rightshift by two.
bfd/
* elfxx-mips.c (micromips_reloc_shuffle_p): Return false for
R_MICROMIPS_GPREL7_S2.
(mips_elf_calculate_relocation): Correct sign extension and
overflow calculation for R_MICROMIPS_GPREL7_S2.
(_bfd_mips_elf_relocate_section): Update small-data overflow
message.
gold/
* mips.cc (Mips_relocate_functions::should_shuffle_micromips_reloc):
Return false for R_MICROMIPS_GPREL7_S2.
(Mips_relocate_functions::mips_reloc_unshuffle): Update comment.
(Mips_relocate_functions::relgprel): Remove R_MICROMIPS_GPREL7_S2
handling.
(Mips_relocate_functions::relgprel7): New function.
(Target_mips::Relocate::relocate): Adjust to suit.
ld/
* testsuite/ld-mips-elf/reloc-4.d: Adjust expected error.
* testsuite/ld-mips-elf/reloc-5.d: Likewise.
Tom Tromey [Sat, 9 Dec 2023 16:19:30 +0000 (09:19 -0700)]
Add some new DW_IDX_* constants
I've reimplemented the .debug_names code in GDB -- it was quite far
from being correct, and the new implementation is much closer to what
is specified by DWARF.
However, the new writer in GDB needs to emit some symbol properties,
so that the reader can be fully functional. This patch adds a few new
DW_IDX_* constants, and tries to document the existing extensions as
well. (My patch series add more documentation of these to the GDB
manual as well.)
2023-12-10 Tom Tromey <tom@tromey.com>
* dwarf2.def (DW_IDX_GNU_internal, DW_IDX_GNU_external): Comment.
(DW_IDX_GNU_main, DW_IDX_GNU_language, DW_IDX_GNU_linkage_name):
New constants.
Jeff Law [Sun, 10 Dec 2023 20:24:59 +0000 (13:24 -0700)]
Improve performance of the H8 simulator
Running the H8 port through the GCC testsuite currently takes 4h 30m on my
fastest server -- that's roughly 1.5hrs per multilib tested and many tests are
disabled for various reasons.
To put that 1.5hr/multilib in perspective, that's roughly 3X the time for other
embedded targets. Clearly something isn't working as well as it should.
A bit of digging with perf shows that we're spending a crazy amount of time
decoding instructions in the H8 simulator. It's not hard to see why --
basically we take a blob of instruction data, then try to match it to every
instruction in the H8 opcode table starting at the beginning. That table has
~8000 entries (each different addressing mode is considered a different
instruction in the table).
Naturally my first thought was to sort the table and use a binary search to
find the right entry. That's made excessively complex due to the encoding on
the H8. Just getting the sort right would be much more complex than I'd
consider advisable.
Another thought was to build a mapping to the right entry for all the
instructions that can be disambiguated based on the first nibble (4 bits) of
instruction data and a mapping for those which can be disambiguated based on
the first byte of instruction data.
That seemed feasible until I realized that the H8/SX did some truly horrid
things with encoding branches in the 0x4XYY opcode space. It uses an "always
zero" bit in the offset to encode new semantic information. So we can't select
on just 0x4X. Ugh!
We could always to a custom decoder. I've done several through the years, they
can be very fast. But no way I can justify the time to do that.
So what I settled on was to first sort the opcode table by the first nibble,
then find the index of the first instruction for each nibble. Decoding uses
that index to start its search. This cuts the overall build/test by more than
half.
Next I adjusted the sort so that instructions that are not available on the
current sub architecture are put at the end of the table. This shaves another
~15% off the total cycle time.
The net of the two changes is on my fastest server we've gone from 4:30 to 1:40
running the GCC testsuite. Same test results before/after, of course. It's
still not fast, but it's a hell of a lot better.
Tom de Vries [Sat, 9 Dec 2023 13:44:49 +0000 (14:44 +0100)]
[gdb/tui] Handle shared border in fixed-sized layout
In tui_layout_split::apply I noticed that for variable-size layouts we take
share_box into account by decreasing used_size:
...
used_size += info[i].size;
if (info[i].share_box)
--used_size;
...
but not for fixed-size layouts:
...
if (info[i].min_size == info[i].max_size)
available_size -= info[i].min_size;
...
Fix this by increasing available_size for fixed-size layouts with shared box.
Tom de Vries [Fri, 8 Dec 2023 22:02:31 +0000 (23:02 +0100)]
[gdb/tui] Show focus window in status line
The focused window is highlighted by using active-border-kind instead of
border-kind.
But if the focused window is the cmd window (which is an unboxed window), then
no highlighting is done, and it's not obvious from looking at the screen which
window has the focus. Instead, you have to notice the absence of highlighting
on boxed windows, and then infer that the focus is on the unboxed window.
That approach stops working if there are multiple unboxed windows.
Likewise if highlighting is switched off by setting active-border-kind to the
same value as border-kind.
Make it more explicit which window has the focus by mentioning it in the status
window, like so:
...
native process 8282 (src) In: main L7 PC: 0x400525
...
Tested on x86_64-linux and ppc64le-linux.
Tested-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com> Reviewed-By: Eli Zaretskii <eliz@gnu.org> Approved-By: Tom Tromey <tom@tromey.com>
Hannes Domani [Fri, 8 Dec 2023 18:06:14 +0000 (19:06 +0100)]
Fix printing of global variable stubs if no inferior is running
Since 3c45e9f915ae4aeab7312d6fc55a947859057572 gdb crashes when trying
to print a global variable stub without a running inferior, because of
a missing nullptr-check (the block_scope function took care of that
check before it was converted to a method).
With this check it works again:
```
(gdb) print s
$1 = <incomplete type>
```
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31128 Approved-By: Tom Tromey <tom@tromey.com>
Andrew Burgess [Wed, 29 Nov 2023 16:10:46 +0000 (16:10 +0000)]
gdb/testsuite: tighten up some end-of-line patterns
Following on from the previous commit, I searched the testsuite for
places where we did:
set eol "<some pattern>"
in most cases the <some pattern> could be replaced with "\r\n" though
in the stabs test I've switched to using the multi_line proc as that
seemed like a better choice.
In gdb.ada/info_types.exp I did need to add an extra use of $eol as
the previous pattern would match multiple newlines, and in this one
place we were actually expecting to match multiple newlines. The
tighter pattern only matches a single newline, so we now need to be
explicit when multiple newlines are expected -- I think this is a good
thing.
All the tests are still passing for me after these changes.
Andrew Burgess [Wed, 29 Nov 2023 15:26:18 +0000 (15:26 +0000)]
gdb/testsuite: fix gdb.ada/complete.exp timeout in READ1 mode
While reviewing another patch I spotted a timeout in
gdb.ada/complete.exp when testing in READ1 mode, e.g.:
$ make check-read1 TESTS="gdb.ada/complete.exp"
...
FAIL: gdb.ada/complete.exp: complete break ada (timeout)
...
The problem is an attempt to match the entire output from GDB within a
single gdb_test_multiple pattern, for a completion command that
returns a large number of completions.
This commit changes the gdb_test_multiple to process the output line
by line. I don't use the gdb_test_multiple -lbl option, as I've
always found that option backward -- it checks for the \r\n at the
start of each line rather than the end, I think it's much clearer to
use '^' at the start of each pattern, and '\r\n' at the end, so that's
what I've done here.
.... Or I would, if this test didn't already define $eol as the end of
line regexp ... except that $eol was set to '[\r\n]*', which isn't
that helpful, so I've updated $eol to be just '\r\n' the actual end of
line regexp.
And now, the test passes without a timeout when using READ1.
There should be no change in what is tested after this commit.
Andrew Burgess [Tue, 7 Nov 2023 16:46:34 +0000 (16:46 +0000)]
gdbserver: allow for general 'monitor set debug COMPONENT VALUE' use
Building on the last commit, which added a general --debug=COMPONENT
option to the gdbserver command line, this commit updates the monitor
command to allow for general:
(gdb) monitor set debug COMPONENT off|on
style commands. Just like with the previous commit, the COMPONENT can
be any one of all, threads, remote, event-loop, and correspond to the
same set of global debug flags.
While on the command line it is possible to do:
--debug=remote,event-loop,threads
the components have to be entered one at a time with the monitor
command. I guess there's no reason why we couldn't allow component
grouping within the monitor command, but (to me) what I have here
seemed more in the spirit of GDB's existing 'set debug ...' commands.
If people want it then we can always add component grouping later.
Notice in the above that I use 'off' and 'on' instead of '0' and '1',
which is what the 'monitor set debug' command used to use. The 0/1
can still be used, but I now advertise off/on in all the docs and help
text, again, this feels more inline with GDB's existing boolean
settings.
I have removed the two existing monitor commands:
monitor set remote-debug 0|1
monitor set event-loop-debug 0|1
These are replaced by:
monitor set debug remote off|on
monitor set debug event-loop off|on
respectively.
Approved-By: Tom Tromey <tom@tromey.com> Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Andrew Burgess [Sun, 5 Nov 2023 21:02:03 +0000 (21:02 +0000)]
gdbserver: allow the --debug command line option to take a value
Currently, gdbserver has the following command line options related to
debugging output:
--debug
--remote-debug
--event-loop-debug
This doesn't scale well. If I want an extra debug component I need to
add another command line flag.
This commit changes --debug to take a list of components.
The currently supported components are: all, threads, remote, and
event-loop. The 'threads' component represents the debug we currently
get from the --debug option. And if --debug is used without a
component list then the threads component is assumed as the default.
Currently the threads component actually includes a lot of output that
is not really threads related. In the future I'd like to split this
up into some new, separate components. But that is not part of this
commit, or even this series.
The special component 'all' does what you'd expect: enables debug
output from all supported components.
The component list is parsed left to write, and you can prefix a
component with '-' to disable that component, so I can write:
target> gdbserver --debug=all,-event-loop
to get debug for all components except the event-loop component.
I've removed the existing --remote-debug and --event-loop-debug
command line options, these are equivalent to --debug=remote and
--debug=event-loop respectively, or --debug=remote,event-loop to
enable both components.
In this commit I've only update the command line options, in the next
commit I'll update the monitor commands to support a similar
interface.
Reviewed-By: Eli Zaretskii <eliz@gnu.org> Approved-By: Tom Tromey <tom@tromey.com>
Andrew Burgess [Wed, 22 Nov 2023 15:57:56 +0000 (15:57 +0000)]
gdb: fix GDB_DEBUG and GDBSERVER_DEBUG Makefile variables
The gdb/testsuite/README file documents GDB_DEBUG and GDBSERVER_DEBUG
flags, which can be passed to make in order to enable debugging within
GDB or gdbserver respectively.
However, when I do:
make check-gdb GDB_DEBUG=infrun
I don't see the corresponding debug feature within GDB being enabled.
Nor does:
make check-gdb GDBSERVER_DEBUG=debug \
RUNTESTFLAGS="--target_board=native-extended-gdbserver"
Appear to enable gdbserver debugging.
I tracked this down to the GDB_DEBUG and GDBSERVER_DEBUG flags being
missing from the TARGET_FLAGS_TO_PASS variable in gdb/Makefile. This
variable already contains lots of testing related flags, like
RUNTESTFLAGS and TESTS, so I think it makes sense to add GDB_DEBUG and
GDBSERVER_DEBUG here too.
With this done, this debug feature is now working as expected.
Hannes Domani [Fri, 8 Dec 2023 17:19:42 +0000 (18:19 +0100)]
Use pretty printers for struct member stubs
PR29079 shows that pretty printers can be used for an incomplete
type (stub), but only when printing it directly, not if it's
part of another struct:
```
(gdb) p s
$1 = {pp m_i = 5}
(gdb) p s2
$2 = {m_s = <incomplete type>, m_l = 20}
```
The reason is simply that in common_val_print the check for stubs
is before any pretty printer is tried.
It works if the pretty printer is tried before the stub check:
```
(gdb) p s
$1 = {pp m_i = 5}
(gdb) p s2
$2 = {m_s = {pp m_i = 10}, m_l = 20}
```
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29079 Approved-By: Tom Tromey <tom@tromey.com>
Tom de Vries [Fri, 8 Dec 2023 16:36:35 +0000 (17:36 +0100)]
[gdb/tui] Fix displaying main after resizing
A TUI src window is displaying either:
- the source for the current frame,
- the source for main, or
- the string "[ No Source Available ]".
Since commit 03893ce67b5 ("[gdb/tui] Fix resizing of terminal to 1 or 2 lines")
we're able to resize the TUI to 1 line without crashing.
I noticed that if TUI is displaying main, and we resize to 1 line (destroying
the src window) and then back to a larger terminal (reconstructing the src
window), the TUI displays "[ No Source Available ]" instead of main.
Fix this by moving the responsibility for showing main from tui_enable to
tui_source_window_base::rerender.
Tom Tromey [Fri, 24 Nov 2023 19:10:53 +0000 (12:10 -0700)]
Allow cast of 128-bit integer to pointer
PR rust/31082 points out that casting a 128-bit integer to a pointer
will fail. This happens because a case in value_cast was not
converted to use GMP.
This patch fixes the problem. I am not really sure that testing
against the negative value here makes sense, but I opted to just
preserve the existing behavior rather than change it.
Guinevere Larsen [Thu, 26 Oct 2023 14:28:54 +0000 (16:28 +0200)]
gdb: Guarantee that an SAL's end is right before the next statement
When examining a failure that happens when testing
gdb.python/py-symtab.c with clang, I noticed that it was going wrong
because the test assumed that whenever we get an SAL, its end would
always be right before statement in the line table. This is true for GCC
compiled binaries, since gcc only adds statements to the line table, but
not true for clang compiled binaries.
This is the second time I run into a problem where GDB doesn't handle
non-statement line table entries correctly. The other was eventually
committed as 9ab50efc463ff723b8e9102f1f68a6983d320517: "gdb: fix until
behavior with trailing !is_stmt lines", but that commit only changes the
behavior for the 'until' command. In this patch I propose a more general
solution, making it so every time we generate the SAL for a given pc, we
set the end of the SAL to before the next statement or the first
instruciton in the next line, instead of naively assuming that to be the
case.
With this new change, the edge case is removed from the processing of
the 'until' command without regressing the accompanying test case, and
no other regressions were observed in the testsuite.
Mike Frysinger [Thu, 7 Dec 2023 03:06:07 +0000 (20:06 -0700)]
sim: cris: fix -Wunused-but-set-variable warnings
We suppress the warning in the generated switch file because the cris
cpu file has a hack to workaround a cgen bug, but that generates a set
but unused variable which makes the compiler upset.
Rework the code to use static inline functions when it's disabled
rather than macros so the compiler knows the various function args
are always used. The ifdef macros are a bit ugly, but get the job
done without duplicating the function prototypes.
Mike Frysinger [Fri, 8 Dec 2023 04:40:00 +0000 (21:40 -0700)]
sim: m32r: fix syslog call
The function returns void, not int. We only pass one argument to
syslog (the format), so use %s as the static format instead since
the emulation layer doesn't handle passing additional arguments.
gdb/record: Support for rdtscp in i386_process_record.
This patch adds support for process recording of the instruction rdtscp in
x86 architecture.
Debugging applications with "record full" fail to record with the error
message "Process record does not support instruction 0xf01f9".
Mike Frysinger [Wed, 6 Dec 2023 06:13:50 +0000 (23:13 -0700)]
sim: warnings: add more flags
Sync with the list of flags from gdbsupport, and add a few more of
our own to catch recent issues. Comment out the C++-specific flags
as we don't build with C++.
Kevin Buettner [Thu, 7 Dec 2023 03:08:53 +0000 (20:08 -0700)]
Add more 'step' tests to gdb.base/watchpoint.exp
The test gdb.base/watchpoint.exp has a proc named 'test_stepping'
which claims to "Test stepping and other mundane operations with
watchpoints enabled". It sets a watchpoint on ival2, performs an
inferior function call (which is not at all mundane), and uses 'next',
'until', and, finally, does a 'step'.
However, that final 'step' command steps to (but not over/through) the
line at which the assignment to ival2 takes place. At no time while
performing these operations is a watchpoint hit.
This commit adds a test to see what happens when stepping over/through
the assignment to ival2. The watchpoint on ival2 should be triggered
during this step. I've added another 'step' to make sure that the
correct statement is reached after performing the watchpoint-hitting
step.
After running the 'test_stepping' proc, gdb.base/watchpoint.exp does
a clean_restart before doing further tests, so nothing depends upon
'test_stepping' to stop at the particular statement at which it had
been stopping.
I've examined all tests which set watchpoints and step. I haven't
been able to identify a(nother) test case which tests what happens
when stepping over/through a statement which triggers a watchpoint.
Therefore, adding these new 'step' tests is testing something which
hasn't being tested elsewhere.
Hannes Domani [Wed, 6 Dec 2023 19:52:06 +0000 (20:52 +0100)]
Fix DLL export forwarding
I noticed it when I was trying to set a breakpoint at ExitProcess:
```
(gdb) b ExitProcess
Breakpoint 1 at 0x14001fdd0
(gdb) r
Starting program: C:\qiewer\heob\heob64.exe
Warning:
Cannot insert breakpoint 1.
Cannot access memory at address 0x3dbf4120
Cannot insert breakpoint 1.
Cannot access memory at address 0x77644120
```
The problem doesn't exist in gdb 13.2, and the difference can easily be
seen when printing ExitProcess.
gdb 14.1:
```
(gdb) p ExitProcess
$1 = {<text variable, no debug info>} 0x77644120 <UserHandleGrantAccess+36128>
```
gdb 13.2:
```
(gdb) p ExitProcess
$1 = {<text variable, no debug info>} 0x77734120 <ntdll!RtlExitUserProcess>
```
The new behavior started with 9675da25357c7a3f472731ddc6eb3becc65b469a,
where VMA was then calculated relative to FORWARD_DLL_NAME, while it was
relative to DLL_NAME before.
Fixed by calculating VMA relative to DLL_NAME again.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31112 Approved-By: Tom Tromey <tom@tromey.com>
Tom Tromey [Fri, 10 Nov 2023 18:58:47 +0000 (11:58 -0700)]
Always use expand_symtabs_matching in ada-lang.c
The previous patch fixed the immediate performance problem with Ada
name matching, by having a subset of matches call
expand_symtabs_matching rather than expand_matching_symbols. However,
it seemed to me that expand_matching_symbols should not be needed at
all.
To achieve this, this patch changes ada_lookup_name_info::split_name
to use the decoded name, rather than the encoded name. In order to
make this work correctly, a new decoded form is used: one that does
not decode operators (this is already done) and also does not decode
wide characters. The latter change is done so that changes to the Ada
source charset don't affect the DWARF index.
With this in place, we can change ada-lang.c to always use
expand_symtabs_matching rather than expand_matching_symbols.
Tom Tromey [Fri, 10 Nov 2023 16:16:17 +0000 (09:16 -0700)]
Improve performance of Ada name searches
A user reported that certain operations -- like printing a large
structure -- could be slow. I tracked this down to
ada-lang.c:map_matching_symbols taking an inordinate amount of time.
Specifically, calls like the one to look for a parallel "__XVZ"
variable, in ada_to_fixed_type_1, could result in gdb walking over all
the entries in the cooked index over and over.
Looking into this reveals that
cooked_index_functions::expand_matching_symbols is not written
efficiently -- it ignores its "ordered_compare" parameter. While
fixing this would be good, it turns out that this entire method isn't
needed; so this series removes it.
However, the deletion is not done in this patch. This one, instead,
fixes the immediate cause of the slowdown, by using
objfile::expand_symtabs_matching when possible. This approach is
faster because it is more selective about which index entries to
examine.
Hannes Domani [Wed, 6 Dec 2023 12:45:51 +0000 (13:45 +0100)]
Fix hardware watchpoints in replay mode
Changes introduced by commit 9e8915c6cee5c37637521b424d723e990e06d597
caused a regression that meant hardware watchpoint stops would not
trigger in reverse execution or replay mode. This was documented in
PR breakpoints/21969.
The problem is that record_check_stopped_by_breakpoint always overwrites
record_full_stop_reason, thus loosing the TARGET_STOPPED_BY_WATCHPOINT
value which would be checked afterwards.
This commit fixes that by not overwriting the stop-reason in
record_full_stop_reason if we're not stopped at a breakpoint.
And the test for hw watchpoints in gdb.reverse/watch-reverse.exp actually
tested sw watchpoints again, since "set can-use-hw-watchpoints 1"
doesn't convert enabled watchpoints to use hardware.
This is fixed by disabling said watchpoint while enabling hw watchpoints.
The same is not done for gdb.reverse/watch-precsave.exp, since it's not
possible to use hw watchpoints in restored recordings anyways.
but I haven't checked. The issue the assert is highlighting is real,
and is caused by this block of code:
if (n_threads < 0)
{
const int hardware_threads = std::thread::hardware_concurrency ();
/* Testing in #29959 indicates that parallel efficiency drops between
n_threads=5 to 8. Therefore, clamp the default value to 8 to avoid an
excessive number of threads in the pool on many-core systems. */
const int throttle = 8;
n_threads = std::clamp (hardware_threads, hardware_threads, throttle);
}
The arguments to std::clamp are VALUE, LOW, HIGH, but in the above, if
we have more than 8 hardware threads available the LOW will be greater
than the HIGH, which is triggering the assert I see above.
I believe std::clamp is the wrong tool to use here. Instead std::min
would be a better choice; we want the smaller value of
HARDWARE_THREADS or THROTTLE. If h/w threads is 2, then we want 2,
but if h/w threads is 16 we want 8, this is what std::min gives us.
This reverts commit 1c04f72368c ("[gdb/symtab] Fix assert in set_length"), due
to a regression reported in PR29572, and implements a different fix for PR29453.
The fix is to not use the CU table in a .debug_names section to construct
all_units, but instead use create_all_units, and then verify the CU
table from .debug_names. This also fixes PR25969, so remove the KFAIL.
Approved-By: Tom Tromey <tom@tromey.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29572
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=25969
Alan Modra [Mon, 4 Dec 2023 22:53:41 +0000 (09:23 +1030)]
PR31096, nm shows 32bit addresses as 64bit addresses
Prior to commit 0e3c1eebb2 nm output depended on the host unsigned
long when printing "negative" symbol values for 32-bit targets.
Commit 0e3c1eebb22 made the output match that seen with a 64-bit host
unsigned long. The fact that nm output changed depending on host is
of course a bug, but it is reasonable to expect 32-bit target output
is only 32 bits. So this patch makes 32-bit target output the same as
it was on 32-bit hosts prior to 0e3c1eebb2.
PR 31096
* nm.c (print_format_string): Make it a static buffer.
(get_print_format): Merge into..
(set_print_format): ..this, renamed from set_print_width. When
print_width is 32, set up print_format_string for an int32_t
value. Don't malloc print_format_string. Adjust calls.
(print_value): Correct printing of 32-bit values.
Jakub Jelinek [Tue, 5 Dec 2023 22:34:01 +0000 (23:34 +0100)]
libiberty: Fix build with GCC < 7
Tobias reported on IRC that the linker fails to build with GCC 4.8.5.
In configure I've tried to use everything actually used in the sha1.c
x86 hw implementation, but unfortunately I forgot about implicit function
declarations. GCC before 7 did have <cpuid.h> header and bit_SHA define
and __get_cpuid function defined inline, but it didn't define
__get_cpuid_count, which compiled fine (and the configure test is
intentionally compile time only) due to implicit function declaration,
but then failed to link when linking the linker, because
__get_cpuid_count wasn't defined anywhere.
The following patch fixes that by using what autoconf uses in AC_CHECK_DECL
to make sure the functions are declared.
2023-12-05 Jakub Jelinek <jakub@redhat.com>
* configure.ac (HAVE_X86_SHA1_HW_SUPPORT): Verify __get_cpuid and
__get_cpuid_count are not implicitly declared.
* configure: Regenerated.
Hannes Domani [Tue, 5 Dec 2023 17:41:44 +0000 (18:41 +0100)]
Fix breakpoints on symbols with multiple trampoline symbols
On mingw targets it's possible that there are multiple trampoline
symbols for __cxa_throw, in each module where a throw is done, but
without a corresponding global symbol.
Since commit 77f2120b200be6cabbf6f610942fc1173a8df6d3 they cancel each
other out in search_minsyms_for_name, which makes it impossible to set
a breakpoint there:
(gdb) b __cxa_throw
Function "__cxa_throw" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 2 (__cxa_throw) pending.
(gdb) c
Continuing.
[Inferior 1 (process 10004) exited with code 03]
With catch throw it also doesn't work, and you don't even get an error
message:
(gdb) catch throw
Catchpoint 2 (throw)
(gdb) c
Continuing.
[Inferior 1 (process 5532) exited with code 03]
(gdb)
The fix is to simply ignore other trampoline symbols when looking for
corresponding global symbols, and it's working as expected:
(gdb) b __cxa_throw
Breakpoint 2 at 0x13f091590 (2 locations)
(gdb) c
Continuing.
Breakpoint 2.1, 0x000000013f091590 in __cxa_throw ()
(gdb)
And catch throw also works again:
(gdb) catch throw
Catchpoint 2 (throw)
(gdb) c
Continuing.
Catchpoint 2.1 (exception thrown), 0x000000013f181590 in __cxa_throw ()
(gdb)
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29548 Approved-By: Tom Tromey <tom@tromey.com>
Richard Bunt [Tue, 5 Dec 2023 09:54:12 +0000 (09:54 +0000)]
gdb/testsuite: Update worker thread show assertion
Commit 33ae45434d0 updated the text reported by GDB when showing the
number of worker threads. However, it neglected to update the assertions
using this text, which caused index-file.exp to fail. This commit
corrects this omission.
Tested index-file.exp is fixed on my local machine.
Nick Clifton [Tue, 5 Dec 2023 15:18:40 +0000 (15:18 +0000)]
Fix: strip --strip-debug breaks relocations
PR 31106
* elfcode.h (elf_write_relocs): Do not convert a relocation against a zero-value absolute symbol into a relocation without a symbol if the symbol is being used for a complex relocation.
Mike Frysinger [Tue, 5 Dec 2023 13:09:49 +0000 (06:09 -0700)]
sim: mips: fix sim_fpu usage
Fix some of the sim_fpu calls to use the right types. While I'm
not familiar with the MIPS ISA in these cases, these look like
simple oversights due to the name/type mismatches. This at least
fixes compiling with -Wenum-conversion.
Mike Frysinger [Tue, 5 Dec 2023 13:05:19 +0000 (06:05 -0700)]
sim: sh: trim trailing whitespace in generated code
No functional change here, but makes it a little easier to read the
generated code when editors aren't highlighting all the spurious
trailing whitespace on lines.
Mike Frysinger [Tue, 5 Dec 2023 12:56:52 +0000 (07:56 -0500)]
sim: mn10300: fix sim_engine_halt call
The sim_stop argument is an enum and should only be one of those
values, not a signal constant. Fix the logic to pass the right
sim_xxx & SIM_xxx values in the right arguments.
This is aimed at fixing holes in two alpha-ecoff relocation functions
that access section contents without first bounds checking offsets.
I've also rewritten ALPHA_R_OP_STORE handling to support writing to
the bytes near the end of the section.
* coff-alpha.c (alpha_ecoff_get_relocated_section_contents): Don't
bother checking ALPHA_R_LITERAL insn. Range check before reading
contents for ALPHA_R_GPDISP, and simplify handling. Rewrite
ALPHA_R_OP_STORE handling. Correct error callback args.
(alpha_relocate_section): Similarly. Don't abort, report errors.
Alan Modra [Tue, 5 Dec 2023 06:01:13 +0000 (16:31 +1030)]
Don't use free_contents in _bfd_elf_slurp_version_tables
In commit 7ac6d0c38c36 I made more use of free_contents in
_bfd_elf_slurp_version_tables, a variable added to tag the case where
raw verneed and verdefs have been read locally by the function, and
thus should be freed before returning. In retrospect it may have been
better to do without the extra variable entirely. It's easy to infer
when "contents" should be freed, costing a little extra on an error
path but costing less elsewhere.
* elf.c (_bfd_elf_slurp_version_tables): Don't use free_contents.
Mike Frysinger [Tue, 5 Dec 2023 04:43:51 +0000 (23:43 -0500)]
sim: warnings: enable only for development builds
Reuse the bfd/development.sh script like most other project to
determine whether the current source tree is a dev build (e.g.
git) or a release build, and disable the warnings for releases.
Mike Frysinger [Tue, 5 Dec 2023 04:40:05 +0000 (23:40 -0500)]
sim: ppc: fix implicit enum conversion
This code tries to use attach_type enums as hw_phb_decode, and while
they're setup to have compatible values, the compiler doesn't like it
when the cast is missing. So cast it explicitly and then use that.
sim/ppc/hw_phb.c:322:28: error:
implicit conversion from enumeration type 'attach_type'
(aka 'enum _attach_type') to different enumeration type
'hw_phb_decode' [-Werror,-Wenum-conversion]
Mike Frysinger [Tue, 5 Dec 2023 04:32:51 +0000 (23:32 -0500)]
sim: ppc: cleanup getrusage decls
Don't conflate HAVE_GETRUSAGE & HAVE_SYS_RESOURCE_H. Use the latter
to include the header and nothing else. Use the former to determine
whether to use the function and nothing else. If we find a system
that doesn't follow POSIX and provides only one of these, we can
figure out how to support it then. The manual local definition is
clashing with the system ones and leading to build failures with
newer C standards.
sim/ppc/emul_netbsd.c:51:5: error: a function declaration without a
prototype is deprecated in all versions of C and is treated as a
zero-parameter prototype in C2x, conflicting with a previous
declaration [-Werror,-Wdeprecated-non-prototype]
Alan Modra [Sun, 3 Dec 2023 22:18:34 +0000 (08:48 +1030)]
aarch64-elf: FAIL: indirect call stub to BTI stub relaxation
aarch64-elf fails the ld-aarch64/bfd-far-3.d test, due to the stubs
being emitted in a different order to that of aarch64-linux. They are
emitted in a different order due to stub names for local symbols
having the section id in the stub name. aarch64-linux-ld generates
one more section than aarch64-elf-ld. That section is .gnu.hash. So
the stub names differ and are hashed to different slots in
stub_hash_table.
Fix this by running the test with --hash-style=sysv, and adjust
expected output. I've also changed the branch over stubs emitted at
the start of a group of stubs to not care about the symbol, for all
groups not just the one that needed changing.
Ciaran Woodward [Mon, 4 Dec 2023 18:49:26 +0000 (18:49 +0000)]
[gdb/doc] Escape the '@' symbols in generated texinfo files.
'@' is a special symbol meaning 'command' in GNU texinfo.
If the GDBINIT or GDBINIT_DIR path during configuration
included an '@' character, the makeinfo command would fail,
as it interpreted the '@' in the path as a start of a command
when expanding the path in the docs.
This patch simply escapes any '@' characters in the path,
by replacing them with '@@'. This was already done for the
bugurl variable.
This was detected because the 'Jenkins' tool sometimes puts
an '@' in the workspace path.
Tom Tromey [Mon, 4 Dec 2023 14:48:42 +0000 (07:48 -0700)]
Fix two buglets in .debug_names dumping
While working on gdb's .debug_names writer, I found a couple of small
bugs in binutils .debug_names dumping.
First, the DWARF spec (section 6.1.1.4.6 Name Table) says:
These two arrays are indexed starting at 1, [...]
I think it is clearer for binutils to follow this, particularly
because DW_IDX_parent refers to this number.
Second, I think the handling of an empty hash table is slightly wrong.
Currently the dumping code assumes there is always an array of hashes.
However, section 6.1.1.4.5 Hash Lookup Table says:
The optional hash lookup table immediately follows the list of
type signatures.
and then:
The hash lookup table is actually two separate arrays: an array of
buckets, followed immediately by an array of hashes.
My reading of this is that the hash table as a whole is optional, and
so the hashes will not exist in this case. (This also makes sense
because the hashes are not useful without the buckets anyway.)
This patch fixes both of these problems. FWIW I have some gdb patches
in progress that change gdb both to omit the hash table and to use
DW_IDX_parent.
2023-12-04 Tom Tromey <tom@tromey.com>
* dwarf.c (display_debug_names): Handle empty .debug_names hash
table. Name entries start at 1.
Jens Remus [Wed, 29 Nov 2023 20:44:34 +0000 (21:44 +0100)]
s390: Support for jump visualization in disassembly
Add support for jump visualization for the s390 architecture in
disassembly:
objdump -d --visualize-jumps ...
Annotate the (conditional) jump and branch relative instructions with
information required for jump visualization:
- jump: Unconditional jump / branch relative.
- condjump: Conditional jump / branch relative.
- jumpsr: Jump / branch relative to subroutine.
Unconditional jump and branch relative instructions are annotated as
jump.
Conditional jump and branch relative instructions, jump / branch
relative on count/index, and compare and jump / branch relative
instructions are annotated as condjump.
Jump and save (jas, jasl) and branch relative and save (bras, brasl)
instructions are annotated as jumpsr (jump to subroutine).
Provide instruction information required for jump visualization during
disassembly.
The instruction type is provided after determining the opcode.
For non-code it is set to dis_noninsn. Otherwise it defaults to
dis_nonbranch. No annotation is done for data reference instructions
(i.e. instruction types dis_dref and dis_dref2). Note that the
instruction type needs to be provided before printing of the
instruction, as it is used in print_address_func() to translate the
argument value into an address if it is assumed to be a PC-relative
offset. Note that this is never the case on s390, as
print_address_func() is only called with addresses and never with
offsets.
The target of the (conditional) jump and branch relative instructions
is provided during print, when the PC relative operand is decoded.
include/
* opcode/s390.h: Define opcode flags to annotate instruction
class information for jump visualization:
S390_INSTR_FLAG_CLASS_BRANCH, S390_INSTR_FLAG_CLASS_RELATIVE,
S390_INSTR_FLAG_CLASS_CONDITIONAL, and
S390_INSTR_FLAG_CLASS_SUBROUTINE.
Define opcode flags mask S390_INSTR_FLAG_CLASS_MASK for above
instruction class information.
Define helpers for common instruction class flag combinations:
S390_INSTR_FLAGS_CLASS_JUMP, S390_INSTR_FLAGS_CLASS_CONDJUMP,
and S390_INSTR_FLAGS_CLASS_JUMPSR.
opcodes/
* s390-mkopc.c: Add opcode flags to annotate information
for jump visualization: jump, condjump, and jumpsr.
* s390-opc.txt: Annotate (conditional) jump and branch relative
instructions with information for jump visualization.
* s390-dis.c (print_insn_s390, s390_print_insn_with_opcode):
Provide instruction information for jump visualization.
Signed-off-by: Jens Remus <jremus@linux.ibm.com> Reviewed-by: Andreas Krebbel <krebbel@linux.ibm.com>
Richard Bunt [Mon, 4 Dec 2023 14:23:17 +0000 (14:23 +0000)]
gdb: Enable early init of thread pool size
This commit enables the early initialization commands (92e4e97a9f5) to
modify the number of threads used by gdb's thread pool.
The motivation here is to prevent gdb from spawning a detrimental number
of threads on many-core systems under environments with restrictive
ulimits.
With gdb before this commit, the thread pool takes the following sizes:
1. Thread pool size is initialized to 0.
2. After the maintenance commands are defined, the thread pool size is
set to the number of system cores (if it has not already been set).
3. Using early initialization commands, the thread pool size can be
changed using "maint set worker-threads".
4. After the first prompt, the thread pool size can be changed as in the
previous step.
Therefore after step 2. gdb has potentially launched hundreds of threads
on a many-core system.
After this change, step 2 and 3 are reversed so there is an opportunity
to set the required number of threads without needing to default to the
number of system cores first.
There does exist a configure option (added in 261b07488b9) to disable
multithreading, but this does not allow for an already deployed gdb to
be configured.
Additionally, the default number of worker threads is clamped at eight
to control the number of worker threads spawned on many-core systems.
This value was chosen as testing recorded on bugzilla issue 29959
indicates that parallel efficiency drops past this point.
GDB built with GCC 13.
No test suite regressions detected. Compilers: GCC, ACfL, Intel, Intel
LLVM, NVHPC; Platforms: x86_64, aarch64.
The scenario that interests me the most involves preventing GDB from
spawning any worker threads at all. This was tested by counting the
number of clones observed by strace:
The new test relies on "gdb: install CLI uiout while processing early
init files" developed by Andrew Burgess. This patch will need pushing
prior to this change.
The clamping was tested on machines with both 16 cores and a single
core. "maint show worker-threads" correctly reported eight and one
respectively.
Andrew Burgess [Mon, 4 Dec 2023 14:23:17 +0000 (14:23 +0000)]
gdb: install CLI uiout while processing early init files
The next commit wants to use a 'show' command within an early
initialisation file, despite these commands not being in the list of
acceptable commands for use within an early initialisation file.
The problem we run into is that the early initialisation files are
processed before GDB has installed the top level interpreter. The
interpreter is responsible to installing the default uiout (accessed
through current_uiout), and as a result code that depends on
uiout (e.g. 'show' commands) will end up dereferencing a nullptr, and
crashing GDB.
I did consider moving the interpreter installation before the early
initialisation, and this would work fine except for the new DAP
interpreter, which relies on having Python available during its
initialisation. Which means we can't install the interpreter until
after Python has been initialised, and the early initialisation
handling has to occur before Python is setup -- that's the whole point
of this feature (to allow customisation of how Python is setup).
So, what I propose is that early within captured_main_1, we install a
temporary cli_ui_out as the current_uiout. This will remain in place
until the top-level interpreter is installed, at which point the
temporary will be replaced.
What this means is that current_uiout will no longer be nullptr,
instead, any commands within an early initialisation file that trigger
output, will perform that output in a CLI style.
I propose that we don't update the documentation for early
initialisation files, we leave the user advice as being only 'set' and
'source' commands are acceptable. But now, if a user does try a
'show' command, then instead of crashing, GDB will do something
predictable.
I've not added a test in this commit. The next commit relies on this
patch and will serve as a test.
projects / thirdparty / binutils-gdb.git / log
