I noticed that we didn't have many tests of the tui 'focus' command,
so I started adding some. This exposed a bug in GDB; we are able to
focus windows that should not be focusable, e.g. the 'status' window.
This is harmless until we then do 'focus next' or 'focus prev', along
this code path we assert that the currently focused window is
focusable, which obviously, is not always true, so GDB fails with an
assertion error.
The fix is simple; add a check to the tui_set_focus_command function
to ensure that the selected window is focusable. If it is not then an
error is thrown. The new tests I've added cover this case.
Following on from the previous commit, in this commit I am updating
the test script gdb.tui/tui-nl-filtered-output.exp to take account of
the changes in commit:
commit 9162a27c5f5828240b53379d735679e2a69a9f41
Date: Tue Nov 13 11:59:03 2018 -0700
Change gdb test suite's TERM setting
In the above commit the TERM environment variable was changed to be
'dumb' by default, which means that tests, that previously activated
tui mode, no longer do unless TERM is set to 'ansi'.
As the gdb.tui/tui-nl-filtered-output.exp script didn't do this, the
test stopped working. As the expect patterns in this script were
pretty generic no tests actually started failing, and we never
noticed.
In this commit I update the test script to correctly activate our
terminal emulator, the test continues to pass after this update, but
now we are testing in tui mode.
Following on from the previous commit, in this commit I am updating
the test script gdb.tui/tui-disasm-long-lines.exp to take account of
the changes in commit:
commit 9162a27c5f5828240b53379d735679e2a69a9f41
Date: Tue Nov 13 11:59:03 2018 -0700
Change gdb test suite's TERM setting
In the above commit the TERM environment variable was changed to be
'dumb' by default, which means that tests, that previously activated
tui mode, no longer do unless TERM is set to 'ansi'.
As the gdb.tui/tui-disasm-long-lines.exp script didn't do this, the
test stopped working. As the expect patterns in this script were
pretty generic no tests actually started failing, and we never
noticed.
In this commit I update the script to use Term::clean_restart, which
correctly sets TERM to 'ansi'. I've also added a check that the asm
box does appear on the screen, which should indicate that tui mode has
correctly activated.
However, I also notice that GDB doesn't appear to fully work
correctly. The test should display the disassembly for the test
program, but it doesn't.
The test is trying to disassemble some code that (deliberately) uses a
very long symbol name, this eventually results in GDB entering
tui_source_window_base::show_source_content and trying to allocate an
ncurses pad in order to hold the current page of disassembler output.
Unfortunately, due to the very long line, the call to newpad fails,
meaning that tui_source_window_base::m_pad is nullptr. Luckily non of
the following calls appear to crash when passed a nullptr, however,
all the output that is written to the pad is lost, which is why we
don't see any assembly code written to the screen.
As the test history indicates that the script was originally checking
for a crash in GDB when the long identifier was encountered, I think
there is value in just leaving the test as it is for now, I have a fix
for the issue of the newpad call failing, which I'll post in a follow
up commit later.
In passing I noticed that the gdb.tui/tui-layout.exp test script was a
little strange, it tests the layout command multiple times, but never
sets up our ANSI terminal emulator, so every layout command fails with
a message about the terminal lacking the required abilities.
It turns out that this was caused by this commit:
commit 9162a27c5f5828240b53379d735679e2a69a9f41
Date: Tue Nov 13 11:59:03 2018 -0700
Change gdb test suite's TERM setting
This was when we changed the testsuite to set the TERM environment
variable to "dumb" by default.
After this, any tui test that didn't set the terminal mode back to
'ansi' would fail to activate tui mode.
For the tui-layout.exp test it just so happens that the test patterns
are generic enough that the test continued to pass, even after this
change.
In this commit I have updated the test so we now check the layout
command both with a 'dumb' terminal and with the 'ansi' terminal.
When testing with the 'ansi' terminal, I have some limited validation
that GDB correctly entered tui mode.
I figured that it is probably worth having at least one test in the
test suite that deliberately tries to enter tui mode in a dumb
terminal, it would be sad if we one day managed to break GDB such that
this caused a crash, and never noticed.
The previous commit touched the source file for the test script
gdb.cp/cpcompletion.exp. This source file is called pr9594.cc. The
source file is only used by the one test script.
This commit renames the source file to cpcompletion.cc to match the
test script, this is more inline with how we name source files these
days.
Spotted in gdb.cp/cpcompletion.exp that we could replace some uses of
gdb_test with test_gdb_complete_unique, this will extend the
completion testing to check tab-completion as well as completion using
the 'complete' command in some additional cases.
'make pdf' in libsframe shows some warnings, some of which (especially
the Overfull warnings) are causing undesirable effects on the rendered
output. Few examples of the warnings:
Underfull \hbox (badness 10000) in paragraph at lines 406--407
@texttt pauth_
Underfull \hbox (badness 10000) in paragraph at lines 407--410
@textrm Specify which key is used for signing the return
...
Overfull \hbox (2.0987pt too wide) in paragraph at lines 412--413
@texttt fdetype[]|
...
Overfull \hbox (28.87212pt too wide) in paragraph at lines 446--447
@textrm SFRAME[]FDE[]TYPE[]PCMASK|
...
This patch adjusts column widths of the affected cells to fix a subset
of these warnings. For the rest of the warnings, use explicit newline
command to fix them.
libsframe/
* doc/sframe-spec.texi: Fix various underfull and overfull
warnings.
ld PR 29998
* pe-dll.c (generate_reloc): Handle sections
with no assigned output section.
Terminate early of there are no relocs to put
in the .reloc section.
(pe_exe_fill_sections): Do not emit an empty
.reloc section.
bfd * cofflink.c (_bfd_coff_generic_relocate_section):
Add an assertion that the output section is set
for defined, global symbols.
When building GDB with clang 16, I got this,
CXX maint.o
maint.c:1045:23: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
m_space_enabled = 1;
^ ~
maint.c:1057:22: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
m_time_enabled = 1;
^ ~
maint.c:1073:24: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
m_symtab_enabled = 1;
^ ~
3 errors generated.
Work around this by using bool bitfields instead.
Tested by rebuilding on x86_64-linux with clang 16 and gcc 12.
Approved-By: Tom Tromey <tom@tromey.com>
This fixes the test failures introduced by 87a5cf5c, by changing the
default subsystem for arm-pe from 9 (IMAGE_SUBSYSTEM_WINDOWS_CE_GUI) to
2 (IMAGE_SUBSYSTEM_WINDOWS_GUI), which matches what happens with other
PE targets.
As far as I can tell there's no working modern Windows CE toolchain
knocking about anyway, so this change shouldn't inconvenience anyone.
This patch adds support for the .secidx directive and its corresponding
relocation to aarch64-w64-mingw32. As with x86, this is a two-byte LE
integer which gets filled in with the 1-based index of the output
section that a symbol ends up in.
This is needed for PDBs, which represent addresses as a .secrel32,
.secidx pair.
The test is substantially the same as for amd64, but with changes made
for padding and alignment.
Consider the test-case test.c, compiled without debug info:
...
void
foo (const char *s)
{
}
int
main (void)
{
foo ("foo");
return 0;
}
...
Disassembly of foo:
...
0000000000400564 <foo>:
400564: d10043ff sub sp, sp, #0x10
400568: f90007e0 str x0, [sp, #8]
40056c: d503201f nop
400570: 910043ff add sp, sp, #0x10
400574: d65f03c0 ret
...
Now, let's do "info frame" at each insn in foo, as well as printing $sp
and $x29 (and strip the output of info frame to the first line, for brevity):
...
$ gdb -q a.out
Reading symbols from a.out...
(gdb) b *foo
Breakpoint 1 at 0x400564
(gdb) r
Starting program: a.out
Breakpoint 1, 0x0000000000400564 in foo ()
(gdb) display /x $sp
1: /x $sp = 0xfffffffff3a0
(gdb) display /x $x29
2: /x $x29 = 0xfffffffff3a0
(gdb) info frame
Stack level 0, frame at 0xfffffffff3a0:
(gdb) si
0x0000000000400568 in foo ()
1: /x $sp = 0xfffffffff390
2: /x $x29 = 0xfffffffff3a0
(gdb) info frame
Stack level 0, frame at 0xfffffffff3a0:
(gdb) si
0x000000000040056c in foo ()
1: /x $sp = 0xfffffffff390
2: /x $x29 = 0xfffffffff3a0
(gdb) info frame
Stack level 0, frame at 0xfffffffff3a0:
(gdb) si
0x0000000000400570 in foo ()
1: /x $sp = 0xfffffffff390
2: /x $x29 = 0xfffffffff3a0
(gdb) info frame
Stack level 0, frame at 0xfffffffff3a0:
(gdb) si
0x0000000000400574 in foo ()
1: /x $sp = 0xfffffffff3a0
2: /x $x29 = 0xfffffffff3a0
(gdb) info frame
Stack level 0, frame at 0xfffffffff3b0:
pc = 0x400574 in foo; saved pc = 0x40058c
(gdb) si
0x000000000040058c in main ()
1: /x $sp = 0xfffffffff3a0
2: /x $x29 = 0xfffffffff3a0
...
The "frame at" bit lists 0xfffffffff3a0 except at the last insn, where it
lists 0xfffffffff3b0.
The frame address is calculated here in aarch64_make_prologue_cache_1:
...
unwound_fp = get_frame_register_unsigned (this_frame, cache->framereg);
if (unwound_fp == 0)
return;
cache->prev_sp = unwound_fp + cache->framesize;
...
For insns after the prologue, we have cache->framereg == sp and
cache->framesize == 16, so unwound_fp + cache->framesize gives the wrong
answer once sp has been restored to entry value by the before-last insn.
Fix this by detecting the situation that the sp has been restored.
This fixes PRs tdep/30010 and tdep/30011.
This also fixes the aarch64 FAILs in gdb.reverse/solib-precsave.exp and
gdb.reverse/solib-reverse.exp I reported in PR gdb/PR29721.
Tested on aarch64-linux.
PR tdep/30010
PR tdep/30011
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30010
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30011
One purpose of the gdb.base/unwind-on-each-insn.exp test-case is to test the
architecture-specific unwinders on foo, so unwind-on-each-insn-foo.c is
compiled with nodebug, to prevent the dwarf unwinders from taking effect.
For for instance gcc x86_64 though, -fasynchronous-unwind-tables is enabled by
default, generating an .eh_frame section contribution which might enable the
dwarf unwinders and bypass the architecture-specific unwinders.
Currently, that happens to be not the case due to the current implementation
of epilogue_unwind_valid, which assumes that in absence of debug info proving
that the compiler is gcc >= 4.5.0, the .eh_frame contribution is invalid.
That may change though, see PR30028, in which case
gdb.base/unwind-on-each-insn.exp stops being a regression test for commit
49d7cd733a7 ("Change calculation of frame_id by amd64 epilogue unwinder").
Fix this by making sure that we don't use .eh_frame info regardless of
epilogue_unwind_valid, simply by not generating it using
-fno-asynchronous-unwind-tables.
Tested on x86_64-linux, target boards unix/{-m64,-m32}, using compilers
gcc 7.5.0 and clang 13.0.1.
In test-case gdb.base/unwind-on-each-insn.exp, we try to determine the last
disassembled insn in function foo.
This in it self is fragile, as demonstrated by commit 91836f41e20 ("Powerpc
fix for gdb.base/unwind-on-each-insn.exp").
The use of the last disassembled insn in the test-case is to stop stepping in
foo once reaching it.
However, the intent is to stop stepping just before returning to main.
There is no guarantee that the last disassembled insn:
- is actually executed
- is executed just before returning to main
- is executed only once.
Fix this by simplying the test-case to continue stepping till stepping out of
foo.
Tested on x86_64-linux.
When running test-case gdb.base/frame-view.exp, I see:
...
gdb compile failed, ld: frame-view0.o: in function `main':
frame-view.c:73: undefined reference to `pthread_create'
ld: frame-view.c:76: undefined reference to `pthread_join'
collect2: error: ld returned 1 exit status
UNTESTED: gdb.base/frame-view.exp: failed to prepare
...
Fix this by adding pthreads to the compilation flags.
Tested on x86_64-linux.
If objdump is used with both --disassemble=symbol and --reloc options
skip relocations that have addresses before the symbol, so that they
are not displayed.
The test suite reports several path names in tests. I couldn't find
most of these, and I suspect they are false reports, but I did manage
to locate one. This one is probably harmless, as I think the path
does not vary; but it's also easy to fix and suppress one warning.
I noticed a weird-looking bit of code in gdb.btrace/enable.exp that is
left over from an earlier change. This patch moves the "!" inside the
braces, where it belongs.
This is the second step of making frame_info_ptr automatic, reinflate on
demand whenever trying to obtain the wrapper frame_info pointer, either
through the get method or operator->. Make the reinflate method
private, it is used as a convenience method in those two.
Add an "is_null" method, because it is often needed to know whether the
frame_info_ptr wraps an frame_info or is empty.
Make m_ptr mutable, so that it's possible to reinflate const
frame_info_ptr objects. Whether m_ptr is nullptr or not does not change
the logical state of the object, because we re-create it on demand. I
believe this is the right use case for mutable.
Change-Id: Icb0552d0035e227f81eb3c121d8a9bb2f9d25794
Reviewed-By: Bruno Larsen <blarsen@redhat.com>
This is the first step of making frame_info_ptr automatic. Remove the
frame_info_ptr::prepare_reinflate method, move that code to the
constructor.
Change-Id: I85cdae3ab1c043c70e2702e7fb38e9a4a8a675d8
Reviewed-By: Bruno Larsen <blarsen@redhat.com>
This patch teaches frame_info_ptr to reinflate user-created frames
(frames created through create_new_frame, with the "select-frame view"
command).
Before this patch, frame_info_ptr doesn't support reinflating
user-created frames, because it currently reinflates by getting the
current target frame (for frame 0) or frame_find_by_id (for other
frames). To reinflate a user-created frame, we need to call
create_new_frame, to make it lookup an existing user-created frame, or
otherwise create one.
So, in prepare_reinflate, get the frame id even if the frame has level
0, if it is user-created. In reinflate, if the saved frame id is user
create it, call create_new_frame.
In order to test this, I initially enhanced the gdb.base/frame-view.exp
test added by the previous patch by setting a pretty-printer for the
type of the function parameters, in which we do an inferior call. This
causes print_frame_args to not reinflate its frame (which is a
user-created one) properly. On one machine (my Arch Linux one), it
properly catches the bug, as the frame is not correctly restored after
printing the first parameter, so it messes up the second parameter:
frame
#0 baz (z1=hahaha, z2=<error reading variable: frame address is not available.>) at /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/frame-view.c:40
40 return z1.m + z2.n;
(gdb) FAIL: gdb.base/frame-view.exp: with_pretty_printer=true: frame
frame
#0 baz (z1=hahaha, z2=<error reading variable: frame address is not available.>) at /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/frame-view.c:40
40 return z1.m + z2.n;
(gdb) FAIL: gdb.base/frame-view.exp: with_pretty_printer=true: frame again
However, on another machine (my Ubuntu 22.04 one), it just passes fine,
without the appropriate fix. I then thought about writing a selftest
for that, it's more reliable. I left the gdb.base/frame-view.exp pretty
printer test there, it's already written, and we never know, it might
catch some unrelated issue some day.
Change-Id: I5849baf77991fc67a15bfce4b5e865a97265b386
Reviewed-By: Bruno Larsen <blarsen@redhat.com>
I would like to improve frame_info_ptr to automatically grab the
information needed to reinflate a frame, and automatically reinflate it
as needed. One thing that is in the way is the fact that some frames
can be created out of thin air by the create_new_frame function. These
frames are not the fruit of unwinding from the target's current frame.
These frames are created by the "select-frame view" command.
These frames are not correctly handled by the frame save/restore
functions, save_selected_frame, restore_selected_frame and
lookup_selected_frame. This can be observed here, using the test
included in this patch:
$ ./gdb --data-directory=data-directory -nx -q testsuite/outputs/gdb.base/frame-view/frame-view
Reading symbols from testsuite/outputs/gdb.base/frame-view/frame-view...
(gdb) break thread_func
Breakpoint 1 at 0x11a2: file /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/frame-view.c, line 42.
(gdb) run
Starting program: /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.base/frame-view/frame-view
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/../lib/libthread_db.so.1".
[New Thread 0x7ffff7cc46c0 (LWP 4171134)]
[Switching to Thread 0x7ffff7cc46c0 (LWP 4171134)]
Thread 2 "frame-view" hit Breakpoint 1, thread_func (p=0x0) at /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/frame-view.c:42
42 foo (11);
(gdb) info frame
Stack level 0, frame at 0x7ffff7cc3ee0:
rip = 0x5555555551a2 in thread_func (/home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/frame-view.c:42); saved rip = 0x7ffff7d4e8fd
called by frame at 0x7ffff7cc3f80
source language c.
Arglist at 0x7ffff7cc3ed0, args: p=0x0
Locals at 0x7ffff7cc3ed0, Previous frame's sp is 0x7ffff7cc3ee0
Saved registers:
rbp at 0x7ffff7cc3ed0, rip at 0x7ffff7cc3ed8
(gdb) thread 1
[Switching to thread 1 (Thread 0x7ffff7cc5740 (LWP 4171122))]
#0 0x00007ffff7d4b4b6 in ?? () from /usr/lib/libc.so.6
Here, we create a custom frame for thread 1 (using the stack from thread
2, for convenience):
(gdb) select-frame view 0x7ffff7cc3f80 0x5555555551a2
The first calls to "frame" looks good:
(gdb) frame
#0 thread_func (p=0x7ffff7d4e630) at /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/frame-view.c:42
42 foo (11);
But not the second one:
(gdb) frame
#0 0x00007ffff7d4b4b6 in ?? () from /usr/lib/libc.so.6
This second "frame" command shows the current target frame instead of
the user-created frame.
It's not totally clear how the "select-frame view" feature is expected
to behave, especially since it's not tested. I heard accounts that it
used to be possible to select a frame like this and do "up" and "down"
to navigate the backtrace starting from that frame. The fact that
create_new_frame calls frame_unwind_find_by_frame to install the right
unwinder suggest that it used to be possible. But that doesn't work
today:
(gdb) select-frame view 0x7ffff7cc3f80 0x5555555551a2
(gdb) up
Initial frame selected; you cannot go up.
(gdb) down
Bottom (innermost) frame selected; you cannot go down.
and "backtrace" always shows the actual thread's backtrace, it ignores
the user-created frame:
(gdb) bt
#0 0x00007ffff7d4b4b6 in ?? () from /usr/lib/libc.so.6
#1 0x00007ffff7d50403 in ?? () from /usr/lib/libc.so.6
#2 0x000055555555521a in main () at /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/frame-view.c:56
I don't want to address all the `select-frame view` issues , but I think
we can agree that the "frame" command changing the selected frame, as
shown above, is a bug. I would expect that command to show the
currently selected frame and not change it.
This happens because of the scoped_restore_selected_frame object in
print_frame_args. The frame information is saved in the constructor
(the backtrace below), and restored in the destructor.
#0 save_selected_frame (frame_id=0x7ffdc0020ad0, frame_level=0x7ffdc0020af0) at /home/simark/src/binutils-gdb/gdb/frame.c:1682
#1 0x00005631390242f0 in scoped_restore_selected_frame::scoped_restore_selected_frame (this=0x7ffdc0020ad0) at /home/simark/src/binutils-gdb/gdb/frame.c:324
#2 0x000056313993581e in print_frame_args (fp_opts=..., func=0x62100023bde0, frame=..., num=-1, stream=0x60b000000300) at /home/simark/src/binutils-gdb/gdb/stack.c:755
#3 0x000056313993ad49 in print_frame (fp_opts=..., frame=..., print_level=1, print_what=SRC_AND_LOC, print_args=1, sal=...) at /home/simark/src/binutils-gdb/gdb/stack.c:1401
#4 0x000056313993835d in print_frame_info (fp_opts=..., frame=..., print_level=1, print_what=SRC_AND_LOC, print_args=1, set_current_sal=1) at /home/simark/src/binutils-gdb/gdb/stack.c:1126
#5 0x0000563139932e0b in print_stack_frame (frame=..., print_level=1, print_what=SRC_AND_LOC, set_current_sal=1) at /home/simark/src/binutils-gdb/gdb/stack.c:368
#6 0x0000563139932bbe in print_stack_frame_to_uiout (uiout=0x611000016840, frame=..., print_level=1, print_what=SRC_AND_LOC, set_current_sal=1) at /home/simark/src/binutils-gdb/gdb/stack.c:346
#7 0x0000563139b0641e in print_selected_thread_frame (uiout=0x611000016840, selection=...) at /home/simark/src/binutils-gdb/gdb/thread.c:1993
#8 0x0000563139940b7f in frame_command_core (fi=..., ignored=true) at /home/simark/src/binutils-gdb/gdb/stack.c:1871
#9 0x000056313994db9e in frame_command_helper<frame_command_core>::base_command (arg=0x0, from_tty=1) at /home/simark/src/binutils-gdb/gdb/stack.c:1976
Since the user-created frame has level 0 (identified by the saved level
-1), lookup_selected_frame just reselects the target's current frame,
and the user-created frame is lost.
My goal here is to fix this particular problem.
Currently, select_frame does not set selected_frame_id and
selected_frame_level for frames with level 0. It leaves them at
null_frame_id / -1, indicating to restore_selected_frame to use the
target's current frame. User-created frames also have level 0, so add a
special case them such that select_frame saves their selected id and
level.
save_selected_frame does not need any change.
Change the assertion in restore_selected_frame that checks `frame_level
!= 0` to account for the fact that we can restore user-created frames,
which have level 0.
Finally, change lookup_selected_frame to make it able to re-create
user-created frame_info objects from selected_frame_level and
selected_frame_id.
Add a minimal test case for the case described above, that is the
"select-frame view" command followed by the "frame" command twice. In
order to have a known stack frame to switch to, the test spawns a second
thread, and tells the first thread to use the other thread's top frame.
Change-Id: Ifc77848dc465fbd21324b9d44670833e09fe98c7
Reviewed-By: Bruno Larsen <blarsen@redhat.com>
The subsequent patches will need to call create_new_frame with an
existing frame_id representing a user created frame. They could call
the existing create_new_frame, passing both addresses, but it seems
nicer to have a version of the function that takes a frame_id directly.
Change-Id: If31025314fec0c3e644703e4391a5ef8079e1a32
Reviewed-By: Bruno Larsen <blarsen@redhat.com>
A subsequent patch makes it possible for frame_info_ptr to reinflate
user-created frames. If two frame_info_ptr objects wrapping the same
user-created frame_info need to do reinflation, we want them to end up
pointing to the same frame_info instance, and not create two separate
frame_infos. Otherwise, GDB gets confused down the line, as the state
kept in one frame_info object starts differing from the other
frame_info.
Achieve this by making create_new_frame place the user-created frames in
the frame stash. This way, when the second frame_info_ptr does
reinflation, it will find the existing frame_info object, created by the
other frame_info_ptr, in the frame stash.
To make the frame stash differentiate between regular and user-created
frame infos which would otherwise be equal, change frame_addr_hash and
frame_id::operator== to account for frame_id::user_created_p.
I made create_new_frame look up existing frames in the stash, and only
create one if it doesn't find one. The goal is to avoid the
"select-frame view"/"info frame view"/"frame view" commands from
overriding existing entries into the stash, should the user specify the
same frame more than once. This will also help in the subsequent patch
that makes frame_info_ptr capable of reinflating user-created frames.
It will be able to just call create_new_frame and it will do the right
thing.
Change-Id: I14ba5799012056c007b4992ecb5c7adafd0c2404
Reviewed-By: Bruno Larsen <blarsen@redhat.com>
Later in this series, we'll need to differentiate frame ids for regular
frames (obtained from the target state and unwinding from it) vs frame
ids for user-created frames (created with create_new_frame). Add the
frame_id::user_created_p field to indicate a frame is user-created, and
set it in create_new_frame.
The field is otherwise not used yet, so not changes in behavior are
expected.
Change-Id: I60de3ce581ed01bf0fddb30dff9bd932840120c3
Reviewed-By: Bruno Larsen <blarsen@redhat.com>
A patch later in this series will make frame_info_ptr access some
fields internal to frame_info, which we don't want to expose outside of
frame.c. Move the frame_info_ptr class to frame.h, and the definitions
to frame.c. Remove frame-info.c and frame-info.h.
Change-Id: Ic5949759e6262ea0da6123858702d48fe5673fea
Reviewed-By: Bruno Larsen <blarsen@redhat.com>
I hesitated between putting the file in the dwarf2 directory (as
gdb/dwarf2/call-site.h) or in the common directory (as gdb/call-site.h).
The concept of call site is not DWARF-specific, another debug info
reader could provide this information. But as it is, the implementation
is a bit DWARF-specific, as one form it can take is a DWARF expression
and parameters can be defined using a DWARF register number. So I ended up
choosing to put it under dwarf2/. If another debug info reader ever
wants to provide call site information, we can introduce a layer of
abstraction between the "common" call site and the "dwarf2" call site.
The copyright start year comes from the date `struct call_site` was
introduced.
Change-Id: I1cd84aa581fbbf729edc91b20f7d7a6e0377014d
Reviewed-By: Bruno Larsen <blarsen@redhat.com>
I want to move the call_site stuff out of gdbtypes.h, to a new header
file, to break some cyclic include problem. The call_site stuff uses
cu_offset, also defined in gdbtypes.h, so cu_offset also needs to move
somewhere else (otherwise, call-site.h will need to include gdbtypes.h,
and we are back to square 1). I could move cu_offset to the future new
file dwarf2/call-site.h, but it doesn't sound like a good place for it,
at cu_offset is not specific to call sites, it's used throughout
dwarf2/. So, move it to its own file, dwarf2/types.h. For now,
gdbtypes.h includes dwarf2/types.h, but that will be removed once the
call site stuff is moved to its own file.
Move sect_offset with it too. sect_offset is not a DWARF-specific
concept, but for the moment it is only used in dwarf2/.
Change-Id: I1fd2a3b7b67dee789c4874244b044bde7db43d8e
Reviewed-By: Bruno Larsen <blarsen@redhat.com>
This helps resolve some cyclic include problem later in the series.
The only language-related thing frame.h needs is enum language, and that
is in defs.h.
Doing so reveals that a bunch of files were relying on frame.h to
include language.h, so fix the fallouts here and there.
Change-Id: I178a7efec1953c2d088adb58483bade1f349b705
Reviewed-By: Bruno Larsen <blarsen@redhat.com>
struct compile_instance needs to be visible to users, since we use
std::unique<compile_instance>. language.c and c-lang.c currently
includes compile-internal.h for this reason, which kind of defeats the
purpose of having an "internal" header file.
Change-Id: Iedffe5f1173b3de7bdc1be533ee2a68e6f6c549f
Reviewed-By: Bruno Larsen <blarsen@redhat.com>
It's only used in compile/compile.c, it doesn't need to be in a header.
Change-Id: Ic5bec996b7b0cd7130055d1e8ff238b5ac4292a3
Reviewed-By: Bruno Larsen <blarsen@redhat.com>
I noticed that pc_in_unmapped_range had a weird return type -- it was
returning a CORE_ADDR but intending to return a bool. This patch
changes all the pc_in_* functions to return bool instead.
gdb.ada/ptype_tagged_param.exp is failing for me on x86-64 Fedora 36.
However, it's actually generating the correct output -- it is just
that the test thinks that the "ptype" will not work because I do not
have the GNAT debuginfo installed.
This patch changes the code to accept either result, and then to issue
a kfail as appropriate.
When running gdb.ada/arrayptr.exp (and others) on Ubuntu 22.04, with the
`gnat-11` package installed (not `gnat`), with UBSan activated, I get:
(gdb) break foo.adb:40
/home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:17689:20: runtime error: shift exponent 127 is too large for 64-bit type 'long unsigned int'
The problematic DIEs are:
0x00001460: DW_TAG_subrange_type
DW_AT_lower_bound [DW_FORM_data1] (0x00)
DW_AT_upper_bound [DW_FORM_data16] (ffffffffffffffff3f00000000000000)
DW_AT_name [DW_FORM_strp] ("foo__packed_array___XP7___XDLU_0__1180591620717411303423")
DW_AT_type [DW_FORM_ref4] (0x0000153f "long_long_long_unsigned")
DW_AT_GNAT_descriptive_type [DW_FORM_ref4] (0x0000147e)
DW_AT_artificial [DW_FORM_flag_present] (true)
0x0000153f: DW_TAG_base_type
DW_AT_byte_size [DW_FORM_data1] (0x10)
DW_AT_encoding [DW_FORM_data1] (DW_ATE_unsigned)
DW_AT_name [DW_FORM_strp] ("long_long_long_unsigned")
DW_AT_artificial [DW_FORM_flag_present] (true)
When processed by this code:
negative_mask =
-((ULONGEST) 1 << (base_type->length () * TARGET_CHAR_BIT - 1));
if (low.kind () == PROP_CONST
&& !base_type->is_unsigned () && (low.const_val () & negative_mask))
low.set_const_val (low.const_val () | negative_mask);
When the base type's length (16 bytes in this case) is larger than a
ULONGEST (typically 8 bytes), the bit shift is too large.
My obvious fix is just to skip the fixup for base types larger than a
ULONGEST (8 bytes). I don't think we really handle constant attribute
values larger than 8 bytes anyway, so this is part of a much larger
problem.
Add a test that replicates this situation, but uses bounds that fit in a
signed 64 bit, so we get a sensible result.
Change-Id: I8d0a24f3edd83b44e0761a0ce38922d3e2e112fb
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29386
I am looking at this code [1]:
/* Normally, the DWARF producers are expected to use a signed
constant form (Eg. DW_FORM_sdata) to express negative bounds.
But this is unfortunately not always the case, as witnessed
with GCC, for instance, where the ambiguous DW_FORM_dataN form
is used instead. To work around that ambiguity, we treat
the bounds as signed, and thus sign-extend their values, when
the base type is signed. */
negative_mask =
-((ULONGEST) 1 << (base_type->length () * TARGET_CHAR_BIT - 1));
if (low.kind () == PROP_CONST
&& !base_type->is_unsigned () && (low.const_val () & negative_mask))
low.set_const_val (low.const_val () | negative_mask);
if (high.kind () == PROP_CONST
&& !base_type->is_unsigned () && (high.const_val () & negative_mask))
high.set_const_val (high.const_val () | negative_mask);
Nothing in the testsuite seems to exercise it, as when I remove it, all
of gdb.dwarf2 still passes. And tests in other directories would be
compiler-dependent, so would rely on having a buggy compiler.
Update gdb.dwarf2/subrange.exp to have a test for it. When removing the
code above, the new test fails with:
ptype array_with_buggy_negative_bounds_type^M
type = array [240..244] of signed_byte^M
(gdb) FAIL: gdb.dwarf2/subrange.exp: ptype array_with_buggy_negative_bounds_type
instead of the expected:
ptype array_with_buggy_negative_bounds_type^M
type = array [-16..-12] of signed_byte^M
(gdb) PASS: gdb.dwarf2/subrange.exp: ptype array_with_buggy_negative_bounds_type
[1] 5ea14aa4e5/gdb/dwarf2/read.c (L17681-17695)
Change-Id: I1992a3ff0cb1e90fa8a9114dae6c591792f059c2
to check a situation that once failed with the new section merging
when it mishandled offsets pointing into alignment padding in mergable
string sections (i.e. pointing to zeros). It made bootstrap.exp fail
but that depends on many factors to actually go wrong so this is a more
explicit variant of it.
the test expects a second, but useless, $d mapping symbol for
the partially merged section, and specifically disallows one
for the completely merged section. The new merging algorithm
makes it so that also the partially merged sections are conceptually
SEC_EXCLUDED, except the first merge section (e.g. as if the very
first object file already contains all strings). So that second mapping
symbol is now missing. It never was needed anyway.
So, adjust the test.
* use power-of-two hash table
* use better hash function (hashing 32bits at once and with better
mixing characteristics)
* use input-offset-to-entry maps instead of retaining full input
contents for lookup time
* don't reread SEC_MERGE section multiple times
* care for cache behaviour for the hot lookup routine
The overall effect is less usage in libz and much faster string merging
itself. On a debug-info-enabled cc1 the effect at the time of this
writing on the machine I used was going from 14400 perf samples to 9300
perf samples or from 3.7 seconds to 2.4 seconds, i.e. about 33% .
