This commit fixes an issue with the commit:
commit d3d13bf876
Date: Thu Apr 25 09:36:43 2024 +0100
gdb: add gdbarch method to get execution context from core file
The above commit improves GDB's ability to display inferior arguments
when opening a core file, however, if an argument includes white
space, then this is not displayed as well as it should be. For
example:
(gdb) core-file /tmp/corefile-exec-context.2.core
[New LWP 4069711]
Reading symbols from /tmp/corefile-exec-context...
Core was generated by `/tmp/corefile-exec-context aaaaa bbbbb ccccc ddddd e e e e e'.
Program terminated with signal SIGABRT, Aborted.
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50 return ret;
(gdb) show args
Argument list to give program being debugged when it is started is "aaaaa bbbbb ccccc ddddd e\ e\ e\ e\ e".
(gdb)
Notice the 'Core was generated by ...' line. In this case it is not
clear if the "e e e e e" is a single argument containing white space,
or 5 single arguments.
But when we 'show args' it is immediately clear that this is a single
argument, as the white space is now escaped.
This problem was caused by the above commit building the argument
string itself, and failing to consider white space escaping.
This commit changes things around, first we place the arguments into
the inferior, then, to print the 'Core was generated by ...' line, we
ask the inferior for the argument string. In this way the quoting is
handled just as it is for 'show args'. The initial output is now:
(gdb) core-file /tmp/corefile-exec-context.2.core
[New LWP 4069711]
Reading symbols from /tmp/corefile-exec-context...
Core was generated by `/tmp/corefile-exec-context aaaaa bbbbb ccccc ddddd e\ e\ e\ e\ e'.
Program terminated with signal SIGABRT, Aborted.
#0 0x00007f4f007af625 in raise () from /lib64/libc.so.6
(gdb)
Much better. The existing test is extended to cover this case.
Reviewed-By: Guinevere Larsen <guinevere@redhat.com>
Approved-By: Tom Tromey <tom@tromey.com>
Commit 3470a0e144 inadvertently broke
the build on MIPS because it's passing a non-existent "pid" argument
to "proc->for_each_thread". This commit fixes the problem by removing
the argument from the call.
Signed-off-by: Sergio Durigan Junior <sergiodj@sergiodj.net>
Approved-By: Simon Marchi <simon.marchi@efficios.com>
I happened to notice that "help add-inferior" said:
-execFILENAME
FILENAME is the file name of the executable to use as the
main program.
This is missing a space after "-exec". This patch fixes the bug.
If ok'd on time I plan to check this in to the gdb-16 branch as well.
Approved-by: Kevin Buettner <kevinb@redhat.com>
(cherry picked from commit 6511d20c9d)
The custom linetable functionality in GDB's JIT Interface has been broken
since commit 1acc9dca42.
In that commit, linetables were made independent from the objfile, which
requires objfile->section_offsets to be initialized. However, section_offsets
were never initialized in objfiles generated by GDB's JIT Interface
with custom jit-readers, leading to GDB crashes when stepping into JITed code
blocks with the following command already executed:
jit-reader-load libmygdbjitreader.so
This patch fixes the issue by initializing the minimum section_offsets required
for linetable parsing procedures.
A minimal test is included. The test sets up some very simple line
table information, which is enough to trigger the bug. However, the
line table information is crafted such that none of the line table
entries will end up being displayed in GDB's output when the test is
run, as such, none of the expected output actually changes.
It might be nice in the future to extend some of the jit tests to
actually test hitting line table entries added via the jit reader.
Approved-By: Tom Tromey <tom@tromey.com>
A comment in bugzilla pointed out a bug in my earlier patch to handle
the DAP "linesStartAt1" setting. In particular, in the backtrace
code, "line" can be None, which would lead to an exception from
export_line.
This patch fixes the problem.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32468
(cherry picked from commit 28e5851344)
Iain pointed out a crash in the DWARF indexer when run on a certain D
program. The DWARF in this case has a nameless enum class; this
causes an assertion failure.
This patch arranges to simply ignore such types. The fact that an
enum class is nameless in this case appears to be a compiler bug.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32518
Approved-By: Tom de Vries <tdevries@suse.de>
(cherry picked from commit 66903f1d66)
procfs.c compilation is currently broken on Solaris:
/vol/src/gnu/gdb/hg/gdb-16-branch/git/gdb/procfs.c: In member function ‘virtual ptid_t procfs_target::wait(ptid_t, target_waitstatus*, target_wait_flags)’:
/vol/src/gnu/gdb/hg/gdb-16-branch/git/gdb/procfs.c:2067:34: error: ‘wait’ is not a member of ‘gdb’; did you mean ‘wait’?
2067 | wait_retval = gdb::wait (&wstat);
| ^~~~
In file included from ../gnulib/import/sys/wait.h:28,
from /usr/include/stdlib.h:16,
from /usr/gcc/14/include/c++/14.2.0/cstdlib:79,
from /vol/src/gnu/gdb/hg/gdb-16-branch/git/gdb/../gdbsupport/common-defs.h:99,
from /vol/src/gnu/gdb/hg/gdb-16-branch/git/gdb/defs.h:26,
from <command-line>:
/usr/include/sys/wait.h:85:14: note: ‘wait’ declared here
85 | extern pid_t wait(int *);
| ^~~~
/vol/src/gnu/gdb/hg/gdb-16-branch/git/gdb/procfs.c:2154:41: error: ‘wait’ is not a member of ‘gdb’; did you mean ‘wait’?
2154 | int temp = gdb::wait (&wstat);
| ^~~~
/usr/include/sys/wait.h:85:14: note: ‘wait’ declared here
85 | extern pid_t wait(int *);
| ^~~~
/vol/src/gnu/gdb/hg/gdb-16-branch/git/gdb/procfs.c: In function ‘void unconditionally_kill_inferior(procinfo*)’:
/vol/src/gnu/gdb/hg/gdb-16-branch/git/gdb/procfs.c:2566:12: error: ‘wait’ is not a member of ‘gdb’; did you mean ‘wait’?
2566 | gdb::wait (NULL);
| ^~~~
/usr/include/sys/wait.h:85:14: note: ‘wait’ declared here
85 | extern pid_t wait(int *);
| ^~~~
The use of gdb::wait was introduced in
commit 4e4dfc4728
Author: Tom de Vries <tdevries@suse.de>
Date: Fri Nov 22 17:44:29 2024 +0100
[gdb] Add gdb::wait
but obviously never tested.
Fixed by including gdbsupport/eintr.h to provide the declaration.
Tested on amd64-pc-solaris2.11 and sparcv9-sun-solaris2.11.
(cherry picked from commit d7bd319e93)
The DAP initialize request has a "linesStartAt1" option, where the
client can indicate that it prefers whether line numbers be 0-based or
1-based.
This patch implements this. I audited all the line-related code in
the DAP implementation.
Note that while a similar option exists for column numbers, gdb
doesn't handle these yet, so nothing is done here.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32468
(cherry picked from commit 8ac42dbf50)
Recent commit 6ab5d62ebc ("[gdb] Fix compilation error in event-top.c") did:
...
fd_copy (fd_set *dst, const fd_set *src, int n)
{
FD_ZERO (dst);
for (int i = 0; i < n; ++i)
- if (FD_ISSET (i, src))
+ if (FD_ISSET (i, (fd_set *)src))
...
but according to [1] only const_cast may be used to cast away constness.
Fix this by using const_cast.
Tested by rebuilding on x86_64-linux.
[1] https://en.cppreference.com/w/cpp/language/const_cast
(cherry picked from commit a189db13c4)
The previous solution used symbols that exist only in MinGW64.
Add a stub implementation of 'alarm' for mingw.org's MinGW.
(cherry picked from commit d46fdacc09)
Running selftest help_doc_invariants.
help doc broken invariant: command 'signal-event' help doc has over-long line
Self test failed: self-test failed at unittests/command-def-selftests.c:121
The reason is that doc string of 'signal-event' doesn't have
newlines at end of its line. Fix by adding newlines.
(cherry picked from commit c1023d9567)
CXX event-top.o
In file included from d:\usr\include\winsock2.h:69,
from ./../gdbsupport/gdb_select.h:30,
from event-top.c:43:
event-top.c: In function 'fd_set* fd_copy(fd_set*, const fd_set*, int)':
event-top.c:1279:22: error: invalid conversion from 'const fd_set*' to 'fd_set*' [-fpermissive]
1279 | if (FD_ISSET (i, src))
| ^
| |
| const fd_set*
d:\usr\include\winsock.h:164:50: note: initializing argument 2 of 'int __FD_ISSET(SOCKET, fd_set*)'
164 | __CRT_ALIAS int __FD_ISSET( SOCKET __fd, fd_set *__set )
| ~~~~~~~~^~~~~
Use an explicit type cast to prevent this.
* gdb/event-top.c (fd_copy): Type-cast in call to FD_ISSET.
(cherry picked from commit 6ab5d62ebc)
People, including me, had forgotten that the bfd_error_handler just
handled standard printf format strings, not MSC %I64 and suchlike.
Using PRIx64 and similar in errors does not work if the host compiler
headers define those formats as the Microsoft %I64 variety. (We
handled %ll OK, editing it to %I64 on such hosts.)
PR 32507
* bfd.c (_bfd_doprnt, _bfd_doprnt_scan): Handle %I64 and %I32
in input strings if the host defines PRId64 as "I64d".
Edit %ll to %I64 on detecting PRId64 as "I64d" rather than on
a preprocessor define.
(cherry picked from commit b38cf91f23)
Now that the GDB 16 branch has been created,
this commit bumps the version number in gdb/version.in to
16.0.90.DATE-git
For the record, the GDB 16 branch was created
from commit ee29a3c4ac.
Using $srcdir/$subdir directly doesn't work, at least not with expect
5.45, dejagnu 1.6, and an out-of-tree build (I assume it's the latter
aspect which is crucial here). Make use of load_file instead.
For PDE, "recompiling with -fPIE" just makes no sense.
For PIE, "recompiling with -fPIE" makes sense for unresolvable absolute
relocs, but not unresolveable PC-relative relocs: if the reloc is
already PC-relative, the problem is not the reloc is PC-relative or
absolute, but the reloc is not applicable for external symbols.
If we hit an unresolvable reloc in PDE or an unresolvable PC-relative
reloc in PIE, it means the programmer has somehow wrongly instructed the
compiler to treat external symbols as local symbols. A misuse of
-mdirect-extern-access can cause the issue, so we can suggest
-mno-direct-extern-access. And in all cases (DSO/PIE/PDE) a mismatching
symbol visibility can also cause the issue, so we should also suggest to
check the visibility.
Signed-off-by: Xi Ruoyao <xry111@xry111.site>
In a static PIE, undefined weak symbols should be just resolved to
runtime address 0, like those symbols with non-default visibility. This
was silently broken in all prior Binutils releases with "-static-pie
-mdirect-extern-access":
$ cat t.c
int x (void) __attribute__ ((weak));
int
main (void)
{
__builtin_printf("%p\n", x);
}
$ gcc t.c -static-pie -mdirect-extern-access
$ ./a.out
0x7ffff1d64000
Since commit 4cb77761d6 ("LoongArch: Check PC-relative relocations for
shared libraries), the situation has been improved: the linker errors
out instead of silently producing a wrong output file.
But logically, using -mdirect-extern-access for a static PIE perfectly
makes sense, and we should not prevent that even if the programmer uses
weak symbols. Linux kernel is such an example, and Linux < 6.10 now
fails to build with Binutils trunk. (The silent breakage with prior
Binutils releases was "benign" due to some blind luck.)
While since the 6.10 release Linux has removed those potentially
undefined weak symbols (due to performance issue), we still should
support weak symbols in -mdirect-extern-access -static-pie and unbreak
building old kernels.
Link: https://lore.kernel.org/loongarch/20241206085810.112341-1-chenhuacai@loongson.cn/
Signed-off-by: Xi Ruoyao <xry111@xry111.site>
An undefined weak hidden/protect symbol should be resolved to runtime
address 0, but we were actually resolving it to link-time address 0. So
in PIE or DSO the runtime address would be incorrect.
Fix the issue by rewriting pcalau12i to lu12i.w, and pcaddi to addi.w.
The latter does not always work because the immediate field of addi.w is
narrower, report an error in the case the addend is too large.
Signed-off-by: Xi Ruoyao <xry111@xry111.site>
This testcase:
.irp x x x "
.end #
.endr
manages to access lex[EOF].
xxx: Warning: end of file in string; '"' inserted
xxx:1: Warning: missing closing `"'
gas/app.c:844:16: runtime error: index -1 out of bounds for type 'char [256]
Following that there is a buffer overflow.
Stop this happening, and in other similar places, by checking for EOF.
