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.
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 487b0ff02d ("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 cd6581da62, Nick made an optimisation that was reasonable
at the time, but then pr22032 came along and commit 7c0ed39626 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
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>
I noticed that rs6000-tdep.c has a global "variants" array that can be
marked "const", moving it into rodata.
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>
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.
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.
* dwarf2.c (struct dwarf2_debug): Add orig_bfd_id. Delete
orig_bfd.
(_bfd_dwarf2_slurp_debug_info): Validate stash with orig_bfd_id.
This also reduces peak memory a little.
* dlltool.c (identify_search_archive): Close last_arfile earlier.
Report an error if bfd_openr_next_archived_file returns the same
bfd. Localise variables.
* nm.c (display_archive): Likewise.
* objdump.c (display_any_bfd): Likewise.
* size.c (display_archive): Likewise.
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.
* nm.c (display_rel_file): Call free_lineno_cache here..
(display_archive, display_file): ..not here.
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 ebd2413529. 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.
I needed to use gdbreplay today. It didn't work quite right, and
using "set debug remote 1" showed that gdb was rejecting some
responses like:
[remote] Sending packet: $vCont?#49
[remote] Junk: #vCont?
[remote] Junk: 8vCont?
[remote] Junk: 3vCont?
[remote] Received Ack
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>
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>
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.
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
If the '-name soname' option is used, the fake '<Total>' function is expanded
with the name loadobject.
gprofng/ChangeLog
2024-12-09 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
* src/Hist_data.cc (Hist_data::sort): Fix sorting.
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
With test-case gdb.dap/step-out.exp on s390x-linux, I get:
...
>>> {"seq": 7, "type": "request", "command": "scopes", "arguments": {"frameId": 0}}
Content-Length: 569^M
^M
{"request_seq": 7, "type": "response", "command": "scopes", "body": {"scopes": [{"variablesReference": 1, "name": "Locals", "presentationHint": "locals", "expensive": false, "namedVariables": 1, "line": 35, "source": {"name": "step-out.c", "path": "/home/vries/gdb/src/gdb/testsuite/gdb.dap/step-out.c"}}, {"variablesReference": 2, "name": "Registers", "presentationHint": "registers", "expensive": false, "namedVariables": 114, "line": 35, "source": {"name": "step-out.c", "path": "/home/vries/gdb/src/gdb/testsuite/gdb.dap/step-out.c"}}]}, "success": true, "seq": 21}PASS: gdb.dap/step-out.exp: get scopes success
FAIL: gdb.dap/step-out.exp: three scopes
...
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.
Tested on s390x-linux.
Approved-By: Tom Tromey <tom@tromey.com>
Since commit e69d35f45e ("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.
Tested on x86_64-linux.
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].
[1] https://github.com/loongson-community/discussions/issues/47
[2] https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/lld/ELF/Arch/LoongArch.cpp#L174-L183
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.
Signed-off-by: WANG Xuerui <git@xen0n.name>
Using r0 as a base address register in the ROP hashst and hashchk instructions
is invalid. Modify the assembler to catch that illegal use and emit an error.
opcodes/
* ppc-opc.c (insert_ras): Update error message and function comment.
(powerpc_opcodes) <hashst, hashstp, hashchk, hashchkp>: Use RAS.
We discovered that attempting to print a very large string-like array
would succeed on the CLI, but in DAP would cause the "variables"
request to fail with:
value requires 67038491 bytes, which is more than max-value-size
This turns out to be a limitation in Value.format_string, which
de-lazy-ifies the value.
This patch fixes this problem by introducing a new NoOpStringPrinter
class, and then using it for string-like values. This printer returns
a lazy string, which solves the problem.
Note there are some special cases where we do not want to return a
lazy string. I've documented these in the code. I considered making
gdb.Value.lazy_string handle these cases -- for example it could
return 'self' rather than a lazy string in some situations -- but this
approach was simpler.
gdbpy_create_lazy_string_object will throw an exception if you pass it
a NULL pointer without also setting length=0 -- the default,
length==-1, will fail. This seems bizarre. Furthermore, it doesn't
make sense to do this check for array types, as an array can have a
zero length. This patch cleans up the check and makes it specific to
TYPE_CODE_PTR.
Currently, gdb.Value.lazy_string will allow the conversion of any
object to a "lazy string". However, this was never the intent and is
weird besides. This patch changes this code to correctly throw an
exception in the non-matching cases.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=20769
I added a new test using gdb_py_test_silent_cmd, and then was
surprised to find out that the new test passed -- it caused a Python
exception and I had expected it to fail. This patch fixes this proc
to detect this situation and fail.
While testing DAP, we found a situation where a compiler-generated
variable caused the "variables" request to fail -- the variable in
question being an apparent 67-megabyte string.
It seems to me that artificial variables like this aren't interesting
to DAP users, and the gdb CLI omits these as well.
This patch changes DAP to omit these variables, adding a new
gdb.Symbol.is_artificial attribute to make this possible.
PR dap/32090 points out that gdb's DAP "launch" sequencing is
incorrect. The current approach (which is itself a 2nd
implementation...) was based on a misreading of the spec. The spec
has since been clarified here:
https://github.com/microsoft/debug-adapter-protocol/issues/497
The clarification here is that a client is free to send the "launch"
(or "attach") request at any point after the "initialized" event has
been sent by gdb. However, the "launch" does not cause any action to
be taken -- and does not send a response -- until after
"configurationDone" has been seen.
This patch implements this by arranging for the launch and attach
commands to return a DeferredRequest object.
All the tests needed updates. I've also added a new test that checks
that the deferred "launch" request can be cancelled. (Note that the
cancellation is lazy -- it also waits until configurationDone is seen.
This could be fixed, but I was not sure whether it is important to do
so.)
Finally, the "launch" command has a somewhat funny sequencing now.
Simply sending the command and waiting for a response yielded strange
results if the inferior did not stop -- in this case, the repsonse was
never sent. So now, the command is split into two parts, with some
setup being done synchronously (for better error propagation) and the
actual "run" being done async.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32090
Reviewed-by: Kévin Le Gouguec <legouguec@adacore.com>
