[wip] Fix range end handling of inlined subroutines
Currently there is a problem when debugging
optimized code when the inferior stops at an inline
sub-range end PC. It is unclear if that location
is from the inline function or from the calling
function. Therefore the call stack is often
wrong.
This patch detects the "weak" line table entries
which are likely part of the previous inline block,
and if we have such a location, it assumes the
location belongs to the previous block.
Additionally it may happen that the infrun machinery
steps from one inline range to another inline range
of the same inline function. That can look like
jumping back and forth from the calling program
to the inline function, while really the inline
function just jumps from a hot to a cold section
of the code, i.e. error handling.
Additionally it may happen that one inline sub-range
is empty or the inline is completely empty. But
filtering that information away is not the right
solution, since although there is no actual code
from the inline, it is still possible that variables
from an inline function can be inspected here.
The issue with the empty ranges is also discussed here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94474
Conceptually this patch uses a heuristic to work around
a deficiency in the dwarf-4 and dwarf-5 rnglists structure.
There should be a location view number for each inline
sub-range begin PC and end PC, similar to the DW_AT_GNU_entry_view
which is the location view for the inline entry point.
This introduces a new line table flag is_weak.
The line entries at the end of a subroutine range,
use this to indicate that they may possibly
be part of the previous subroutine.
When there is a sequence of line entries at the
same address where an inline range ends, and the
last item has is_stmt = 0, we force all previous
items to have is_weak = 1.
Additionally this adds a "fake" end sequence to the
record_line function, that is line number -1.
That will be used in the next patch.
Finally this adds a handling for empty ranges to
record_block_range. Currently this function is
not called with empty ranges, but that will be used
in the next patch.
There should be no functional changes after this commit.
Well, except the new is-weak flag in the line table of course.
As an example consider the following test code:
$ cat test.c
inline int test ()
{
asm ("nop");
return 0;
}
int main ()
{
int x = test ();
return x;
}
$ gcc -g -O2 test.c
This will receive the following line table:
(gdb) maintenance info line-table
INDEX LINE REL-ADDRESS UNREL-ADDRESS IS-STMT IS-WEAK PROLOGUE-END EPILOGUE-BEGIN
0 8 0x0000555555555040 0x0000000000001040 Y
1 9 0x0000555555555040 0x0000000000001040 Y
2 1 0x0000555555555040 0x0000000000001040 Y
3 3 0x0000555555555040 0x0000000000001040 Y
4 4 0x0000555555555041 0x0000000000001041 Y Y
5 4 0x0000555555555041 0x0000000000001041 Y <---+ set is_weak
6 10 0x0000555555555041 0x0000000000001041 Y Y ^
7 11 0x0000555555555041 0x0000000000001041 <----+ no is-stmt
8 END 0x0000555555555044 0x0000000000001044 Y
Rebased on top of current HEAD. Some of these tests are probably
duplicates of tests that have been upstreamed into other locations,
e.g. see recent additions to gdb.opt/
Also, I moved these tests into their own commit to make it easier for
me to move them between branches for testing, but when it comes to
upstreaming, these tests should be merged into the appropriate GDB
related commit, and not left as a commit on their own.
Andrew Burgess [Fri, 26 Jul 2024 15:32:33 +0000 (16:32 +0100)]
gdb: improve line number lookup around inline functions
This commit aims to fix an issue where GDB would report the wrong line
for frames other than #0 if a previous frame had just left an inline
function.
Consider this example which is compiled at -Og:
volatile int global = 0;
static inline int bar (void) { asm (""); return 1; }
static void foo (int count)
{ global += count; }
int main (void)
{
foo (bar ());
return 0;
}
Used in this GDB session:
(gdb) break foo
Breakpoint 1 at 0x401106: file test.c, line 6.
(gdb) run
Starting program: /tmp/inline-bt/test.x
Breakpoint 1, foo (count=count@entry=1) at test.c:6
6 { global += count; }
(gdb) frame 1
#1 0x0000000000401121 in main () at test.c:3
3 static inline int bar (void) { asm (""); return 1; }
Notice that GDB incorrectly reports frame #1 as being at line 3 when
it should really be reporting this line:
foo (bar ());
The cause of this problem is in find_pc_sect_line (symtab.c). This
function is passed a PC for which GDB must find the symtab_and_line
information. The function can be called in two modes based on the
NOTCURRENT argument.
When NOTCURRENT is false then we are looking for information about the
current PC, i.e. the PC at which the inferior is currently stopped
at.
When NOTCURRENT is true we are looking for information about a PC that
it not the current PC, but is instead the PC for a previous frame.
The interesting thing in this case is that the PC passed in will be
the address after the address we actually want to lookup information
for, this is because as we unwind the program counter from frame #0
what we get is the return address in frame #1. The return address is
often (or sometimes) on the line after the calling line, and so in
find_pc_sect_line, when NOTCURRENT is true, we subtract 1 from PC and
then proceed as normal looking for information about this new PC
value.
Now lets look at the x86-64 disassembly for 'main' from the above
example. The location marker (=>) represents the return address in
'main' after calling 'foo':
(gdb) run
Starting program: /tmp/inline-bt/test.x
Breakpoint 1, foo (count=count@entry=1) at test.c:6
6 { global += count; }
#0 foo (count=count@entry=1) at test.c:6
#1 0x000000000040111f in main () at test.c:3
(gdb) up
#1 0x000000000040111f in main () at test.c:3
3 static inline int bar (void) { asm (""); return 1; }
(gdb) disassemble
Dump of assembler code for function main:
0x0000000000401115 <+0>: mov $0x1,%edi
0x000000000040111a <+5>: call 0x401106 <foo>
=> 0x000000000040111f <+10>: mov $0x0,%eax
0x0000000000401124 <+15>: ret
End of assembler dump.
And the corresponding line table:
(gdb) maintenance info line-table
objfile: /tmp/inline-bt/test.x ((struct objfile *) 0x59405a0)
compunit_symtab: test.c ((struct compunit_symtab *) 0x53ad320)
symtab: /tmp/inline-bt/test.c ((struct symtab *) 0x53ad3a0)
linetable: ((struct linetable *) 0x53adc90):
INDEX LINE REL-ADDRESS UNREL-ADDRESS IS-STMT PROLOGUE-END EPILOGUE-BEGIN
0 6 0x0000000000401106 0x0000000000401106 Y
1 6 0x0000000000401106 0x0000000000401106 Y
2 6 0x0000000000401106 0x0000000000401106
3 6 0x0000000000401114 0x0000000000401114
4 9 0x0000000000401115 0x0000000000401115 Y
5 10 0x0000000000401115 0x0000000000401115 Y
6 3 0x0000000000401115 0x0000000000401115 Y
7 3 0x0000000000401115 0x0000000000401115 Y
8 3 0x0000000000401115 0x0000000000401115 Y
9 10 0x0000000000401115 0x0000000000401115
10 11 0x000000000040111f 0x000000000040111f Y
11 12 0x000000000040111f 0x000000000040111f
12 END 0x0000000000401125 0x0000000000401125 Y
When looking for the line information of frame #1 we start with the
return address 0x40111f, however, as this is not the current program
counter value we subtract one and look for line information for
0x40111e.
We will find the entry at index 9, this is the last entry with an
address less than the address we're looking for, the next entry has an
address greater than the one we're looking for. The entry at index 9
is for line 10 which is the correct line, but GDB reports line 3, so
what's going on?
Having found a matching entry GDB checks to see if the entry is marked
as is-stmt (is statement). In our case index 9 (line 10) is not a
statement, and so GDB looks backwards for entries at the same address,
if any of these are marked is-stmt then GDB will use the last of these
instead. In our case the previous entry at index 8 is marked is-stmt,
and so GDB uses that. The entry at index 8 is for line 3, and that is
why GDB reports the wrong line. So why perform the backward is-stmt
check?
When NOTCURRENT is false (not our case) the backward scan makes
sense. If the inferior has just stopped at some new location, and we
want to report that location to the user, then it is better (I think)
to select an is-stmt entry. In this way we will report a line number
for a line which the inferior is just about to start executing, and
non of the side effects of that line have yet taken place. The line
GDB prints will correspond with the reported line, and if the user
queries the inferior state, the inferior should (assuming the compiler
emitted correct is-stmt markers) correspond to the line in question
having not yet been started.
However, in our case NOTCURRENT is true. We're looking back to
previous frames that are currently in-progress. If upon return to the
previous frame we are about to execute the next line then (is seems to
me) that this indicates we must be performing the very last action
from the previous line. As such, looking back through the line table
in order to report a line that has not yet started is the wrong thing
to do. We really want to report the very last line table entry for
the previous address as this is (I think) most likely to represent the
previous line that is just about to complete.
Further, in the NOTCURRENT case, we should care less about reporting
an is-stmt line. When a user looks back to a previous frame I don't
think they expect the line being reported to have not yet started. In
fact I think the expectation is the reverse ... after all, the
previous line must have executed enough to call the current frame.
So my proposal is that the backward scan of the line table looking for
an is-stmt entry should not be performed when NOTCURRENT is true. In
the case above this means we will report the entry at index 9, which
is for line 10, which is correct.
For testing this commit I have:
1. Extended the existing gdb.opt/inline-bt.exp test. I've extended
the source code to include a test similar to the example above. I
have also extended the script so that the test is compiled at a
variety of optimisation levels (O0, Og, O1, O2).
2. Added a new DWARF assembler test which hard codes a line table
similar to the example given above. My hope is that even if test
case (1) changes (due to compiler changes) this test will continue to
test the specific case I'm interested in.
I have tested the gdb.opt/inline-bt.exp test with gcc versions 8.4.0,
9.3.1, 10.5.0, 11.5.0, 12.2.0, and 14.2.0, in each case the test will
fail (with the expected error) without this patch applied, and will
pass with this patch applied.
I was inspired to write this patch while reviewing these patches:
though this patch only covers one of the issues addressed by these
patches, and the approach taken is quite different. Still, those
patches are worth reading for the history of this fix.
That series has the fixes here merged along with other changes, and
takes a different approach for how to handle the issue addressed here.
Credit for identifying the original issue belongs with Bernd, the
author of the original patch, who I have included as a co-author on
this patch. A brief description of how the approach taken in this
patch differs from the approach Bernd took can be found at the end of
this commit message.
When compiling with optimisation, it can often happen that gcc will
emit an inline function instance with an empty range associated. This
can happen in two ways. The inline function might have a DW_AT_low_pc
and DW_AT_high_pc, where the high-pc is an offset from the low-pc, but
the high-pc offset is given as 0 by gcc.
Alternatively, the inline function might have a DW_AT_ranges, and one
of the sub-ranges might be empty, though usually in this case, other
ranges will be non-empty.
The second case is made worse in that sometimes gcc will specify a
DW_AT_entry_pc value which points to the address of the empty
sub-range.
My understanding of the DWARF spec is that empty ranges as seen in
these examples indicate that no instructions are associated with the
inline function, and indeed, this is how GDB handles these cases,
rejecting blocks and sub-ranges which are empty.
DWARF-5, 2.17.2, Contiguous Address Range:
The value of the DW_AT_low_pc attribute is the address of the
first instruction associated with the entity. If the value of the
DW_AT_high_pc is of class address, it is the address of the first
location past the last instruction associated with the entity...
DWARF-5, 2.17.3, Non-Contiguous Address Ranges:
A bounded range entry whose beginning and ending address offsets
are equal (including zero) indicates an empty range and may be
ignored.
As a consequence, an attempt by the user to place a breakpoint on an
inline function with an empty low/high address range will trigger
GDB's pending breakpoint message:
(gdb) b foo
Function "foo" not defined.
Make breakpoint pending on future shared library load? (y or [n]) n
While, having the entry-pc point at an empty range forces GDB to
ignore the given entry-pc and select a suitable alternative.
If instead of ignoring these empty ranges, we instead teach GDB to
treat these as non-empty, what we find is that, in all the cases I've
seen, the debug experience is improved.
As a minimum, in the low/high case, GDB now knows about the inline
function, and can place breakpoints that will be hit. Further, in
most cases, local variables from the inline function can be accessed.
If we do start treating empty address ranges as non-empty then we are
deviating from the DWARF spec. It is not clear if we are working
around a gcc bug (I suspect so), or if gcc actually considers the
inline function gone, and we're just getting lucky that the debug
experience seems improved.
My proposed strategy for handling these empty address ranges is to
only perform this work around if the compiler is gcc, so far I've not
seen this issue with Clang (the only other compiler I've tested),
though extending this to other compilers in the future would be
trivial.
Additionally, I only apply the work around for
DW_TAG_inlined_subroutine DIEs, as I've only seen the issue for
inline functions.
If we find a suitable empty address range then the fix-up is to give
the address range a length of 1 byte.
Now clearly, in most cases, 1 byte isn't even going to cover a single
instruction, but so far this doesn't seem to be a problem. An
alternative to using a 1-byte range would be to try and disassemble
the code at the given address, calculate the instruction length, and
use that, the length of one instruction. But this means that the
DWARF parser now needs to make use of the disassembler, which feels
like a big change that I'd rather avoid if possible.
The other alternative is to allow blocks to be created with zero
length address ranges and then change the rest of GDB to allow for
lookup of zero sized blocks to succeed. This is the approach taken by
the original patch series that I linked above.
The results achieved by the original patch are impressive, and Bernd,
the original patch author, makes a good argument that at least some of
the problems relating to empty ranges are a result of deficiencies in
the DWARF specification rather than issues with gcc.
However, I remain unconvinced. But even if I accept that the issue is
with DWARF itself rather than gcc, the question still remains; should
we fix the problem by synthesising new DWARF attributes and/or accept
non-standard DWARF during the dwarf2/read.c phase, and then update GDB
to handle the new reality, or should we modify the incoming DWARF as
we read it to make it fit GDB's existing algorithms.
The original patch, I believe, took the former approach, while I
favour the later, and so, for now, I propose that the single byte
range proposal is good enough, at least until we find counter examples
where this doesn't work.
This leaves just one question: what about the remaining work in the
original patch. That work deals with problems around the end address
of non-empty ranges. The original patch handled that case using the
same algorithm changes, which is neat, but I think there are
alternative solutions that should be investigated. If the
alternatives don't end up working out, then it's trivial to revert
this patch in the future and adopt the original proposal.
For testing I have two approaches, C/C++ test compiled with
optimisation that show the problems discussed. These are good because
they show that these issues do crop up in compiled code. But they are
bad in that the next compiler version might change the way the test is
optimised such that the problem no longer shows.
And so I've backed up the real code tests with DWARF assembler tests
which reproduce each issue.
The DWARF assembler tests are not really impacted by which gcc version
is used, but I've run all of these tests using gcc versions 8.4.0,
9.5.0, 10.5.0, 11.5.0, 12.2.0, and 14.2.0. I see failures in all of
the new tests when using an unpatched GDB, and no failures when using
a patched GDB.
Jan Beulich [Tue, 3 Dec 2024 09:48:16 +0000 (10:48 +0100)]
gas: partly restore how current_location() had worked
Commit 4a826962e760 changed its behavior without saying why, and without
putting in place any testcase demonstrating the required behavior.
Firmly latch the current position unless deferred-evaluation mode is in
effect.
Jan Beulich [Tue, 3 Dec 2024 09:47:36 +0000 (10:47 +0100)]
gas: streamline expr_build_dot()
There's no point involving symbol_clone_if_forward_ref(), just for it to
replace dot_symbol by one obtained from symbol_temp_new_now(). For the
abs-section case also produce a slightly more "complete" (as in: all
potentially relevant fields filled) expression by going through
expr_build_uconstant().
Move the function next to current_location(), for it to be easier to see
the (dis)similarities. Correct the function's comment while there.
Kong Lingling [Tue, 3 Dec 2024 07:34:05 +0000 (15:34 +0800)]
Support Intel AVX10.2 BF16 instructions
In this patch, we will support AVX10.2 BF16 instructions. All of them
are new instructions forms. In current documentation, it is still
VSCALEFPBF16, but it will change to VSCALEFNEPBF16 eventually.
In disassembler part, we added %XB to reduce W table pass since all
of them get evex.w=0.
Simon Marchi [Mon, 2 Dec 2024 15:35:23 +0000 (10:35 -0500)]
gdb, gdbserver, gdbsupport: flatten and sort some list in configure files
This makes the lists easier sort read and modify. There are no changes
in the generated config.h files, so I'm confident this brings no
functional changes.
aarch64: GCS feature check in GNU note properties for input objects
This patch adds support for Guarded Control Stack in AArch64 linker.
This patch implements the following:
1) Defines GNU_PROPERTY_AARCH64_FEATURE_1_GCS bit for GCS in
GNU_PROPERTY_AARCH64_FEATURE_1_AND macro.
2) Adds readelf support to read and print the GCS feature in GNU
properties in AArch64.
Displaying notes found in: .note.gnu.property
[ ]+Owner[ ]+Data size[ ]+Description
GNU 0x00000010 NT_GNU_PROPERTY_TYPE_0
Properties: AArch64 feature: GCS
3) Adds support for the "-z gcs" linker option and document all the values
allowed with this option (-z gcs[=always|never|implicit]) where "-z gcs" is
equivalent to "-z gcs=always". When '-z gcs' option is omitted from the
command line, it defaults to "implicit" and relies on the GCS feature
marking in GNU properties.
4) Adds support for the "-z gcs-report" linker option and document all the
values allowed with this option (-z gcs-report[=none|warning|error]) where
"-z gcs-report" is equivalent to "-z gcs-report=warning". When this option
is omitted from the command line, it defaults to "warning".
The ABI changes adding GNU_PROPERTY_AARCH64_FEATURE_1_GCS to the GNU
property GNU_PROPERTY_AARCH64_FEATURE_1_AND is merged into main and
can be found in [1].
Matthieu Longo [Thu, 7 Nov 2024 14:33:09 +0000 (14:33 +0000)]
aarch64: rename BTI error/warning message
The previous message for missing BTI feature in GNU properties was
not very clear. The new message explains that a missing GNU property
marking is lacking on this specific input.
Matthieu Longo [Tue, 5 Nov 2024 13:22:31 +0000 (13:22 +0000)]
aarch64: limit number of reported issues on missing GNU properties
This patch attempts to make the linker output more friendly for the
developers by limiting the number of emitted warning/error messages
related to BTI issues.
Every time an error/warning related to BTI is emitted, the logger
also increments the BTI issues counter. A batch of errors/warnings is
limited to a maximum of 20 explicit errors/warnings. At the end of
the merge, a summary of the total of errors/warning is given if the
number exceeds the limit of 20 invidual messages.
Matthieu Longo [Wed, 6 Nov 2024 17:59:46 +0000 (17:59 +0000)]
aarch64: bugfix when finding 1st bfd input with GNU property
The current implementation of searching the first input BFD with GNU
properties has a bug. The search was not filtering on object inputs
belonging to the output link unit only, but was also including dynamic
objects, BFD plugins, and linker-created files.
This means that the initial initialization of the output properties
were skewed, and warnings on input files that should have been emitted
were not.
This patch fixes the filtering to exclude the object input files not
belonging to the output link unit, not having the same ELF class, and
not the same target architecture.
Matthieu Longo [Thu, 14 Nov 2024 17:35:24 +0000 (17:35 +0000)]
aarch64: remove early exit when setting up GNU properties with partial linking
There is an early exit in _bfd_aarch64_elf_link_setup_gnu_properties
that is enabled when the output link unit is relocatable, i.e. ld
generates an output file that can in turn serve as input to ld. (see
ld manual, -r,--relocatable for more details).
At this stage, the GNU properties have already been merged and errors
or warnings (if any) have already been issued. However, OUTPROP has
not been updated yet.
Not updating OUTPROP means that implicits enablement of BTI PLTs via
the GNU properties will be ignored for final links. Indeed, the
enablement of BTI PLTs is checked inside _bfd_aarch64_add_call_stub_entries
by looking up at gnu_property_aarch64_feature_1_and (OUTPROP).
Since the final link does not happen in the case of partial linking,
the behaviour with or without the early exit should be the same.
Given that there is currently no comment for explain why the exit is
there, and that there might in the future be cases were these properties
affect relocatable links, it is preferrable to drop the early exit.
Move the code related to the search of the first bfd input with GNU
properties to a separate function:
_bfd_aarch64_elf_find_1st_bfd_input_with_gnu_property
Before this patch, warnings were reported normally, and errors
(introduced by a previous patch adding '-z bti-report' option)
were logged as error but were not provoking a link failure.
The root of the issue was a misuse of _bfd_error_handler to
report the errors.
Replacing _bfd_error_handler by info->callbacks->einfo, with the
addition of the formatter '%X' for errors fixed the issue.
Exposing the output GNU property as a parameter of
_bfd_aarch64_elf_link_setup_gnu_properties seems to break the
encapsulation. The output GNU property update should be part of the
function that sets up the GNU properties.
This patch removes the parameter, and perform the update of the GNU
property on the output object inside the function.
Matthieu Longo [Mon, 28 Oct 2024 18:12:38 +0000 (18:12 +0000)]
aarch64: group software protection options under a same struct.
- 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.
Matthieu Longo [Mon, 28 Oct 2024 13:59:55 +0000 (13:59 +0000)]
aarch64: move tests for AArch64 protections (BTI, PAC) into a subfolder
- 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.
Andrew Burgess [Tue, 19 Nov 2024 21:43:06 +0000 (21:43 +0000)]
gdb: handle DW_AT_entry_pc pointing at an empty sub-range
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:
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:
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.
Jan Beulich [Mon, 2 Dec 2024 08:38:47 +0000 (09:38 +0100)]
x86: always set ISA_1_BASELINE property for 64-bit objects
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).
Jan Beulich [Mon, 2 Dec 2024 08:38:15 +0000 (09:38 +0100)]
x86/COFF: support section-index relocations in insn operands
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).
Jan Beulich [Mon, 2 Dec 2024 08:37:34 +0000 (09:37 +0100)]
x86/COFF: support RVA (image-relative) relocations in insn operands
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.
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.
oltolm [Fri, 29 Nov 2024 21:02:07 +0000 (22:02 +0100)]
Remove more remnants of old Mach-O workaround
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.
Jens Remus [Fri, 29 Nov 2024 15:52:13 +0000 (16:52 +0100)]
s390: Fix linker test TLS -fpic and -fno-pic exec transitions
Commit 36bbf8646c8b ("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: 36bbf8646c8b ("s390: Treat addressing operand sequence as one in disassembler") Signed-off-by: Jens Remus <jremus@linux.ibm.com>
Jens Remus [Fri, 29 Nov 2024 14:37:19 +0000 (15:37 +0100)]
s390: Treat addressing operand sequence as one in disassembler
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.
Jens Remus [Fri, 29 Nov 2024 14:37:19 +0000 (15:37 +0100)]
s390: Treat addressing operand sequence as one in assembler
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.
Jens Remus [Fri, 29 Nov 2024 14:37:19 +0000 (15:37 +0100)]
s390: Fix disassembly of optional addressing operands
"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.
Jan Beulich [Fri, 29 Nov 2024 08:37:13 +0000 (09:37 +0100)]
x86/Solaris: support Sun form of CMOVcc
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.
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.)
In commit 58776901074 ("[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
Guinevere Larsen [Mon, 25 Nov 2024 18:15:36 +0000 (15:15 -0300)]
gdb/testsuite: skip gdb.threads/omp-par-scope.exp with clang
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.
Tom de Vries [Wed, 27 Nov 2024 17:48:43 +0000 (18:48 +0100)]
[gdb/symtab] Fix parent map dump
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)
...
[gdb/symtab] Fix parent map when handling .debug_info and .debug_types
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]
...
Sandra Loosemore [Tue, 26 Nov 2024 19:13:07 +0000 (19:13 +0000)]
nios2: Remove binutils support for Nios II target.
The Nios II architecture has been EOL'ed by the vendor. This patch
removes all binutils, bfd, gas, binutils, and opcodes support for this
target with the exception of the readelf utility. (The ELF EM_*
number remains valid and the relocation definitions from the Nios II
ABI will never change in future, so retaining the readelf support
seems consistent with its purpose as a utility that tries to parse the
headers in any ELF file provided as an argument regardless of target.)
Sandra Loosemore [Tue, 26 Nov 2024 19:13:07 +0000 (19:13 +0000)]
nios2: Remove all GDB support for Nios II targets.
Intel has EOL'ed the Nios II architecture, and it's time to remove support
from all toolchain components before it gets any more bit-rotten from
lack of maintenance or regular testing.
Alan Modra [Mon, 25 Nov 2024 21:54:19 +0000 (08:24 +1030)]
PR32387 ppc64 TLS optimization bug with -fno-plt code
The inline plt code emitted by gcc is incompatible with the
linker/ld.so --tls-get-addr-optimize scheme. This is the runtime
optimisation where the first call to __tls_get_addr results in
__tls_get_addr updating the tls_index pair, then the special linker
stub using that to short-circuit second and subsequent calls for a
given tls symbol. Enabled by default when the linker sees
__tls_get_addr_opt is preseent, and enabled in ld.so when DT_PPC64_OPT
has PPC64_OPT_TLS set. Note that this is distinct from link-time tls
optimisation.
PR 32387
* elf64-ppc.c (ppc64_elf_check_relocs): Disable tls_get_addr_opt
on detecting inline plt calls to __tls_get_addr.
Tom de Vries [Tue, 26 Nov 2024 09:02:37 +0000 (10:02 +0100)]
[gdb/syscalls] Sync with strace v6.12
I ran gdb/syscalls/update-linux-defaults.sh with strace sources v6.12, and got
one difference in gdb/syscalls/linux-defaults.xml.in:
...
+ <syscall name="mseal" groups="memory"/>
...
Rerun make to propagate this change to the xml files.
Tom de Vries [Tue, 26 Nov 2024 08:49:29 +0000 (09:49 +0100)]
[gdb/syscalls] Use update-linux-from-src.sh for arm-linux
I tried to use arm-linux.py to regenerate arm-linux.xml.in, but it didn't work.
Fix this by:
- adding handling of arm-linux.xml.in in update-linux-from-src.sh,
- regenerating arm-linux.xml.in using update-linux-from-src.sh and linux 6.11
sources,
- regenerating arm-linux.xml using make, and
- removing arm-linux.py.
This changes the name "oldolduname" into "olduname".
Tom de Vries [Tue, 26 Nov 2024 08:49:29 +0000 (09:49 +0100)]
[gdb/syscalls] Improve update-linux-from-src.sh
Some improvements in gdb/syscalls/update-linux-from-src.sh:
- use bash instead of sh
- use local to distinguish between local and global vars
(which brings to light that pre uses the global rather than the local
start_date)
- factor out main and parse_args
- factor out regen
- iterate over *.xml.in instead of *.in
Tested on aarch64-linux. Verified with shellcheck.
Simon Marchi [Mon, 4 Nov 2024 18:27:51 +0000 (13:27 -0500)]
Convert all_bfds to new hash table
This converts gdb_bfd.c to use the new hash table for all_bfds.
This patch slightly changes the htab_t pretty-printer test, which was
relying on all_bfds. Note that with the new hash table, gdb-specific
printers aren't needed; the libstdc++ printers suffice -- in fact,
they are better, because the true types of the contents are available.
Change-Id: I48b7bd142085287b34bdef8b6db5587581f94280 Co-Authored-By: Tom Tromey <tom@tromey.com> Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Mon, 4 Nov 2024 18:27:50 +0000 (13:27 -0500)]
Convert typedef hash to new hash table
This converts the typedef hash to use the new hash table.
This patch found a latent bug in the typedef code. Previously, the
hash function looked at the type name, but the hash equality function
used types_equal -- but that strips typedefs, meaning that equality of
types did not imply equality of hashes. This patch fixes the problem
and updates the relevant test.
Change-Id: I0d10236b01e74bac79621244a1c0c56f90d65594 Co-Authored-By: Tom Tromey <tom@tromey.com> Approved-By: Tom Tromey <tom@tromey.com>
projects / thirdparty / binutils-gdb.git / log
