- declare a new struc aarch_protection_opts to store all the
configuration options related to software protections (i.e. bti-plt,
pac-plt, bti-report level).
- add a new option "-z bti-report" to configure the log level of reported
issues when BTI PLT is forced.
- encapsulate the BTI report inside _bfd_aarch64_elf_check_bti_report.
- moved all the BTI and PAC tests into a new subfolder: "protections".
bti-far-*
bti-plt-*
bti-pac-plt-*
- move several procedures used only for AArch64 linker tests to a new exp
library file aarch64-elf-lib.exp in ld/testsuite/ld-aarch64/lib.
- use aarch64-elf-lib.exp in aarch64-ld.exp and aarch64-protections.exp.
The test gdb.cp/step-and-next-inline.exp creates a test binary called
step-and-next-inline-no-header. This test includes a function
`tree_check` which is inlined 3 times.
When testing with some older versions of gcc (I've tried 8.4.0, 9.3.1)
we see the following DWARF representing one of the inline instances of
tree_check:
<2><8d9>: Abbrev Number: 38 (DW_TAG_inlined_subroutine)
<8da> DW_AT_abstract_origin: <0x9ee>
<8de> DW_AT_entry_pc : 0x401165
<8e6> DW_AT_GNU_entry_view: 0
<8e7> DW_AT_ranges : 0x30
<8eb> DW_AT_call_file : 1
<8ec> DW_AT_call_line : 52
<8ed> DW_AT_call_column : 10
<8ee> DW_AT_sibling : <0x92d>
...
<1><9ee>: Abbrev Number: 46 (DW_TAG_subprogram)
<9ef> DW_AT_external : 1
<9ef> DW_AT_name : (indirect string, offset: 0xe8): tree_check
<9f3> DW_AT_decl_file : 1
<9f4> DW_AT_decl_line : 38
<9f5> DW_AT_decl_column : 1
<9f6> DW_AT_linkage_name: (indirect string, offset: 0x2f2): _Z10tree_checkP4treei
<9fa> DW_AT_type : <0x9e8>
<9fe> DW_AT_inline : 3 (declared as inline and inlined)
<9ff> DW_AT_sibling : <0xa22>
...
Contents of the .debug_ranges section:
Offset Begin End
...
00000030 0000000000401165 0000000000401165 (start == end)
00000030 0000000000401169 0000000000401173
00000030 0000000000401040 0000000000401045
00000030 <End of list>
...
Notice that one of the sub-ranges of tree-check is empty, this is the
line marked 'start == end'. As the end address is the first address
after the range, this range cover absolutely no code.
But notice too that the DW_AT_entry_pc for the inline instance points
at this empty range.
Further, notice that despite the ordering of the sub-ranges, the empty
range is actually in the middle of the region defined by the lowest
address to the highest address. The ordering is not a problem, the
DWARF spec doesn't require that ranges be in any particular order.
However, this empty range is causing issues with GDB newly acquire
DW_AT_entry_pc support.
GDB already rejects, and has done for a long time, empty sub-ranges,
after all, the DWARF spec is clear that such a range covers no code.
The recent DW_AT_entry_pc patch also had GDB reject an entry-pc which
was outside of the low/high bounds of a block.
But in this case, the entry-pc value is within the bounds of a block,
it's just not within any useful sub-range. As a consequence, GDB is
storing the entry-pc value, and making use of it, but when GDB stops,
and tries to work out which block the inferior is in, it fails to spot
that the inferior is within tree_check, and instead reports the
function into which tree_check was inlined.
I've tested with newer versions of gcc (12.2.0 and 14.2.0) and with
these versions gcc is still generating the empty sub-range, but now
this empty sub-range is no longer the entry point. Here's the
corresponding ranges table from gcc 14.2.0:
Contents of the .debug_rnglists section:
Table at Offset: 0:
Length: 0x56
DWARF version: 5
Address size: 8
Segment size: 0
Offset entries: 0
Offset Begin End
...
00000021 0000000000401165 000000000040116f
0000002b 0000000000401040 (base address)
00000034 0000000000401040 0000000000401040 (start == end)
00000037 0000000000401041 0000000000401046
0000003a <End of list>
...
The DW_AT_entry_pc is 0x401165, but this is not the empty sub-range,
as a result, when GDB stops at the entry-pc, GDB will correctly spot
that the inferior is in the tree_check function.
The fix I propose here is, instead of rejecting entry-pc values that
are outside the block's low/high range, instead reject entry-pc values
that are not inside any of the block's sub-ranges.
Now, GDB will ignore the prescribed entry-pc, and will instead select
a suitable default entry-pc based on either the block's low-pc value,
or the first address of the first range.
I have extended the gdb.cp/step-and-next-inline.exp test to check this
case, but this does depend on the compiler version being used (newer
compilers will always pass, even without the fix).
So I have also added a DWARF assembler test to cover this case.
Reviewed-By: Kevin Buettner <kevinb@redhat.com>
The baseline was, afaik, specifically chosen to align with the baseline
ISA of x86-64. It therefore makes no sense to emit that property only
conditionally; if anything it confuses tools analyzing the difference
between generated object files, which may result from just
added / changed / removed (entirely ISA-independent) code, without any
change to the enabled extensions. Compilers, after all, are free to use
these baseline "extensions" when generating 64-bit code.
While changing the one testcase that needs adjustment, also correct its
misleading name (to be in sync with the filename).
On the grounds of the principle put down near the bottom of [1], along
with image and section relative operations, let's also support as insn
operands what .secidx is for on the data side (of course like elsewhere
the reloc operator can then also be used for data generation, albeit a
small tweak to x86_cons() is needed for this to work).
[1] https://sourceware.org/pipermail/binutils/2024-November/137617.html
As was pointed out in [1] compilers produce code using such constructs,
and hence we'd better support this. In analogy to the .rva directive
permit @rva to be used for this, and in analogy with other architectures
(plus to not diverge from e.g. Clang's integrated assembler, albeit I
haven't been able myself to confirm it knows this form) also permit
@imgrel.
While there also adjust the operand type specifier for the adjacent
@secrel32 - 64-bit fields cannot be used with a 32-bit relocation.
Further while there also deal with *-*-pe* in x86-64.exp, even if (right
now) perhaps only for completeness.
[1] https://sourceware.org/pipermail/binutils/2024-November/137548.html
Add missing return statements in
* gdb.threads/process-exit-status-is-leader-exit-status.c
* gdb.threads/next-fork-exec-other-thread.c
to fix 'no return statement' compiler warnings, e.g.:
process-exit-status-is-leader-exit-status.c: In function ‘start’:
process-exit-status-is-leader-exit-status.c:46:1: warning: no return
statement in function returning non-void [-Wreturn-type]
46 | }
| ^
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Fix more potential buffer overflows, and correct trad-code.c and
cisco-core.c where they should be using bfd_{z}alloc rather than
bfd_{z}malloc. To stop buffer overflows with fuzzed objects that
don't have a terminator on the core_file_failing_command string, this
patch allocates an extra byte at the end of the entire header buffer
rather than poking a NUL at the end of the name array (u_comm[] or
similar) because (a) it's better to not overwrite the file data, and
(b) it is possible that some core files make use of fields in struct
user beyond the end of u_comm to extend the command name. The patch
also changes some unnecessary uses of bfd_zalloc to bfd_alloc.
There's not much point in clearing memeory that will shortly be
completely overwritten.
PR 32399
* aix5ppc-core.c (xcoff64_core_p): Allocate an extra byte to
ensure the core_file_failing_command string is terminated.
* netbsd-core.c (netbsd_core_file_p): Likewise.
* ptrace-core.c (ptrace_unix_core_file_p): Likewise.
* rs6000-core.c (rs6000coff_core_p): Likewise.
* trad-core.c (trad_unix_core_file_p): Likewise, and bfd_alloc
tdata rather than bfd_zmalloc.
* cisco-core.c (cisco_core_file_validate): bfd_zalloc tdata.
Remove another adjustment for section address, this time for the
offset into .debug_str{,.dwo} read from .debug_str_offsets{,.dwo} by
fetch_indexed_string.
Signed-off-by: oltolm <oleg.tolmatcev@gmail.com>
Commit 36bbf8646c ("s390: Treat addressing operand sequence as one in
disassembler") changed how plain "nop" gets disassembled and missed to
update any affected linker tests accordingly.
ld/testsuite/
* ld-s390/tlsbin.dd: "nop" disassembles into "nop".
Fixes: 36bbf8646c ("s390: Treat addressing operand sequence as one in disassembler")
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
The index register operand X in D(X,B) can optionally be omitted by
coding D(,B) or D(B). Simplify the parsing logic.
gas/
* config/tc-s390.c (md_gather_operands): Rename
omitted_base_or_index to omitted_index and simplify logic.
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
Reuse logic introduced with the preceding commit in the assembler to
treat addressing operand sequences D(X,B), D(B), and D(L,B) as one
with regards to optional last operands (i.e. optparm and optparm2).
With this "nop" now disassembles into "nop" instead of "nop 0".
opcodes/
* s390-dis.c (operand_count): New helper to count the remaining
operands, treating D(X,B), D(B), and D(L,B) as one.
(skip_optargs_p): New helper to test whether remaining operands
are optional.
(skip_optargs_zero_p): New helper to test whether remaining
operands are optional and their values are zero.
(s390_print_insn_with_opcode): Use skip_optargs_zero_p to skip
optional last operands with a value of zero.
gas/testsuite/
* gas/s390/zarch-optargs.d (nop): Adjust test case accordingly.
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
The assembler erroneously treated any number of operands as optional,
if the instruction was flagged to have one or two optional operands
(i.e. optparm or optparm2).
Only treat the exact specified number of operands as optional while
treating addressing operand sequences D(X,B), D(B), and D(L,B) as one
operand.
gas/
* config/tc-s390.c (operand_count): New helper to count the
remaining operands, treating D(X,B), D(B), and D(L,B) as one.
(skip_optargs_p): Use new helper operand_count to treat
D(X,B), D(B), and D(L,B) as one operand.
(md_gather_operands): Use skip_optargs_p to skip only the
optional last operands.
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
"nop D1(B1)" erroneously disassembled into "nop D1(B1" (missing
closing parenthesis). "nop D1(X1,0)" and "nop D1(X1,)" erroneously
disassembled into "nop D1(X1)" (missing zero base register) instead
of "nop D1(X1,0)".
Do not skip disassembly of optional operands if they are index (X)
or base (B) registers or length (L) in an addressing operand sequence
"D(X,B)", "D(B)", or "D(L,B). Index and base register operand values
of zero are being handled separately, as they may not be omitted
unconditionally. For instance a base register value of zero must be
printed in above mentioned case, to distinguish the index from the
base register. This also ensures proper formatting of addressing
operand sequences.
While at it add further test cases for instructions with optional
operands.
opcodes/
* s390-dis.c (s390_print_insn_with_opcode): Do not
unconditionally skip disassembly of optional operands with a
value of zero, if within an addressing operand sequence.
gas/testsuite/
* gas/s390/zarch-optargs.d: Add further test cases for
instructions with optional operands.
* gas/s390/zarch-optargs.s: Likewise.
Reported-by: Florian Krohm <flo2030@eich-krohm.de>
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
When there for Solaris compatibility only, also recognize it only there.
This way the option becomes available for other possible uses.
While adjusting md_shortopts[], also re-arrange things such that we have
only a single, uniform definition of it.
Sun specifies an alternative form for CMOVcc [1], which for some reason
we never cared to support, even if - as per gcc's configure checking for
it - it may have been the only permitted form at some point.
While documentation doesn't indicate FCMOVcc to have similar alternative
forms, gcc assumes so. Hence cover FCMOVcc as well.
[1] https://docs.oracle.com/cd/E37838_01/html/E61064/ennbz.html#XALRMeoizm
Having just one each (AVX512F) ought to be sufficient to cover Intel
syntax disassembly.
In x86-64.exp also reorder tests some, so that related ones are again
next to each other, rather than being interspersed with APX ones.
Assorted targets do not check, as the ELF targets do, that the program
name in a core file is NUL terminated. Fix some of them. I haven't
attempted to fix all targets because editing host specific code can
easily result in build bugs, which aren't discovered until someone
build binutils for that host. (Of the files edited here, I can't
easily compile hpux-core.c and osf-core.c on a linux system.)
PR 32399
* hppabsd-core.c (hppabsd_core_core_file_p): Ensure core_command
string is terminated.
* hpux-core.c (hpux_core_core_file_p): Likewise.
* irix-core.c (irix_core_core_file_p): Likewise.
* lynx-core.c (lynx_core_file_p): Likewise.
* osf-core.c (osf_core_core_file_p): Likewise.
* mach-o.c (bfd_mach_o_core_file_failing_command): Likewise.
In commit 5877690107 ("[gdb/syscalls] Update to linux v6.11") I updated to
linux v6.11, but a recent submission for loongarch [1] used a current trunk
version, so it makes sense to do this as well elsewhere.
Using linux current trunk with update-linux-from-src.sh gets us 4 more
syscalls:
- setxattrat
- getxattrat
- listxattrat
- removexattrat
Tested on x86_64-linux.
[1] https://sourceware.org/pipermail/gdb-patches/2024-November/213613.html
gprofng crashes when the GUI sends an invalid command.
Skip unrecognized commands and return an error status to the GUI.
gprofng/ChangeLog
2024-11-26 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
* src/ipc.cc (ipc_doWork): Skip unrecognized commands.
* src/ipcio.cc (writeError): New function.
* src/ipcio.h: Add RESPONSE_STATUS_ERROR.
Since 2020 it has been reported to clang[1] that the debug information
around OpenMP is insufficient. The OpenMP section is not declared
within the correct scope, and instead clang marks as if the section was
a function in the global scope. This causes several failures in the
test gdb.threads/omp-par-scope.exp when using clang to test GDB.
Since this isn't a true failure of GDB, and there is little expectation
that clang will be able to fix this soon, this commit disables the
aforementioned test when clang is being used.
[1] https://github.com/llvm/llvm-project/issues/44236
Approved-by: Kevin Buettner <kevinb@redhat.com>
Before the fix for PR symtab/32225, the parent map dump showed a mapping from
section offsets to cooked index entries:
...
0x0000000000000035 0x3ba9560 (0x34: sp1::A)
...
but now that's no longer the case:
...
0x00000000406f5405 0x410a04d0 (0x34: sp1::A)
...
Fix this by extending the annotation somewhat, such that we get:
...
map start:
0x0000000012c52405 0x135fd550
(section: .debug_info, offset: 0x35) -> (0x34: sp1::A)
...
Tested on x86_64-linux.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32225
Consider test-case:
...
$ cat test.c
namespace sp1 {
class A {
int i;
const int f1 = 1;
...
const int f29 = 1;
};
}
sp1::A a;
void _start (void) {}
$ cat test2.c
namespace sp2 {
class B {
float f;
const float f1 = 1;
...
const float f29 = 1;
};
}
sp2::B b;
...
compiled like this:
...
$ g++ test.c -gdwarf-4 -c -g -fdebug-types-section
$ g++ test2.c -gdwarf-5 -c -g -fdebug-types-section
$ g++ -g test.o test2.o -nostdlib
...
Using:
...
$ gdb -q -batch -iex "maint set worker-threads 0" a.out -ex "maint print objfiles"
...
we get a cooked index entry with incorrect parent:
...
[29] ((cooked_index_entry *) 0x3c57d1a0)
name: B
canonical: B
qualified: sp1::A::B
DWARF tag: DW_TAG_class_type
flags: 0x0 []
DIE offset: 0x154
parent: ((cooked_index_entry *) 0x3c57d110) [A]
...
The problem is that the parent map assumes that all offsets are in the same
section.
Fix this by using dwarf2_section_info::buffer-relative addresses instead,
which get us instead:
...
[29] ((cooked_index_entry *) 0x3f0962b0)
name: B
canonical: B
qualified: sp2::B
DWARF tag: DW_TAG_class_type
flags: 0x0 []
DIE offset: 0x154
parent: ((cooked_index_entry *) 0x3f096280) [sp2]
...
Tested on x86_64-linux.
PR symtab/32225
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32225
