This extends PDB support to the aarch64 PE targets.
The changes to the test files are just to make it so they can be assembled as
either x86, x86_64, or aarch64, mainly by changing the comment style.
The only actual code change here is in adding the architecture constants
to pdb.c.
This patch resolves the performance issue reported in pr/29738 by
caching the values for the stack pointers for the inner frame. By
doing so, the impact can be reduced to checking the state and
returning the appropriate value.
Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>
Signed-off-by: Yvan Roux <yvan.roux@foss.st.com>
When there is no dwarf2 data for a register, a function can be called
to provide the value of this register. In some situations, it might
not be trivial to determine the value to return and it would cause a
performance bottleneck to do the computation each time.
This patch allows the called function to have a "cache" object that it
can use to store some metadata between calls to reduce the performance
impact of the complex logic.
The cache object is unique for each function and frame, so if there are
more than one function pointer stored in the dwarf2_frame_cache->reg
array, then the appropriate pointer will be supplied (the type is not
known by the dwarf2 implementation).
dwarf2_frame_get_fn_data can be used to retrieve the function unique
cache object.
dwarf2_frame_allocate_fn_data can be used to allocate and retrieve the
function unique cache object.
Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>
Signed-off-by: Yvan Roux <yvan.roux@foss.st.com>
I noticed some unusual code in mi-cmd-stack.c. This code is a switch,
where one of the cases appears in the middle of another block. It
seemed cleaner to me to have the earlier case just conditionally fall
through.
Pass -Wl,--no-as-needed to linker tests to fix
FAIL: Run pr19031
FAIL: Run got1
FAIL: Undefined weak symbol (-fPIE -no-pie)
FAIL: Undefined weak symbol (-fPIE -pie)
when --as-needed is passed to linker by compiler.
PR ld/30050
* testsuite/ld-i386/i386.exp: Pass -Wl,--no-as-needed to compiler
as needed.
This changes some tests to use require with 'is_remote', rather than
an explicit test. This adds uniformity helps clean up more spots
where a test might exit early without any notification.
A number of tests will exit early without saying why. This patch adds
"unsupported" at spots like this that I could readily find.
There are definitely more of these; for example dw2-ranges.exp fails
silently because a compilation fails. I didn't attempt to address
these as that is a much larger task.
A few tests work on two different targets that can't be detected with
a single call to istarget -- that proc only accepts globs, not regular
expressions.
This patch introduces a new is_any_target proc and then converts these
tests to use it in a 'require'.
This changes many tests to use require when checking 'istarget'. A
few of these conversions were already done in earlier patches.
No change was needed to 'require' to make this work, due to the way it
is written. I think the result looks pretty clear, and it has the
bonus of helping to ensure that the reason that a test is skipped is
always logged.
With test-case gdb.base/unwind-on-each-insn.exp and target board unix/-m32, I
now get:
...
# of expected passes 25
...
instead of:
...
# of expected passes 133
...
as I used to get before commit d25a8dbc7c3 ("[gdb/testsuite] Allow debug
srcfile2 in gdb.base/unwind-on-each-insn.exp"), due to the test-case trying to match
"rip = " and info frame printing "eip = " instead.
Fix this by dropping "rip" from the regexp.
Tested on x86_64-linux, target boards unix/{-m64,-m32}.
Test-case gdb.base/unwind-on-each-insn.exp compiles $srcfile with debug info, and
$srcfile2 without.
Occasionally, I try both files with debug info:
...
- $srcfile $debug_flags $srcfile2 $nodebug_flags]]} {
+ $srcfile $debug_flags $srcfile2 $debug_flags]]} {
...
This shortcuts the test due to no longer recognizing that stepi still lands
in foo.
Fix this by determining whether still in foo by checking the info frame output.
Tested on x86_64-linux.
Test-case gdb.base/unwind-on-each-insn.exp compiles $srcfile with debug info, and
$srcfile2 without.
Occasionally, I try both files with debug info:
...
- $srcfile $debug_flags $srcfile2 $nodebug_flags]]} {
+ $srcfile $debug_flags $srcfile2 $debug_flags]]} {
...
and both files without:
...
- $srcfile $debug_flags $srcfile2 $nodebug_flags]]} {
+ $srcfile $nodebug_flags $srcfile2 $nodebug_flags]]} {
...
In the latter case, I run into:
...
FAIL: gdb.base/unwind-on-each-insn.exp: foo: instruction 1: bt 2
FAIL: gdb.base/unwind-on-each-insn.exp: foo: instruction 1: up
...
due to a mismatch between the regexp and the different output due to using
nodebug.
Fix this by making the regexp less strict.
Tested on x86_64-linux.
In test-case gdb.base/unwind-on-each-insn.exp, we stepi through function foo
to check various invariants at each insn, in particular hoping to excercise
insns that modify stack and frame pointers.
Function foo is a leaf function, so add a non-leaf function bar, and step
through it as well (using nexti instead of stepi).
With the updated test-case, on powerpc64le-linux, I run into PR tdep/30049:
...
FAIL: bar: instruction 5: bt 2
FAIL: bar: instruction 5: up
FAIL: bar: instruction 5: [string equal $fid $::main_fid]
FAIL: bar: instruction 6: bt 2
FAIL: bar: instruction 6: up
FAIL: bar: instruction 6: [string equal $fid $::main_fid]
...
Tested on:
- x86_64-linux (-m64 and -m32)
- s390x-linux (-m64 and -m31)
- aarch64-linux
- powerpc64le-linux
In test-case gdb.base/unwind-on-each-insn.exp, we stepi through function foo
to check various invariants at each insn, in particular hoping to excercise
insns that modify stack and frame pointers.
For x86_64-linux, we have a reasonably complex foo (and similar for -m32):
...
4004bc: 55 push %rbp
4004bd: 48 89 e5 mov %rsp,%rbp
4004c0: 90 nop
4004c1: 5d pop %rbp
4004c2: c3 ret
...
Both stack pointer (%rsp) and frame pointer (%rbp) are modified.
Also for s390x-linux (and similar for -m31):
...
0000000001000668 <foo>:
1000668: e3 b0 f0 58 00 24 stg %r11,88(%r15)
100066e: b9 04 00 bf lgr %r11,%r15
1000672: e3 b0 b0 58 00 04 lg %r11,88(%r11)
1000678: 07 fe br %r14
...
Frame pointer (%r11) is modified.
Likewise for powerpc64le-linux:
...
00000000100006c8 <foo>:
100006c8: f8 ff e1 fb std r31,-8(r1)
100006cc: d1 ff 21 f8 stdu r1,-48(r1)
100006d0: 78 0b 3f 7c mr r31,r1
100006d4: 00 00 00 60 nop
100006d8: 30 00 3f 38 addi r1,r31,48
100006dc: f8 ff e1 eb ld r31,-8(r1)
100006e0: 20 00 80 4e blr
...
Both stack pointer (r1) and frame pointer (r31) are modified.
But for aarch64-linux, we have:
...
00000000004005fc <foo>:
4005fc: d503201f nop
400600: d65f03c0 ret
...
There's no insn that modifies stack or frame pointer.
Fix this by making foo more complex, adding an (unused) argument:
...
0000000000400604 <foo>:
400604: d10043ff sub sp, sp, #0x10
400608: f90007e0 str x0, [sp, #8]
40060c: d503201f nop
400610: 910043ff add sp, sp, #0x10
400614: d65f03c0 ret
...
such that the stack pointer (sp) is modified.
[ Note btw that we're seeing the effects of -momit-leaf-frame-pointer, with
-mno-omit-leaf-frame-pointer we have instead:
...
0000000000400604 <foo>:
400604: a9be7bfd stp x29, x30, [sp, #-32]!
400608: 910003fd mov x29, sp
40060c: f9000fa0 str x0, [x29, #24]
400610: d503201f nop
400614: a8c27bfd ldp x29, x30, [sp], #32
400618: d65f03c0 ret
...
such that also the frame pointer (x29) is modified. ]
Having made foo more complex, we now run into the following fail on
x86_64/-m32:
...
FAIL: gdb.base/unwind-on-each-insn.exp: instruction 1: $sp_value == $main_sp
....
The problem is that the stack pointer has changed inbetween the sampling of
main_sp and *foo, in particular by the push insn:
...
804841a: 68 c0 84 04 08 push $0x80484c0
804841f: e8 10 00 00 00 call 8048434 <foo>
...
Fix this by updating main_sp.
On powerpc64le-linux, with gcc 7.5.0 I now run into PR tdep/30021:
...
FAIL: gdb.base/unwind-on-each-insn.exp: insn 7: $fba_value == $main_fba
FAIL: gdb.base/unwind-on-each-insn.exp: insn 7: [string equal $fid $main_fid]
...
but I saw the same failure before this commit with gcc 4.8.5.
Tested on:
- x86_64-linux (-m64 and -m32)
- s390x-linux (-m64 and -m31)
- powerpc64le-linux
- aarch64-linux
Also I've checked that the test-case still functions as regression test for PR
record/16678 on x86_64.
Make use of a scoped_restore object in tui_mld_read_key instead of
doing a manual save/restore.
I don't think the existing code can throw an exception, so this is
just a cleanup rather than a bug fix.
There should be no user visible changes after this commit.
While working on the previous couple of commits, I noticed that the
'focus' command would happily suggest 'status' as a possible focus
completion, even though the 'status' window is non-focusable, and,
after the previous couple of commits, trying to focus the status
window will result in an error.
This commit improves the tab-completion results for the focus command
so that the status window is not included.
While working on the previous commit, I realised that there was an
error in tui_set_focus_command that could never be triggered.
Since the big tui rewrite (adding dynamic layouts) it is no longer
true that there is a tui_win_info object for every window at all
times. We now only create a tui_win_info object for a particular
window, when the window is part of the current layout. As a result,
if we have a tui_win_info pointer, then the window must be visible
inside tui_set_focus_command (this function calls tui_enable as its
first action, which makes the current layout visible).
The gdb.tui/tui-focus.exp test script exercises this area of code, and
doesn't trigger the assert, nor do any of our other existing tui
tests.
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.
