| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Fix typo in lib/compiler.cc: IBM'x -> IBM's.
|
|
Fix typo in gdb.base/nodebug.exp and lib/compiler.c: IBM'x -> IBM's.
|
|
With test-case gdb.base/nodebug.exp I run into:
...
gdb compile failed, gdb.base/nodebug.c: In function 'multf_noproto':
gdb.base/nodebug.c:63:1: warning: old-style function definition \
[-Wold-style-definition]
63 | multf_noproto (v1, v2)
| ^~~~~~~~~~~~~
...
Fix this using -std=c99.
Tested on x86_64-linux.
PR testsuite/32756
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32756
|
|
A user pointed out that the Python API can't create a type that is
both const and volatile.
The bug is that the calls to make_cv_type did not preserve the "other"
flag.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33585
Reviewed-By: Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
|
|
On x86_64-linux, with test-case gdb.rust/simple.exp I get:
...
(gdb) print sizeof(e)^M
$52 = 24^M
(gdb) PASS: $exp: print sizeof(e)
...
but on i686-linux I get instead:
...
(gdb) print sizeof(e)^M
$52 = 20^M
(gdb) FAIL: $exp: print sizeof(e)
...
The variable e for which we print the size:
...
let e = MoreComplicated::Two(73);
...
has type MoreComplicated which is defined like this:
...
pub struct HiBob {
pub field1: i32,
field2: u64,
}
...
enum MoreComplicated {
One,
Two(i32),
Three(HiBob),
Four{this: bool, is: u8, a: char, struct_: u64, variant: u32},
}
...
The answer to the question what the size of the enum should be seems to be
non-trivial [1][2], but AFAICT it doesn't seem to be illegal that the size can
differ between different platforms.
Fix this by accepting both 20 and 24 as valid size.
Tested on x86_64-linux and i686-linux.
Approved-By: Tom Tromey <tom@tromey.com>
[1] https://doc.rust-lang.org/reference/types/enum.html
[2] https://doc.rust-lang.org/reference/type-layout.html#the-rust-representation
|
|
This commit allows GDB to make use of the file set with the 'file'
command when starting a new inferior on an extended-remote target.
There are however some restrictions.
If the user has used 'set remote exec-file', then this setting is
always used in preference to the file set with the 'file' command.
Similarly, if the qExecAndArgs packet has succeeded, and GDB knows
that the remote target has an executable set, then this will be used
in preference to the file set with the 'file' command; this preserves
GDB's existing behaviour. In effect, when GDB connects to the remote
target, the remote sets the 'remote exec-file' and this prevents GDB
from using the 'file' filename.
And, GDB can only use the file set with the 'file' command if it
believes that both GDB and the remote target will both be able to
access this file. This means that one of these is true:
+ the the remote_target::filesystem_is_local function returns
true (see the implementation of that function for details of when
this can happen). This means GDB and the remote target can see
the same file system, GDB can just use the current executable's
filename as is, or
+ the user has set the 'file' to something with a 'target:' prefix,
e.g. 'file target:/path/to/exec'. In this last case, GDB will use
the exec filename without the 'target:' prefix, this filename is,
by definition, something the remote target can see, or
+ the sysroot has been updated by the user and no longer contains a
'target:' prefix. In this case, if the 'file' filename is within
the sysroot, then it is assumed the remote will also be able to
see a file with the same filename. For example, if the sysroot is
'/aa/', and the current executable is '/aa/bb/cc', then GDB will
tell the remote to run '/bb/cc'. One common case here is when the
sysroot is set to the empty string, which is usually done when GDB
and the remote target can see the same filesystem, in this case
GDB will use the current executable's filename unmodified.
If one of these conditions is met, then GDB will use the current
executable's filename (with possible modifications as mentioned
above), when starting a new extended-remote inferior, in all other
cases, GDB will use the file name set with 'set remote exec-file'.
This change could be useful any time a user is running a remote target
on the same machine as GDB, but I am specifically thinking of the case
where GDB is using a tool other than gdbserver, e.g. valgrind, as this
saves one additional step that a user must remember. The current
steps to start valgrind with GDB, as given on the valgrind
website (https://valgrind.org/docs/manual/manual-core-adv.html) are:
$ gdb prog
(gdb) set remote exec-file prog
(gdb) set sysroot /
(gdb) target extended-remote | vgdb --multi --vargs -q
(gdb) start
With this GDB work, and once support for the qExecAndArgs packet is
added to valgrind, then the 'set remote exec-file' line can be dropped
from those instructions.
This commit also extends the 'show remote exec-file' command so that
GDB will display the automatic value that it plans to use. Here's an
example of the new output:
$ gdb -q /tmp/hello
Reading symbols from /tmp/hello...
(gdb) set sysroot
(gdb) target extended-remote | ./gdbserver/gdbserver --multi --once -
Remote debugging using | ./gdbserver/gdbserver --multi --once -
Remote debugging using stdio
(gdb) show remote exec-file
The remote exec-file is unset, using automatic value "/tmp/hello".
The last line shows the new output.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
On i686-linux (and likewise arm-linux), I run into:
...
(gdb) file str-chars^M
Reading symbols from str-chars...^M
warning: stabs debug information is not supported.^M
(No debugging symbols found in str-chars)^M
(gdb) delete breakpoints^M
...
Fix this by using fpc option -gw2.
Tested on i686-linux.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
PR testsuite/33564
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33564
|
|
I ran the testsuite twice, once with target board unix, and once with target
board unix/-fPIE/-pie, compare the two sum files, and got for test-case
gdb.mi/mi-memory-changed.exp:
...
< PASS: $exp: set var *(unsigned int *) 0x4011b0 = 0xe5894855
---
> PASS: $exp: set var *(unsigned int *) 0x5555555551c3 = 0xe5894855
...
Fix this by dropping the concrete address from the test name:
...
PASS: $exp: set var *(unsigned int *) 0x${main_addr} = ${main_insn}
...
Tested on x86_64-linux.
|
|
gdb.arch/amd64-shadow-stack-corefile.exp
I ran the testsuite twice, compare the two sum files, and got for test-case
gdb.arch/amd64-shadow-stack-corefile.exp:
...
3077c3077
< PASS: $exp: OS corefile: pl3_ssp contents from core file 0x7f7a38
3fffe0
---
> PASS: $exp: OS corefile: pl3_ssp contents from core file 0x7f179e
...
Fix this by dropping the address from the test name.
Tested on x86_64-linux.
|
|
With test-case gdb.trace/mi-trace-frame-collected.exp I run into:
...
gdb compile failed, gdb.trace/actions.c: In function 'main':
gdb.trace/actions.c:139:1: warning: old-style function definition \
[-Wold-style-definition]
139 | main (argc, argv, envp)
| ^~~~
...
Fix this by rewriting main into a prototyped function.
Tested on x86_64-linux.
PR testsuite/32756
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32756
|
|
In test-case gdb.base/callfuncs.exp I run into:
...
gdb compile failed, gdb.base/callfuncs.c: In function 't_func_values':
gdb.base/callfuncs.c:611:12: error: too many arguments to function \
'func_arg1'; expected 0, have 2
611 | return ((*func_arg1) (5,5) == (*func_val1) (5,5)
| ~^~~~~~~~~~~ ~
...
Fix this by using -std=c99.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
PR testsuite/32756
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32756
|
|
native-extended-gdbserver board
I'm seeing this FAIL with the native-extended-gdbserver board:
(gdb) add-inferior^M
[New inferior 2]^M
Added inferior 2 on connection 1 (extended-remote localhost:2365)^M
(gdb) FAIL: gdb.python/py-parameter.exp: test_per_inferior_parameters: add-inferior
This is another case of add-inferior producing more output when
connected to a remote target. Adjust the regexp to accomodate it.
Change-Id: Ic5760ff66712c54b90b9debf379dcbf6e07f6eeb
|
|
native-extended-gdbserver board
I see this FAIL when running with the native-extended-gdbserver board:
Expecting: ^(-add-inferior[^M
]+)?(.*\^done,inferior="i2"[^M
]+[(]gdb[)] ^M
[ ]*)
-add-inferior^M
=thread-group-added,id="i2"^M
~"[New inferior 2]\n"^M
~"Added inferior 2 on connection 1 (extended-remote localhost:2345)\n"^M
^done,inferior="i2",connection={number="1",name="extended-remote"}^M
(gdb) ^M
FAIL: gdb.mi/set-show.exp: test_per_inferior_parameters: add inferior (unexpected output)
This is another case of the add-inferior command producing more output
when connected to a remote target. Adjust the regexp to accomodate it.
Change-Id: Ifa0590211fd75d4a01dff942c6bb810d5caf1257
|
|
relaunch" test
I see this failure:
$ make check TESTS="gdb.base/with.exp" RUNTESTFLAGS="--target_board=native-extended-gdbserver"
FAIL: gdb.base/with.exp: repeat: reinvoke with no previous command to relaunch
It seems like that failure has always been there and I didn't notice?
I'm not sure what is the intent of the test exactly. It sounds like it
is meant to test what happens when you use command "with language ada"
as the very first command of a GDB session? However, clean_restart and
gdb_load issue some commands before that test. The different between
the native-extended-gdbserver board and the other boards is: for other
boards, the previous command is a "file" command, which is a "no repeat"
command, which gives the expected error message. With the
native-extended-gdbserver board, the previous command is "set remote
exec-file", which is a repeatable command.
"Fix" it by making a "no repeat" command just before the test, so that
it works the same regardless of the target board.
Change-Id: I254faf196f49e9efd492fc9dd5f6ce7b96f72af7
Approved-By: Tom Tromey <tom@tromey.com>
|
|
C standard gnu23 introduces a new keyword 'thread_local'.
So, this variables must be renamed to avoid build errors.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
In commit f283e80f (Fix use of "main" marker in gdb index), I changed
the DWARF reader to understand that the C language's "main" might
appear in the .gdb_index, and should not be ignored.
This week I realized that this same problem can affect C++ as well.
I'm not sure why I didn't consider this at the time.
This patch fixes the bug. It's somewhat of a hack, I guess, but also
at least understandable.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33441
|
|
I see this failure:
$ make check TESTS="gdb.base/with.exp" RUNTESTFLAGS="--target_board=native-extended-gdbserver"
FAIL: gdb.base/with.exp: per-inferior parameters: add-inferior
The add-inferior command produces more output than expected when using
the native-extended-gdbserver board, because it is already connected to
a remote target:
(gdb) add-inferior
[New inferior 2]
Added inferior 2 on connection 1 (extended-remote localhost:2348)
Fix that by accepting output after "Added inferior 2", as is done
elsewhere in the testsuite already (e.g. gdb.btrace/multi-inferior.exp).
Change-Id: I047a3be5249dd803839b213dd2f1646736fc8289
|
|
I noticed that when printing a gdb.Block object in Python, I would
occasionally get corrupted, nonsensical output, like this:
<gdb.Block <anonymous> {intintyinty_1inty_3inty_5... (-5 more symbols)}>
The symbol list is missing commas, it should be:
int, inty, inty_1, inty_3, inty_5, ...
And the '-5 more symbols' is clearly not right.
The problem is in python/py-block.c, we use this line to calculate the
number of symbols in a block:
const int len = mdict_size (block->multidict ());
Then we loop over the symbols in the block like this:
for (struct symbol *symbol : block_iterator_range (block))
...
The problem here is that 'block_iterator_range (block)' can loop over
more symbols than just those within 'block'. For global and static
blocks, block_iterator_range() takes into account included CUs; and so
can step through multiple global or static blocks. See
block_iterator_step and find_iterator_compunit_symtab in block.c for
more details.
In contrast, 'mdict_size (block->multidict ())' only counts the
symbols contained within 'block' itself.
I could fix this by either fixing LEN, or by only iterating over the
symbols within 'block'.
I assume that printing a gdb.Block object is used mostly for debug
purposes; the output isn't really user friendly, so I cannot imagine a
user script that is relying on printing a gdb.Block as a way to inform
the user about blocks in their program. As such, I think it makes
more sense if the symbols listed are restricted to those strictly held
within the block.
And so, instead of block_iterator_range, I've switched to iterating
over the multidict symbols. Now the calculated LEN will match the
number of symbols being printed, which fixes the output seen above.
However, as we're now only printing symbols that are within the block
being examined, the output above becomes:
<gdb.Block <anonymous> {}>
All the symbols that GDB previously tried to print, are coming from an
included CU.
For testing, I've made use of an existing DWARF test that tests
DW_AT_import. In the wild I saw this in an inferior that used
multiple shared libraries that has their debug information stored in a
separate debug file, and then parts of that debug information was
combined into a third separate file using the DWZ tool. I made a few
attempts to craft a simpler reproducer, but failed. In the end it was
easier to just use a DWARF assembler test to reproduce the issue.
I have added some more typedef symbols into the DWARF test, I don't
believe that this will impact the existing test, but makes the
corrupted output more obvious.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
With test-case gdb.base/callfuncs.exp I get:
...
UNTESTED: gdb.base/callfuncs.exp: failed to prepare
...
UNTESTED: gdb.base/callfuncs.exp: failed to prepare
DUPLICATE: gdb.base/callfuncs.exp: failed to prepare
...
Fix this by moving a with_test_prefix up one level.
Tested on x86_64-linux.
|
|
Currently, there is no way for a new user to have an idea of common
useful commands and behaviors from the GDB interface itself, without
checking the example session in the documentation. This command class
aims to close that gap by providing a set of quickstart commands that
allows for any simple debug session to happen without anything too
egregious missing.
The set of commands was chosen somewhat arbitrarily, based on what I
used or missed the most. The one overarching important thing, however,
is that the list is kept short, so as to not overwhelm new users. This
is confirmed by the newly introduced selftest, essential_command_count,
which ensures there are 20 or fewer essential commands.
Here's the reasoning for some of the choices:
* The command "start" was picked over "run" because combining it with
"continue" achieves the same effect, and I prefer it over needing to set
a breakpoint on main to stop at the start of the inferior.
* The command "ptype" is chosen because I believe it is important to
provide a way for the user to check a variable's type from inside GDB,
and ptype is a more complete command than the alternative, "whatis".
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Change-Id: I2e26a9953324c752edd01b37db6b176fd0ee9187
|
|
When running test-case gdb.threads/thread-specific-bp.exp using taskset to
select an Efficient-core in a loop, it fails 19 out of 100 runs.
For example, like this:
...
(gdb) continue -a^M
Continuing.^M
^M
Thread 1 "thread-specific" hit Breakpoint 4, end () at thread-specific-bp.c:29^M
29 }^M
(gdb) FAIL: $exp: non_stop=on: continue to end
[Thread 0x7ffff7cbe6c0 (LWP 2348848) exited]^M
Thread-specific breakpoint 3 deleted - thread 2 no longer in the thread list.^M
...
The way we're trying to match this gdb output is:
...
gdb_test_multiple "$cmd" "continue to end" {
-re "$\r\n${gdb_prompt} .*${msg_re}\r\n" {
pass $gdb_test_name
}
-re "\r\n${msg_re}\r\n.*$gdb_prompt " {
pass $gdb_test_name
}
}
...
The problem is that the two -re clauses above do not match the output ending
in a prompt, so the default fail in gdb_test_multiple triggers.
Fix this by splitting this up in two gdb_test_multiple calls:
- the first matches a prompt (with or without preceding $msg_re), making sure
that the default fail doesn't trigger, and
- the second matches $msg_re, if that was not already matched by the first call.
Using this approach, the test-case passes 100 out of 100 runs.
Tested on x86_64-linux, also with make-check-all.sh.
PR testsuite/32688
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32688
|
|
On openSUSE Leap 15.6 x86_64 with test-case gdb.dwarf2/dw2-ranges.exp I ran
into:
...
(gdb) file dw2-ranges^M
Reading symbols from dw2-ranges...^M
warning: stabs debug information is not supported.^M
(gdb)
...
The test-case checks a combination of dwarf and stabs.
Now that stabs is no longer supported, checking the combination is no longer possible.
Fix this by removing the test-case.
|
|
This changes gdb.rust tests to use plain "return" rather than
"return -1". In these spots, the "-1" has no meaning.
Approved-by: Kevin Buettner <kevinb@redhat.com>
|
|
We don't really need three inferiors to test multi-inferior recording.
We don't really need to check info record before starting recording.
If we were recording, there would be output, causing a fail.
This just complicates the test when there is something to debug.
|
|
When we stop replaying a thread, it moves to the end of its execution
history. It retains its state from when it was replaying, though, so a
subsequent 'info program' command would show wrong information.
Clear all execution state used by the 'info program' command.
|
|
With asynchronous stepping commands, one may start replaying a thread in
the background and then stop recording its inferior in the foreground.
This causes the execution history to be cleared and the record target to
be unpushed while the thread is using said execution history.
I fail to see a use-case for this, so rather than trying to make this
work, I prevent such a scenario by not allowing replaying or recording to
be stopped while a thread is running.
We could do this only when a thread is running in replay mode and preserve
the existing behavior of being able to stop recording while threads are
running in recording mode. It seems more consistent to not allow this for
both replaying and recording threads, though.
|
|
As a side effect of the 'record stop' command, threads may move to the end
of their execution history if they had been replaying.
When using CLI or TUI, there is no indication of that move for the
selected thread.
Notify about the frame change for the selected thread. This makes CLI
print the selected frame and TUI update their view.
Add a note to the MI record-stopped event.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Tom Tromey <tom@tromey.com>
|
|
GDB fails with an assertion when stopping recording on a replaying thread
and then resuming that thread. Stopping recording left the thread
replaying but the record target is gone.
Stop replaying all threads in the selected inferior before stopping recording.
I had to change the stepping test slightly to account for different
compilers generating slightly different debug information, so when
stepping the 'return 0' after 'record stop' I would end up in a different
location depending on which compiler I used. The test still covers all
stepping commands.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=19340
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
Fix flake8 warnings like this one:
gdb/testsuite/gdb.perf/template-breakpoints.py:35:13: E731 do not assign a lambda expression, use a def
I chose to inline the lambdas in the expressions, since they are simple
enough and only used once each.
Change-Id: I46fac428a95da38f5a6a87e101be4da9fa4acc31
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Fix this flake8 warning:
gdb/testsuite/gdb.python/py-commands-breakpoint.py:37:13: E741 ambiguous variable name 'l'
This one is a bit subjective, but renaming the variable is easy enough
and the simplest way to get rid of the warning.
Change-Id: I9b1ffd898e27a9d0e172f29715aff3ff3cc785b9
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Fix flake8 warnings like this one:
gdb/testsuite/gdb.python/py-send-packet.py:68:12: E713 test for membership should be 'not in'
Change-Id: I2b4cc1eeb63ee2fceb8c4264e7d6ce2d22824688
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Address flake8 warnings like this one:
gdb/testsuite/gdb.python/py-typeprint.py:60:1: E402 module level import not at top of file
Change-Id: I6ab7880ec5b55b6a5c85cb01d0f85172d44b4ee1
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Fix flake8 errors like this one:
gdb/testsuite/gdb.python/py-unwind-inline.py:61:17: F841 local variable 'v' is assigned to but never used
For this one, there is a slight possibility that removing a variable
changes some behavior, and perhaps renders some test uneffective (where
the test would no longer exercises what it meant to). Removing a
variable means that the object it pointed to likely gets de-allocated
earlier (its tp_dealloc method gets called). So if the intent of the
variable was to ensure the variable outlives the statements that come
after, then this change would be wrong. But I didn't see any evidence
of that being the intent in all the occurences.
Change-Id: Ic57bc68ad225a43ae6771c47b7f443956e8029a6
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Fix flake8 warnings like this:
gdb/testsuite/gdb.python/py-unwind-inline.py:62:9: E722 do not use bare 'except'
Change-Id: I9736c948bc84fefcb7db2a6ac7322cbbfe39da94
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Fix flake8 warnings like:
gdb/testsuite/gdb.base/pc-not-saved.py:55:18: E711 comparison to None should be 'if cond is None:'
Change-Id: Icb8bbe3ea444125c9d7ae63b7c1461045782b4b2
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Fix flake8 warnings like:
gdb/testsuite/gdb.python/py-unwind.py:253:20: E721 do not compare types, for exact checks use `is` / `is not`, for instance checks use `isinstance()`
Change-Id: I506c0874bba88aa418757d94168992bf4ec677f8
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Fix the flake8 warnings of this type:
gdb/testsuite/gdb.python/py-disasm.py:855:9: F824 `global current_pc` is unused: name is never assigned in scope
Change-Id: If492c69553cebea932cfb21e6fea26529761254c
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Remove the imports reported as unused by flake8.
Change-Id: I6e657de3dea8db18a99e711e594cb92f98e1cebb
Approved-By: Tom Tromey <tom@tromey.com>
|
|
gdb.server/fileio-packets.py
flake8 complains about:
gdb/testsuite/gdb.server/fileio-packets.py:67:9: E741 ambiguous variable name 'l'
I think the variable is unnecessary anyway, inline the expression in the
format string.
Change-Id: Ib294f58e663e79e65de058139a770d572bafb282
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Fix flake8 warnings like:
gdb/system-gdbinit/wrs-linux.py:21:5: F821 undefined name 'gdb'
These scripts get executed in a context where the gdb module is already
loaded, so this is not strictly necessary. However, adding these
imports removes a lot of red lines when editing these files in an IDE.
Without them, the code uses this `gdb` thing that appears to be
undefined. Pylance is able to pull the module definition from typeshed
[1] and provide a good experience with typings.
[1] https://github.com/python/typeshed/tree/main/stubs/gdb/gdb
Change-Id: I09c6ae1866ef66f10d8270457771687343c84e32
Approved-By: Tom Tromey <tom@tromey.com>
|
|
On a system with a single GPU, I spotted this test failing. The environment
variable ROCR_VISIBLE_DEVICES can be a bit misleading, as it actually expects
a list of device id's as opposed to a literal number of devices to make
visible.
This test sets it to 1, which is the second GPU on the system. As a result,
systems with a single GPU will have no visible GPU's and the test will FAIL.
Set ROCR_VISIBLE_DEVICES to 0 to make use of the first GPU on the system.
Approved-By: Lancelot Six <lancelot.six@amd.com> (AMDGPU)
|
|
When running the following command on LoongArch:
git clone git://sourceware.org/git/binutils-gdb.git gdb
mkdir -p build && cd build && ../gdb/configure && make -j"$(nproc)"
make check-gdb TESTS="gdb.threads/step-over-thread-exit-while-stop-all-threads.exp"
there exists the following error:
gdb/gdb/testsuite/lib/my-syscalls.S:67:3: error: #error "Unsupported architecture"
this is because there is no SYSCALL macro for LoongArch, just add it.
With this patch, the above test passes on LoongArch.
Signed-off-by: Zewei Yang <yangzewei@loongson.cn>
Tested-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
|
|
In the recently added gdb.src/pre-commit.exp test, we check if the
source directory is a git repository like this:
if {![file isdirectory $repodir/.git]} {
unsupported "Not in a git repository"
return
}
I make extensive use of git worktrees for development. In a worktree
.git is a file containing the location of the actual .git directory,
it is not itself a directory. As such, the above check fails,
claiming my source tree is not a git repository, when in fact, it is.
Fix this by relaxing the check to 'file exists $repodir/.git', which
will cover the directory and file case.
Approved-By: Kevin Buettner <kevinb@redhat.com>
|
|
pre-commit / codespell pointed out a typo in
break-kernel-no-debug-info.exp. This patch fixes it.
|
|
The convert_address_location_to_sals function builds a symtab_and_line
from an explicit pc. Unless overlay debugging is enabled, the sal does not
contain a valid section (as find_pc_overlay will simply return nullptr).
While it is usually not a problem (as the sal users often recompute the
proper section, when needed), it may lead to the proper gdbarch not
being assigned when setting a breakpoint.
In code_breakpoint::add_location, gdb attempts to retrieve the gdbarch
through get_sal_arch by checking for the section or the symtab. However,
neither are currently set by cinvert_address_location_to_sals if the
debug symbols cannot be found. We then fall back to the current
architecture, which may cause errors in heterogeneous programs
(in ROCm, a breakpoint was not being hit since GDB was setting an
x86 int3 instruction instead of the architecture-appropriate s_trap 1).
This is a rework of a patch that was approved, but never merged
upstream (https://inbox.sourceware.org/gdb-patches/20241108195257.485488-2-lancelot.six@amd.com/).
The original change proposed to set the objfile field in the sal, and
check this field in get_sal_arch() if neither the section, nor the
symtab is defined. This patch makes GDB compute the section from the pc
instead of checking from the objfile in get_sal_arch, in accordance with
the rule of trying to set the section when creating the sal implemented
in this patch series. The test cases from the original patch are
included in this new one.
This should have minimal impact on other parts of GDB as users of this
section field would either (1) recompute it the same way (2) not use it
at all. In the case of overlay debugging, then the preceding call to
find_pc_overlay would likely assign a section.
Co-Authored-By: Lancelot SIX <lancelot.six@amd.com>
Approved-By: Tom Tromey <tom@tromey.com>
Change-Id: I23cef6ad5a66f696536c7c49c885a074bfea9b23
|
|
We may rely on a minimal symbol to place a breakpoint on a function,
for instance when debug infos are unavailable. The minsym_found
function attempts to convert that minsym to a sal using either
find_function_start_sal or filling a sal manually from the minimal
symbol. This patch implements the decision to make it the responsibility
of the sal creation site to properly fill out the section field when
that is possible.
The function address may be updated when dealing with ifuncs, which
means the section from the minsym may be completely different from the
actual function address's section. A preceding change (6f7ad238 : gdb:
ensure bp_location::section is set correct to avoid an assert) has
proposed recomputing the section by calling find_pc_overlay. However,
this ends up setting the section to NULL in most cases. While the
section is often recomputed later on, I think it might be more
appropriate to set it once and for all when creating the sal.
The parent commit ensures that find_function_start_sal will return a
symtab_and_line with a section if possible. minsym_found can pass the
section if it can be trusted later on - it is in fact necessary to
ensure we get the proper pc/section with overlays. When dealing with
an ifunc that was resolved, then the section has to be recomputed
since the ifunc implementation may be in another section, or objfile.
This is now done in find_sal_for_pc_sect.
This change restores the section argument in
find_function_start_sal that was removed in a previous commit (6b0581fc
: gdb/symtab: remove section parameter from find_function_start_sal),
as it avoids an unnecessary lookup later in find_sal_for_pc_sect. The
function now sends the minsym's section if it corresponds to the actual
function, and not an ifunc.
This commit fixes a failure on gdb.rocm/displaced-stepping.exp. A new
test case is also provided to check that a breakpoint on a kernel is hit
without debug infos.
Approved-By: Tom Tromey <tom@tromey.com>
Change-Id: I7a502dc4565911cec92618f34be3d4bcbf8560c5
|
|
gnat-llvm will sometimes emit a structure that that uses
DW_AT_bit_size with an expression to compute the bit size of a record.
I believe this is a DWARF extension. This patch implements support
for this in gdb.
Reviewed-By: Keith Seitz <keiths@redhat.com>
|
|
On openSUSE Leap 15.6 x86_64 I ran into:
....
(gdb) file gdbindex-stabs^M
Reading symbols from gdbindex-stabs...^M
warning: stabs debug information is not supported.^M
(gdb) list stabs_function^M
(gdb) FAIL: gdb.base/gdbindex-stabs.exp: list stabs_function
...
Fix this by removing the test-case.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Simplify test-case gdb.cp/local-static.exp in the following way.
First rewrite this uplevel into a more usual form:
...
-set print_quoted_re [uplevel 1 "subst_vars \"$print_quoted_re\""]
+set print_quoted_re [uplevel 1 [list subst -nocommands $print_quoted_re]]
...
This requires us to use "subst -nocommands" instead of subst_vars, to allow
backslash substitution, which previously was happening implicitly because of
the way uplevel was used.
Then, declare globals hex and syntax_re, such that we no longer have to use
uplevel:
...
-set print_quoted_re [uplevel 1 [list subst -nocommands $print_quoted_re]]
+set print_quoted_re [subst -nocommands $print_quoted_re]
...
Finally, stop applying backslash substitution, simplifying cxx_scopes_list and
c_scopes_list:
...
-set print_quoted_re [subst -nocommands $print_quoted_re]
+set print_quoted_re [subst_vars $print_quoted_re]
...
While we're at it, simplify some regexps using string_to_regexp in a few places.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
