Andrew Burgess [Tue, 1 Nov 2022 14:09:17 +0000 (14:09 +0000)]
libopcodes/mips: add support for disassembler styling
This commit adds disassembler styling support for MIPS. After this
commit objdump and GDB will style disassembler output.
This is a pretty straight forward change, we switch to use the
disassemble_info::fprintf_styled_func callback, and pass an
appropriate style through as needed. No additional tricks were
needed (compared to say i386, or ARM).
Tested by running all of the objdump commands used by the gas
testsuite and manually inspecting the styled output, everything looks
reasonable, though I'm not a MIPS expert, so it is possible that I've
missed some corner cases. Worst case though is that something will be
styled incorrectly, the actual content should be unchanged.
All the gas, ld, and binutils tests still pass for me.
Andrew Burgess [Wed, 2 Nov 2022 15:53:43 +0000 (15:53 +0000)]
opcodes/mips: use .word/.short for undefined instructions
While working on disassembler styling for MIPS, I noticed that
undefined instructions are printed by the disassembler as raw number
with no assembler directive prefix (e.g. without .word or .short).
I think adding something like .word, or .short, helps to make it
clearer the size of the value that is being displayed, and is inline
with what many of the other libopcode disassemblers do.
In this commit I've added the .word and .short directives, and updated
all the tests that I spotted that failed as a result.
Nick Clifton [Thu, 3 Nov 2022 09:20:37 +0000 (09:20 +0000)]
AVR Linker: Allow the start of the data region to be specified on the linker command line. [Fix PR number in ChangeLog entry]
PR 29741
* scripttempl/avr.sc (__DATA_REGION_ORIGIN__): Define. If a value
has not been provided on the command line then use DATA_ORIGIN.
(MEMORY): Use __DATA_REGION_ORIGIN__ as the start of the data region.
Nick Clifton [Thu, 3 Nov 2022 09:17:41 +0000 (09:17 +0000)]
AVR Linker: Allow the start of the data region to specified on the command line.
PR 29471
* scripttempl/avr.sc (__DATA_REGION_ORIGIN__): Define. If a value
has not been provided on the command line then use DATA_ORIGIN.
(MEMORY): Use __DATA_REGION_ORIGIN__ as the start of the data region.
Mike Frysinger [Mon, 31 Oct 2022 12:50:52 +0000 (18:35 +0545)]
sim: move common flags to default AM_CPPFLAGS
Since all host files we compile use these settings, move them out of
libcommon.a and into the default AM_CPPFLAGS. This has the effect of
dropping the custom per-target automake rules. Currently it saves us
~150 lines, but since it's about ~8 lines per object, the overhead
will increase quite a bit as we merge more files into a single build.
This also changes the object output names, so we have to tweak the
rules that were pulling in the common objects when linking.
Mike Frysinger [Mon, 31 Oct 2022 12:31:14 +0000 (18:16 +0545)]
sim: common: remove unused include paths
A bunch of these paths don't include any headers, and most likely
never will, so there's no real need to keep them. This will let
us harmonize paths with the top-level Makefile more easily, which
will in turn make it easier to move more compile steps there.
Christophe Lyon [Wed, 2 Nov 2022 16:50:15 +0000 (16:50 +0000)]
arm: PR 29739 Fix typo where ';' should not have been replaced with '@'
';' does not always indicate the start of a comment, and commit 8cb6e17571f3fb66ccd4fa19f881602542cd06fc incorrectly replaced 3
instances of ';' with '@' in expected diagnostics, leading to tests
failures.
This patch restores the original ';' as needed in these testcases.
Mike Frysinger [Mon, 31 Oct 2022 07:35:13 +0000 (13:20 +0545)]
sim: split CPPFLAGS between build & host
In order to merge more common/ files into the top-level, we need to
add more host flags to CPPFLAGS, and that conflicts with our current
use with build-time tools. So split them apart like we do with all
other build flags to avoid the issue.
Mike Frysinger [Mon, 31 Oct 2022 15:58:10 +0000 (21:43 +0545)]
sim: common: change sim_{fetch,store}_register helpers to use void* buffers
When reading/writing arbitrary data to the system's memory, the unsigned
char pointer type doesn't make that much sense. Switch it to void so we
align a bit with standard C library read/write functions, and to avoid
having to sprinkle casts everywhere.
Absent _UNICODE being defined (which gdb's Makefile doesn't do),
windows.h will always define STARTUPINFO is as STARTUPINFOA, so this
cast isn't correct when create_process expects a STARTUPINFOW
parameter (i.e. in a Cygwin build).
Instead write this as &info_ex.StartupInfo (which is always of the
correct type).
Jan Beulich [Wed, 2 Nov 2022 07:21:04 +0000 (08:21 +0100)]
x86: drop bogus Tbyte
Prior to commit 1cb0ab18ad24 ("x86/Intel: restrict suffix derivation")
the Tbyte modifier on the FLDT and FSTPT templates was pointless, as
No_ldSuf would have prevented it being accepted. Due to the special
nature of LONG_DOUBLE_MNEM_SUFFIX said commit, however, has led to these
insns being accepted in Intel syntax mode even when "tbyte ptr" was
present. Restore original behavior by dropping Tbyte there. (Note that
these insns in principle should by marked AT&T syntax only, but since
they haven't been so far we probably shouldn't change that.)
Jan Beulich [Wed, 2 Nov 2022 07:18:24 +0000 (08:18 +0100)]
x86: simplify expressions in update_imm()
Comparing the sum of the relevant .imm<N> fields against a constant imo
makes more obvious what is actually meant. It allows dropping of two
static variables, with a 3rd drop requiring two more minor adjustments
elsewhere, utilizing that "i" is zeroed first thing in md_assemble().
This also increases the chances of the compiler doing the calculations
all in registers.
Assembler adds $d for the odd .byte, and then adds $x+arch for the
alignment. Since norelax, riscv_add_odd_padding_symbol will add the
$d and $x for the odd alignment, but accidently remove the $x+arch because
it has the same address as $d. Therefore, we will get the unexpected result
before applying this patch,
gas/
* config/tc-riscv.c (make_mapping_symbol): If we are adding mapping symbol
for odd alignment, then we probably will remove the $x+arch by accidently
when it has the same address of $d. Try to add the removed $x+arch back
after the $d rather than just $x.
(riscv_mapping_state): Updated since parameters of make_mapping_symbol are
changed.
(riscv_add_odd_padding_symbol): Likewise.
(riscv_remove_mapping_symbol): Removed and moved the code into the
riscv_check_mapping_symbols.
(riscv_check_mapping_symbols): Updated.
* testsuite/gas/riscv/mapping-dis.d: Updated and added new testcase.
* testsuite/gas/riscv/mapping-symbols.d: Likewise.
* testsuite/gas/riscv/mapping.s: Likewise.
Hongyu Wang [Tue, 1 Nov 2022 02:49:29 +0000 (10:49 +0800)]
Support Intel AVX-IFMA
x86: Support Intel AVX-IFMA
Intel AVX IFMA instructions are marked with CpuVEX_PREFIX, which is
cleared by default. Without {vex} pseudo prefix, Intel IFMA instructions
are encoded with EVEX prefix. {vex} pseudo prefix will turn on VEX
encoding for Intel IFMA instructions.
introduced two places where a register name was passed as the format
string to the disassembler's fprintf_styled_func callback. This will
cause a warning from some compilers, like this:
../../binutils-gdb/opcodes/arm-dis.c: In function ‘print_mve_vld_str_addr’:
../../binutils-gdb/opcodes/arm-dis.c:6005:3: error: format not a string literal and no format arguments [-Werror=format-security]
6005 | func (stream, dis_style_register, arm_regnames[gpr]);
| ^~~~
This commit fixes these by using "%s" as the format string.
was causing a compiler warning about a possible uninitialized variable
usage within opcodes/arm-dis.c.
The problem is in print_mve_unpredictable, and relates to the reason
variable, which is set by a switch table.
Currently the switch table does cover every valid value, though there
is no default case. The variable switched on is passed in as an
argument to the print_mve_unpredictable function.
Looking at how print_mve_unpredictable is used, there is only one use,
the second argument is the one that is used for the switch table,
looking at how this argument is set, I don't believe it is possible
for this argument to take an invalid value.
So, I think the compiler warning is a false positive. As such, my
proposed solution is to initialize the reason variable to the string
"??", this will silence the warning, and the "??" string should never
end up being printed.
Andrew Burgess [Thu, 7 Jul 2022 12:43:45 +0000 (13:43 +0100)]
opcodes/arm: add disassembler styling for arm
This commit adds disassembler styling for the ARM architecture.
The ARM disassembler is driven by several instruction tables,
e.g. cde_opcodes, coprocessor_opcodes, neon_opcodes, etc
The type for elements in each table can vary, but they all have one
thing in common, a 'const char *assembler' field. This field
contains a string that describes the assembler syntax of the
instruction.
Embedded within that assembler syntax are various escape characters,
prefixed with a '%'. Here's an example of a very simple instruction
from the arm_opcodes table:
"pld\t%a"
The '%a' indicates a particular type of operand, the function
print_insn_arm processes the arm_opcodes table, and includes a switch
statement that handles the '%a' operand, and takes care of printing
the correct value for that instruction operand.
It is worth noting that there are many print_* functions, each
function handles a single *_opcodes table, and includes its own switch
statement for operand handling. As a result, every *_opcodes table
uses a different mapping for the operand escape sequences. This means
that '%a' might print an address for one *_opcodes table, but in a
different *_opcodes table '%a' might print a register operand.
Notice as well that in our example above, the instruction mnemonic
'pld' is embedded within the assembler string. Some instructions also
include comments within the assembler string, for example, also from
the arm_opcodes table:
"nop\t\t\t@ (mov r0, r0)"
here, everything after the '@' is a comment that is displayed at the
end of the instruction disassembly.
The next complexity is that the meaning of some escape sequences is
not necessarily fixed. Consider these two examples from arm_opcodes:
"ldrex%c\tr%12-15d, [%16-19R]"
"setpan\t#%9-9d"
Here, the '%d' escape is used with a bitfield modifier, '%12-15d' in
the first instruction, and '%9-9d' in the second instruction, but,
both of these are the '%d' escape.
However, in the first instruction, the '%d' is used to print a
register number, notice the 'r' immediately before the '%d'. In the
second instruction the '%d' is used to print an immediate, notice the
'#' just before the '%d'.
We have two problems here, first, the '%d' needs to know if it should
use register style or immediate style, and secondly, the 'r' and '#'
characters also need to be styled appropriately.
The final thing we must consider is that some escape codes result in
more than just a single operand being printed, for example, the '%q'
operand as used in arm_opcodes ends up calling arm_decode_shift, which
can print a register name, a shift type, and a shift amount, this
could end up using register, sub-mnemonic, and immediate styles, as
well as the text style for things like ',' between the different
parts.
I propose a three layer approach to adding styling:
(1) Basic state machine:
When we start printing an instruction we should maintain the idea
of a 'base_style'. Every character from the assembler string will
be printed using the base_style.
The base_style will start as mnemonic, as each instruction starts
with an instruction mnemonic. When we encounter the first '\t'
character, the base_style will change to text. When we encounter
the first '@' the base_style will change to comment_start.
This simple state machine ensures that for simple instructions the
basic parts, except for the operands themselves, will be printed in
the correct style.
(2) Simple operand styling:
For operands that only have a single meaning, or which expand to
multiple parts, all of which have a consistent meaning, then I
will simply update the operand printing code to print the operand
with the correct style. This will cover a large number of the
operands, and is the most consistent with how styling has been
added to previous architectures.
(3) New styling syntax in assembler strings:
For cases like the '%d' that I describe above, I propose adding a
new extension to the assembler syntax. This extension will allow
me to temporarily change the base_style. Operands like '%d', will
then print using the base_style rather than using a fixed style.
Here are the two examples from above that use '%d', updated with
the new syntax extension:
The syntax has the general form '%{X:....%}' where the 'X'
character changes to indicate a different style. In the first
instruction I use '%{R:...%}' to change base_style to the register
style, and in the second '%{I:...%}' changes base_style to
immediate style.
Notice that the 'r' and '#' characters are included within the new
style group, this ensures that these characters are printed with
the correct style rather than as text.
The function decode_base_style maps from character to style. I've
included a character for each style for completeness, though only
a small number of styles are currently used.
I have updated arm-dis.c to the above scheme, and checked all of the
tests in gas/testsuite/gas/arm/, and the styling looks reasonable.
There are no regressions on the ARM gas/binutils/ld tests that I can
see, so I don't believe I've changed the output layout at all. There
were two binutils tests for which I needed to force the disassembler
styling off.
I can't guarantee that I've not missed some untested corners of the
disassembler, or that I might have just missed some incorrectly styled
output when reviewing the test results, but I don't believe I've
introduced any changes that could break the disassembler - the worst
should be some aspect is not styled correctly.
Andrew Burgess [Fri, 2 Sep 2022 17:15:30 +0000 (18:15 +0100)]
opcodes/arm: use '@' consistently for the comment character
Looking at the ARM disassembler output, every comment seems to start
with a ';' character, so I assumed this was the correct character to
start an assembler comment.
I then spotted a couple of places where there was no ';', but instead,
just a '@' character. I thought that this was a case of a missing
';', and proposed a patch to add the missing ';' characters.
Turns out I was wrong, '@' is actually the ARM assembler comment
character, while ';' is the statement separator. Thus this:
nop ;@ comment
is two statements, the first is the 'nop' instruction, while the
second contains no instructions, just the '@ comment' comment text.
This:
nop @ comment
is a single 'nop' instruction followed by a comment. And finally,
this:
nop ; comment
is two statements, the first contains the 'nop' instruction, while the
second contains the instruction 'comment', which obviously isn't
actually an instruction at all.
Why this matters is that, in the next commit, I would like to add
libopcodes syntax styling support for ARM.
The question then is how should the disassembler style the three cases
above?
As '@' is the actual comment start character then clearly the '@' and
anything after it can be styled as a comment. But what about ';' in
the second example? Style as text? Style as a comment?
And the third example is even harder, what about the 'comment' text?
Style as an instruction mnemonic? Style as text? Style as a comment?
I think the only sensible answer is to move the disassembler to use
'@' consistently as its comment character, and remove all the uses of
';'.
Then, in the next commit, it's obvious what to do.
There's obviously a *lot* of tests that get updated by this commit,
the only actual code changes are in opcodes/arm-dis.c.
Tom Tromey [Wed, 12 Oct 2022 14:40:34 +0000 (08:40 -0600)]
Add missing TYPE_CODE_* constants to Python
A user noticed that TYPE_CODE_FIXED_POINT was not exported by the gdb
Python layer. This patch fixes the bug, and prevents future
occurences of this type of bug.
Carl Love [Mon, 31 Oct 2022 18:44:17 +0000 (14:44 -0400)]
Remove REPARSE condition to force hardware resource checking when updating watchpoints
Currently the resource checking is done if REPARSE is true. The hardware
watchpoint resource checking in update_watchpoint needs to be redone on
each call to function update_watchpoints as the value chain may have
changed. The number of hardware registers needed for a watchpoint can
change if the variable being watched changes. This situation occurs in
this test when watching variable **global_ptr_ptr. Initially when the
watch command is issued, only two addresses need to be watched as
**global_ptr_ptr has not yet been initialized. Once the value of
**global_ptr_ptr is initialized the locations to be tracked increase to
three addresses. However, update_watchpoints is not called again with
REPARSE set to 1 to force the resource checking to be redone. When the
test is run on Power 10, an internal gdb error occurs when the PowerPC
routine tries to setup the three hardware watchpoint address since the hw
only has two hardware watchpoint registers. The error occurs because the
resource checking was not redone in update_watchpoints after
**global_ptr_ptr changed.
The following descibes the situation in detail that occurs on Power 10 with
gdb running on the binary for gdb.base/watchpoint.c.
1 break func4
2 run
3 watch *global_ptr
4 next execute source code: buf[0] = 3;
5 next execute source code: global_ptr = buf;
6 next execute source code: buf[0] = 7;
7 delete 2 (delete watch *global_ptr)
8 watch **global_ptr_ptr
9 next execute source code: buf[1] = 5;
10 next global_ptr_ptr = &global_ptr;
11 next buf[0] = 9;
In step 8, the the watch **global_ptr_prt command calls update_watchpoint
in breakpoint.c with REPARSE set to 1. The function update_watchpoint
calls can_use_hardware_watchpoint to see if there are enough
resources available to add the watchpoint since REPARSE is set to 1. At
this point, **global_ptr_ptr has not been initialized so only two addresses
are watched. The val_chain contains the address for **global_ptr_ptr and 0
since **global_ptr_ptr has not been initialized. The update_watchpoint
updates the breakpoint list as follows:
breakpoint 0
loc 0: b->address = 0x100009c0
breakpoint 1
loc 1: b->address = 0x7ffff7f838a0
breakpoint 2
loc 2: b->address = 0x7ffff7b7fc54
breakpoint 3
loc 3: b->address = 0x7ffff7a5788c
breakpoint 4
loc 4: b->address = 0x0 <-- location pointed to by global_ptr_ptr
loc 5: b->address = 0x100200b8 <-- global_ptr_ptr watchpoint
breakpoint 5
loc 6: b->address = 0x7ffff7b7fc54
In step 10, the next command executes the source code
global_ptr_ptr = &global_ptr. This changes the set of locations to be
watched for the watchpoint **global_ptr_prt. The list of addresses for the
breakpoint consist of the address for global_ptr_prt, global_ptr and buf.
The breakpoint list gets updated by update_watchpoint as follows:
breakpoint 0
loc 0: b->address = 0x100009c0
breakpoint 1
loc 1: b->address = 0x7ffff7f838a0
breakpoint 2
loc 2: b->address = 0x7ffff7b7fc54
breakpoint 3
loc 3: b->address = 0x7ffff7a5788c
breakpoint 4
loc 4: b->address = 0x10020050 buf
loc 5: b->address = 0x100200b0 watch *global_ptr
loc 6: b->address = 0x100200b8 watch **global_ptr_ptr
breakpoint 5
loc 7: b->address = 0x7ffff7b7fc54
breakpoint 6
However, the hardware resource checking was not redone because
update_breakpoint was called with REPARSE equal to 0.
Step 11, execute the third next command. The function
ppc_linux_nat_target::low_prepare_to_resume() attempts a ptrace
call to setup each of the three address for breakpoint 4. The slot
value returned for the third ptrace call is -1 indicating an error
because there are only two hardware watchpoint registers available on
Power 10.
This patch removes just the statement "if (reparse)" in function
update_watchpoint to force the resources to be rechecked on every call to
the function. This ensures that any changes to the val_chain resulting
in needing more resources then available will be caught.
The patch has been tested on Power 8, Power 10 and X86-64. Note the patch
has no effect on Power 9 since hardware watchpoint support is disabled on
that processor.
Jan Beulich [Mon, 31 Oct 2022 16:56:06 +0000 (17:56 +0100)]
x86: minor improvements to optimize_imm() (part III)
Earlier tidying still missed an opportunity: There's no need for the
"anyimm" static variable. Instead of using it in the loop to mask
"allowed" (which is necessary to satisfy operand_type_or()'s assertions)
simply use "mask", requiring it to be calculated first. That way the
post-loop masking by "mask" ahead of the operand_type_all_zero() can be
dropped.
Mike Frysinger [Wed, 26 Oct 2022 16:08:30 +0000 (21:53 +0545)]
sim: common: change sim_read & sim_write to use void* buffers
When reading/writing arbitrary data to the system's memory, the unsigned
char pointer type doesn't make that much sense. Switch it to void so we
align a bit with standard C library read/write functions, and to avoid
having to sprinkle casts everywhere.
H.J. Lu [Mon, 31 Oct 2022 16:01:15 +0000 (09:01 -0700)]
x86: Silence GCC 12 warning on tc-i386.c
Silence GCC 12 warning on tc-i386.c:
gas/config/tc-i386.c: In function ‘md_assemble’:
gas/config/tc-i386.c:5039:16: error: too many arguments for format [-Werror=format-extra-args]
5039 | as_warn (_("only support RIP-relative address"), i.tm.name);
Tom Tromey [Tue, 18 Oct 2022 15:48:09 +0000 (09:48 -0600)]
Inline initialization of gdbarch members
This changes gdbarch to use the "predefault" to initialize its members
inline. This required changing a couple of the Value instantiations
to avoid a use of "gdbarch" during initialization, but on the whole I
think this is better -- it removes a hidden ordering dependency.
Tom Tromey [Tue, 18 Oct 2022 17:32:52 +0000 (11:32 -0600)]
Fix regression in pointer-to-member printing
PR c++/29243 points out that "info func" on a certain C++ executable
will cause an infinite loop in gdb.
I tracked this down to a bug introduced by commit 6b5a7bc76 ("Handle
member pointers directly in generic_value_print"). Before this
commit, the C++ code to print a member pointer would wind up calling
value_print_scalar_formatted; but afterward it simply calls
generic_value_print and gets into a loop.
This patch restores the previous behavior and adds a regression test.
Bruno Larsen [Tue, 4 Oct 2022 14:09:05 +0000 (16:09 +0200)]
gdb/testsuite: fix gdb.cp/converts.exp to run with clang
Clang attempts to minimize the size of the debug-info by not adding
complete information about types that aren't constructed in a given
file. Specifically, this meant that there was minimal information about
class B in the test gdb.cp/converts.exp. To fix this, we just need to
construct any object of type B in that file.
Bruno Larsen [Fri, 9 Sep 2022 18:34:27 +0000 (20:34 +0200)]
gdb/testsuite: add XFAIL to gdb.cp/ptype-flags.exp when using clang
When running gdb.cp/ptype-flags.exp using Clang, we get an unexpected
failure when printing the type of a class with an internal typedef. This
happens because Clang doesn't add accessibility information for typedefs
inside classes (see https://github.com/llvm/llvm-project/issues/57608
for more info). To help with Clang testing, an XFAIL was added to this
test.
Fuzzers have found a weakness in the code stashing pool section
entries. With random nonsensical values in the index entries (rather
than each index pointing to its own set distinct from other sets),
it's possible to overflow the space allocated, losing the NULL
terminator. Without a terminator, find_section_in_set can run off the
end of the shndx_pool buffer. Fix this by scanning the pool directly.
binutils/
* dwarf.c (add_shndx_to_cu_tu_entry): Delete range check.
(end_cu_tu_entry): Likewise.
(process_cu_tu_index): Fill shndx_pool by directly scanning
pool, rather than indirectly from index entries.
Tsukasa OI [Sat, 24 Sep 2022 09:11:52 +0000 (09:11 +0000)]
sim/sh: Remove redundant function declaration
Clang generates a warning if there is a function declaration/definition
with zero arguments. Such declarations/definitions without a prototype (an
argument list) are deprecated forms of indefinite arguments
("-Wdeprecated-non-prototype"). On the default configuration, it causes a
build failure (unless "--disable-werror" is specified).
But there is another issue. This function declaration in sim/sh/interp.c
is completely redundant. This commit just removes that declaration.
Tsukasa OI [Sat, 24 Sep 2022 09:54:32 +0000 (09:54 +0000)]
sim/erc32: Use int32_t as IRQ callback argument
Clang generates a warning if an argument is passed to a function without
prototype (zero arguments, even without (void)). Such calls are deprecated
forms of indefinite arguments passing ("-Wdeprecated-non-prototype").
On the default configuration, it (somehow) doesn't cause a build failure but
a warning is generated.
But because the cause is the same as the issue the author fixed in
"sim/erc32: Use int32_t as event callback argument", it would be better to
fix it now to prevent problems in the future.
To fix the issue, this commit makes struct irqcall to use int32_t as a
callback (callback) argument of an IRQ.
Tsukasa OI [Sat, 24 Sep 2022 09:49:42 +0000 (09:49 +0000)]
sim/erc32: Use int32_t as event callback argument
Clang generates a warning if an argument is passed to a function without
prototype (zero arguments, even without (void)). Such calls are deprecated
forms of indefinite arguments passing ("-Wdeprecated-non-prototype").
On the default configuration, it causes a build failure (unless
"--disable-werror" is specified).
To fix that, this commit makes struct evcell to use int32_t as a callback
(cfunc) argument of an event. int32_t is chosen because "event" function
accepts "int32_t arg".
Tsukasa OI [Sat, 24 Sep 2022 09:16:57 +0000 (09:16 +0000)]
sim/erc32: Insert void parameter
Clang generates a warning if there is a function declaration/definition
with zero arguments. Such declarations/definitions without a prototype (an
argument list) are deprecated forms of indefinite arguments
("-Wdeprecated-non-prototype"). On the default configuration, it causes a
build failure (unless "--disable-werror" is specified).
This commit replaces () with (void) to avoid this warning.
Tom de Vries [Sat, 29 Oct 2022 07:43:32 +0000 (09:43 +0200)]
[gdb/testsuite] Use ssh -t in remote-*.exp
When running test-case gdb.server/multi-ui-errors.exp on target board
remote-gdbserver-on-localhost.exp, I run into:
...
(gdb) PASS: gdb.server/multi-ui-errors.exp: connect to gdbserver
continue^M
Continuing.^M
PASS: gdb.server/multi-ui-errors.exp: continue - extra UI
Remote debugging from host ::1, port 35466^M
FAIL: gdb.server/multi-ui-errors.exp: ensure inferior is running
...
The problem is that the target board uses ssh -T, which fails to guarantee
that output from the inferior will be available.
Fix this by copying proc ${board}_spawn from local-remote-host.exp, which
ensures using ssh -t. [ It would be nice to define an ssh base board to
get rid of the copies, but I'm not addressing that in this commit. ]
Likewise for target board remote-stdio-gdbserver.exp.
Tom de Vries [Sat, 29 Oct 2022 07:43:32 +0000 (09:43 +0200)]
[gdb/testsuite] Fix gdb.server/multi-ui-errors.exp with local-remote-host-notty
With test-case gdb.server/multi-ui-errors.exp and host board
local-remote-host-notty, I run into:
...
(gdb) PASS: gdb.server/multi-ui-errors.exp: interact with GDB's main UI
Executing on target: kill -9 29666 (timeout = 300)
builtin_spawn -ignore SIGHUP kill -9 29666^M
echo^M
Remote connection closed^M
(gdb) (gdb) FAIL: gdb.server/multi-ui-errors.exp: \
main UI, prompt after gdbserver dies (timeout)
...
In contrast, with local-remote-host (so, everything the same but editing off):
...
(gdb) PASS: gdb.server/multi-ui-errors.exp: interact with GDB's main UI
Executing on target: kill -9 31245 (timeout = 300)
builtin_spawn -ignore SIGHUP kill -9 31245^M
Remote connection closed^M
(gdb) echo^M
(gdb) PASS: gdb.server/multi-ui-errors.exp: main UI, prompt after gdbserver dies
...
The test-case issues a kill, which results in a "Remote connection closed"
message and a prompt.
The problem is that the prompt is not consumed, so the subsequent echo may be
issued before that prompt, which causes a mismatch when matching the result
of the echo.
Fix this by consuming the "Remote connection closed" message and prompt.
Tom de Vries [Sat, 29 Oct 2022 07:43:32 +0000 (09:43 +0200)]
[gdb/testsuite] Consume output asap in gdb.server/multi-ui-errors.exp
With test-case gdb.server/multi-ui-errors.exp we see:
...
(gdb) PASS: multi-ui-errors.exp: main UI, prompt after gdbserver dies
continue^M
Continuing.^M
echo^M
(gdb) PASS: multi-ui-errors.exp: extra UI, prompt after gdbserver dies
...
The continue is issued earlier in the test-case, but the output has not been
consumed, which makes it show up much later.
Consume the continue output asap, to make it clear when the continue is issued:
...
(gdb) PASS: gdb.server/multi-ui-errors.exp: connect to gdbserver
continue^M
Continuing.^M
PASS: gdb.server/multi-ui-errors.exp: continue - extra UI
...
Tsukasa OI [Mon, 17 Oct 2022 15:47:23 +0000 (15:47 +0000)]
sim, sim/{m32c,ppc,rl78}: Use getopt_long
Because of a Libiberty hack, getopt on GNU libc (2.25 or earlier) is
currently unusable on sim, causing a regression on CentOS 7.
This is caused as follows:
1. If HAVE_DECL_GETOPT is defined (getopt declaration with known prototype
is detected while configuration), a declaration of getopt in
"include/getopt.h" is suppressed.
The author started to define HAVE_DECL_GETOPT in sim with the commit 340aa4f6872c ("sim: Check known getopt definition existence").
2. GNU libc (2.25 or earlier)'s <unistd.h> includes <getopt.h> with a
special purpose macro defined to declare only getopt function but due
to include path (not tested while configuration), it causes <unistd.h>
to include Libiberty's "include/getopt.h".
3. If both 1. and 2. are satisfied, despite that <unistd.h> tries to
declare getopt by including <getopt.h>, "include/getopt.h" does not do
so, causing getopt function undeclared.
Getting rid of "include/getopt.h" (e.g. renaming this header file) is the
best solution to avoid hacking but as a short-term solution, this commit
replaces getopt with getopt_long under sim/.
Alan Modra [Sat, 29 Oct 2022 00:01:01 +0000 (10:31 +1030)]
NULL dereference read in som_write_object_contents
objcopy copy_object may omit the call to bfd_copy_private_bfd_data for
various conditions deemed non-fatal, in which case obj_som_exec_data
will be NULL for the output file.
Tsukasa OI [Thu, 6 Oct 2022 04:18:52 +0000 (04:18 +0000)]
RISC-V: Fallback for instructions longer than 64b
We don't support instructions longer than 64-bits yet. Still, we can
modify validate_riscv_insn function to prevent unexpected behavior by
limiting the "length" of an instruction to 64-bit (or less).
gas/ChangeLog:
* config/tc-riscv.c (validate_riscv_insn): Fix function
description comment based on current spec. Limit instruction
length up to 64-bit for now. Make sure that required_bits does
not corrupt even if unsigned long long is longer than 64-bit.
Jan Beulich [Fri, 28 Oct 2022 13:47:03 +0000 (15:47 +0200)]
RISC-V/gas: fix build with certain gcc versions
Some versions of gcc warn by default about shadowed outer-scope
declarations. This affects frag_align_code, which is declared in
frags.h. Rename the offending function parameter. While there also
switch to using true/false at the function call sites.
Tsukasa OI [Fri, 28 Oct 2022 06:46:13 +0000 (06:46 +0000)]
RISC-V: Fix build failure for -Werror=maybe-uninitialized
Commit 40f1a1a4564b ("RISC-V: Output mapping symbols with ISA string.")
caused a build failure on GCC 12 as follows:
make[3]: Entering directory '$(builddir)/gas'
CC config/tc-riscv.o
In file included from $(srcdir)/gas/config/tc-riscv.c:23:
$(srcdir)/gas/as.h: In function ‘make_mapping_symbol’:
$(srcdir)/gas/as.h:123:15: error: ‘buff’ may be used uninitialized [-Werror=maybe-uninitialized]
123 | #define xfree free
| ^~~~
$(srcdir)/gas/config/tc-riscv.c:487:9: note: ‘buff’ was declared here
487 | char *buff;
| ^~~~
cc1: all warnings being treated as errors
make[3]: *** [Makefile:1425: config/tc-riscv.o] Error 1
This is caused by a false positive of "maybe uninitialized" variable
detection (-Wmaybe-uninitialized). To avoid this error, this commit
initializes the local variable buff to NULL first in all cases.
gas/ChangeLog:
* config/tc-riscv.c (make_mapping_symbol): Initialize variable
buff with NULL to avoid build failure caused by a GCC's false
positive of maybe uninitialized variable detection.
Tsukasa OI [Thu, 27 Oct 2022 04:33:37 +0000 (04:33 +0000)]
include: Define macro to ignore -Wdeprecated-declarations on GCC
"-Wdeprecated-declarations" warning option can be helpful to track
deprecated function delarations but sometimes we need to disable this
warning for a good reason.
DIAGNOSTIC_IGNORE_DEPRECATED_DECLARATIONS is an existing macro but only
defined on Clang. Since "-Wdeprecated-declarations" is also available on
GCC (>= 3.4.0), this commit adds equivalent definition as Clang.
__GNUC__ and __GNUC_MINOR__ are not checked because this header file seems
to assume GCC >= 4.6 (with "GCC diagnostic push/pop").
include/ChangeLog:
* diagnostics.h (DIAGNOSTIC_IGNORE_DEPRECATED_DECLARATIONS):
Define also on GCC.
bfd/
* elfxx-riscv.c (riscv_release_subset_list): Free arch_str if needed.
(riscv_copy_subset_list): Copy arch_str as well.
* elfxx-riscv.h (riscv_subset_list_t): Store arch_str for each subset list.
gas/
* config/tc-riscv.c (riscv_reset_subsets_list_arch_str): Update the
architecture string in the subset_list.
(riscv_set_arch): Call riscv_reset_subsets_list_arch_str after parsing new
architecture string.
(s_riscv_option): Likewise.
(need_arch_map_symbol): New boolean, used to indicate if .option
directives do affect instructions.
(make_mapping_symbol): New boolean parameter reset_seg_arch_str. Need to
generate $x+arch for MAP_INSN, and then store it into tc_segment_info_data
if reset_seg_arch_str is true.
(riscv_mapping_state): Decide if we need to add $x+arch for MAP_INSN. For
now, only add $x+arch if the architecture strings in subset list and segment
are different. Besides, always add $x+arch at the start of section, and do
not add $x+arch for code alignment, since rvc for alignment can be judged
from addend of R_RISCV_ALIGN.
(riscv_remove_mapping_symbol): If current and previous mapping symbol have
same value, then remove the current $x only if the previous is $x+arch;
Otherwise, always remove previous.
(riscv_add_odd_padding_symbol): Updated.
(riscv_check_mapping_symbols): Don't need to add any $x+arch if
need_arch_map_symbol is false, so changed them to $x.
(riscv_frag_align_code): Updated since riscv_mapping_state is changed.
(riscv_init_frag): Likewise.
(s_riscv_insn): Likewise.
(riscv_elf_final_processing): Call riscv_release_subset_list to release
subset_list of riscv_rps_as, rather than only release arch_str in the
riscv_write_out_attrs.
(riscv_write_out_attrs): No need to call riscv_arch_str, just get arch_str
from subset_list of riscv_rps_as.
* config/tc-riscv.h (riscv_segment_info_type): Record current $x+arch mapping
symbol of each segment.
* testsuite/gas/riscv/mapping-0*: Merged and replaced by mapping.s.
* testsuite/gas/riscv/mapping.s: New testcase, to test most of the cases in
one file.
* testsuite/gas/riscv/mapping-symbols.d: Likewise.
* testsuite/gas/riscv/mapping-dis.d: Likewise.
* testsuite/gas/riscv/mapping-non-arch.s: New testcase for the case that
does need any $x+arch.
* testsuite/gas/riscv/mapping-non-arch.d: Likewise.
* testsuite/gas/riscv/option-arch-01a.d: Updated.
opcodes/
* riscv-dis.c (riscv_disassemble_insn): Set riscv_fpr_names back to
riscv_fpr_names_abi or riscv_fpr_names_numeric when zfinx is disabled
for some specfic code region.
(riscv_get_map_state): Recognized mapping symbols $x+arch, and then reset
the architecture string once the ISA is different.
Peter Bergner [Sat, 8 Oct 2022 21:19:51 +0000 (16:19 -0500)]
PowerPC: Add support for RFC02658 - MMA+ Outer-Product Instructions
gas/
* config/tc-ppc.c (md_assemble): Only check for prefix opcodes.
* testsuite/gas/ppc/rfc02658.s: New test.
* testsuite/gas/ppc/rfc02658.d: Likewise.
* testsuite/gas/ppc/ppc.exp: Run it.
Andrew Burgess [Mon, 24 Oct 2022 15:55:07 +0000 (16:55 +0100)]
sim/cgen: initialize variable at creation in engine_run_n
Zero initialize engine_fns entirely at creation, then override those
fields we intend to use, rather than zero just initializing the unused
fields later on.
There should be no user visible changes after this commit.
Tom de Vries [Thu, 27 Oct 2022 14:53:12 +0000 (16:53 +0200)]
[gdb/testsuite] Fix silent timeouts in gdb.mi/mi-exec-run.exp with remote host
I noticed that running test-case gdb.mi/mi-exec-run.exp with host board
local-remote-host.exp takes about 44 seconds.
I found two silent timeouts responsible for this.
The first is in mi_gdb_exit, where we have:
...
if { [is_remote host] && [board_info host exists fileid] } {
send_gdb "999-gdb-exit\n"
gdb_expect 10 {
-re "y or n" {
send_gdb "y\n"
exp_continue
}
-re "Undefined command.*$gdb_prompt $" {
send_gdb "quit\n"
exp_continue
}
-re "DOSEXIT code" { }
}
}
...
so in gdb.log we see:
...
999-gdb-exit^M
999^exit^M
=thread-exited,id="1",group-id="i1"^M
=thread-group-exited,id="i1"^M
...
after which expect just waits for the timeout.
Fix this by adding a gdb_expect clause to parse the exit:
...
-re "\r\n999\\^exit\r\n" { }
...
Note that we're not parsing the thread-exited/thread-group-exited messages, because
they may not be present:
...
$ gdb -i=mi
=thread-group-added,id="i1"
(gdb)
999-gdb-exit
999^exit
$
...
After fixing that, we have:
...
(gdb) ^M
saw mi error
PASS: gdb.mi/mi-exec-run.exp: inferior-tty=separate: mi=separate: \
force-fail=1: run failure detected
quit^M
&"quit\n"^M
...
What seems to be happening is that default_gdb_exit sends a cli interpreter
quit command to an mi interpreter, after which again expect just waits for the
timeout.
Fix this by adding mi_gdb_exit to the end of the test-case, as in many other
gdb.mi/*.exp test-cases.
After these two fixes, the test-case takes about 4 seconds.
Tom de Vries [Thu, 27 Oct 2022 14:53:12 +0000 (16:53 +0200)]
[gdb/testsuite] Use remote_exec chmod instead of remote_spawn
I build gdb using -O2, and ran the testsuite using taskset -c 0, and ran into:
...
(gdb) PASS: gdb.server/connect-with-no-symbol-file.exp: sysroot=: \
action=delete: setup: adjust sysroot
builtin_spawn gdbserver --once localhost:2385 /connect-with-no-symbol-file^M
/bin/bash: connect-with-no-symbol-file: Permission denied^M
/bin/bash: line 0: exec: connect-with-no-symbol-file: cannot execute: \
Permission denied^M
During startup program exited with code 126.^M
Exiting^M
target remote localhost:2385^M
`connect-with-no-symbol-file' has disappeared; keeping its symbols.^M
localhost:2385: Connection timed out.^M
(gdb) FAIL: gdb.server/connect-with-no-symbol-file.exp: sysroot=: \
action=delete: connection to GDBserver succeeded
...
The expected series of events is (skipping disconnect and detach as I don't
think they're relevant to the problem):
- enter scenario "permission"
- cp $exec.bak $exec
- gdbserver start with $exec
- chmod 000 $exec
- connect to gdbserver
- enter scenario "delete"
- cp $exec.bak $exec
- gdbserver start with $exec
- delete $exec
- connect to gdbserver
The problem is that the chmod is executed using remote_spawn:
...
} elseif { $action == "permission" } {
remote_spawn target "chmod 000 $target_exec"
}
...
without waiting on the resulting spawn id, so we're not sure when the
chmod will have effect.
The FAIL we're seeing above is explained by the chmod having effect during the
delete scenario, after the "cp $exec.bak $exec" and before the "gdbserver
start with $exec".
Fix this by using remote_exec instead.
Likewise, fix a similar case in gdb.mi/mi-exec-run.exp.
Nelson Chu [Thu, 27 Oct 2022 01:39:13 +0000 (09:39 +0800)]
RISC-V: Fix build failures for -Werror=sign-compare.
elfnn-riscv.c: In function ‘riscv_relax_resolve_delete_relocs’:
elfnn-riscv.c:4256:30: error: operand of ‘?:’ changes signedness from ‘int’ to ‘unsigned int’ due to unsignedness of other operand [-Werror=sign-compare]
So make the operands unsigned could resolve problem.
bfd/
* elfnn-riscv.c (riscv_relax_resolve_delete_relocs): Fixed build
failures for -Werror=sign-compare.
Alan Modra [Thu, 27 Oct 2022 05:31:17 +0000 (16:01 +1030)]
Fuzzed files in archives
Given a fuzzed object file in an archive with section size exceeding
file size, objcopy will report an error like "section size (0xfeffffff
bytes) is larger than file size (0x17a bytes)" but will create a copy
of the object laid out for the large section. That means a large
temporary file on disk that is read back and written to the output
archive, which can take a while. The output archive is then deleted
due to the error. Avoid some of this silliness.
* objcopy.c (copy_section): If section contents cannot be read
set output section size to zero.
Alan Modra [Thu, 27 Oct 2022 00:52:13 +0000 (11:22 +1030)]
re: Support Intel AMX-FP16
Fix these fails due to the target padding out sections with nops.
x86_64-w64-mingw32 +FAIL: x86_64 AMX-FP16 insns
x86_64-w64-mingw32 +FAIL: x86_64 AMX-FP16 insns (Intel disassembly)
Alan Modra [Thu, 27 Oct 2022 00:15:18 +0000 (10:45 +1030)]
Re: ld/testsuite: adjust ld-arm to run shared tests only when supported
commit 67527cffcd enabled previously disabled tests unresolved-1-dyn,
thumb-plt and thumb-plt-got for nacl. The first fails due to trying
to link against mixed-lib.so which isn't compiled for nacl. The last
two fail with
objdump: tmpdir/dump(.rel.plt): relocation 0 has invalid symbol index 14885104
and
readelf: Error: bad symbol index: 00e320f0 in reloc
Relocation section '.rel.plt' at offset 0x128 contains 1 entry:
Offset Info Type Sym. Value Symbol's Name e320f000e320f000 R_ARM_NONE
* testsuite/ld-arm/arm-elf.exp: Disable unresolved-1-dyn,
thumb-plt and thumb-plt-got for nacl.
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 6bbe1a929c6 ("[gdb/testsuite] Fix gdb.guile/scm-breakpoint.exp
with guile 3.0").
Luis Machado [Wed, 26 Oct 2022 12:00:50 +0000 (13:00 +0100)]
gdb/arm: Fix M-profile EXC_RETURN
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.
Luis Machado [Wed, 26 Oct 2022 11:59:13 +0000 (12:59 +0100)]
gdb/arm: Terminate frame unwinding in M-profile lockup
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.
projects / thirdparty / binutils-gdb.git / log
