Revise a sentence to avoid misinterpretation. Move @cindex entries
before the text they index. Refer to trace frames regarding partial
reads.
Approved-By: Eli Zaretskii <eliz@gnu.org>
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)
Approved-By: Eli Zaretskii <eliz@gnu.org>
This patch is the result of running check-include-guards.py on the
current tree. Running it a second time causes no changes.
Reviewed-By: Tom de Vries <tdevries@suse.de>
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.
Reviewed-By: Tom de Vries <tdevries@suse.de>
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.
Reviewed-By: Tom de Vries <tdevries@suse.de>
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.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32162
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.
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>
In gdb commit a08dc2aa00 ("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].
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d6e1cc6b7220
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Approved-By: Tom de Vries <tdevries@suse.de>
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>
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 dcaa85e58c
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>
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>
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>
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>
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>
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>
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.
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>
This adds a new "deferred request" capability to DAP. The idea here
is that if a request returns a DeferredRequest object, then no
response is sent immediately to the client. Instead, the request is
pending until the deferred request is rescheduled.
Some minor refactorings, particularly in cancellation, were needed to
make this work.
There's no use of this in the tree yet -- that is the next patch.
Reviewed-by: Kévin Le Gouguec <legouguec@adacore.com>
This patch started as an attempt to fix the comment in
CancellationHandler.cancel, but while working on it I found that the
code could be improved as well.
The current DAP cancellation code only handles the case where work is
done on the gdb thread -- by checking for cancellation in
interruptable_region. This means that if a request is handled
completely in tthe DAP thread, then cancellation will never work.
Now, this isn't a bug per se. DAP doesn't actually require that
cancellation succeed. In fact, I think it can't, because cancellation
is inherently racy.
However, a coming patch will add a sort of "pending" request, and it
would be nice if that were cancellable before any commands are sent to
the gdb thread.
No test in this patch, but one will arrive at the end of the series.
Reviewed-by: Kévin Le Gouguec <legouguec@adacore.com>
This refactors the DAP CancellationHandler to be a context manager,
and reorganizes the caller to use this. This is a bit more robust and
also simplifies a subsequent patch in this series.
Reviewed-by: Kévin Le Gouguec <legouguec@adacore.com>
This adds a new call_function_later API to DAP. This arranges to run
a function after the current request has completed. This isn't used
yet, but will be at the end of this series.
Reviewed-by: Kévin Le Gouguec <legouguec@adacore.com>
This patch changes how delayed events are implemented in DAP. The new
implementation makes it simpler to add a delayed function call, which
will be needed by the final patch in this series.
Reviewed-by: Kévin Le Gouguec <legouguec@adacore.com>
Right now, stopAtBeginningOfMainSubprogram is implemented "by hand",
but then later the launch function uses "starti" to implement
stopOnEntry. This patch unifies this code and rewrites it to use
"start" when appropriate.
Reviewed-by: Kévin Le Gouguec <legouguec@adacore.com>
In commit 8a61ee551c ("[gdb/symtab] Workaround PR gas/31115"), I applied a
workaround for PR gas/31115 in read_func_scope, fixing test-case
gdb.arch/pr25124.exp.
Recently I noticed that the test-case is failing again.
Fix this by factoring out the workaround into a new function fixup_low_high_pc
and applying it in dwarf2_die_base_address.
While we're at it, do the same in dwarf2_record_block_ranges.
Tested on arm-linux with target boards unix/-marm and unix/-mthumb.
Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
Currently aarch64-linux.xml.in is skipped by update-linux-from-src.sh:
...
$ ./update-linux-from-src.sh ~/upstream/linux-stable.git/
Skipping aarch64-linux.xml.in, no syscall.tbl
...
$
...
and instead we use update-linux.sh.
This works fine, but requires an aarch64 system with recent system headers,
which makes it harder to pick up the latest changes in the linux kernel.
Fix this by updating ./update-linux-from-src.sh to:
- build the linux kernel headers for aarch64
- use update-linux.sh with those headers to generate
aarch64-linux.xml.in.
Regenerating aarch64-linux.xml.in using current trunk of linux-stable gives me
these changes:
...
+ <syscall name="setxattrat" number="463"/>
+ <syscall name="getxattrat" number="464"/>
+ <syscall name="listxattrat" number="465"/>
+ <syscall name="removexattrat" number="466"/>
...
which are the same changes I see for the other architectures.
Note that the first step, building the linux kernel headers is a cross build
and should work on any architecture.
But the second step, update-linux.sh uses plain gcc rather than a cross-gcc,
so there is scope for problems, but we seem to get away with this on
x86_64-linux.
So, while we could constrain this to only generate aarch64-linux.xml.in on
aarch64-linux, I'm leaving this unconstrained.
For aarch64-linux.xml.in, this doesn't matter much to me because I got an
aarch64-linux system.
But I don't have a longaarch system, and the same approach seems to work
there. I'm leaving this for follow-up patch though.
Tested on aarch64-linux and x86_64-linux. Verified with shellcheck.
Commit c8889b9131 ("gdb, gdbserver, gdbsupport: remove some unused
gdb_vecs.h includes") removed gdbsupport/gdb_vecs.h from various
header files. This caused an compile issue for gdb/s390-linux-nat.c
../../binutils-gdb/gdb/s390-linux-nat.c: In member function ‘virtual int s390_linux_nat_target::remove_watchpoint(CORE_ADDR, int, target_hw_bp_type, expression*)’:
../../binutils-gdb/gdb/s390-linux-nat.c:875:11: error: ‘unordered_remove’ was not declared in this scope
875 | unordered_remove (state->watch_areas, ix);
| ^~~~~~~~~~~~~~~~
../../binutils-gdb/gdb/s390-linux-nat.c: In member function ‘virtual int s390_linux_nat_target::remove_hw_breakpoint(gdbarch*, bp_target_info*)’:
../../binutils-gdb/gdb/s390-linux-nat.c:928:11: error: ‘unordered_remove’ was not declared in this scope
928 | unordered_remove (state->break_areas, ix);
| ^~~~~~~~~~~~~~~~
Fix this by including gdbsupport/gdb_vecs.h in gdb/s390-linux-nat.c.
After the commit:
commit 03ad29c86c
Date: Wed Jun 19 11:14:08 2024 +0100
gdb: 'target ...' commands now expect quoted/escaped filenames
it was no longer possible to pass GDB the name of a core file
containing any special characters (white space or quote characters) on
the command line. For example:
$ gdb -c /tmp/core\ file.core
Junk after filename "/tmp/core": file.core
(gdb)
The problem is that the above commit changed the 'target core' command
to expect quoted filenames, so before the above commit a user could
write:
(gdb) target core /tmp/core file.core
[New LWP 2345783]
Core was generated by `./mkcore'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x0000000000401111 in ?? ()
(gdb)
But after the above commit the user must write:
(gdb) target core /tmp/core\ file.core
or
(gdb) target core "/tmp/core file.core"
This is part of a move to make GDB's filename argument handling
consistent.
Anyway, the problem with the '-c' command line flag is that it
forwards the filename unmodified through to the 'core-file' command,
which in turn forwards to the 'target core' command.
So when the user, at a shell writes:
$ gdb -c "core file.core"
this arrives in GDB as the unquoted string 'core file.core' (without
the single quotes). GDB then forwards this to the 'core-file'
command as if the user had written this at a GDB prompt:
(gdb) core-file core file.core
Which then fails to parse due to the unquoted white space between
'core' and 'file.core'.
The solution I propose is to escape any special characters in the core
file name passed from the command line before calling 'core-file'
command from main.c.
I've updated the corefile.exp test to include a test for passing a
core file containing a white space character. While I was at it I've
modernised the part of corefile.exp that I was touching.
