Jan Beulich [Thu, 19 Dec 2024 09:39:38 +0000 (10:39 +0100)]
bfd/ELF: refine PR binutils/31872 fix
The fix for PR binutils/31872 (commit b20ab53f81db) neglected the case
of targets with only RELA support, where nevertheless object files using
REL exist. In particular objcopy will create such objects for x86-64
when converting from an i?86 ELF object (this by itself probably isn't
quite right, but we ought to cope with what our own tools are doing).
Restore the fallback to the RELA lookup, just without re-introducing the
blind NULL de-ref that was there before.
Alan Modra [Wed, 18 Dec 2024 08:29:41 +0000 (18:59 +1030)]
target_id for cr16 and vax
Both of these targets extend elf_link_hash_entry, so arguably should
set hash_table_id to something other than GENERIC_ELF_DATA. The patch
also sorts enum elf_target_id.
Alan Modra [Wed, 18 Dec 2024 07:06:01 +0000 (17:36 +1030)]
Add a few elf_backend_data target ids
aarch64, am33, csky, ia64-vms, kvx, and sparc64 all use more than
the base GENERIC_ELF_DATA, but don't set ELF_TARGET_ID. Fix that.
These are all targets that use other than GENERIC_ELF_DATA in their
object and hash table ids.
Keith Seitz [Wed, 18 Dec 2024 18:06:52 +0000 (10:06 -0800)]
[doc] Update gdb-add-index manpage
The current gdb-add-index manual page is a bit out-of-date. This
commit fixes a few deficiencies:
- gdb-add-index does not use objdump; it uses objcopy and readelf
- missing info on environment variables (in appropriate ENVIRONMENT section).
- missing mention of -dwarf-5 option
- adds important notice about FILENAME being writable
- explains exit status
- the script adds appropriate section(s) to the file; it does not
output new files with the section(s)
Tom Tromey [Wed, 17 Apr 2024 20:11:45 +0000 (14:11 -0600)]
Add an include-checking script
This adds a new Python script that checks the header guards of all gdb
source files. It enforces a fairly strict formatting and naming
scheme.
In particular, for a file "x/y-z.h" (relative to the repository root),
the include guard will be named "X_Y_Z_H". Only the '#ifndef' form is
allowed, not "#if !defined(...)". The trailing comment on the
"#endif" is also required.
The script also tries to update files that appear to have the required
lines if they are in the wrong form or use the wrong name.
Tom Tromey [Wed, 17 Apr 2024 20:30:56 +0000 (14:30 -0600)]
Fix some minor header file irregularities
The script in the next patch noticed some irregularities in some
headers: trailing or leading blank lines, or in one case a missing
copyright header. This patch fixes these.
Tom Tromey [Wed, 18 Dec 2024 15:34:31 +0000 (08:34 -0700)]
Fix typo in Python documentation
Oleg pointed out that when renaming from "status" to "enabled" in the
Python TUI events patch, I neglected to update one spot in the
documentation. This patch fixes this. I'm checking it in as obvious.
You can verify that this change is correct by examining
gdb/python/py-event-types.def.
Haochen Jiang [Wed, 18 Dec 2024 02:40:33 +0000 (10:40 +0800)]
Support Intel SM4 AVX10.2 extension
In this patch, we will support SM4 AVX10.2 extension part. It is
a promotion from VEX encoding to EVEX encoding. The EVEX encoding
is based on AVX10.2, which is the same as the upcoming MOVRS ISA.
Thus, we decide to pull AVX10.2 out to CPU_COMMON_FLAGS.
While I have also tried to merge the table like AVX/AVX512, I
choose to just templatize the table. I am okay to go either way,
but slightly prefer the templatizing one since probably SM4 would
be the only ISA with AVX10.2 needs such VEX to EVEX extension (MOVRS
does not need that). Also, it is a tendancy that we will directly
provide EVEX encodings and no VEX encodings for vector instructions
since AVX10. This will make the adding in gas/config/tc-i386.c not
that worthy.
Tom Tromey [Tue, 17 Dec 2024 19:13:22 +0000 (12:13 -0700)]
Minor C++-ification in rust-parse.c
This patch changes a few spots in rust-parse.c to use 'bool', and also
declares a couple of loop iteration variables in the loop headers.
I'm checking this in.
Tiezhu Yang [Mon, 16 Dec 2024 07:03:05 +0000 (15:03 +0800)]
gdb: syscalls: Update ARM64 xml files
There are some new syscalls in the latest upstream Linux kernel [1],
some archs updated the xml files in the recent commit 19f3450f7429
("[gdb/syscalls] Add syscalls {set,get,list,remove}xattrat"), also
update ARM64 to reflect the reality.
Tiezhu Yang [Mon, 16 Dec 2024 07:03:03 +0000 (15:03 +0800)]
gdb: syscalls: Remove tips for LoongArch xml files
After commit "gdb: syscalls: Handle __NR3264_ prefixed syscall number",
no need to do special handling when generating xml file for LoongArch,
just remove the tips in the file comment.
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn> Approved-By: Tom de Vries <tdevries@suse.de>
Tiezhu Yang [Mon, 16 Dec 2024 07:03:02 +0000 (15:03 +0800)]
gdb: syscalls: Handle __NR3264_ prefixed syscall number
In gdb commit a08dc2aa004b ("gdb: syscalls: Add loongarch-linux.xml.in"),
we find:
There exist some __NR3264_ prefixed syscall numbers, replace them
with digital numbers according to /usr/include/asm-generic/unistd.h
and sort them by syscall number manually, maybe we can modify the
script to do it automatically in the future.
It is time to do it now, just handle __NR3264_ prefixed syscall number
automatically in the script update-linux.sh.
By the way, a Linux kernel patch did the similar change [1].
Matthieu Longo [Mon, 1 Jul 2024 10:33:47 +0000 (11:33 +0100)]
aarch64: testsuite: remove macro expansion messages from expected error output
gas generates an information diagnostic message for every context
invoking a macro and generating a warning or error message.
For the specific case of sysreg tests, this pollutes the expected
error output for no benefit in term of test debug or testing coverage.
This patch aims at stopping such diagnostic messages to be generated
for the failure tests by providing --no-info flag to gas.
It also removed from the expected outputs the information messages
related to macro expansions.
Matthieu Longo [Thu, 27 Jun 2024 10:02:18 +0000 (11:02 +0100)]
gas: add new command line options to control diagnostic informational messages
gas currently emits informational messages for context information along warnings.
In the context of system register tests in AArch64 backend, these messages
pollute the tests when checking for error message patterns in stderr output.
This patch aims at providing two new flags while preserving the existing
behavior if none of the options is provided.
* --info, similar to the existing --warn flag to enable diagnostic
informational messages (default behavior).
* --no-info, similar to the existing --no-warn flag to disable diagnostic
informational messages.
It also adds the flags to the existing documentation, and command manual.
gdbserver: return tracked register status in regcache_raw_read_unsigned
In regcache_raw_read_unsigned, we unconditionally return REG_VALID as
the register status. This does not seem right, since the register may
in fact be in another state, such as REG_UNAVAILABLE. Return the
tracked status.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
gdbserver: rename regcache's registers_valid to registers_fetched
The registers_valid field of the regcache struct is used for tracking
whether we have attempted to fetch all the registers from the target.
Its name does not reflect this well, I think. It falsely gives the
impression that all the registers are valid. This may conflict an
individual register status, which could be REG_UNAVAILABLE. To better
reflect the purpose, rename the field to "registers_fetched".
Approved-By: Simon Marchi <simon.marchi@efficios.com>
gdbserver: check for nullptr condition in regcache::get_register_status
A regcache can be initialized with a register value buffer, in which
case, the register_status pointer is null. This condition is checked
in set_register_status, but not in get_register_status. Do this check
for consistence and safety.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
gdbserver: boolify and defaultize the 'fetch' parameter of get_thread_regcache
Boolify the 'fetch' parameter of the get_thread_regcache function.
All of the current uses pass true for this parameter. Therefore, define
its default value as true and remove the argument from the uses.
We still keep the parameter, though, to give downstream targets the
option to obtain a regcache without having to fetch the whole
contents. Our (Intel) downstream target is an example.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
The `get_thread_regcache` function has a `fetch` option to skip
fetching the registers from the target. It seems this option is set
to false only at uses where we just need to access the tdesc through
the regcache of the current thread, as in
Since the tdesc of a regcache is set from the process of the thread
that owns the regcache, we can simplify the code to access the tdesc
via the process, as in
... current_process ()->tdesc ...
This is intended to be a refactoring with no behavioral change.
Tested only for the linux-x86-low target.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Tom Tromey [Sat, 16 Nov 2024 17:34:35 +0000 (10:34 -0700)]
Import GNU Readline 8.2
This imports readline 8.2 patch 13.
This time around I thought I would try to document the process.
First I have a checkout of the upstream readline repository. I make a
local branch there, based on the previous upstream import. In this
case that was readline 8.1; see gdb commit b4f26d541aa.
Then, I apply all readline changes from the gdb repository since the
previous readline import. In this case that is up to commit 3dee0baea2e in the gdb repo.
After this, I "git merge" from the relevant upstream commit. In the
past I feel like I used a tag, but readline is managed very strangely
and I didn't see a tag. So I just used the patch 13 commit, aka
commit 037d85f1 upstream.
Then I fixed all the merge conflicts. Re-running autoconf requires a
symlink from '../../config' into the gdb tree, due to the local
m4_include addition. It's possible other hacks like this are
required, I don't remember how I set things up in the past.
After this, I did a build + test of gdb. I also did a mingw
cross-hosted build, because that's caused build failures in past
imports.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32265 Reviewed-by: Sam James <sam@gentoo.org>
Tom Tromey [Thu, 6 Jun 2024 15:42:15 +0000 (09:42 -0600)]
Greatly speed up rbreak
While debugging another issue, I noticed that 'rbreak' on a large
program was very slow. In particular, with 'maint time 1':
(gdb) with pagination off -- rbreak ^command_display
[...]
Command execution time: 1940.646332 (cpu), 1960.771517 (wall)
"ps" also reported that, after this command, gdb's VSZ was 4619360.
Looking into this, I found something strange. When 'rbreak' found a
function "f" in file "file.adb", it would try to set the breakpoint
using "break 'file.adb':'f'".
This then interacted somewhat poorly with linespec. linespec first
expands all the symtabs matching "file.adb", but in this program this
results in thousands of CU expansions (probably due to inlining, but I
did not investigate).
There is probably a linespec bug here. It would make more sense for
it to combine the file- and symbol- lookups, as this is more
efficient. I plan to file a bug about this at least.
I tracked this "file:function" style of linespec to the earliest days
of gdb. Back then, "break function" would only break on the first
"function" that was found -- it wasn't until much later that we
changed gdb to break on all matching functions. So, I think that
rbreak was written this way to try to work around this limitation, and
it seems to me that this change obsoleted the need for rbreak to
mention the file at all.
That is, "break file:function" is redundant now, because plain
"break function" will redo that same work -- just more efficiently.
(The only exception to this is the case where a file is given
to rbreak -- here the extra filtering is still needed.)
This patch implements this. On the aforementioned large program, with
this patch, rbreak still sets all the desired breakpoints (879 of
them) but is now much faster:
(gdb) with pagination off -- rbreak ^command_display
[...]
Command execution time: 91.702648 (cpu), 92.770430 (wall)
Tom Tromey [Fri, 24 May 2024 16:51:02 +0000 (10:51 -0600)]
Don't let exception terminate 'rbreak'
'rbreak' searches symbols and then sets a number of breakpoints. If
setting one of the breakpoints fails, then 'rbreak' will terminate
before examining the remaining symbols.
However, it seems to me that it is better for 'rbreak' to keep going
in this situation. That is what this patch implements.
This problem can be seen by writing an Ada program that uses "pragma
import" to reference a symbol that does not have debug info. In this
case, the program will link but setting a breakpoint on the imported
name will not work.
I don't think it's possible to write a reliable test for this, as it
depends on the order in which symtabs are examined.
New in v2: rbreak now shows how many breakpoints it made and also how
many errors it encountered.
I got a failure report from the Linaro CI system. I eventually
tracked the issue down to a filename clash with glibc. I was able to
reproduce the issue when I installed the glibc debug information on to
my local machine, and ran the gdb.base/dlmopen.exp test as updated in
the above series.
Here's what's happening:
There is a file called dlmopen.c within glibc, within the glibc source
tree the file can be found at ./dlfcn/dlmopen.c. When this file is
compiled it appears that the glibc build system first enters the dlfcn
directory, and then compiles the file using the relative path
./dlmopen.c, here's a snippet of the DWARF:
The important thing here is the DW_AT_name, which is just "dlmopen.c".
The gdb.base/dlmopen.exp test also has a source file called
"dlmopen.c".
The dlmopen.exp test makes use of the clean_restart TCL proc, which
calls gdb_reinitialize_dir, which resets the source directories search
path to '$cdir:$cwd', and then prepends the test source directory to
the front of the list, so the source directory search path will look
something like:
In the existing test we try to place a breakpoint on 'dlmopen.c:64'.
This is the line tagged 'bp.main' in the source file. This currently
works fine. GDB searches through the symtabs and finds two matches,
the test dlmopen.c, and the glibc dlmopen.c. For each GDB tries to
convert line 64 into an address.
For the testsuite source file this is fine, we get the address of the
line tagged 'bp.main' from the source, and the breakpoint is created.
For the glibc source file though, at least, for the version available
to me, line 64 happens to be the closing '}' of a function, and there
isn't a line table entry for this exact line. So GDB searches forward
looking for the next line in order to place a breakpoint there. The
next line GDB finds is the start of the next function, and so GDB
rejects this location due to commit:
gdb: reject inserting breakpoints between functions
So we managed to avoid creating two breakpoint locations in this case,
but only by pure good luck.
In my updates to the test though I try to create a breakpoint at line
61 in addition to the breakpoint at line 64. So now the breakpoint
spec is 'dlmopen.c:61'.
Just as before, GDB identifies the 'dlmopen.c' could mean two files,
and searches for line 61 in both. The test source works as expected
and the breakpoint is created in the desired location.
But this time, line 61 in the glibc source file is an actual line,
with actual code, and so GDB places a breakpoint at this location.
This second breakpoint, in glibc is entirely unexpected (by the
dlmopen.exp test script). Unfortunately, the inferior hits this
second glibc breakpoint before it hits the actual breakpoint within
the main test executable, this throws the test off and causes some
failures.
In trying to fix this, I did wonder if I could just specify the full
path to the source file, instead of using just 'dlmopen.c:61'.
However, this doesn't work.
Remember that the glibc source file is recorded as just 'dlmopen.c'.
So, when GDB tries to figure out the absolute path to this source
file, the source directory search path is used. In this case, the
first entry in the source directory search path is the gdb.base/
directory in the GDB source tree. GDB looks in this directory and
finds a dlmopen.c, and so GDB assumes that this is the file in
question.
Thus, GDB actually thinks that both files _are_ the same source file.
Indeed, when GDB stops at the incorrect (glibc) breakpoint, and lists
the source code, it actually lists the source code from the correct
file. This confused me to begin with, GDB reported the wrong
function (the glibc function), but listed code from the correct file
and line.
Now on my machine I have installed the package that provides the glibc
source code. If I change the source directory search path so that
$cdir is first instead of the gdb.base/ from the GDB source tree, this
fixes the listing the wrong file problem. GDB does not realise that
the files are different, and if I create the breakpoint using the
absolute path then only a single breakpoint location is created.
However, this relies on the developer having both the glibc debug
information, and the glibc source package installed, this doesn't seem
like a great requirement to have in place.
So instead, I propose that we just take the easy way out, rename the
test source file. By doing this all the issues are avoided. The test
now creates a breakpoint at 'dlmopen-main.c:61', and there is only one
file with this name found, so we only get a single breakpoint location
created.
I renamed the source file, but not the dlmopen.exp file because the
test already makes use of multiple source files, so having a range of
different names didn't feel that bad, but if this bothers people, I
could rename both the .exp and main .c file, just let me know.
If you want to explore this issue for yourself then try with
installing the glibc debug information for your system, and ensure
that your GDBs under test are able to find the glibc debug
information. You can then either apply the series I linked above, or,
you can modify the existing test source so that the line tagged as
'bp.main' becomes line 61, I just deleted 3 lines from the big comment
at the head of the file.
Of course, reproducing this does depend on how glibc is compiled,
which could change from system to system, or overtime. I reproduced
this issue on Fedora 39 with glibc-2.38-19.
With this patch applied I no longer see any regressions when I apply
the above linked series.
While making these changes I took the opportunity to update the test
script to make better use of standard_testfile and build_executable.
Reviewed-By: Keith Seitz <keiths@redhat.com> Approved-By: Tom Tromey <tom@tromey.com>
Alan Modra [Mon, 16 Dec 2024 09:01:34 +0000 (19:31 +1030)]
score and mmix target_id
These targets currently use GENERIC_ELF_DATA as their target_id, but
that isn't exactly correct. While their bfd tdata is generic elf,
their elf_section_data is extended with extra target data. Add
MMIX_ELF_DATA and SCORE_ELF_DATA.
Alan Modra [Mon, 16 Dec 2024 07:24:03 +0000 (17:54 +1030)]
record_section_with_aarch64_elf_section_dat
Nowhere in the aarch64 backend is the list created by this function
examined, and in any case there are much simpler ways to determine the
type of elf_section_data attached to a bfd ELF section. It will
always be according to the target_id of the section owner.
Delete sections_with_aarch64_elf_section_data and everything
associated with it.
Alan Modra [Mon, 16 Dec 2024 04:34:57 +0000 (15:04 +1030)]
section tdata tidy
Any _new_section_hook that is not itself called from another
_new_section_hook will always see used_by_bfd NULL. Remove those
NULL checks in such hooks, and tidy code a little.
Lulu Cai [Tue, 10 Dec 2024 11:42:14 +0000 (19:42 +0800)]
LoongArch: Fix bfd ld failed test case
This test case requires host gcc, and different distributions have
different default configurations for gcc, which can cause address value
mismatches.
Therefore, it is fixed by passing consistent options and using regular
expressions.
Alan Modra [Sun, 15 Dec 2024 21:15:34 +0000 (07:45 +1030)]
Move modification of bfd abs and und back to gas
In commit f592407e4d75 I deleted gas' obj_sec_set_private_data, and
instead put the gas modification of bfd's *ABS* and *UND* sections in
bfd_make_section_old_way. More recently in commit 8b5a21249537 I made
tekhex symbol creation use bfd_make_section_old_way for symbol
sections. After that we saw numerous non-repeatable oss-fuzz reports
of accesses to freed memory involving relocation symbols. I think
what is happening is:
A tekhex testcase with an absolute symbol is run through the tool,
modifying bfd_abs_section.symbol to point to a symbol on the bfd's
objalloc memory. On closing that bfd bfd_abs_section.symbol points to
freed memory.
A second testcase is run through the tool with some access to the
*ABS* symbol. This triggers the invalid memory access.
The same thing could happen if a user runs objdump or nm with two
files on the command line, the first being a tekhex file with absolute
symbols, or if ld is given tekhex input among other files. Clearly,
it's a bad idea to modify the *ABS* or *UND* sections for input files.
bfd/
* section.c (bfd_make_section_old_way): Don't call
_new_section_hook for standard abs, com, und and ind sections.
gas/
* as.c (bfd_std_section_init): New function.
(perform_an_assembly_pass): Move section initialisation to..
(gas_init): ..here. Use bfd_std_section_init.
Alan Modra [Sat, 14 Dec 2024 00:56:45 +0000 (11:26 +1030)]
Delete asection.symbol_ptr_ptr
This field is always set to point to asection.symbol, and no code ever
changes it from its initial value. With one exception. elfxx-mips.c
creates two sections with separate pointers to their symbols, and uses
those as asection.symbol_ptr_ptr. Those pointers aren't modified,
so they disappear in this patch too.
Tom de Vries [Sat, 14 Dec 2024 08:36:37 +0000 (09:36 +0100)]
[gdb/dap] Fix regressions with python 3.6
With test-case gdb.dap/ada-arrays.exp, on Leap openSUSE 15.6 with python 3.6,
I run into:
...
Python Exception <class 'TypeError'>: 'type' object is not subscriptable
Error occurred in Python: 'type' object is not subscriptable
ERROR: tcl error sourcing ada-arrays.exp.
...
This is due to using a python 3.9 construct:
...
thread_ids: dict[int, int] = {}
...
oltolm [Sun, 24 Nov 2024 17:39:13 +0000 (18:39 +0100)]
gdb/dap: allow some requests when the process is running
It is impossible to set a breakpoint when the process is running,
which I find annoying. LLDB does not have this restriction. I made
`setBreakpoints` and `breakpointLocations` work when the process is
running. Probably more requests can be changed, but I only need these
two at the moment.
Oleg Tolmatcev [Mon, 26 Aug 2024 21:11:36 +0000 (23:11 +0200)]
gdb-dap: fix gdb.error: Frame is invalid.
When you try to use a frame on one thread and it was created on
another you get an error. I fixed it by creating a map from a frame ID
to a thread ID. When a frame is created it is added to the map. When
you try to find a frame for an id it checks if it is on the correct
thread and if not switches to that thread. I had to store the frame id
instead of the frame itself in a "_ScopeReference".
Signed-off-by: Oleg Tolmatcev <oleg.tolmatcev@gmail.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32133 Approved-By: Tom Tromey <tom@tromey.com>
Jan Beulich [Fri, 13 Dec 2024 08:43:12 +0000 (09:43 +0100)]
msp430/gas: correct BFD_RELOC_32 handling
It was likely a copy-and-paste oversight that bfd_putl16() was used here
from the very beginning. And of course there's a difference only if the
value to be stored is different from the value that's already there;
typically both are 0.
Jan Beulich [Fri, 13 Dec 2024 08:42:55 +0000 (09:42 +0100)]
gas: avoid UB on signed multiplication in resolve_symbol_value()
Commit 487b0ff02dda ("ubsan: signed integer multiply overflow") touched
only one of the two affected places (the 3rd, resolve_expression(), is
already using valueT type local variables).
Alan Modra [Wed, 11 Dec 2024 06:32:00 +0000 (17:02 +1030)]
xcoff reading dynamic relocs
This adds a sanity check to relocation symbol indices, and tidies code
a little.
The patch does result in a couple of testsuite failures
rs6000-aix7.2 +FAIL: TLS relocations (32-bit)
rs6000-aix7.2 +FAIL: TLS relocations (64-bit)
That seems reasonable to me, because prior to this patch l_symndx was
being set to -1 and -2 for .tdata and .tbss symbols resulting in a
buffer overflow when accessing the syms array.
bfd/
* xcofflink.c (_bfd_xcoff_canonicalize_dynamic_reloc): Prevent
symbol array overflow on invalid relocation symbol index.
Tidy code for relocs against standard sections.
(xcoff_create_ldrel): Remove cast.
include/
* coff/xcoff.h (struct internal_ldrel): Make l_symndx uint32_t.
Make l_rtype and l_rsecnm int16_t.
Alan Modra [Fri, 13 Dec 2024 03:18:45 +0000 (13:48 +1030)]
small coffgen.c tidy
_bfd_coff_free_cached_info should always call
_bfd_generic_bfd_free_cached_info, even if _bfd_coff_free_symbols
returns an error. (It won't return an error here, but let's not leave
anyone wondering about _bfd_coff_free_cached_info.)
* coffgen.c (_bfd_coff_free_cached_info): Ignore return status
of _bfd_coff_free_symbols.
Alan Modra [Thu, 12 Dec 2024 22:22:57 +0000 (08:52 +1030)]
objdump: Delete close optimisation
In commit cd6581da62c3, Nick made an optimisation that was reasonable
at the time, but then pr22032 came along and commit 7c0ed39626e3 made
bfd_close_all_done free memory. So Nick's optimisation is now
ineffective, and the comment wrong.
Tom Tromey [Thu, 3 Oct 2024 22:25:05 +0000 (16:25 -0600)]
Replace uses of "title" style with "command"
Currently the "title" style is only used when printing command names.
The "title" name itself is probably a misnomer, but meanwhile this
patch changes the existing uses to instead use the new "command" style
for consistency.
The "title" style is not removed; see the next patch.
Reviewed-By: Keith Seitz <keiths@redhat.com> Approved-By: Andrew Burgess <aburgess@redhat.com>
Tom Tromey [Sat, 18 May 2024 17:35:32 +0000 (11:35 -0600)]
Introduce "command" styling
This adds a new "command" style that is used when styling the name of
a gdb command.
Note that not every instance of a command name that is output by gdb
is changed here. There is currently no way to style error() strings,
and there is no way to mark up command help strings.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31747 Reviewed-By: Eli Zaretskii <eliz@gnu.org> Reviewed-By: Keith Seitz <keiths@redhat.com> Approved-By: Andrew Burgess <aburgess@redhat.com>
Tom Tromey [Sat, 9 Nov 2024 20:45:50 +0000 (13:45 -0700)]
Lock bfd_stat and bfd_get_mtime
PR gdb/31713 points out some races when using the background DWARF
reader.
This particular patch fixes some of these, namely the ones when using
the sim. In this case, the 'load' command calls reopen_exec_file,
which calls bfd_stat, which introduces a race.
BFD only locks globals -- concurrent use of a single BFD must be
handled by the application. To this end, this patch adds locked
wrappers for bfd_stat and bfd_get_mtime.
I couldn't reproduce these data races but the original reporter tested
the patch and confirms that it helps.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31713 Approved-By: Andrew Burgess <aburgess@redhat.com>
Tom Tromey [Fri, 1 Nov 2024 23:19:20 +0000 (17:19 -0600)]
Fix races involving _bfd_section_id
BFD's threading approach is that global variables are guarded by a
lock. However, while implementing this, I missed _bfd_section_id. A
user pointed out, via Thread Sanitizier, that this causes a data race
when gdb's background DWARF reader is enabled.
This patch fixes the problem by using the BFD lock in most of the
appropriate spots. However, in ppc64_elf_setup_section_lists I chose
to simply assert that multiple threads are not in use instead. (Not
totally sure if this is good, but I don't think this can be called by
gdb.)
I chose locking in bfd_check_format_matches, even though it is a
relatively big hammer, because it seemed like the most principled
approach, and anyway if this causes severe contention we can always
revisit the decision. Also this approach means we don't need to add
configury to check for _Atomic, or figure out whether bfd_section_init
can be reworded to make "rollback" unnecessary.
I couldn't reproduce these data races but the original reporter tested
the patch and confirms that it helps.
Tom Tromey [Mon, 2 Dec 2024 19:37:28 +0000 (12:37 -0700)]
Use generic_printstr from ada_language::printstr
Currently, if you create a lazy string while in Ada language mode, the
string will be rendered strangely, like:
"["d0"]["9f"]["d1"]["80"]["d0"]["b8"]...
This happens because ada_printstr does not really handle UTF-8
decoding.
This patch changes ada_language::printstr to use generic_printstr when
UTF-8 is used.
Note that this code could probably be improved some more -- the
current patch only addresses the narrow case of the Python API. I've
filed a follow-up bug (PR ada/32413) for the remaining changes.
Tom Tromey [Wed, 11 Dec 2024 13:54:27 +0000 (06:54 -0700)]
Fix GNAT version check in gdb.ada
Commit 1411185a ("Introduce and use gnat_version_compare") changed the
Ada tests to use a new proc for version checking. Unfortunately this
patch inadvertently reversed the sense of the test in
packed_array_assign.exp.
After fixing this, I went through that patch again and looked for
other problems. I found one spot where the wrong syntax was used, and
some others where I believe the sense of the test was inverted.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32444 Approved-By: Andrew Burgess <aburgess@redhat.com>
Update bfd/dwarf2.c with the post DWARF5 language codes which
were added after DWARF5 was finalized. Adding them makes it
possible to return the mangling style for the new language
codes for Ada 2005 Fortran, C++, C and Assembly.
Reviewed-By: Andrew Burgess <aburgess@redhat.com> Approved-By: Jan Beulich <jbeulich@suse.com>
Alan Modra [Tue, 10 Dec 2024 23:56:27 +0000 (10:26 +1030)]
Revert bfd_use_reserved_id patch
Commit fc1cfaa5f1 and bc110b6e40 were made to avoid testsuite
regressions on a number of targets that used bfd id in symbol hashing.
Since it no longer seems necessary to start plugin bfd id's from -1
and count down, revert the functional changes in those patches.
Alan Modra [Wed, 11 Dec 2024 02:31:23 +0000 (13:01 +1030)]
Use bfd id to validate dwarf2 cache
Using a bfd pointer to validate the cache isn't very robust. If a bfd
is closed somehow without clearing the cache, then it's possible that
another bfd is opened using the same memory and thus orig_bfd compares
equal to the new bfd.
Alan Modra [Sun, 8 Dec 2024 10:57:27 +0000 (21:27 +1030)]
nm.c free_lineno_cache
free_lineno_cache frees symbol and relocation data used when displaying
line number info for symbols (nm -l). Currently that is done when
closing the bfd, but that's not ideal for archives since that results
in two bfds worth of memory in use.
Alan Modra [Tue, 10 Dec 2024 05:32:53 +0000 (16:02 +1030)]
tdata related object_p tidy for various formats
The aout object_p function copies any existing tdata. Apparently this
was done for hp300, an old target that is no longer supported. See
commit ebd241352942. This isn't useful for current sources, nor is it
necessary or useful any more to preserve tdata in object_p functions
when a target doesn't match. When I was fixing this, I noticed some
object_p functions rudely didn't release memory on failures, and
others had nits in the bfd_error returns.
* aoutx.h (some_aout_object_p): Don't restore previous tdata
on failure. Don't copy any existing tdata.
* archive.c (bfd_generic_archive_p): Don't restore previous
tdata on failure.
* pdp11.c (some_aout_object_p): Likewise.
* coff-rs6000.c (_bfd_xcoff_archive_p): Allocate both artdata
and extension in one call. Don't restore previous tdata on
failure.
* coff64-rs6000.c (xcoff64_archive_p): Likewise.
* coffgen.c (coff_real_object_p): Don't restore previous
tdata on failure.
* ihex.c (ihex_object_p): Likewise. Simplify release of tdata
on scan failure.
* mach-o.c (bfd_mach_o_scan): Don't set tdata here. Do set
error on read_command failure.
(bfd_mach_o_header_p): Set tdata here, release on failure.
Tidy bfd_error return values.
(bfd_mach_o_fat_archive_p): Tidy error return values.
* mmo.c (mmo_mkobject): Do not test current tdata.
* pef.c (bfd_pef_scan_start_address): Set bfd_error on
failure.
(bfd_pef_scan): Don't set tdata here.
(bfd_pef_object_p): Set tdata here, release on failure. Tidy
bfd_error return values.
(bfd_pef_xlib_object_p): Tidy bfd_error return values.
* srec.c (srec_object_p): Don't restore previous tdata on
failure. Do release tdata on failure.
(symbolsrec_object_p): Likewise.
* tekhex.c (tekhex_object_p): Don't ignore tekhex_mkobject
failure. Release tdata on failure.
* vms-alpha.c (alpha_vms_object_p): Don't restore previous
tdata on failure. Simplify release of tdata.
* xsym.c (bfd_sym_scan): Don't set tdata here.
(bfd_sym_object_p): Set tdata here. Release on failure.
The checksum recalculation seems to have gone wrong. Looking at the
code, it seems like 'where_csum' is calculated inconsistently: in the
main loop it is after the '#' but in the "== 0" case it is before the
'#'.
This patch fixes the problem and also avoids a string copy.
CC: Alexandra Hájková <ahajkova@redhat.com> Approved-By: Andrew Burgess <aburgess@redhat.com>
dwarf_lang_to_enum_language: Map new DWARF5 constants
Add new DWARF5 language codes to gdb/dwarf2/read.c where
they are converted to GDB language names. The codes
were added to include/dwarf.h by syncing with gcc, Ada language
codes were added to dwarf.h earlier.
Approved-By: Tom Tromey <tom@tromey.com> Approved-By: Andrew Burgess <aburgess@redhat.com>
Jens Remus [Wed, 11 Dec 2024 08:58:35 +0000 (09:58 +0100)]
gdb: s390: Correct record/replay of may/mayr insn
The IBM z/Architecture Principles of Operation [1] specifies that the
R1 operand of the may and mayr instructions designates may designate
either the lower- or higher-numbered register of a floating-point-
register (FPR) pair.
[1]: IBM z/Architecture Principles of Operation, SA22-7832-13, IBM z16,
https://publibfp.dhe.ibm.com/epubs/pdf/a227832d.pdf
gdb/
* s390-tdep.c (s390_process_record): may/mayr operand R1 may
designate lower- or higher numbered register of FPR pair.
Tom de Vries [Tue, 10 Dec 2024 19:30:05 +0000 (20:30 +0100)]
[gdb/testsuite] Use setVariable in gdb.dap/scopes.exp
The test-case gdb.dap/scopes.exp contains the following outdated comment:
...
# setVariable isn't implemented yet, so use the register name.
...
Now that setVariable is implemented, use it to set variable scalar, and remove
the bit that sets the first register. That part is known to fail on s390x,
because the first register isn't writeable [1].
Tested on x86_64-linux.
Suggested-By: Tom Tromey <tom@tromey.com> Approved-By: Tom Tromey <tom@tromey.com>
[1] https://sourceware.org/pipermail/gdb-patches/2024-December/213823.html
The problem is that the test-case expects three scopes:
...
lassign $scopes scope reg_scope return_scope
...
but the return_scope is missing because this doesn't work:
...
$ gdb -q -batch outputs/gdb.dap/step-out/step-out \
-ex "b function_breakpoint_here" \
-ex run \
-ex finish
...
Value returned has type: struct result. Cannot determine contents
...
This is likely caused by a problem in gdb, but there's nothing wrong the DAP
support.
Fix this by:
- allowing two scopes, and
- declaring the tests of return_scope unsupported.
Tom de Vries [Tue, 10 Dec 2024 10:48:33 +0000 (11:48 +0100)]
[gdb/testsuite] Fix fails in gdb.python/py-arch-reg-groups.exp
Since commit e69d35f45e0 ("Use ui-out table in "maint print reggroups""),
test-case gdb.python/py-arch-reg-groups.exp fails with check-read1:
...
FAIL: $exp: Same number of registers groups found
FAIL: $exp: all register groups match
...
Fix this by adding a gdb_test_multiple clause that matches the command.
WANG Xuerui [Sat, 19 Oct 2024 14:11:52 +0000 (22:11 +0800)]
LoongArch: Default to a maximum page size of 64KiB
As per the spec (Section 7.5.10, LoongArch Reference Manual Vol. 1),
LoongArch machines are not limited in page size choices, and currently
page sizes of 4KiB, 16KiB and 64KiB are supported by mainline Linux.
While 16KiB is the most common, the current BFD code says it is the
maximum; this is not correct, and as an effect, almost all existing
binaries are incompatible with a 64KiB kernel because the sections are
not sufficiently aligned, while being totally fine otherwise.
This is needlessly complicating integration testing [1].
This patch fixes the inconsistency, and also brings BFD behavior in line
with that of LLD [2].
bfd/
* elfnn-loongarch.c (ELF_MAXPAGESIZE): Bump to 64KiB.
(ELF_MINPAGESIZE): Define as 4KiB.
(ELF_COMMONPAGESIZE): Define as 16KiB.
ld/
* testsuite/ld-loongarch-elf/64_pcrel.d: Update assertions after
changing the target max page size to 64KiB.
* testsuite/ld-loongarch-elf/data-got.d: Likewise.
* testsuite/ld-loongarch-elf/desc-relex.d: Likewise.
* testsuite/ld-loongarch-elf/relax-align-ignore-start.d: Likewise.
* testsuite/ld-loongarch-elf/tlsdesc_abs.d: Make the fuzzy match work
as intended by not checking exact instruction words.
* testsuite/ld-loongarch-elf/tlsdesc_extreme.d: Likewise.
projects / thirdparty / binutils-gdb.git / log
