Since commit 90319cefe3 ("GDB/Guile: Don't assert that an integer value
is boolean"), I see:
FAIL: gdb.guile/scm-parameter.exp: kind=PARAM_ZINTEGER: test-PARAM_ZINTEGER-param: guile (set-parameter-value! test-PARAM_ZINTEGER-param #:unlimited)
FAIL: gdb.guile/scm-parameter.exp: kind=PARAM_ZUINTEGER: test-PARAM_ZUINTEGER-param: guile (set-parameter-value! test-PARAM_ZUINTEGER-param #:unlimited)
This comes from the fact that GDB outputs this:
ERROR: In procedure set-parameter-value!:
In procedure gdbscm_set_parameter_value_x: Wrong type argument in position 2 (expecting integer): #:unlimited
Error while executing Scheme code.
while the test expects an additional "ERROR:" on the second line,
something like this:
ERROR: In procedure set-parameter-value!:
ERROR: In procedure gdbscm_set_parameter_value_x: Wrong type argument in position 2 (expecting integer): #:unlimited
Error while executing Scheme code.
Guile 2.0 outputs the `ERROR:` on the second line, while later versions
do not. Change the pattern to accept both outputs. This is similar to
commit 6bbe1a929c ("[gdb/testsuite] Fix gdb.guile/scm-breakpoint.exp
with guile 3.0").
Change-Id: I9dc45e7492a4f08340cad974610242ed689de959
Arm v8-M Architecture Reference Manual,
D1.2.95 EXC_RETURN, Exception Return Payload
describes ES bit:
"ES, bit [0]
Exception Secure. The security domain the exception was taken to.
The possible values of this bit are:
0 Non-secure.
1 Secure"
arm-tdep.c:3443, arm_m_exception_cache () function tests this bit:
exception_domain_is_secure = (bit (lr, 0) == 0);
The test is negated!
Later on line 3553, the condition evaluates if an additional state
context is stacked:
/* With the Security extension, the hardware saves R4..R11 too. */
if (tdep->have_sec_ext && secure_stack_used
&& (!default_callee_register_stacking || exception_domain_is_secure))
RM, B3.19 Exception entry, context stacking
reads:
RPLHM "In a PE with the Security Extension, on taking an exception,
the PE hardware:
...
2. If exception entry requires a transition from Secure state to
Non-secure state, the PE hardware extends the stack frame and also
saves additional state context."
So we should test for !exception_domain_is_secure instead of non-negated
value!
These two bugs compensate each other so unstacking works correctly.
But another test of exception_domain_is_secure (negated due to the
first bug) prevents arm_unwind_secure_frames to work as expected:
/* Unwinding from non-secure to secure can trip security
measures. In order to avoid the debugger being
intrusive, rely on the user to configure the requested
mode. */
if (secure_stack_used && !exception_domain_is_secure
&& !arm_unwind_secure_frames)
Test with GNU gdb (GDB) 13.0.50.20221016-git.
Stopped in a non-secure handler:
(gdb) set arm unwind-secure-frames 0
(gdb) bt
#0 HAL_SYSTICK_Callback () at C:/dvl/stm32l5trustzone/GPIO_IOToggle_TrustZone/NonSecure/Src/nsmain.c:490
#1 0x0804081c in SysTick_Handler ()
at C:/dvl/stm32l5trustzone/GPIO_IOToggle_TrustZone/NonSecure/Src/nsstm32l5xx_it.c:134
#2 <signal handler called>
#3 HAL_GPIO_ReadPin (GPIOx=0x52020800, GPIO_Pin=8192)
at C:/dvl/stm32l5trustzone/GPIO_IOToggle_TrustZone/Drivers/STM32L5xx_HAL_Driver/Src/stm32l5xx_hal_gpio.c:386
#4 0x0c000338 in SECURE_Mode () at C:/dvl/stm32l5trustzone/GPIO_IOToggle_TrustZone/Secure/Src/main.c:86
#5 0x080403f2 in main () at C:/dvl/stm32l5trustzone/GPIO_IOToggle_TrustZone/NonSecure/Src/nsmain.c:278
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
The frames #3 and #4 are secure. backtrace should stop before #3.
Stopped in a secure handler:
(gdb) bt
#0 HAL_SYSTICK_Callback () at C:/dvl/stm32l5trustzone/GPIO_IOToggle_TrustZone/Secure/Src/main.c:425
#1 0x0c000b6a in SysTick_Handler ()
at C:/dvl/stm32l5trustzone/GPIO_IOToggle_TrustZone/Secure/Src/stm32l5xx_it.c:234
warning: Non-secure to secure stack unwinding disabled.
#2 <signal handler called>
The exception from secure to secure erroneously stops unwinding. It should
continue as far as the security unlimited backtrace:
(gdb) set arm unwind-secure-frames 1
(gdb) si <-- used to rebuild frame cache after change of unwind-secure-frames
0x0c0008e6 425 if (SecureTimingDelay != 0U)
(gdb) bt
#0 0x0c0008e6 in HAL_SYSTICK_Callback () at C:/dvl/stm32l5trustzone/GPIO_IOToggle_TrustZone/Secure/Src/main.c:425
#1 0x0c000b6a in SysTick_Handler ()
at C:/dvl/stm32l5trustzone/GPIO_IOToggle_TrustZone/Secure/Src/stm32l5xx_it.c:234
#2 <signal handler called>
#3 0x0c000328 in SECURE_Mode () at C:/dvl/stm32l5trustzone/GPIO_IOToggle_TrustZone/Secure/Src/main.c:88
#4 0x080403f2 in main () at C:/dvl/stm32l5trustzone/GPIO_IOToggle_TrustZone/NonSecure/Src/nsmain.c:278
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
Set exception_domain_is_secure to the value expected by its name.
Fix exception_domain_is_secure usage in the additional state context
stacking condition.
Signed-off-by: Tomas Vanek <vanekt@fbl.cz>
Arm v8-M Architecture Reference Manual,
D1.2.141 IPSR, Interrupt Program Status Register reads
"Exception, bits [8:0]"
9 bits, not 8! It is uncommon but true!
Signed-off-by: Tomas Vanek <vanekt@fbl.cz>
In the lockup state the PC value of the the outer frame is irreversibly
lost. The other registers are intact so LR likely contains
PC of some frame next to the outer one, but we cannot analyze
the nearest outer frame without knowing its PC
therefore we do not know SP fixup for this frame.
The frame unwinder possibly gets mad due to the wrong SP value.
To prevent problems terminate unwinding if PC contains the magic
value of the lockup state.
Example session wihtout this change,
Cortex-M33 CPU in lockup, gdb 13.0.50.20221016-git:
----------------
(gdb) c
Continuing.
Program received signal SIGINT, Interrupt.
0xeffffffe in ?? ()
(gdb) bt
#0 0xeffffffe in ?? ()
#1 0x0c000a9c in HardFault_Handler ()
at C:/dvl/stm32l5trustzone/GPIO_IOToggle_TrustZone/Secure/Src/stm32l5xx_it.c:99
#2 0x2002ffd8 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb)
----------------
The frame #1 is at correct PC taken from LR, #2 is a total nonsense.
With the change:
----------------
(gdb) c
Continuing.
Program received signal SIGINT, Interrupt.
warning: ARM M in lockup state, stack unwinding terminated.
<signal handler called>
(gdb) bt
#0 <signal handler called>
(gdb)
----------------
There is a visible drawback of emitting a warning in a cache buildnig routine
as introduced in Torbjörn SVENSSON's
[PATCH v4] gdb/arm: Stop unwinding on error, but do not assert
The warning is printed just once and not repeated on each backtrace command.
Signed-off-by: Tomas Vanek <vanekt@fbl.cz>
Should be functionally the same, but uses more pythonic idioms to get
fewer lines of code, and to make sure to not leak open file handles.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
The current logic limits itself to a maxdepth of 4 when looking for
results. This wouldn't be a problem if cris didn't have a testsuite
at a depth of 5 which we end up ignoring when summarizing. Rather
than bump the number from 4 to 5, rework the code so that we gather
the exact set of tests that we tried to run.
The external reloc size check was wrong. Here asect is the code/data
section, not the reloc section. So using this_hdr gave the size of
the code/data section.
* elf.c (_bfd_elf_get_reloc_upper_bound): Properly get
external size from reloc headers.
This patch checks that relocations emitted in som_write_fixups have
offsets that are monotonic and within a section. To do that properly
using bfd_reloc_offset_in_range it is necessary to set the reloc howto
size field, which isn't used otherwise by the som backend. Note that
the sizes used are not exactly those in the old sizing switch
statement deleted from som_write_fixups, but all relocs handled by the
main switch statement there get the same size. Most unhandled relocs
get a zero size (exceptions being R_RELOCATION, R_SPACE_REF,
R_MILLI_REL, R_BREAKPOINT which all involve writing one word according
to my SOM reference). I figure it doesn't matter since any unhandled
reloc is converted to 0xff R_RESERVED, and a default of zero is better
for a "don't know" reloc.
Besides tidying the code, stringizing name from type in SOM_HOWTO
fixes R_REPEATED_INIT name.
* som.c (SOM_HOWTO): Add SIZE arg, delete NAME. Stringize type
to name.
(som_hppa_howto_table): Update with sizes.
(som_write_fixups): Delete sizing switch statement. Sanity check
bfd_reloc address against subsection size.
Fuzzed object files can put random values in bfd_reloc->address,
leading to large som_reloc_skip output.
* som.c (som_write_fixups): Allow for maximal som_reloc_skip.
On x86-64 the default ELF_MAXPAGESIZE depends on a configure
option (--disable-separate-code). Since 9833b775
("PR28824, relro security issues") we use max-page-size for relro
alignment (with a short interval, from 31b4d3a ("PR28824, relro
security issues, x86 keep COMMONPAGESIZE relro") to its revert
a1faa5ea, where x86-64 only used COMMONPAGESIZE as relro alignment
target).
But that means that a linker configured with --disable-separate-code
behaves different from one configured with --enable-separate-code
(the default), _even if using "-z {no,}separate-code" option to use
the non-configured behaviour_ . In particular it means that when
configuring with --disable-separate-code the linker will produce
binaries aligned to 2MB pages on disk, and hence generate 2MB
executables for a hello world (and even 6MB when linked with
"-z separate-code").
Generally we can't have constants that ultimately land in static
variables be depending on configure options if those only influence
behaviour that is overridable by command line options.
So, do away with that, make the default MAXPAGESIZE be 4k (as is default
for most x86-64 configs anyway, as most people won't configure with
--disable-separate-code). If people need more they can use the
"-z max-page-size" (with would have been required right now for a
default configure binutils).
bfd/
* elf64-x86-64.c (ELF_MAXPAGESIZE): Don't depend on
DEFAULT_LD_Z_SEPARATE_CODE.
This test fails quite reliably for me when ran as:
$ taskset -c 1 make check TESTS="gdb.base/unwind-on-each-insn.exp" RUNTESTFLAGS="--target_board=native-gdbserver"
or more simply:
$ make check-read1 TESTS="gdb.base/unwind-on-each-insn.exp"
The problem is that the gdb_test_multiple call that grabs the frame id
from "maint print frame-id" does not consume the prompt. Well, it does
sometimes due to the trailing .*, but not always. If the prompt is not
consumed, the tests that follow get confused:
FAIL: gdb.base/unwind-on-each-insn.exp: gdb_breakpoint: set breakpoint at *foo
FAIL: gdb.base/unwind-on-each-insn.exp: disassemble foo
FAIL: gdb.base/unwind-on-each-insn.exp: get $sp and frame base in foo: get hexadecimal valueof "$sp"
... many more ...
Use -wrap to make gdb_test_multiple consume the prompt.
While at it, remove the bit that consumes the command name and do
exp_continue, it's not really necessary. And for consistency, do the
same changes to the gdb_test_multiple that consumes the stack address,
although that one was fine, it did consume the prompt explicitly.
Change-Id: I2b7328c8844c7e98921ea494c4c05107162619fc
Reviewed-By: Bruno Larsen <blarsen@redhat.com>
On openSUSE Tumbleweed I run into this for the dwarf assembly test-cases, and
some hardcoded assembly test-cases:
...
Running gdb.dwarf2/fission-absolute-dwo.exp ...
gdb compile failed, ld: warning: fission-absolute-dwo.o: \
missing .note.GNU-stack section implies executable stack
ld: NOTE: This behaviour is deprecated and will be removed in a future \
version of the linker
=== gdb Summary ===
# of untested testcases 1
...
Fix the dwarf assembly test-cases by adding the missing .note.GNU-stack in
proc Dwarf::assemble.
Fix the hard-coded test-cases using this command:
...
$ for f in $(find gdb/testsuite/gdb.* -name *.S); do
if ! grep -q note.GNU-stack $f; then
echo -e "\t.section\t.note.GNU-stack,\"\",@progbits" >> $f;
fi;
done
...
Likewise for .s files, and gdb/testsuite/lib/my-syscalls.S.
The idiom for arm seems to be to use %progbits instead, see commit 9a5911c08b
("gdb/testsuite/gdb.dwarf2: Replace @ with % for ARM compatability"), so
hand-edit gdb/testsuite/gdb.arch/arm-disp-step.S to use %progbits instead.
Note that dwarf assembly testcases use %progbits as decided by proc _section.
Tested on x86_64-linux.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29674
Recent commit b2829fcf9b ("[gdb] Fix rethrow exception slicing in
insert_bp_location") introduced macro RETHROW_ON_TARGET_CLOSE_ERROR.
I wrote this as a macro in order to have the rethrowing throw be part of the
same function as the catch, but as it turns out that's not necessary.
Rewrite into a function.
Tested on x86_64-linux.
Commit f34652de0b ("internal_error: remove need to pass
__FILE__/__LINE__") renamed the internal_error function to
internal_error_loc. Change gdb-gdb.gdb.in accordingly.
Change-Id: I876e1623607b6becf74ade53d102ead53a74ed86
The R_RISCV_DELETE relocations are no longer deleted at another relax pass,
so we should reset 'again' flag to true for _bfd_riscv_relax_pc, while the
deleted bytes are marked as R_RISCV_DELETE.
bfd/
* elfnn-riscv.c (_bfd_riscv_relax_pc): Set `again' to true while the
deleted bytes are marked as R_RISCV_DELETE.
The riscv port does deletion and symbol table update for each relocation
while relaxing, so we are moving section bytes and scanning symbol table once
for each relocation. Compared to microblaze port, they record the relaxation
changes into a table, then do the deletion and symbol table update once per
section, rather than per relocation. Therefore, they should have better link
time complexity than us.
To improve the link time complexity, this patch try to make the deletion in
linear time. Compared to record the relaxation changes into a table, we
replace the unused relocation with R_RISCV_DELETE for the deleted bytes, and
then resolve them at the end of the section. Assuming the number of
R_RISCV_DELETE is m, and the number of symbols is n, the total link complexity
should be O(m) for moving section bytes, and O(m*n^2) for symbol table update.
If we record the relaxation changes into the table, and then sort the symbol
table by values, then probably can reduce the time complexity to O(m*n*log(n))
for updating symbol table, but it doesn't seem worth it for now.
bfd/
* elfnn-riscv.c (_riscv_relax_delete_bytes): Renamed from
riscv_relax_delete_bytes, updated to reduce the tiem complexity to O(m)
for memmove.
(typedef relax_delete_t): Function pointer declaration of delete functions.
(riscv_relax_delete_bytes): Can choose to use _riscv_relax_delete_piecewise
or _riscv_relax_delete_immediate for deletion.
(_riscv_relax_delete_piecewise): Just mark the deleted bytes as R_RISCV_DELETE.
(_riscv_relax_delete_immediate): Delete some bytes from a section while
relaxing.
(riscv_relax_resolve_delete_relocs): Delete the bytes for R_RISCV_DELETE
relocations from a section, at the end of _bfd_riscv_relax_section.
(_bfd_riscv_relax_call): Mark deleted bytes as R_RISCV_DELETE by reusing
R_RISCV_RELAX.
(_bfd_riscv_relax_lui): Likewise, but reuse R_RISCV_HI20 for lui, and reuse
R_RISCV_RELAX for c.lui.
(_bfd_riscv_relax_tls_le): Likewise, but resue R_RISCV_TPREL_HI20 and
R_RISCV_TPREL_ADD.
(_bfd_riscv_relax_pc): Likewise, but resue R_RISCV_PCREL_HI20 for auipc.
(_bfd_riscv_relax_align): Updated, don't need to resue relocation since
calling _riscv_relax_delete_immediate.
(_bfd_riscv_relax_delete): Removed.
(_bfd_riscv_relax_section): Set riscv_relax_delete_bytes for each relax_func,
to delete bytes immediately or later. Call riscv_relax_resolve_delete_relocs
to delete bytes for DELETE relocations from a section.
In the lm32 simulator, I was seeing some warnings about missing
function declarations.
The lm32 simulator has a weird header structure, in order to pull in
the full cpu.h header we need to define WANT_CPU_LM32BF. This is done
in some files, but not in others. Critically, it's not done in some
files that then use functions declared in cpu.h
In this commit I added the missing #define so that the full cpu.h can
be included.
After doing this there are still a few functions that are used
undeclared, these functions appear to be missing any declarations at
all, so I've added some to cpu.h.
With this done all the warnings when compiling lm32 are resolved for
both gcc and clang, so I've removed the SIM_WERROR_CFLAGS line from
Makefile.in, this allows lm32 to build with -Werror.
There are two places in the h8300 simulator where we assign a variable
to itself. Clang gives a warning for this, which is converted into an
error by -Werror.
Silence the warning by removing the self assignments. As these
assignments were in a complex if/then/else tree, rather than try to
adjust all the conditions, I've just replaced the self assignments
with a comment and an empty statement.
In the ppc simulator, clang was warning about some code like this:
busy_ptr->nr_writebacks = 1 + (PPC_ONE_BIT_SET_P(out_vmask)) ? 1 : 2;
The warning was:
operator '?:' has lower precedence than '+'; '+' will be evaluated first
I suspect that this is not the original authors intention.
PPC_ONE_BIT_SET_P is going to be 0 or 1, so if we evaluate the '+'
first, the condition will always be non-zero, so true. The whole
expression could then be simplified to just '1', which doesn't make
much sense.
I suspect the answer the author was expecting was either 2 or 3. Why
they didn't just write:
busy_ptr->nr_writebacks = (PPC_ONE_BIT_SET_P(out_vmask)) ? 2 : 3;
I have no clue, however, to keep the structure of the code unchanged,
I've updated things to:
busy_ptr->nr_writebacks = 1 + (PPC_ONE_BIT_SET_P (out_vmask) ? 1 : 2);
which silences the warning from clang, and is, I am guessing, what the
original author intended.
In the ppc simulator's do_fstat function, which provides the fstat
call for the simulator, if the fstat is going to fail then we
currently write an uninitialized buffer into the simulated target.
In theory, I think this is fine, we also write the error status into
the simulated target, so, given that the fstat has failed, the target
shouldn't be relying on the buffer contents.
However, writing an uninitialized buffer means we might leak simulator
private data into the simulated target, which is probably a bad thing.
Plus it probably makes life easier if something consistent, like all
zeros, is written rather than random junk, which might look like a
successful call (except for the error code).
So, in this commit, I initialize the stat buffer to zero before
it is potentially used. If the stat call is not made then the buffer
will be left initialized as all zeros.
The ppc simulator, in sim_create_inferior, tries to print the function
local entry_point variable before the variable is initialized.
In this commit, I defer the debug print line until the variable has
been initialized.
The preferred way of rethrowing an exception is by using throw without
expression, because it avoids object slicing of the exception [1].
Fix this in insert_bp_location.
Tested on x86_64-linux.
[1] https://en.cppreference.com/w/cpp/language/throw
Approved-By: Andrew Burgess <aburgess@redhat.com>
The preferred way of rethrowing an exception is by using throw without
expression, because it avoids object slicing of the exception [1].
Fix this in gdb_pretty_print_disassembler::pretty_print_insn.
Tested on x86_64-linux.
[1] https://en.cppreference.com/w/cpp/language/throw
Approved-By: Andrew Burgess <aburgess@redhat.com>
If a custom arm-elf target is disabling the shared support, a lot of
failures are reported by the testsuite.
Moreover, some tests try to access libraries which have been explicitly
skipped earlier (eg mixed-lib.so).
ld/ChangeLog:
* testsuite/ld-arm/arm-elf.exp: Separate tests needing shared
lib support.
There's little point in having Intel syntax disassembler tests when the
purpose of a test is assembler functionality: Drop all
*avx512*_vpclmulqdq-wig1-intel.
For *avx512*_vpclmulqdq-wig1 share source with *avx512*_vpclmulqdq.
Finally put in place similar tests for -mvexwig=1.
There's little point in having Intel syntax disassembler tests when the
purpose of a test is assembler functionality: Drop all
*avx512*_vaes-wig1-intel.
For *avx512*_vaes-wig1 share source with *avx512*_vaes. This in
particular makes sure that the 32-bit VL test actually tests any EVEX
encodings in the first place.
Finally put in place similar tests for -mvexwig=1.
When no AVX512-specific functionality is in use, the disassembly of
AVX512VL insns is indistinguishable from their AVX counterparts (if such
exist). Emit the {evex} pseudo-prefix in such cases.
Where applicable drop stray uses of PREFIX_OPCODE from table entries.
I did a gdb build without python support, and during testing ran into FAILs in
test-case gdb.python/tui-window-names.exp.
Fix this by adding the missing skip_python_test.
Tested on x86_64-linux.
Now that we run `check/foo.exp` instead of `check/./foo.exp`,
update the config/ & lib/ exceptions to cover both paths.
Bug: https://sourceware.org/PR29596
Make sure we invoke runtest with the same exp filenames when running in
parallel as it will find when run single threaded. When `runtest` finds
files itself, it will use paths like "aarch64/allinsn.exp". When we run
`find .` with the %p option, it produces "./aarch64/allinsn.exp". Switch
to %P to get "aarch64/allinsn.exp".
Bug: https://sourceware.org/PR29596
These configure scripts check $target and change behavior. They
shouldn't be doing that, but until we can rework the sim to change
behavior based on the input ELF, restore AC_CANONICAL_SYSTEM to
these so that $target is correctly populated.
This was lost in the d3562f83a7
("sim: unify toolchain probing logic") refactor as the logic was
hoisted up to the common code. But the fact the vars weren't
passed down to the sub-configure scripts was missed.
Bug: https://sourceware.org/PR29439
This test sends my CI in an infinite loop of failures. We expect to
have a handful of iterations (5 on my development machine, where the
test passes fine)but the log shows that it went up to 104340 iterations:
FAIL: gdb.base/unwind-on-each-insn.exp - instruction 104340: maint print frame-id
DUPLICATE: gdb.base/unwind-on-each-insn.exp - instruction 104340: maint print frame-id
FAIL: gdb.base/unwind-on-each-insn.exp - instruction 104340: [string equal $fid $main_fid]
FAIL: gdb.base/unwind-on-each-insn.exp - instruction 104340: get hexadecimal valueof "$pc"
Add a max instruction check, exit the loop if we reach 100 iterations.
This should allow the test to fail fast if there's a problem, but 100
iterations should be more than enough for when things are working.
Change-Id: I77978d593aca046068f9209272d82e1675ba17c2
- avoid "GDB proper" to refer to global locus, as object files and
program spaces are also GDB proper.
- gdb.register_unwinder does not accept locus=gdb.
- "a unwinder" -> "an unwinder"
Approved-by: Eli Zaretskii <eliz@gnu.org>
Change-Id: I98c1b1000e1063815238e945ca71ec6f37b5702e
Small cleanup to use std::vector iterators rather than raw pointers.
Approved-By: Tom Tromey <tom@tromey.com>
Change-Id: I8d50dbb3f2d8dad7ff94066a578d523f1f31b590
