| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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>
|
|
Convert the free `regcache_cpy` function to a method of the
regcache struct.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
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
struct regcache *regcache = get_thread_regcache (current_thread, 0);
... regcache->tdesc ...
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>
|
|
elflink.c checks elf_object_id(ibfd) == elf_hash_table_id(hash_table)
in a number of places. Make them match.
|
|
|
|
A user noticed that the sim assigns the result of a call to 'signal'
to a variable like:
RETSIGTYPE (*prev_sigint) ();
However, it's more correct to use (int) here.
This patch fixes the error.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32466
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
Upstream readline 8.2 does not build on mingw. This patch fixes the
build, but I do not know how well it works.
I've submitted this to readline here:
https://lists.gnu.org/archive/html/bug-readline/2024-11/msg00007.html
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32265
|
|
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>
|
|
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)
It also reduces the VSZ number to 2539216.
Regression tested on x86-64 Fedora 40.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=14340
Approved-By: Pedro Alves <pedro@palves.net>
|
|
'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.
Regression tested on x86-64 Fedora 40.
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
I noticed that an earlier commit caused a change in the isort output.
This patch repairs the problem.
|
|
After posting this series:
https://inbox.sourceware.org/gdb-patches/cover.1733742925.git.aburgess@redhat.com
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:
<0><d5d27>: Abbrev Number: 12 (DW_TAG_compile_unit)
<d5d28> DW_AT_producer : (alt indirect string, offset: 0x16433) t
<d5d2c> DW_AT_language : 29 (C11)
<d5d2d> DW_AT_name : (indirect line string, offset: 0x5c8f): dlmopen.c
<d5d31> DW_AT_comp_dir : (indirect line string, offset: 0xb478): /usr/src/debug/glibc-2.38-19.fc39.x86_64/dlfcn
<d5d35> DW_AT_low_pc : 0x8a4c0
<d5d3d> DW_AT_high_pc : 408
<d5d3f> DW_AT_stmt_list : 0x68ec1
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:
/tmp/src/gdb/testsuite/gdb.base/gdb.base:$cdir:$cwd
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:
commit dcaa85e58c4ef50a92908e071ded631ce48c971c
Date: Wed May 1 10:47:47 2024 +0100
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>
|
|
languages.
|
|
At least makeinfo 4.13 doesn't tolerate @item@samp, considering it a
single command.
|
|
Add an assertion that verifies we have filled the mdata->sections
array in bfd_mach_o_flatten_sections.
|
|
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.
|
|
aout_section_data->relocs isn't set by anything, so delete it.
|
|
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.
|
|
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.
|
|
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.
|
|
|
|
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.
|
|
|
|
Fix the Windows build that was broken in "Introduce \"command\" styling".
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Describe all the new post DWARF5 language codes from the latest sync
of include/dwarf.h with gcc.
|
|
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.
|
|
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] = {}
...
Fix this by using typing.Dict instead.
Tested on x86_64-linux.
|
|
|
|
* xcofflink.c (_bfd_xcoff_canonicalize_dynamic_reloc): Use
.tdata and .tbss section symbols.
(xcoff_create_ldrel): Abort on h and hsec both NULL.
|
|
When building gdb with -fsanitize=thread and running test-case
gdb.base/bg-exec-sigint-bp-cond.exp, I run into:
...
==================^M
WARNING: ThreadSanitizer: signal handler spoils errno (pid=25422)^M
#0 handler_wrapper gdb/posix-hdep.c:66^M
#1 decltype ({parm#2}({parm#3}...)) gdb::handle_eintr<>() \
gdbsupport/eintr.h:67^M
#2 gdb::waitpid(int, int*, int) gdbsupport/eintr.h:78^M
#3 run_under_shell gdb/cli/cli-cmds.c:926^M
...
Likewise in:
- tui_sigwinch_handler with test-case gdb.python/tui-window.exp, and
- handle_sighup with test-case gdb.base/quit-live.exp.
Fix this by saving the original errno, and restoring it before returning [1].
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
[1] https://www.gnu.org/software/libc/manual/html_node/POSIX-Safety-Concepts.html
|
|
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.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
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>
|
|
Some people might use devcontainer to set up development environment.
Ignore this directory, similar to other existing IDE-specific ignores.
Signed-off-by: Marek Pikuła <m.pikula@partner.samsung.com>
|
|
|
|
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.
|
|
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).
|
|
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.
|
|
_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.
|
|
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.
* objdump.c (display_file): Delete last_file param. Update
caller. Call bfd_close always.
|
|
This patch reuses the "title" style for titles -- in particular the
header line of a list display.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Reviewed-By: Keith Seitz <keiths@redhat.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
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>
|
|
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>
|
|
|
|
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>
|
|
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.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31713
|
|
This fixes a formatting issue and corrects a comment in the new
gdb.ada/lazy-string.exp. I meant to do this in an earlier patch but
forgot to save.
|
|
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.
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
I noticed that gdbreplay --help is rather sparse -- it doesn't even
mention the names of the options it accepts.
This patch updates the help output to be more complete.
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
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>
|
