| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Right now, LoongArch linker relaxation is 2-pass, since after alignment
is done, byte deletion can no longer happen. However, as the alignment
pass also shrinks text sections, new relaxation chances may well be
created after alignment is done. Although at this point we can no longer
delete unused instructions without disturbing alignment, we can still
replace them with NOPs; popular LoongArch micro-architectures can
eliminate NOPs during execution, so we can expect a (very) slight
performance improvement from those late-created relaxation chances.
To achieve this, the number of relax passes is raised to 3 for
LoongArch, and every relaxation handler except loongarch_relax_align is
migrated to a new helper loongarch_relax_delete_or_nop, that either
deletes bytes or fills the bytes to be "deleted" with NOPs, depending on
whether the containing section already has undergone alignment. Also,
since no byte can be deleted during this relax pass, in the pass the
pending_delete_ops structure is no longer allocated, and
loongarch_calc_relaxed_addr(x) degrades to the trivial "return x" in
this case.
In addition, previously when calculating distances to symbols, an
extra segment alignment must be considered, because alignment may
increase distance between sites. However in the newly added 3rd pass
code size can no longer increase for "closed" sections, so we can skip
the adjustment for them to allow for a few more relaxation chances.
A simple way to roughly measure this change's effectiveness is to check
how many pcalau12i + addi.d pairs are relaxed into pcaddi's. Taking a
Firefox 140.0.2 test build of mine as an example:
Before: 47842 pcaddi's in libxul.so
After: 48089
This is a 0.5% increase, which is kind of acceptable for a peephole
optimization like this; of which 9 are due to the "relax"ed symbol
distance treatment.
Signed-off-by: WANG Xuerui <git@xen0n.name>
|
|
|
|
For relocatable links the output .sframe section size may be wrong.
This can be observed when dumping the SFrame information from the x86-64
sframe-reloc-1 test:
Name Address Off Size
.sframe 0000000000000000 000110 00007f
Offset Type Symbol's Value Symbol's Name + Addend
000000000000001c R_X86_64_PC32 0000000000000000 .text + 1c
0000000000000030 R_X86_64_PC32 0000000000000000 .text + 65
0x00000000 e2de0201 0300f800 02000000 08000000 ................
0x00000010 1e000000 00000000 28000000 00000000 ........(.......
0x00000020 35000000 00000000 04000000 00000000 5...............
0x00000030 00000000 25000000 0f000000 04000000 ....%...........
offset 1st FRE---^^^^^^^^ ^^^^^^^^---number of FREs
0x00000040 00000000 00030801 0510f004 0410f034 ...............4
FDE info---^^ | begin of FDEs
0x00000050 0508f000 03080105 10f00404 10f02405 ..............$.
11111112222222223333333334444---FRE 1, 2, 3, 4
0x00000060 08f00000 00000000 00000000 00000000 ................
4444^^^^...
0x00000070 00000000 00000000 00000000 000000 ...............
...^^^^^^---excessive section
When running the x86-64 test cross build on a big-endian system, such
as s390x, objdump and readelf fail to dump the SFrame information with
the following error message:
Error: SFrame decode failure: Buffer does not contain SFrame data.
This is because the following check in flip_sframe() fails, which gets
only invoked if the endianness of the SFrame data is different from the
host system one:
/* All FDEs and FREs must have been endian flipped by now. */
if ((j != ihp->sfh_num_fres) || (bytes_flipped != (buf_size - hdrsz)))
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
With:
j=8, ihp->sfh_num_fres=8, bytes_flipped=70, buf_size=127, hdrsz=28
While at it, remove the incorrect code comment. There is no
relationship between "do not update size" and the fact that the
"contents have not been relocated".
bfd/
* elf-sframe.c (_bfd_elf_write_section_sframe): Update section
size also for relocatable links.
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
|
|
The SFrame FDE's function start address is always emitted as follows by
GAS and ld: it is the offset of the start PC of the respective function
from the FDE field itself.
GAS and ld will emit a flag SFRAME_F_FDE_FUNC_START_PCREL set to 1
when emitting the field in this encoding.
* binutils/NEWS: Announce the change of encoding for SFrame FDE
func start addr field.
* gas/NEWS: Announce the emission of new flag
SFRAME_F_FDE_FUNC_START_PCREL.
* ld/NEWS: Likewise. Relocatable links are now fixed.
|
|
PR/32666 Incorrect .rela.sframe when using ld -r
Input SFrame sections are merged using _bfd_elf_merge_section_sframe (),
which clubs all SFrame FDEs together in one blob and all SFrame FREs in
another. This, of course, means the offset of an SFrame FDE in the output
section cannot be simply derived from the output_offset of the sections.
Fix this by providing _bfd_elf_sframe_section_offset () which returns
the new offset of the SFrame FDE in the merged SFrame section.
Unlike EH_Frame sections, which also use the _bfd_elf_section_offset (),
to update the r_offset, SFrame sections have distinct merging semantics.
In case of SFrame, the SFrame FDE will not simply sit at location
"sec->output_offset + offset of SFrame FDE in sec". Recall that information
layout in an SFrame section is as follows:
SFrame Header
SFrame FDE 1
SFrame FDE 2
...
SFrame FDEn
SFrame FREs (Frame Row Entries)
Note how the SFrame FDEs and SFrame FREs are clubber together in groups
of their own.
Next, also note how the elf_link_input_bfd () does a:
irela->r_offset += o->output_offset;
This, however, needs to be avoided for SFrame sections because the
placement of all FDEs is at the beginning of the section. So, rather than
conditionalizing this as follows:
if (o->sec_info_type != SEC_INFO_TYPE_SFRAME)
irela->r_offset += o->output_offset;
the implementation in _bfd_elf_sframe_section_offset () does a reverse
adjustment, so that the generic parts of the linking process in
elf_link_input_bfd () are not made to do SFrame specific adjustments.
Add a new enum to track the current state of the SFrame input section
during the linking process (SFRAME_SEC_DECODED, SFRAME_SEC_MERGED) for
each input SFrame section. This is then used to assert an assumption
that _bfd_elf_sframe_section_offset () is being used on an input SFrame
sections which have not been merged (via
_bfd_elf_merge_section_sframe ()) yet.
bfd/
* elf-bfd.h: New declaration.
* elf-sframe.c (_bfd_elf_sframe_section_offset): New definition.
* elf.c (_bfd_elf_section_offset): Adjust offset if SFrame
section.
ld/testsuite/
* ld-x86-64/x86-64.exp: New test.
* ld-x86-64/sframe-reloc-1.d: New test.
|
|
This patch convenes a set of changes in bfd, gas, ld, libsframe towards
moving to the new encoding for the 'sfde_func_start_address' field in
SFrame FDE.
First, gas must now mark all SFrame sections with the new flag
SFRAME_F_FDE_FUNC_START_PCREL. gas was already emitting the field
in the said encoding.
* gas/gen-sframe.c (output_sframe_internal): Emit the flag
SFRAME_F_FDE_FUNC_START_PCREL.
Similarly for ld, adopt the new semantics of sfde_func_start_address
consistently. This means:
- When merging SFrame sections, check that all input SFrame sections
have the SFRAME_F_FDE_FUNC_START_PCREL flag set. If the check
fails, ld errors out.
- When merging SFrame sections, keep even the in-memory contents of
the FDE function start address (buffer passed to libsframe
sframe_encoder_write () for writing out) encoded in the new
semantics. While it is, in theory, possible that instead of doing this
change here, we adjust the value of sfde_func_start_address at the final
write (sframe_encoder_write) time. But latter is not favorable for
maintenanance and may be generally confusing for developers.
- When creating SFrame for PLT entries, emit flag
SFRAME_F_FDE_FUNC_START_PCREL.
include/
* sframe-api.h (SFRAME_F_LD_MUSTHAVE_FLAGS): New definition.
bfd/
* elf-sframe.c (_bfd_elf_merge_section_sframe): Check for flag
combinatation SFRAME_F_LD_MUSTHAVE_FLAGS set for all input and
output SFrame sections. If not, error out. Also, adopt the new
semantics of function start address encoding.
* bfd/elfxx-x86.c (_bfd_x86_elf_create_sframe_plt): Emit flag
SFRAME_F_FDE_FUNC_START_PCREL.
Next, for dumping SFrame sections, now that we are emitting the same
encoding in GAS, non-relocatable and relocatable SFrame links, it is the
time to set relocate to TRUE in debug_displays[].
binutils/
* dwarf.c (struct dwarf_section_display): Allow sframe sections
to now be relocated.
gas/testsuite/
* gas/cfi-sframe/cfi-sframe-aarch64-pac-ab-key-1.d: Update the
test. Relocatable SFrame sections now display non-zero value
(appropriate function start address).
Now, as the SFrame sections on-disk and in-memory use the new semantics of
sfde_func_start_address encoding (i.e., function start address is the
offset from the sfde_func_start_address field to the start PC), the
calculation to make it human readable (i.e., relatable to the addresses
in .text sections) needs adjustment.
libsframe/
* sframe-dump.c (dump_sframe_func_with_fres): Adjust the
function start address for dumping.
Now that both the emission of the new encoding, and the relocation of
sections before dumping them is in place, it is time to adjust the
testcases.
gas/testsuite/
* gas/cfi-sframe/cfi-sframe-aarch64-1.d: Update expected output
to include SFRAME_F_FDE_FUNC_START_PCREL instead of NONE.
* gas/cfi-sframe/cfi-sframe-aarch64-2.d: Likewise.
* gas/cfi-sframe/cfi-sframe-aarch64-3.d: Likewise.
* gas/cfi-sframe/cfi-sframe-aarch64-4.d: Likewise.
* gas/cfi-sframe/cfi-sframe-common-1.d: Likewise.
* gas/cfi-sframe/cfi-sframe-common-10.d: Likewise.
* gas/cfi-sframe/cfi-sframe-common-11.d: Likewise.
* gas/cfi-sframe/cfi-sframe-common-2.d: Likewise.
* gas/cfi-sframe/cfi-sframe-common-3.d: Likewise.
* gas/cfi-sframe/cfi-sframe-common-4.d: Likewise.
* gas/cfi-sframe/cfi-sframe-common-5.d: Likewise.
* gas/cfi-sframe/cfi-sframe-common-6.d: Likewise.
* gas/cfi-sframe/cfi-sframe-common-7.d: Likewise.
* gas/cfi-sframe/cfi-sframe-common-8.d: Likewise.
* gas/cfi-sframe/cfi-sframe-common-9.d: Likewise.
* gas/cfi-sframe/cfi-sframe-x86_64-1.d: Likewise.
* gas/cfi-sframe/cfi-sframe-x86_64-2.d: Likewise.
* gas/cfi-sframe/cfi-sframe-x86_64-empty-1.d: Likewise.
* gas/cfi-sframe/cfi-sframe-x86_64-empty-2.d: Likewise.
* gas/cfi-sframe/cfi-sframe-x86_64-empty-3.d: Likewise.
* gas/cfi-sframe/cfi-sframe-x86_64-empty-4.d: Likewise.
* gas/cfi-sframe/common-empty-1.d: Likewise.
* gas/cfi-sframe/common-empty-2.d: Likewise.
* gas/cfi-sframe/common-empty-3.d: Likewise.
* gas/scfi/x86_64/scfi-cfi-sections-1.d: Likewise.
* gas/scfi/x86_64/scfi-dyn-stack-1.d: Likewise.
ld/testsuite/
* ld-aarch64/sframe-simple-1.d: Update expected output to
include SFRAME_F_FDE_FUNC_START_PCREL.
* ld-x86-64/sframe-ibt-plt-1.d: Likewise.
* ld-x86-64/sframe-plt-1.d: Likewise.
* ld-x86-64/sframe-pltgot-1.d: Likewise.
* ld-x86-64/sframe-pltgot-2.d: Likewise.
* ld-x86-64/sframe-simple-1.d: Likewise.
Naturally, the change of semantics for 'SFrame FDE function start address'
has consequences on the implementation in libsframe. As per the new
semantics:
- Function start address in the SFrame FDE (sfde_func_start_address)
is an offset from the FDE function start address field to the start
PC of the associated function.
Note that, the libsframe library brings the SFrame section contents into
its own memory to create a sframe_decoder_ctx object via sframe_decode
(). Many internal and user-interfacing APIs then may use
sframe_decoder_ctx object to interact and fulfill the work.
In context of changing semantics for sfde_func_start_address, following
relevant examples may help understand the impact:
- sframe_find_fre () finds a the SFrame stack trace data (SFrame FRE)
given a lookup offset (offset of lookup_pc from the start of SFrame
section). Now that the sfde_func_start_address includes the
distance from the sfde_func_start_address field to the start of
SFrame section itself, the comparison checks of
sfde_func_start_address with the incoming lookup offset need
adjustment.
- Some internal functions (sframe_get_funcdesc_with_addr_internal ()
finds SFrame FDE by using binary seach comparing
sfde_func_start_address fields, etc.) need adjustments.
- sframe_encoder_write () sorts the SFrame FDEs before writing out
the SFrame data. Sorting of SFrame FDE via the internal function
sframe_sort_funcdesc() needs adjustments: the new encoding of
sfde_func_start_address means the distances are not from the same
anchor, so cannot be sorted directly.
This patch takes the approach of adding a new internal function:
- sframe_decoder_get_secrel_func_start_addr (): This function returns
the offset of the start PC of the function from the start of SFrame
section, i.e., it gives a section-relative offset.
As the sframe_decoder_get_secrel_func_start_addr () API needs the value
of the function index in the FDE list, another internal API needs
sframe_fre_check_range_p () adjustments too.
Sorting the FDEs (via sframe_sort_funcdesc ()) is done by first bringing
all offsets in sfde_func_start_address relative to start of SFrame
section, followed by sorting, and then readjusting the offsets accroding
to the new position in the FDE list.
libsframe/
* sframe.c (sframe_decoder_get_secrel_func_start_addr): New
static function.
(sframe_fre_check_range_p): Adjust the interface a bit.
(sframe_get_funcdesc_with_addr_internal): Use
sframe_decoder_get_secrel_func_start_addr () when comparing
sfde_func_start_address with user input offset.
(sframe_find_fre): Adopt the new semantics.
(sframe_sort_funcdesc): Likewise.
For the libsframe testsuite, use the new encoding for FDE func start
addr: distance between the FDE sfde_func_start_address field and the
start PC of the function itself.
Use SFRAME_F_FDE_FUNC_START_PCREL flag, though the sframe_encode ()
interface in libsframe applies no sanity checks for the encoding itself.
libsframe/testsuite/
* libsframe.find/findfre-1.c: Adjust to use the new
SFRAME_F_FDE_FUNC_START_PCREL specific encoding.
* libsframe.find/findfunc-1.c: Likewise.
* libsframe.find/plt-findfre-1.c: Likewise.
* libsframe/testsuite/libsframe.decode/DATA2: Update data file
due to usage of new SFRAME_F_FDE_FUNC_START_PCREL flag.
* libsframe/testsuite/libsframe.encode/encode-1.c: Use flag
SFRAME_F_FDE_FUNC_START_PCREL.
|
|
PR libsframe/32589 - function start address is zero in SFrame section dump
Currently, readelf and objdump display the SFrame sections in ET_REL
object files with function start addresses of each function as 0. This
makes it difficult to correlate SFrame stack trace information with the
individual functions in the object file.
For objdump, use the dump_dwarf () interface to dump SFrame section.
Similarly, for readelf, use the display_debug_section () interface to
dump SFrame section. These existing interfaces (for DWARF debug
sections) already support relocating the section contents before
dumping, so lets use them for SFrame sections as well.
When adding a new entry for SFrame in debug_option_table[], use char
'nil' and the option name of "sframe-internal-only". This is done so
that there is no additional (unnecessary) user-exposed ways of dumping
SFrame sections. Additionally, we explicitly disallow the
"sframe-internal-only" from external/user input in --dwarf (objdump).
Similarly, "sframe-internal-only" is explicitly matched and disallowed
from --debug-dump (readelf).
For objdump and readelf, we continue to keep the same error messaging as
earlier:
$ objdump --sframe=sframe bubble_sort.o
...
No sframe section present
$ objdump --sframe=.sfram bubble_sort.o
...
No .sfram section present
$ objdump --sframe=sframe-internal-only sort
...
No sframe-internal-only section present
Similarly for readelf:
$ readelf --sframe= bubble_sort.o
readelf: Error: Section name must be provided
$ readelf --sframe=.sfram bubble_sort.o
readelf: Warning: Section '.sfram' was not dumped because it does not exist
$ readelf --sframe=sframe bubble_sort.o
readelf: Warning: Section 'sframe' was not dumped because it does not exist
PS: Note how this patch adds a new entry to debug_displays[] with a
relocate value set to FALSE. This will be set to TRUE in a subsequent
patch ("bfd: gas: ld: libsframe: emit func start addr field as an offset
from FDE") when fixes are made to emit the value of the
'sfde_func_start_address' field in the new encoding
SFRAME_F_FDE_FUNC_START_PCREL across gas and ld.
binutils/
* dwarf.c (display_sframe): New definition.
(dwarf_select_sections_all): Enable SFrame section too.
(struct dwarf_section_display): Add entry for SFrame section.
* dwarf.h (enum dwarf_section_display_enum): Add enumerator for
SFrame.
* objdump.c (dump_section_sframe): Remove.
(dump_sframe_section): Add new definition.
(dump_bfd): Use dump_sframe_section.
* binutils/readelf.c (dump_section_as_sframe): Remove.
|
|
Add a new flag SFRAME_F_FDE_FUNC_START_PCREL to SFrame stack trace
format. If set, this flag indicates that the function start address
field (sfde_func_start_address) is the offset to the function start
address from the SFrame FDE function start address field itself.
Such an encoding is friendlier to the exisitng PC-REL relocations
available in the ABIs supported in SFrame: AMD64 (R_X86_64_PC32) and
AArch64 (R_AARCH64_PREL32). In subsequent patches, we will make the
implementation in gas and ld to both:
- emit the values in the same (above-mentioned) encoding uniformly.
- set the flag SFRAME_F_FDE_FUNC_START_PCREL in the SFrame header
for consumers to be able to distinguish.
Define SFRAME_V2_F_ALL_FLAGS in sframe.h to help keep the implementation
less error-prone by keeping a set of all defined flags at a central
place. Adjust the check in sframe_header_sanity_check_p () to use the
SFRAME_V2_F_ALL_FLAGS instead.
Add documentation for SFRAME_F_FDE_FUNC_START_PCREL. Update the
documentation about the encoding of the sfde_func_start_address field.
Also, update the section "Changes from Version 1 to Version 2" to
include the specification of the new flag SFRAME_F_FDE_FUNC_START_PCREL
as an erratum to the SFrame Version 2 specification.
include/
* sframe.h (SFRAME_F_FDE_FUNC_START_PCREL): New definition.
(SFRAME_V2_F_ALL_FLAGS): Likewise.
libsframe/
* sframe-dump.c (dump_sframe_header_flags): Update to include
the new flag SFRAME_F_FDE_FUNC_START_PCREL.
* sframe.c (sframe_header_sanity_check_p): Use
SFRAME_V2_F_ALL_FLAGS.
libsframe/doc/
* sframe-spec.texi: Add details about the new flag. Also update
the defails about the sfde_func_start_address encoding.
|
|
These APIs will be later used by the linker to arrange SFrame FDEs in
the output SFrame section.
include/
* sframe-api.h (sframe_decoder_get_offsetof_fde_start_addr): New
declaration.
(sframe_encoder_get_offsetof_fde_start_addr): Likewise.
libsframe/
* libsframe.ver: List the new APIs.
* sframe.c (sframe_decoder_get_offsetof_fde_start_addr): New
definition.
(sframe_encoder_get_offsetof_fde_start_addr): Likewise.
|
|
To prepare code for accommodating new flag additions easily as the
format evolves.
libsframe/
* sframe-dump.c (SFRAME_HEADER_FLAGS_STR_MAX_LEN): Remove.
(dump_sframe_header_flags): .. to here. New definition.
(PRINT_FLAG): New definition.
(dump_sframe_header): Move some implementation from here ..
|
|
Add new APIs, one each for getting flags from the SFrame decoder and
SFrame encoder context objects respectively.
These will later be used by the linker to uniformly access the flags,
given the SFrame decoder and SFrame encoder objects.
Use the new API, where applicable, within libsframe.
include/
* sframe-api.h (sframe_decoder_get_flags): New declaration.
(sframe_encoder_get_flags): Likewise.
libsframe/
* libsframe.ver: List new APIs.
* sframe.c (sframe_decoder_get_flags): New definition.
(sframe_encoder_get_flags): Likewise.
(sframe_get_funcdesc_with_addr_internal): Use the new API.
(sframe_encoder_get_flags): Likewise.
(sframe_encoder_write_sframe): Likewise.
|
|
It was never used, pushed by mistake along with pic-and-nonpic-1a-r6.s.
|
|
The patch corrects the mips16 and micromips rela tables to *not*
use _bfd_mips_elf_{hi,lo}16_reloc. These special functions are
inappropriate for RELA relocs where addends are in the reloc rather
than in the section contents. See corresponding rela R_MIPS howtos.
bfd/
* elf64-mips.c (mips16_elf64_howto_table_rela)
<R_MIPS16_HI16, R_MIPS16_LO16>: Use _bfd_mips_elf_generic_reloc
special_function.
(micromips_elf64_howto_table_rela)
<R_MICROMIPS_HI16, R_MICROMIPS_LO16>: Similarly.
* elfn32-mips.c: As for elf64-mips.c.
|
|
Fix an issue with `_bfd_mips_elf_generic_reloc' not taking into account
any borrow from the lower part in the handling of relocations of the
HI/LO kind and resulting in incorrect calculations made for RELA targets
in the generic used for non-ELF output such as S-records. This doesn't
trigger for REL targets because they call `_bfd_mips_elf_generic_reloc'
indirectly from `_bfd_mips_elf_lo16_reloc' so as to obtain a complete
32-bit addend from relocation pairs and in calculating the addend the
latter function uses a hack to work around the lack of borrow handling
in the former function.
The MIPS/ELF linker is unaffected as it uses its own calculations.
Correct the calculation of the relevant partial relocations made in
`_bfd_mips_elf_generic_reloc' then to take the borrow into account and
remove the hack from `_bfd_mips_elf_lo16_reloc' as no longer needed.
Add generic linker test cases accordingly expecting the same disassembly
from srec output produced as from ELF output produced by the MIPS/ELF
linker.
|
|
Expand test coverage for HI/LO relocation handling and add conventional
MIPS and microMIPS GAS tests as well as conventional MIPS, microMIPS,
and MIPS16e2 LD tests, covering R_MIPS_HI16, R_MIPS_LO16, R_MIPS16_HI16,
R_MIPS16_LO16, R_MICROMIPS_HI16, and R_MICROMIPS_LO16 relocations, as
well as 64-bit R_MIPS_HIGHEST, R_MIPS_HIGHER, R_MICROMIPS_HIGHEST, and
R_MICROMIPS_HIGHER relocations.
Modify the linker script so as to retain the `.MIPS.abiflags' section so
as to disassemble MIPS16e2 code correctly, as MIPS16e2 ASE information
is only carried in that section and not in ELF file header's `e_flags'.
MIPS16e2 and microMIPS code requires at least the MIPS32r2 ISA (or the
MIPS64r2 one for the n32 and n64 ABIs), which is incompatible with the
`mips:5900' linker output architecture and causes link failures such as:
./ld-new: tmpdir/mips-hilo1.o: linking mips:isa32r2 module with previous mips:5900 modules
./ld-new: failed to merge target specific data of file tmpdir/mips-hilo1.o
Therefore exclude `mips*el-ps2-elf*' targets from microMIPS and MIPS16e2
LD testing.
|
|
Switch the o32 and n32 mips16-hilo MIPS LD tests to the new disassembly
format, to reduce discrepancies in output in preparation to reuse for
generic linker tests.
Taking the first line of disassembly output as an example the difference
is:
00500000 <stuff> 6c00 li a0,0
vs:
0x0000000000500000 6c00 li a0,0
for ELF and srec input respectively with the currently used older format
requested with `--prefix-addresses', but with the new disassembly format
it is exactly the same between the two input formats and no information
that we need is lost in the transition:
500000: 6c00 li a0,0
|
|
The o32 and n32 mips16-hilo MIPS LD tests request symbol table output
only to discard it in matching. The symbol table is not relevant to
these tests, so remove it from output requested and adjust matching
patterns accordingly.
|
|
Fix a couple of places in MIPS GAS and LD R_MIPS16_HI16/R_MIPS16_LO16
relocation tests where the %hi operator has been incorrectly used, but
the %lo operator is expected to complement the preceding %hi operation.
|
|
IRIX 6 emulations place external small common symbols in the regular
common section instead of the small common section. With mips16-hilo
test this leads to a different symbol assignment to memory locations
between o32 and n32 ABIs, as follows:
--- o32.map
+++ n32.map
@@ -46,23 +46,22 @@
*(.sdata)
0x00765430 . = 0x765430
-.bss 0x00765430 0x7d8
+.bss 0x00765430 0x7d9
*(.bss)
.bss 0x00765430 0x3f0 tmpdir/mips16-hilo.o
.bss 0x00765820 0x0 tmpdir/mips16-hilo1.o
*(COMMON)
- COMMON 0x00765820 0x3e8 tmpdir/mips16-hilo.o
+ COMMON 0x00765820 0x3e9 tmpdir/mips16-hilo.o
0x00765820 big_external_common
+ 0x00765c08 small_external_common
-.sbss 0x00765c08 0x2
+.sbss 0x00765c09 0x1
*(.sbss)
- .sbss 0x00765c08 0x1 tmpdir/mips16-hilo.o
+ .sbss 0x00765c09 0x1 tmpdir/mips16-hilo.o
*(.scommon)
- .scommon 0x00765c09 0x1 tmpdir/mips16-hilo.o
- 0x00765c09 small_external_common
/DISCARD/
*(*)
LOAD tmpdir/mips16-hilo.o
LOAD tmpdir/mips16-hilo1.o
-OUTPUT(tmpdir/dump elf32-bigmips)
+OUTPUT(tmpdir/dump elf32-nbigmips)
which in turn causes a testsuite regression. Since the specific mapping
of symbols does not matter for the scope of the test, reorder the small
common section ahead of SBSS, so that the `small_external_common' symbol
ends up in the same place regardless of whether via the regular common
section or the small common section. Adjust embedded addresses in the
disassembly expected accordingly, removing the regression concerned:
mips-sgi-irix6 -FAIL: R_MIPS16_HI16 and R_MIPS16_LO16 relocs n32
mips64el-ps2-elf -FAIL: R_MIPS16_HI16 and R_MIPS16_LO16 relocs n32
|
|
The mips16-hilo MIPS LD test case is supposed to produce the same final
linked output regardless of whether the o32 or n32 ABI has been chosen
for assembly. Reuse o32 output for the n32 test then.
|
|
Remove regressions across MIPSr6 targets with the MIPS16 HI/LO tests,
which are incompatible with the default architecture of these targets:
mips-img-elf -FAIL: R_MIPS16_HI16 and R_MIPS16_LO16 relocs
mips-img-linux -FAIL: R_MIPS16_HI16 and R_MIPS16_LO16 relocs
mips64-img-linux -FAIL: R_MIPS16_HI16 and R_MIPS16_LO16 relocs
mips64-img-linux -FAIL: R_MIPS16_HI16 and R_MIPS16_LO16 relocs n32
mips64el-img-linux -FAIL: R_MIPS16_HI16 and R_MIPS16_LO16 relocs
mips64el-img-linux -FAIL: R_MIPS16_HI16 and R_MIPS16_LO16 relocs n32
mipsel-img-elf -FAIL: R_MIPS16_HI16 and R_MIPS16_LO16 relocs
mipsel-img-linux -FAIL: R_MIPS16_HI16 and R_MIPS16_LO16 relocs
mipsisa32r6-elf -FAIL: R_MIPS16_HI16 and R_MIPS16_LO16 relocs
mipsisa32r6-linux -FAIL: R_MIPS16_HI16 and R_MIPS16_LO16 relocs
mipsisa32r6el-elf -FAIL: R_MIPS16_HI16 and R_MIPS16_LO16 relocs
mipsisa32r6el-linux -FAIL: R_MIPS16_HI16 and R_MIPS16_LO16 relocs
mipsisa64r6-elf -FAIL: R_MIPS16_HI16 and R_MIPS16_LO16 relocs
mipsisa64r6-linux-gnuabi64 -FAIL: R_MIPS16_HI16 and R_MIPS16_LO16 relocs
mipsisa64r6-linux -FAIL: R_MIPS16_HI16 and R_MIPS16_LO16 relocs
mipsisa64r6el-elf -FAIL: R_MIPS16_HI16 and R_MIPS16_LO16 relocs
mipsisa64r6el-linux-gnuabi64 -FAIL: R_MIPS16_HI16 and R_MIPS16_LO16 relocs
mipsisa64r6el-linux -FAIL: R_MIPS16_HI16 and R_MIPS16_LO16 relocs
|
|
Add a GAS test case for R_MICROMIPS_HI16/R_MICROMIPS_LO16 REL relocation
pairing, analogous to one for R_MIPS16_HI16/R_MIPS16_LO16 relocations.
|
|
Remove trailing whitespace and extraneous new-line characters from
mips16-hilo-match.d test case.
|
|
oss-fuzz managed to trigger this assert, by assembling directives in
the absolute section. Avoid this using similar code to that in
frags.c:frag_new (commit 2dc2dfa7d7a5).
|
|
Use valueT when calculating sizes, since fr_fix is that type.
unsigned int was fine for sane code, but can lose to fuzzed input.
|
|
Avoid signed overflow when resolving constant +/- constant.
|
|
When sanity check of SFrame header fails, set error code to
SFRAME_ERR_BUF_INVAL instead of the current SFRAME_ERR_NOMEM.
|
|
|
|
On x86_64-freebsd, I run into:
...
$ gdb -q -batch -ex "maint selftest scoped_mmap"
Running selftest scoped_mmap.
Self test failed: self-test failed at scoped_mmap-selftests.c:50
Failures:
scoped_mmap
Ran 1 unit tests, 1 failed
...
The problem is that this call:
...
::scoped_mmap smmap (nullptr, sysconf (_SC_PAGESIZE), PROT_WRITE,
MAP_ANONYMOUS | MAP_PRIVATE, 0, 0);
...
returns MAP_FAILED and sets errno to EINVAL because the argument fd == 0.
If MAP_ANONYMOUS is used, fd == -1 should be used on freebsd. On linux, fd is
ignored but -1 is recommended for portability.
Fix this by using fd == -1 instead.
Tested x86_64-freebsd and x86_64-linux.
|
|
On x86_64-freebsd, I ran into:
...
$ gdb -q -batch -ex "maint selftest help_doc_invariants"
Running selftest help_doc_invariants.
help doc broken invariant: command 'kvm pcb' help doc first line is not \
terminated with a '.' character
Self test failed: self-test failed at command-def-selftests.c:120
Failures:
help_doc_invariants
Ran 1 unit tests, 1 failed
...
Fix this by adding the missing terminating dot.
Likewise for the kvm proc command.
Tested on x86_64-freebsd.
|
|
Use the contrib/dg-extract-results.sh script to create a gdb.sum and
gdb.log summary after running the check-all-boards make target.
Having the results from all the boards merged into a single file
isn't (maybe) the most useful, but it isn't a bad thing. However, the
great thing about merge the results is that the totals are also
merged.
The 'check-all-boards' recipe can then extract these totals, just as
we do for the normal 'check' recipe, this makes is much easier to
spot if there are any unexpected failures when using
'check-all-boards'.
Reviewed-By: Keith Seitz <keiths@redhat.com>
|
|
Sync the dg-extract-results.{sh,py} scripts with GCC, up to commit
4e9104ae5455a3c02c2a7e07f52e6bc574cc761d.
This extends the dg-extract-results scripts to handle GDB's
'unexpected core files' count.
contrib/ChangeLog:
* dg-extract-results.py: Handle GDB's unexpected core file count.
* dg-extract-results.sh: Likewise.
Reviewed-By: Keith Seitz <keiths@redhat.com>
|
|
AC_STRUCT_ST_* are the names of the autoconf macros, the C
preprocessor macros defined by autoconf/authoeader are
HAVE_STRUCT_STAT_ST_*.
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
Running `autoreconf -vf -Wall' in the sim directory shows errors about the use
of obsolete macros. This patch fix the issues with macros used or defined in
the sim directory. However, it doesn't fix all warnings. There's 1 autoconf
warning from `config/pkg.m4', and many automake warnings about target
shadowing. It cuts a lot of the noise down and makes an upgrade to
autoconf 2.71+ easier.
- Replace AC_CANONICAL_SYSTEM by AC_CANONICAL_TARGET
https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/
Obsolete-Macros.html#index-AC_005fCANONICAL_005fSYSTEM-1997
- Replace AC_TRY_COMPILE by AC_COMPILE_IFELSE
https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/
Obsolete-Macros.html#index-AC_005fTRY_005fCOMPILE-2203
- Replace AC_ERROR by AC_MSG_ERROR
https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/
Obsolete-Macros.html#index-AC_005fERROR-2034
- Remove AC_TYPE_SIGNAL and replace `RETSIGTYPE' by `void' in the source
https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/
Obsolete-Macros.html#index-AC_005fTYPE_005fSIGNAL-2213
- Remove AC_STRUCT_ST_BLKSIZE, it's already covered by a AC_CHECK_MEMBERS call
https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/
Obsolete-Macros.html#index-AC_005fSTRUCT_005fST_005fBLKSIZE-2176
- Remove AC_STRUCT_ST_RDEV, it's already covered by a AC_CHECK_MEMBERS call
https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/
Obsolete-Macros.html#index-AC_005fSTRUCT_005fST_005fRDEV-2180
- Remove AC_STRUCT_ST_BLOCKS. It is not obsolete, but it's already covered by a
AC_CHECK_MEMBERS call.
- Replace deprecated C macros HAVE_ST_${MEMBER} by HAVE_STRUCT_STAT_ST_${MEMBER}
https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/
Particular-Structures.html#index-AC_005fSTRUCT_005fST_005fBLOCKS-693
Approved-By: Tom Tromey <tom@tromey.com>
|
|
|
|
|
|
Rather than having people resort to indirect means to issue a certain
kind of diagnostic conditionally upon an expression which can (or
should) only be evaluated when all sections were sized and all symbols
had their final values established, provide directives to directly
achieve this.
|
|
It has been more than once that I would have wanted to have a way to
know the gas version in assembly sources, perhaps for use with .if. Add
such a pre-defined symbol, introducing the common pattern GAS(<symbol>)
for any such symbols. The use of parentheses is to keep the risk of
collisions with users' symbols as low as possible. (Possible future
arch-specific symbols may want to use GAS(<arch>:<symbol>).)
Similarly permit determining whether the assembler is a released
version. The exact value probably isn't of much use, it's more the
defined-ness that one might care about. Yet the symbol needs to have
some value anyway.
While by default pre-defined symbols won't be emitted to the symbol
table, introduce -emit-local-absolute to allow requesting this. Re-
purpose flag_strip_local_absolute to become tristate, with a negative
value indicating to also emit pre-defined symbols.
|
|
Using such abbreviations is fine when written on an interactive command
line by a human. In scripts and alike, doing so risks colliding with
later option additions, as is about to occur for gas: Shortly there'll
be --emit-local-absolute.
|
|
|
|
When running gdb.base/foll-fork-syscall.exp with a GDB built with UBSan,
I get:
/home/simark/src/binutils-gdb/gdb/linux-nat.c:1906:28: runtime error: load of value 3200171710, which is not a valid value for type 'target_waitkind'
ERROR: GDB process no longer exists
GDB process exited with wait status 3026417 exp9 0 1
UNRESOLVED: gdb.base/foll-fork-syscall.exp: follow-fork-mode=child: detach-on-fork=on: test_catch_syscall: continue to breakpoint after fork
The error happens here:
#0 __sanitizer::Die () at /usr/src/debug/gcc/gcc/libsanitizer/sanitizer_common/sanitizer_termination.cpp:50
#1 0x00007ffff600d8dd in __ubsan::__ubsan_handle_load_invalid_value_abort (Data=<optimized out>, Val=<optimized out>) at /usr/src/debug/gcc/gcc/libsanitizer/ubsan/ubsan_handlers.cpp:551
#2 0x00005555636d37b6 in linux_handle_syscall_trap (lp=0x7cdff1eb1b00, stopping=0) at /home/simark/src/binutils-gdb/gdb/linux-nat.c:1906
#3 0x00005555636e0991 in linux_nat_filter_event (lwpid=3030627, status=1407) at /home/simark/src/binutils-gdb/gdb/linux-nat.c:3044
#4 0x00005555636e407f in linux_nat_wait_1 (ptid=..., ourstatus=0x7bfff0d6cf18, target_options=...) at /home/simark/src/binutils-gdb/gdb/linux-nat.c:3381
#5 0x00005555636e7795 in linux_nat_target::wait (this=0x5555704d35e0 <the_amd64_linux_nat_target>, ptid=..., ourstatus=0x7bfff0d6cf18, target_options=...) at /home/simark/src/binutils-gdb/gdb/linux-nat.c:3607
#6 0x000055556378fad2 in thread_db_target::wait (this=0x55556af42980 <the_thread_db_target>, ptid=..., ourstatus=0x7bfff0d6cf18, options=...) at /home/simark/src/binutils-gdb/gdb/linux-thread-db.c:1398
#7 0x0000555564811327 in target_wait (ptid=..., status=0x7bfff0d6cf18, options=...) at /home/simark/src/binutils-gdb/gdb/target.c:2593
I believe the problem is that lwp_info::syscall_state is never
initialized. Fix that by initializing it with TARGET_WAITKIND_IGNORE.
This is the value we use elsewhere when resetting this field to mean
"not stopped at a syscall".
Change-Id: I5b76c63d1466d6e63448fced03305fd5ca8294eb
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Reviewed-By: Luis Machado <luis.machado@arm.com>
|
|
Change-Id: I15e307e6910ecbea5a5852e07757f892ea799536
|
|
This was suggested in review, to separate the comment from the following
code.
Change-Id: I077ad4545ee5ef1d362dcfacf585400e26dfdb29
|
|
|
|
This commit adds fpcr_flags and dyn_rm_enum types to define the fpcr.
For details on the floating-point control register (fpcr), please see
the Alpha Architecture Reference Manual, 4th Ed. [1]; in brief, it
consists of a 64-bit bitfield with most bits reserved/unused. All but a
pair of the used bits are boolean flags; the exception, DYN_RM, is a
2-bit enum indicating the IEEE rounding mode and is defined as a
dyn_rm_enum type in the target description annex.
[1] https://archive.org/details/dec-alpha_arch_ref
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Change-Id: Iea54c9e201faae6147a03de124b0368752bce060
|
|
This commit adds target description support for Alpha.
The target description obviates the alpha_register_type and
alpha_register_name functions in alpha-tdep.c. Removal of
alpha_register_reggroup_p was considered but ultimately abandoned,
because the "info regs" command would no longer omit the zero, fpcr, and
unique registers from its output (they are neither vector nor float
types).
Register types in the target description annex match the types that the
alpha_register_type function returned.
The locally defined register_names array was moved out of
alpha_register_name and renamed to alpha_register_names as a static
global; calls to alpha_register_name have been replaced with direct
access of the array.
The patch follows the code pattern outlined in the following GDB
Internals Wiki entry:
https://sourceware.org/gdb/wiki/Internals%20Adding-Target-Described-Register-Support
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Change-Id: If4b25a891228388519074a31a682e33358c71063
|
|
gdb.arch/amd64-disp-step-avx.exp
In commit 8e73fddeb0d ("[gdb/testsuite] Fix gdb.arch/amd64-disp-step-avx.exp
on x86_64-freebsd") I added a "require {istarget *-*-linux*}", but since then
I found support_displaced_stepping, which seems more appropriate and
descriptive.
Fix this by requiring support_displaced_stepping instead.
Tested on x86_64-freebsd.
|
|
With test-case gdb.arch/amd64-disp-step-avx.exp on x86_64-freebsd I run into:
...
(gdb) continue
Continuing.
Breakpoint 3, test_rip_vex2_end () at amd64-disp-step-avx.S:35
35 nop
(gdb) FAIL: $exp: vex2: continue to test_rip_vex2_end
...
This happens while executing this bit of the test-case:
...
# Turn "debug displaced" on to make sure a displaced step is actually
# executed, not an inline step.
gdb_test_no_output "set debug displaced on"
gdb_test "continue" \
"Continuing.*prepared successfully .*Breakpoint.*, ${test_end_label} ().*" \
"continue to ${test_end_label}"
...
The problem is that on x86_64, displaced stepping is only supported for linux.
Consequently, the "prepared successfully" message is missing.
Fix this by requiring linux.
Approved-by: Kevin Buettner <kevinb@redhat.com>
Tested on x86_64-freebsd.
|
|
|
