Luis Machado [Fri, 28 Feb 2025 09:36:42 +0000 (09:36 +0000)]
Fix gdbserver crashes on SVE/SME-enabled systems
Commit 51e6b8cfd649013ae16a3d00f1451b2531ba6bc9 fixed a
regression for SVE/SME registers on gdb's side by using a <= comparison for
regcache's raw_compare assertion check. We seem to have failed to do the same
for gdbserver's raw_compare counterpart.
With the code as it is, I'm seeing a lot of crashes for gdbserver on a machine
with SVE enabled. For instance, with the following invocation:
make check-gdb RUNTESTFLAGS="--target_board=native-gdbserver" TESTS=gdb.base/break.exp
Running /work/builds/binutils-gdb/gdb/testsuite/../../../../repos/binutils-gdb/gdb/testsuite/gdb.base/break.exp ...
FAIL: gdb.base/break.exp: test_break: run until function breakpoint
FAIL: gdb.base/break.exp: test_break: run until breakpoint set at a line number (the program is no longer running)
FAIL: gdb.base/break.exp: test_break: run until file:function(6) breakpoint (the program is no longer running)
FAIL: gdb.base/break.exp: test_break: run until file:function(5) breakpoint (the program is no longer running)
FAIL: gdb.base/break.exp: test_break: run until file:function(4) breakpoint (the program is no longer running)
FAIL: gdb.base/break.exp: test_break: run until file:function(3) breakpoint (the program is no longer running)
FAIL: gdb.base/break.exp: test_break: run until file:function(2) breakpoint (the program is no longer running)
FAIL: gdb.base/break.exp: test_break: run until file:function(1) breakpoint (the program is no longer running)
FAIL: gdb.base/break.exp: test_break: run until quoted breakpoint (the program is no longer running)
FAIL: gdb.base/break.exp: test_break: run until file:linenum breakpoint (the program is no longer running)
FAIL: gdb.base/break.exp: test_break: breakpoint offset +1
FAIL: gdb.base/break.exp: test_break: step onto breakpoint (the program is no longer running)
FAIL: gdb.base/break.exp: test_break: setting breakpoint at }
FAIL: gdb.base/break.exp: test_break: continue to breakpoint at } (the program is no longer running)
FAIL: gdb.base/break.exp: test_no_break_on_catchpoint: runto: run to main
FAIL: gdb.base/break.exp: test_break_nonexistent_line: runto: run to main
FAIL: gdb.base/break.exp: test_break_default: runto: run to main
FAIL: gdb.base/break.exp: test_break_silent_and_more: runto: run to main
FAIL: gdb.base/break.exp: test_break_line_convenience_var: runto: run to main
FAIL: gdb.base/break.exp: test_break_user_call: runto: run to main
FAIL: gdb.base/break.exp: test_finish_arguments: runto: run to main
FAIL: gdb.base/break.exp: test_next_with_recursion: kill program
FAIL: gdb.base/break.exp: test_next_with_recursion: run to factorial(6)
FAIL: gdb.base/break.exp: test_next_with_recursion: continue to factorial(5) (the program is no longer running)
FAIL: gdb.base/break.exp: test_next_with_recursion: backtrace from factorial(5)
FAIL: gdb.base/break.exp: test_next_with_recursion: next to recursive call (the program is no longer running)
FAIL: gdb.base/break.exp: test_next_with_recursion: next over recursive call (the program is no longer running)
FAIL: gdb.base/break.exp: test_next_with_recursion: backtrace from factorial(5.1)
FAIL: gdb.base/break.exp: test_next_with_recursion: continue until exit at recursive next test (the program is no longer running)
FAIL: gdb.base/break.exp: test_break_optimized_prologue: run until function breakpoint, optimized file
FAIL: gdb.base/break.exp: test_break_optimized_prologue: run until breakpoint set at small function, optimized file (the program is no longer running)
FAIL: gdb.base/break.exp: test_rbreak_shlib: rbreak junk
Adjusting the regcache raw_compare assertion check to use <= fixes
the problem on aarch64-linux on a SVE-capable system.
This patch also adds a simple selftest to gdbserver that validates this
particular case by simulating a raw_compare operation.
This commit allows the escape sequences \x1b[39m and \x1b[49m, which
select the default foreground and background colours respectively, to
work correctly.
This fix is just a small part of the above commit. Only these two
changes are required to fix this bug. As we are currently preparing
for a 16.3 release, I don't think we should be pulling in the whole of
the above commit.
Craig Blackmore [Thu, 13 Feb 2025 15:53:34 +0000 (15:53 +0000)]
gdb: Fix assertion failure when inline frame #0 is duplicated
Modifying inline-frame-cycle-unwind.exp to use `bt -no-filters` produces
the following incorrect backtrace:
#0 inline_func () at .../gdb/gdb/testsuite/gdb.base/inline-frame-cycle-unwind.c:49
#1 normal_func () at .../gdb/gdb/testsuite/gdb.base/inline-frame-cycle-unwind.c:32
#2 0x000055555555517f in inline_func () at .../gdb/gdb/testsuite/gdb.base/inline-frame-cycle-unwind.c:50
#3 normal_func () at .../gdb/gdb/testsuite/gdb.base/inline-frame-cycle-unwind.c:32
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) FAIL: gdb.base/inline-frame-cycle-unwind.exp: cycle at level 1: backtrace when the unwind is broken at frame 1
The expected output, which we get with `bt`, is:
#0 inline_func () at .../gdb/gdb/testsuite/gdb.base/inline-frame-cycle-unwind.c:49
#1 normal_func () at .../gdb/gdb/testsuite/gdb.base/inline-frame-cycle-unwind.c:32
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) PASS: gdb.base/inline-frame-cycle-unwind.exp: cycle at level 1: backtrace when the unwind is broken at frame 1
The cycle checking in `get_prev_frame_maybe_check_cycle` relies on newer
frame ids having already been computed and stashed. Unlike other
frames, frame #0's id does not get computed immediately.
The test passes with `bt` because when applying python frame filters,
the call to `bootstrap_python_frame_filters` happens to compute the id
of frame #0. When `get_prev_frame_maybe_check_cycle` later tries to
stash frame #2's id, the cycle is detected.
The test fails with `bt -no-filters` because frame #0's id has not been
stashed by the time `get_prev_frame_maybe_check_cycle` tries to stash
frame #2's id which succeeds and the cycle is only detected later when
trying to stash frame #4's id. Doing `stepi` after the incorrect
backtrace would then trigger an assertion failure when trying to stash
frame #0's id because it is a duplicate of #2's already stashed id.
In `get_prev_frame_always_1`, if this_frame is inline frame 0, then
compute and stash its frame id before returning the previous frame.
This ensures that the id of inline frame 0 has been stashed before
`get_prev_frame_maybe_check_cycle` is called on older frames.
The test case has been updated to run both `bt` and `bt -no-filters`.
Co-authored-by: Andrew Burgess <aburgess@redhat.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32757
Tom de Vries [Sat, 15 Mar 2025 12:17:36 +0000 (13:17 +0100)]
[gdb/tdep] Rewrite i386_canonicalize_syscall
On openSUSE Tumbleweed x86_64, with target board unix/-m32 and test-case
gdb.reverse/recvmsg-reverse.exp, I run into:
...
(gdb) continue^M
Continuing.^M
Process record and replay target doesn't support syscall number 360^M
Process record: failed to record execution log.^M
^M
Program stopped.^M
0xf7fc5575 in __kernel_vsyscall ()^M
(gdb) FAIL: $exp: continue to breakpoint: marker2
...
The syscall number 360 in i386 is for syscall socketpair, as we can see in
arch/x86/entry/syscalls/syscall_32.tbl:
...
<number> <abi> <name> <entry point>
360 i386 socketpair sys_socketpair
...
Function i386_canonicalize_syscall assumes that any syscall below 500 maps to
an identically valued enum in enum gdb_syscall:
...
static enum gdb_syscall
i386_canonicalize_syscall (int syscall)
{
enum { i386_syscall_max = 499 };
However, that's not the case. The value of gdb_sys_socketpair is not 360,
but 512:
...
enum gdb_syscall {
...
gdb_sys_getrandom = 355,
gdb_sys_statx = 383,
...
gdb_sys_socketpair = 512,
...
Consequently, when record_linux_system_call is called with
syscall == i386_canonicalize_syscall (360), we hit the default case here:
....
switch (syscall)
{
...
default:
gdb_printf (gdb_stderr,
_("Process record and replay target doesn't "
"support syscall number %d\n"), syscall);
return -1;
break;
}
...
rather than hitting the case for gdb_sys_socketpair.
I initially wrote a trivial fix for this, changing the value of
gdb_sys_socketpair to 360. However, Andreas Schwab pointed out that there are
other functions (ppc_canonicalize_syscall and s390_canonicalize_syscall) that
make assumptions about specific values of enum gdb_syscall, and fixing this
for i386 may break things for ppc or s390.
So instead, I decided to rewrite i386_canonicalize_syscall to match the
approach taken in aarch64_canonicalize_syscall, which allows
gdb_sys_socketpair to keep the same value.
So, fix this by:
- adding a new table file gdb/i386-syscalls.def, using a SYSCALL entry for
each syscall, generated from arch/x86/entry/syscalls/syscall_32.tbl,
- using gdb/i386-syscalls.def to define enum i386_syscall, and
- using macros SYSCALL_MAP, SYSCALL_MAP_RENAME and UNSUPPORTED_SYSCALL_MAP to
define the mapping from enum i386_syscall to enum gdb_syscall in
i386_canonicalize_syscall.
I've created the mapping as follows:
- I used arch/x86/entry/syscalls/syscall_32.tbl to generate an initial mapping
using SYSCALL_MAP for each syscall,
- I attempted to compile this and used the compilation errors about
non-existing gdb_sys_ values to change those entries to
UNSUPPORTED_SYSCALL_MAP, which got me a compiling version,
- I reviewed the UNSUPPORTED_SYSCALL_MAP entries, changing to
SYSCALL_MAP_RENAME where necessary,
- I then reviewed syscalls below 500 that mapped to a gdb_syscall value below
500, but not the same, and fixed those using SYSCALL_MAP_RENAME, and
- reviewed the mapping for gdb_syscall entries >= 500.
On the resulting mapping, I was able to do the following sanity check:
...
for (int i = 0; i < 500; ++i)
{
int res = i386_canonicalize_syscall (i);
if (res == i)
continue;
if (res == -1)
continue;
if (res >= 500)
continue;
gdb_assert_not_reached ("");
}
}
...
to make sure that any syscall below 500 either:
- maps to the same number,
- is unsupported, or
- maps to a number >= 500.
Coming back to our original problem, the socket pair syscall is addressed by
an entry:
...
SYSCALL_MAP (socketpair);
...
which maps i386_sys_socketpair (360) to gdb_sys_socketpair (512).
Tested on x86_64-linux with target board unix/-m32.
Tom de Vries [Thu, 13 Mar 2025 10:15:05 +0000 (11:15 +0100)]
[gdb/record] Fix out-of-bounds write in aarch64_record_asimd_load_store
After compiling gdb with -fstack-protector-all, and running test-case
gdb.reverse/getrandom.exp on aarch64-linux, we run into
"Stack smashing detected" in function aarch64_record_asimd_load_store.
This is reported in PR record/32784.
This happens due to an out-of-bounds write to local array record_buf_mem:
...
uint64_t record_buf_mem[24];
...
when recording insn:
...
B+>0xfffff7ff4d10 st1 {v0.16b-v3.16b}, [x0]
...
We can fix this by increasing the array size to 128, but rather than again
hardcoding a size, reimplement record_buf_mem as std::vector.
The problem is that dwarf2_per_cu objects created in the
read_cutu_die_from_dwo code path never have their DWARF version set. A
seemingly obvious solution would be to add a call to
dwarf2_per_cu::set_version in there (there's a patch in the referenced
PR that does that). However, this comment in
read_comp_units_from_section is a bit scary:
/* Init this asap, to avoid a data race in the set_version in
cutu_reader::cutu_reader (which may be run in parallel for the cooked
index case). */
this_cu->set_version (cu_header.version);
I don't know if a DWO file can be read while the cooked indexer runs, so
if it would be a problem here, but I prefer to be safe than sorry. This
patch side-steps the problem by deleting the DWARF version from
dwarf2_per_cu.
The only users of dwarf2_per_cu::version are the loclists callbacks in
`loc.c`. Add the DWARF version to dwarf2_loclist_baton and modify those
callbacks to get the version from there instead. Initialize that new
field in fill_in_loclist_baton.
I like this approach because there is no version field that is possibly
unset now.
I wasn't keen on doing this at first because I thought it would waste
space, but the dwarf2_loclist_baton has 7 bytes of padding at the end
anyway, so we might as well use that.
Cc: Ricky Zhou <ricky@rzhou.org> Cc: Tom de Vries <tdevries@suse.de> Cc: Tom Tromey <tom@tromey.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32309
Change-Id: I30d4ede7d67da5d80ff65c6122f5868e1098ec52 Approved-By: Tom Tromey <tom@tromey.com>
(cherry picked from commit f62cf22157cf527f1cc5c91854b1be3373024d4a)
Brandon Belew [Sun, 9 Mar 2025 04:15:07 +0000 (08:15 +0400)]
Fix segfault if target_fileio_read_alloc fails
Check for target_fileio_read_alloc failure in linux_fill_prpsinfo
before dereferencing buffer. This fixes a segfault in the 'gcore'
command when attached to certain remote targets.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32441 Approved-By: Andrew Burgess <aburgess@redhat.com>
(cherry picked from commit cbc6950a6603e184ebc6671f2c252a56013b07c2)
Andrew Burgess [Wed, 5 Feb 2025 20:12:03 +0000 (20:12 +0000)]
gdb/tui: use wrefresh if output is not surpressed
Recent work in the TUI has improved GDB's use of the curses
wnoutrefresh and doupdate mechanism, which improves performance by
batching together updates and then doing a single set of writes to the
screen when doupdate is finally called.
The tui_batch_rendering type is a RAII class which, in its destructor,
calls doupdate to send the batched updates to the screen.
However, if there is no tui_batch_rendering active on the call stack
then any wnoutrefresh calls will remain batched but undisplayed until
the next time doupdate happens to be called.
This problem can be seen in PR gdb/32623. When an inferior is started
the 'Starting program' message is not immediately displayed to the
user.
The 'Starting program' message originates from run_command_1 in
infcmd.c, the message is sent to the current_uiout, which will be the
TUI ui_out. After the message is sent, ui_out::flush() is called,
here's the backtrace when that happens:
#0 tui_file::flush (this=0x36e4ab0) at ../../src/gdb/tui/tui-file.c:42
#1 0x0000000001004f4b in pager_file::flush (this=0x36d35f0) at ../../src/gdb/utils.c:1531
#2 0x0000000001004f71 in gdb_flush (stream=0x36d35f0) at ../../src/gdb/utils.c:1539
#3 0x00000000006975ab in cli_ui_out::do_flush (this=0x35a50b0) at ../../src/gdb/cli-out.c:250
#4 0x00000000009fd1f9 in ui_out::flush (this=0x35a50b0) at ../../src/gdb/ui-out.h:263
#5 0x00000000009f56ad in run_command_1 (args=0x0, from_tty=1, run_how=RUN_NORMAL) at ../../src/gdb/infcmd.c:449
#6 0x00000000009f599a in run_command (args=0x0, from_tty=1) at ../../src/gdb/infcmd.c:511
And if we check out tui_file::flush (tui-file.c) we can see that this
just calls tui_win_info::refresh_window(), which in turn, just uses
wnoutrefresh to batch any pending output.
The problem is that, in the above backtrace, there is no
tui_batch_rendering active, and so there will be no doupdate call to
flush the output to the screen.
We could add a tui_batch_rendering into tui_file::flush. And
tui_file::write. And tui_file::puts .....
... but that all seems a bit unnecessary. Instead, I propose that
tui_win_info::refresh_window() should be changed. If suppress_output
is true (i.e. a tui_batch_rendering is active) then we should continue
to call wnoutrefresh(). But if suppress_output is false, meaning that
no tui_batch_rendering is in place, then we should call wrefresh(),
which immediately writes the output to the screen.
Testing but PR gdb/32623 was a little involved. We need to 'run' the
inferior and check for the 'Starting program' message. But DejaGNUU
can only check for the message once it knows the message should have
appeared. But, as the bug is that output is not displayed, we don't
have any output hints that the inferior is started yet...
In the end, I have the inferior create a file in the test's output
directory. Now DejaGNU can send the 'run' command, and wait for the
file to appear. Once that happens, we know that the 'Starting
program' message should have appeared.
Tom de Vries [Fri, 7 Feb 2025 16:06:30 +0000 (17:06 +0100)]
[gdb/corefiles] Fix segfault in core_target_open
On x86_64-freebsd, with test-case gdb.arch/i386-biarch-core.exp I run into a
segfault here in corelow.c:core_target_open:
...
{
gdb::unique_xmalloc_ptr<char> failing_command = make_unique_xstrdup
(bfd_core_file_failing_command (current_program_space->core_bfd ()));
if (failing_command != nullptr)
gdb_printf (_("Core was generated by `%s'.\n"),
failing_command.get ());
}
...
where bfd_core_file_failing_command returns nullptr, so the segfault happens
somewhere during "strdup (nullptr)".
There doesn't seem to be a need to make a copy of the string, so fix this by
dropping the make_unique_xstrdup.
Tested on x86_64-linux.
Tested the test-case on x86_64-freebsd.
Approved-By: Tom Tromey <tom@tromey.com>
PR corefiles/32634
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32634
Simon Marchi [Wed, 29 Jan 2025 15:45:31 +0000 (10:45 -0500)]
gdb: include cli/cli-style.h in darwin-nat.c
PR 32610 says:
File gdb/darwin-nat.c is missing an #include statement of
"cli/cli-style.h". It is needed because there is a reference to class
object command_style in the .c file.
I'm not able to build-test this change (I only have access to arm64
macos machines, which GDB doesn't support yet), but I don't think I'm
doing things worse by adding this.
Tom de Vries [Wed, 29 Jan 2025 08:02:21 +0000 (09:02 +0100)]
[gdb/tui] Fix assert in tui_source_window_base::refresh_window
Say we use the executable of test-case gdb.tui/tui-missing-src.exp like this:
...
$ gdb.sh -q -tui outputs/gdb.tui/tui-missing-src/tui-missing-src \
-ex "b f2"\
-ex run
...
(from a directory not containing a file called main.c to make sure that the
missing source stays missing) and then issue finish:
...
(gdb) finish
Run till exit from #0 f2 (x=4)
at f2.c:5
0x0000000000400570 in main ()
at main.c:7
Value returned is $1 = 13
(gdb)
...
and use control-<minus> to decrease the font size (IOW increase the $LINES and
$COLUMNS) on the terminal, we get:
...
gdb/tui/tui-winsource.c:340: internal-error: refresh_window: \
Assertion `pad_x + view_width <= pad_width || m_pad.get () == nullptr' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
...
The tui_source_window_base class has variable m_pad which keeps track of a
curses pad that is used to display the source code or disassembly efficiently.
The assert in tui_source_window_base::refresh_window triggers while preparing
to display part of the pad.
The problem is that the window is in a state in which the pad is not used,
because m_content.empty () == true. Instead, it simply shows
"[ No Source Available ]".
Fix this by bailing out of tui_source_window_base::refresh_window before
accessing the m_pad variable, if m_content.empty () == true.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
PR tui/32592
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32592
highlighted the following issue with GDB's 'x' packet implementation.
Unfortunately, LLDB also has an 'x' packet, but their implementation
is different to GDB's and so targets that have implemented LLDB's 'x'
packet are incompatible with GDB.
The above thread is specifically about the 'rr' tool, but there could
be other remote targets out there that have this problem.
The difference between LLDB and GDB is that GDB expects a 'b' prefix
on the reply data, while LLDB does not. The 'b' is important as it
allows GDB to distinguish between an empty reply (which will be a 'b'
prefix with no trailing data) and an unsupported packet (which will be
a completely empty packet). It is not clear to me how LLDB
distinguishes these two cases.
I propose that we add a new feature 'binary-upload' which can be
reported by a stub in its qSupported reply. By default this feature
is "off", meaning GDB will not use the 'x' packet unless a stub
advertises this feature.
I have updated gdbserver to send 'binary-upload+', and when I examine
the gdbserver log I can see this feature being sent back, and then GDB
will use the 'x' packet.
When connecting to an older gdbserver, the feature is not sent, and
GDB does not try to use the 'x' packet at all.
I also built the latest version of `rr` and tested using current HEAD
of master, where I see problems like this:
(rr) x/10i main
0x401106 <main>: Cannot access memory at address 0x401106
Then tested using this patched version of GDB, and now I see:
There is still a problem building the bfd docs from a release tar
file.
As the release tar file contains the pre-generated .texi files we
expect the bfd/doc build stage to symlink to the pre-existing .texi
files in the source tree.
However, this is still not working as expected if $(srcdir) is
relative. The problem is this line in REGEN_TEXI:
test -e $$texi || test ! -f $(srcdir)/$$texi || $(LN_S) $(srcdir)/$$texi $$texi; \
This is executed from the build/bfd/ directory, so if $(srcdir) is
relative, then this will get you from the bfd/ directory in the build
tree to the corresponding bfd/ directory in the src tree. However,
the symlink is created in the bfd/doc/ build directory. The relative
path will then fail to take you to the bfd/ directory in the src
tree.
Fix this by using $(abs_srcdir) when creating the symlink.
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 3470a0e144df6c01f8479fa649f43aa907936e7e 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>
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.
projects / thirdparty / binutils-gdb.git / log
