Remove this overload, prefer to use `process_info::for_each_thread`. In
many instances, the `process_info` is already available, so this saves a
map lookup. In other instances, add the `process_info` lookup at the
call site.
In `linux-arm-low.cc` and `win32-i386-low.cc`, use `current_process ()`
instead of `current_thread->id.pid ()`. I presume that if
`current_process ()` and `current_thread` don't match, it's a bug
orthogonal to this change.
Change-Id: I751ed497cb1f313cf937b35125151bee9316fc51
Reviewed-By: Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
LoongArch doesn't implement the hook gdbarch_remove_non_address_bits, so
there is no need to use the hook in gdb/loongarch-linux-nat.c.
Approved-By: Luis Machado <luis.machado@arm.com>
When GDB is unable to read an objfile, it prints the error message "I'm
sorry Dave, I can't do that. Symbol format `%s' unknown.". While it is a
great reference, an end user won't have much information about the
problem.
So far this wasn't much of a problem, as it is very uncommon for GDB to
be unable to read an objfile. However, a future patch will allow users
to selectively disable support to some formats, making it somewhat
expected that the message will be seen by end users.
This commit makes the end message more informative and direct.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=13299
Approved-By: Tom Tromey <tom@tromey.com>
This patch introduces a new operand flag OPD_F_UNSIGNED to signal that
the immediate value should be treated as an unsigned value. The default
signedness of immediate operands is signed.
The current space optmization on enum aarch64_opn_qualifier forced its
encoding using an unsigned char. This "hard-coded" optimization has the
bad consequence of making the array of such enums being completely
unreadable when debugging with GDB because the enum type is lost along
the way.
Keeping this space optimization, and the enum type as well, is possible
when the declaration of the enum is tagged with attribute((packed)).
attribute((packed)) is a GNU extension, and is wrapped in the macro
ATTRIBUTE_PACKED (defined in ansidecl.h), and should be used instead.
The enum aarch64_opnd_qualifiers in include/opcode/aarch64.h needs to
stay in sync with the array of struct operand_qualifier_data which
defines various properties for the different type of operands. For
instance, for:
- registers: the size of the register, the number of elements.
- immediates: lower and upper bits to determine the range of values.
In the recent commit:
commit 31ada87f91
Date: Wed Nov 6 22:18:55 2024 +0000
gdb: fixes and tests for the 'edit' command
the new gdb.base/basic-edit-cmd.exp was added. The Linaro CI
highlighted an issue with the test which I failed to address before
pushing the above commit.
Part of the test loads a file into GDB and then uses the 'edit'
command with no arguments to edit the default location. This default
location is expected to be the 'main' function.
On my local machine the line reported is the opening '{' of main, and
that is what the test checks for.
The Linaro CI though appears to see the first code line of main.
I think either result is fine as far as this test is concerned, so
I've expanded the test regexp to check for either line number. This
should make the CI testing happy again.
This commit was inspired by this mailing list post:
https://inbox.sourceware.org/gdb-patches/osmtfvf5xe3yx4n7oirukidym4cik7lehhy4re5mxpset2qgwt@6qlboxhqiwgm
When reviewing that patch, the first thing I wanted to do was add some
tests for the 'edit' command because, as far as I can tell, there are
no real tests right now.
The approach I've taken for testing is to override the EDITOR
environment variable, setting this to just 'echo'. Now when the
'edit' command is run, instead of entering an interactive editor, the
shell instead echos back the arguments that GDB is trying to pass to
the editor. The output might look like this:
(gdb) edit
+22 /tmp/gdb/testsuite/gdb.base/edit-cmd.c
(gdb)
We can then test this like any other normal command. I then wrote
some basic tests covering a few situations like, using 'edit' before
the inferior is started. Using 'edit' without any arguments, and
using 'edit' with a line number argument.
There are plenty of cases that are still not tested, for example, the
test program only has a single source file for example. But we can
always add more tests later.
I then used these tests to validate the fix proposed in the above
patch.
The patch above does indeed fix some cases, specifically, when GDB
stops at a location (e.g. a breakpoint location) and then the 'edit'
command without any arguments is fixed. But using the 'list' command
to show some other location, and then 'edit' to edit the just listed
location broken before and after the above patch.
I am instead proposing this alternative patch which I think fixes more
cases. When GDB stops at a location then 'edit' with no arguments
should correctly edit the current line. And using 'list XX' to list a
specific location, followed by 'edit' should also now edit the just
listed location.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17669
Co-Authored-By: Lluís Batlle i Rossell <viric@viric.name>
Approved-By: Tom Tromey <tom@tromey.com>
After commit 2e60790cf7 "Remove the
paramstuff word" there is no caller left of the static find function
in doc/chew.c, so it should be removed.
* doc/chew.c (find): Remove.
For any arm elf target, disable an old piece of code that forced disassembly to
disassemble for 'unknown architecture' which once upon a time meant it would
disassemble ANY arm instruction. This is no longer true with the addition of
Armv8.1-M Mainline, as there are conflicting encodings for different thumb
instructions.
BFD however can detect what architecture the object file was assembled for
using information in the notes section. So if available, we use that,
otherwise we default to the old 'unknown' behaviour.
With the changes above code, a mode changing 'bx lr' assembled for armv4 with
the option --fix-v4bx will result in an object file that is recognized by bfd
as one for the armv4 architecture. The disassembler now disassembles this
encoding as a BX even for Armv4 architectures, but warns the user when
disassembling for Armv4 that this instruction is only valid from Armv4T
onwards.
Remove the unused and wrongfully defined ARM_ARCH_V8A_CRC, and
define and use a ARM_ARCH_V8R_CRC to make sure instructions enabled by
-march=armv8-r+crc are disassembled correctly.
Patch up some of the tests cases, see a brief explanation for each below.
inst.d:
This test checks the assembly & disassembly of basic instructions in armv3m. I
changed the expected behaviour for teqp, cmnp cmpp and testp instructions to
properly print p when disassembling, whereas before, in the 'unknown' case it
would disassemble these as UNPREDICTABLE as they were changed in later
architectures.
nops.d:
Was missing an -march, added one to make sure we were testing the right
behavior of NOP<c> instructions.
unpredictable.d:
Was missing an -march, added armv6 as that reproduced the behaviour being
tested.
We don't seem to support any m-profile assembly/disassembly tests for wince or
pe, so skipping the pacbti one too.
The pr29494 test needs to be skipped because it uses assembly syntax that is
not supported in wince/pe like for instance eabi_attribute directives.
The ARM simulator is no longer able to simulator modern ARM cores, so it
is being deprecated. Once this change has been active for a while - and
assuming that no problems have been found - the ARm simulator codebase
will be removed.
Replace the servers global thread list with a process specific thread
list and a ptid -> thread map similar to 'inferior::ptid_thread_map' on
GDB side. Optimize the 'find_thread' and 'find_thread_ptid' functions
to use std::unordered_map::find for faster lookup of threads without
iterating over all processes and threads, if applicable. This becomes
important when debugging applications with a large thread count, e.g.,
in the context of GPU debugging.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
This patch replaces the 'std::list' type of 'all_processes' and
'all_threads' with the more lightweight 'owning_intrusive_list'
type.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
gas/
* testsuite/gas/ppc/rfc02655.[ds]: Rename from this...
* testsuite/gas/ppc/future.[ds]: ... to this.
* testsuite/gas/ppc/rfc02656.[ds]: Delete. Move tests to future.[ds].
* testsuite/gas/ppc/ppc.exp: Update for file name changes.
struct symtab *find_line_symtab (struct symtab *, int, int *, bool *);
The last parameter is bool* that when set will receive information
if the match was exact. This parameter is never used by any callsite
and can therefore be removed.
This will become:
symtab *find_line_symtab (symtab *sym_tab, int line, int *index);
Approved-By: Tom Tromey <tom@tromey.com>
This rewrites decode_line_2_compare_items to be an operator< on the
relevant type. This simplifies the code a little.
Reviewed-by: Keith Seitz <keiths@redhat.com>
Remove includes reported as unused by clangd.
Include "gdb-hashtab.h" in typeprint.h for the use of "htab_up".
Change-Id: I5b04ec14e71800e2d6ad622838e39b7033e168cf
gdb::hash_enum is a workaround for a small oversight in C++11:
std::hash was not defined for enumeration types. This was rectified
in C++14 and so we can remove the local workaround.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Convert the add-inferior and clone-inferior commands to make use of
the option framework. This improves the tab completion for these
commands.
Previously the add-inferior command used a trick to simulate
completion of -exec argument. The command use filename completion for
everything on the command line, thus you could do:
(gdb) add-inferior /path/to/some/fil<TAB>
and GDB would complete the file name, even though add-inferior doesn't
really take a filename as an argument. This helped a little though
because, if the user did this:
(gdb) add-inferior -exec /path/to/some/fil<TAB>
then the file name would be completed. However, GDB didn't really
understand the options, so couldn't offer completion of the options
themselves.
After this commit, the add-inferior command makes use of the recently
added gdb::option::filename_option_def feature. This means that the
user now has full completion of the option names, and that file names
will still complete for the '-exec' option, but will no longer
complete if the '-exec' option is not used.
I have also converted the clone-inferior command, though this command
does not use any file name options. This command does now have proper
completion of the command options.
This commit adds support for filename options to GDB's option
sub-system (see cli/cli-option.{c,h}).
The new filename options support quoted and escaped filenames, and tab
completion is fully supported.
This commit adds the new option, and adds these options to the
'maintenance test-options' command as '-filename', along with some
tests that exercise this new option.
I've split the -filename testing into two. In gdb.base/options.exp we
use the -filename option with some arbitrary strings. This tests that
GDB can correctly extract the value from a filename option, and that
GDB can complete other options after a filename option. However,
these tests don't actually pass real filenames, nor do they test
filename completion.
In gdb.base/filename-completion.exp I have added some tests that test
the -filename option with real filenames, and exercise filename tab
completion.
This commit doesn't include any real uses of the new filename options,
that will come in the next commit.
I had reason to look at the gdb.stabs/gdb11479.exp test script and
figured it could do with a small clean up. I've:
- Made use of standard_testfile and the variables it defines.
- Made use of with_test_prefix and removed the prefix from the end
of each test name.
- Avoid overwriting the test binary when we recompile, instead use a
different name for each recompilation.
- Add '.' at the end of each comment.
There should be no changes in what is tested with this commit.
Reviewed-By: Keith Seitz <keiths@redhat.com>
Consider the test case:
void *thread_main(void *) {
std::cout << getpid() << std::endl;
sleep(20);
return nullptr;
}
int main(void) {
pthread_t thread;
pthread_create(&thread, nullptr, thread_main, nullptr);
pthread_join(thread, nullptr);
return 0;
}
This program creates a thread via main that sleeps for 20 seconds.
When we debug this with gdb we get,
Reading symbols from ./test...
(gdb) b main
Breakpoint 1 at 0x10000934: file test.c, line 11.
(gdb) r
Starting program: /read_only_gdb/binutils-gdb/gdb/test
Breakpoint 1, main () at test.c:11
11 pthread_create(&thread, nullptr, thread_main, nullptr);
(gdb) c
Continuing.
15335884
[New Thread 258 (tid 31130079)]
Thread 2 received signal SIGINT, Interrupt.
[Switching to Thread 258 (tid 31130079)]
0xd0611d70 in _p_nsleep () from /usr/lib/libpthread.a(_shr_xpg5.o)
(gdb) thread 1
[Switching to thread 1 (Thread 1 (tid 25493845))]
(gdb) c
Continuing.
[Thread 1 (tid 25493845) exited]
[Thread 258 (tid 31130079) exited]
inferior.c:405: internal-error: find_inferior_pid: Assertion `pid != 0' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
----- Backtrace -----
There are two bugs here. One is the core dump. The other is the main thread information
not captured.
So, while I was debugging the first part the reason, the reason I figured out was
the last for loop in sync_threadlists ().
Once both my threads exit we delete them as below:
for (struct thread_info *it : all_threads ())
{
if (in_queue_threads.count (priv->pdtid) == 0
&& in_thread_list (proc_target, it->ptid)
&& pid == it->ptid.pid ())
{
delete_thread (it);
data->exited_threads.insert (priv->pdtid);
But once these two threads are deleted, all_threads ()
has one more thread whose tid and pid are 0.
gdb) c
Continuing.
In for loop 8782296 is pid, 19857879 is tid
[Thread 1 (tid 19857879) exited]
In for loop 8782296 is pid, 30933401 is tid
[Thread 258 (tid 30933401) exited]
In for loop 0 is pid, 0 is tid
[Inferior 1 (process 8782296) exited normally]
(gdb) q
I used a printf in the for loop mentioned above for explaination.
You see the loop enters the third time with 0 as pid.
The reason being though the threads are removed but not deleted since they are
not deletable ().
Hence we use all_threads_safe () iterator instead.
The second part to the bug is the lack of information of the main thread.
Andrew was right here (https://sourceware.org/pipermail/gdb-patches/2024-September/211875.html)
Thank you Andrew.
The thread has loaded but then ptrace () call when we tried to fetch_regs_kernel_thread
failed. This returned EPERM as errno.
if (!ptrace32 (PTT_READ_GPRS, tid, (uintptr_t) gprs32, 0, NULL))
memset (gprs32, 0, sizeof (gprs32));
Hence all registers were set to 0 and we did not get the required infromation.
This issue will be fixed within the AIX ptrace call.
Approved By: Ulrich Weigand <ulrich.weigand@de.ibm.com>.
PR/32298 sframe: no SFrame stack trace info generated for .plt.got
Add support to generate SFrame stack trace info for .plt.got section.
Enhance the current definition of struct elf_x86_sframe_plt to include
initialized SFrame FDE/FREs applicable for .plt.got section. There are
two variants of .plt.got entries: 16 byte and 8 byte.
8 byte:
ff 25 00 00 00 00 jmpq *name@GOTPCREL(%rip)
66 90 xchg %ax,%ax
16 byte:
f3 0f 1e fa endbr64
ff 25 66 2f 00 00 jmpq *name@GOTPCREL(%rip)
66 0f 1f 44 00 00 nopw 0x0(%rax,%rax,1)
For the testcase, define some application symbols such that their PLT
entry is placed in .plt.got and ensure SFrame information is generated
with and without -z ibtplt.
ChangeLog:
PR/32298
* bfd/elf64-x86-64.c (elf_x86_64_link_setup_gnu_properties):
PLT GOT entry size is different for IBT vs non IBT PLTs.
* bfd/elfxx-x86.c (enum dynobj_sframe_plt_type): New enum for
SFRAME_PLT_GOT.
(_bfd_x86_elf_create_sframe_plt): Handle SFRAME_PLT_GOT.
(_bfd_x86_elf_write_sframe_plt): Likewise.
(_bfd_x86_elf_late_size_sections): Likewise.
(_bfd_x86_elf_finish_dynamic_sections): Likewise.
* bfd/elfxx-x86.h (struct elf_x86_sframe_plt): Add new members
to keep information about PLT GOT entries.
(struct elf_x86_link_hash_table): Add support for creating
SFrame section for .plt.got.
* ld/testsuite/ld-x86-64/x86-64.exp: Add new tests.
* ld/testsuite/ld-x86-64/sframe-pltgot-1.d: New test.
* ld/testsuite/ld-x86-64/sframe-pltgot-1.s: New test.
* ld/testsuite/ld-x86-64/sframe-pltgot-2.d: New test.
Fix PR/32296 sframe: wrong SFrame info for pltN and .plt.sec for -z ibtplt
The x86 psABI defines a 2-PLT scheme for IBT which uses .plt and
.plt.sec entries. It was observed that SFrame information for .plt.sec
section was incorrect. The erroneous assumption was that SFrame stack
trace information for .plt.sec with lazy binding is the same as SFrame
stack trace information for .plt with lazy binding. This is corrected
now by initializing a new SFrame PLT helper object
elf_x86_64_sframe_ibt_plt for lazy PLT with IBT.
Add a testcase where linking with -z ibtplt generates .plt.sec entries and
ensure correct SFrame information for it.
Committed by Indu Bhagat.
ChangeLog:
PR/32296
* bfd/elf64-x86-64.c (elf_x86_64_sframe_ibt_pltn_fre2): New
definition elf_x86_64_sframe_ibt_plt. Use it in
elf_x86_64_sframe_plt.
(elf_x86_64_link_setup_gnu_properties): Lazy IBT PLT entries are
different from lazy PLT.
* bfd/elfxx-x86.c (_bfd_x86_elf_create_sframe_plt): Adjust for
SFrame for IBT PLT.
* ld/testsuite/ld-x86-64/x86-64.exp: Add new test.
* ld/testsuite/ld-x86-64/sframe-ibt-plt-1.d: New test.
When _creating_ SFrame information for the linker created .plt.sec, the
code correctly checks for presence of .plt.sec. When _writing_ the
SFrame section for the corresponding .plt.sec, however, the conditionals
were wrongly checking for splt. This was causing an assertion at link
time.
This issue has been known to affect glibc build with SFrame enabled.
No testcase is added just yet. A later commit ensures correct SFrame
stack trace information is created for .plt.got. A test case (where only
.plt and .plt.got are created) is added then.
PR/32297 sframe: bfd assertion with empty main on IBT enabled system
Committed by Indu Bhagat.
ChangeLog:
PR/32297
* bfd/elfxx-x86.c (_bfd_x86_elf_late_size_sections): Check for
plt_second member not for splt.
Linker should report an error for hidden undefined symbol when building
a shared library without the "recompile with -fPIC" message:
$ cat x.c
extern int foo __attribute__ ((visibility ("hidden")));
int
func (void)
{
return foo;
}
$ gcc -c -fPIC -O2 x.c
$ objdump -dwr x.o
x.o: file format elf64-x86-64
Disassembly of section .text:
0000000000000000 <func>:
0: 8b 05 00 00 00 00 mov 0x0(%rip),%eax # 6 <func+0x6> 2: R_X86_64_PC32 foo-0x4
6: c3 ret
$ ld -shared -o x.so x.o
ld: x.o: in function `func':
x.c:(.text+0x2): undefined reference to `foo'
ld: x.o: relocation R_X86_64_PC32 against undefined hidden symbol `foo' can not be used when making a shared object
ld: final link failed: bad value
$
since -fPIC has been used.
* testsuite/ld-x86-64/hidden6.d: New file.
* testsuite/ld-x86-64/hidden6.s: Likewise.
* testsuite/ld-x86-64/x86-64.exp: Run hidden6.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
Since commit d9deb60b2e, I get the
following compiler error when building binutils (cross-compiling) on
macos:
CXX remote-sim.o
../../gdb/remote-sim.c:334:28: error: assigning to 'void (*)(host_callback *, const char *, ...) __attribute__((noreturn))' (aka 'void (*)(host_callback_struct *, const char *, ...) __attribute__((noreturn))') from incompatible type 'void (host_callback
*, const char *, ...)' (aka 'void (host_callback_struct *, const char *, ...)')
gdb_callback.error = gdb_os_error;
^~~~~~~~~~~~
1 error generated.
This appears to be due to the mismatch between ATTRIBUTE_NORETURN and
[[noreturn]] on gdb_os_error. Reverting the change for gdb_os_error
resolves the issue. Removing ATTTRIBUTE_NORETURN on the
declaration of host_callback::error also works, but deprives the
compiler of data.
Tested by compiling on macos both with the system clang, as well as with
GCC 14. With clang, remote-sim.c does not compile (per above) without
this patch. With GCC, it compiles with and without the patch (it
doesn't link, but AFAICT that is unrelated).
The clang bug is reported upstream at
https://github.com/llvm/llvm-project/issues/113511
Approved-By: Tom Tromey <tom@tromey.com>
This adds a new event source so that Python scripts can track whether
or not the TUI is presently enabled.
v2 of the patch renames "status" -> "enabled".
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32162
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Reviewed-by: Keith Seitz <keiths@redhat.com>
