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>
On Windows gcore is not implemented, and if you try it, you get an
heap-use-after-free error:
(gdb) gcore C:/gdb/build64/gdb-git-python3/gdb/testsuite/outputs/gdb.base/gcore-buffer-overflow/gcore-buffer-overflow.test
warning: cannot close "=================================================================
==10108==ERROR: AddressSanitizer: heap-use-after-free on address 0x1259ea503110 at pc 0x7ff6806e3936 bp 0x0062e01ed990 sp 0x0062e01ed140
READ of size 111 at 0x1259ea503110 thread T0
#0 0x7ff6806e3935 in strlen C:/gcc/src/gcc-14.2.0/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:391
#1 0x7ff6807169c4 in __pformat_puts C:/gcc/src/mingw-w64-v12.0.0/mingw-w64-crt/stdio/mingw_pformat.c:558
#2 0x7ff6807186c1 in __mingw_pformat C:/gcc/src/mingw-w64-v12.0.0/mingw-w64-crt/stdio/mingw_pformat.c:2514
#3 0x7ff680713614 in __mingw_vsnprintf C:/gcc/src/mingw-w64-v12.0.0/mingw-w64-crt/stdio/mingw_vsnprintf.c:41
#4 0x7ff67f34419f in vsnprintf(char*, unsigned long long, char const*, char*) C:/msys64/mingw64/x86_64-w64-mingw32/include/stdio.h:484
#5 0x7ff67f34419f in string_vprintf[abi:cxx11](char const*, char*) C:/gdb/src/gdb.git/gdbsupport/common-utils.cc:106
#6 0x7ff67b37b739 in cli_ui_out::do_message(ui_file_style const&, char const*, char*) C:/gdb/src/gdb.git/gdb/cli-out.c:227
#7 0x7ff67ce3d030 in ui_out::call_do_message(ui_file_style const&, char const*, ...) C:/gdb/src/gdb.git/gdb/ui-out.c:571
#8 0x7ff67ce4255a in ui_out::vmessage(ui_file_style const&, char const*, char*) C:/gdb/src/gdb.git/gdb/ui-out.c:740
#9 0x7ff67ce2c873 in ui_file::vprintf(char const*, char*) C:/gdb/src/gdb.git/gdb/ui-file.c:73
#10 0x7ff67ce7f83d in gdb_vprintf(ui_file*, char const*, char*) C:/gdb/src/gdb.git/gdb/utils.c:1881
#11 0x7ff67ce7f83d in vwarning(char const*, char*) C:/gdb/src/gdb.git/gdb/utils.c:181
#12 0x7ff67f3530eb in warning(char const*, ...) C:/gdb/src/gdb.git/gdbsupport/errors.cc:33
#13 0x7ff67baed27f in gdb_bfd_close_warning C:/gdb/src/gdb.git/gdb/gdb_bfd.c:437
#14 0x7ff67baed27f in gdb_bfd_close_or_warn C:/gdb/src/gdb.git/gdb/gdb_bfd.c:646
#15 0x7ff67baed27f in gdb_bfd_unref(bfd*) C:/gdb/src/gdb.git/gdb/gdb_bfd.c:739
#16 0x7ff68094b6f2 in gdb_bfd_ref_policy::decref(bfd*) C:/gdb/src/gdb.git/gdb/gdb_bfd.h:82
#17 0x7ff68094b6f2 in gdb::ref_ptr<bfd, gdb_bfd_ref_policy>::~ref_ptr() C:/gdb/src/gdb.git/gdbsupport/gdb_ref_ptr.h:91
#18 0x7ff67badf4d2 in gcore_command C:/gdb/src/gdb.git/gdb/gcore.c:176
0x1259ea503110 is located 16 bytes inside of 4064-byte region [0x1259ea503100,0x1259ea5040e0)
freed by thread T0 here:
#0 0x7ff6806b1687 in free C:/gcc/src/gcc-14.2.0/libsanitizer/asan/asan_malloc_win.cpp:90
#1 0x7ff67f2ae807 in objalloc_free C:/gdb/src/gdb.git/libiberty/objalloc.c:187
#2 0x7ff67d7f56e3 in _bfd_free_cached_info C:/gdb/src/gdb.git/bfd/opncls.c:247
#3 0x7ff67d7f2782 in _bfd_delete_bfd C:/gdb/src/gdb.git/bfd/opncls.c:180
#4 0x7ff67d7f5df9 in bfd_close_all_done C:/gdb/src/gdb.git/bfd/opncls.c:960
#5 0x7ff67d7f62ec in bfd_close C:/gdb/src/gdb.git/bfd/opncls.c:925
#6 0x7ff67baecd27 in gdb_bfd_close_or_warn C:/gdb/src/gdb.git/gdb/gdb_bfd.c:643
#7 0x7ff67baecd27 in gdb_bfd_unref(bfd*) C:/gdb/src/gdb.git/gdb/gdb_bfd.c:739
#8 0x7ff68094b6f2 in gdb_bfd_ref_policy::decref(bfd*) C:/gdb/src/gdb.git/gdb/gdb_bfd.h:82
#9 0x7ff68094b6f2 in gdb::ref_ptr<bfd, gdb_bfd_ref_policy>::~ref_ptr() C:/gdb/src/gdb.git/gdbsupport/gdb_ref_ptr.h:91
#10 0x7ff67badf4d2 in gcore_command C:/gdb/src/gdb.git/gdb/gcore.c:176
It happens because gdb_bfd_close_or_warn uses a bfd-internal name for
the failing-close warning, after the close is finished, and the name
already freed:
static int
gdb_bfd_close_or_warn (struct bfd *abfd)
{
int ret;
const char *name = bfd_get_filename (abfd);
for (asection *sect : gdb_bfd_sections (abfd))
free_one_bfd_section (sect);
ret = bfd_close (abfd);
if (!ret)
gdb_bfd_close_warning (name,
bfd_errmsg (bfd_get_error ()));
return ret;
}
Fixed by making a copy of the name for the warning.
Approved-By: Andrew Burgess <aburgess@redhat.com>
Since QEMU have supported -Max option to to enable all normal extensions,
the dis-assembler should also add an option, -M,max to do the same thing.
For the instruction, which have overlapped encodings like zfinx, will not
be considered by the -M,max option.
opcodes/
* riscv-dis.c (all_ext): New static boolean. If set, disassemble
without checking architectire string.
(riscv_disassemble_insn): Likewise.
(parse_riscv_dis_option_without_args): Recognized -M,max option.
binutils/
* NEWS: Updated.
Pass --no-rosegment to ld to support linker configured with
--enable-rosegment,
PR ld/25207
* ld-elf/pr25207.d: Pass --no-rosegment to ld.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
Given the recent CVE filed for GDB (CVE-2024-36699), I decided to update
the gdb/SECURITY.txt to be more explicit about some details. Specifically,
we now explicitly say that internal errors aren't security
vulnerabilities, and mention that users should review plugins before
running them, and under which conditions a plugin can cause a security
bug.
Reviewed-By: Tom Tromey <tom@tromey.com>
Approved-By: Luis Machado <luis.machado@arm.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>
I noticed commit 84786372e1 ("Fix size of register buffer") fixing a
stack-buffer-overflow found by AddressSanitizer in
amd64_windows_store_arg_in_reg:
...
- gdb_byte buf[8];
+ gdb_byte buf[16];
...
and wondered if we could have found this without AddressSanitizer.
I realized that the problem is that this:
...
gdb_byte buf[N];
...
regcache->cooked_write (regno, buf);
...
is using the deprecated variant of cooked_write instead of the one using
gdb::array_view:
...
/* Transfer of pseudo-registers. */
void cooked_write (int regnum, gdb::array_view<const gdb_byte> src);
/* Deprecated overload of the above. */
void cooked_write (int regnum, const gdb_byte *src);
...
and consequently cooked_write does not know the size of buf.
Fix this by using std::array, and likewise in other places in
gdb/amd64-windows-tdep.c.
In the process I fixed another out of bounds access here:
...
gdb_byte imm16[2];
...
cache->prev_sp = cur_sp
+ extract_unsigned_integer (imm16, 4, byte_order);
...
where we're reading 4 bytes from the 2-byte buffer imm16.
Tested by rebuilding on x86_64-linux.
Tested-By: Hannes Domani <ssbssa@yahoo.de>
We're doing such in fairly many places, and yet more are likely to
appear; centralize the logic, much like we already have
swap_2_operands().
While there also correct mis-indentation in adjacent code in
process_operands().
Without this APX support isn't really complete.
For Intel syntax displacement form is needed, such that symbolic
operands won't need prefixing by "offset". (The other form is actually
not used at all in Intel syntax.)
For the record: To restrict displacement form to Intel syntax is not
something I actually agree with.
