Target specific data shouldn't be put in struct bfd_section.
* section.c (struct bfd_section): Delete relax and relax_count.
(BFD_FAKE_SECTION): Adjust to suit.
(struct relax_table): Move to..
* elf32-microblaze.c (struct relax_table): ..here.
(struct _microblaze_elf_section_data): New.
(microblaze_elf_section_data): Define.
(microblaze_elf_new_section_hook): New function.
(bfd_elf32_new_section_hook): Define.
(calc_fixup): Return a size_t. Adjust to suit new location of
relax and relax_count.
(microblaze_elf_relax_section): Adjust to suit new location of
relax and relax_count. Make some variables size_t.
* bfd-in2.h: Regenerate.
PR 28592
PR 15994
PR 15935
* dwarf2.c (lookup_address_in_line_info_table): Return bool rather
than a range.
(comp_unit_find_nearest_line): Likewise. Return true if function
info found without line info.
(_bfd_dwarf2_find_nearest_line): Revert range handling code.
This includes adding pseudosections when reading a core dump as well
as support for writing out a core dump note from a pseudosection.
bfd/ChangeLog:
* elf-bfd.h (elfcore_write_x86_segbases): New.
* elf.c (elfcore_grok_freebsd_note): Add pseudosections for
NT_FREEBSD_X86_SEGBASES register notes.
(elfcore_write_x86_segbases): New.
(elfcore_write_register_note): Write NT_FREEBSD_X86_SEGBASES
register notes.
This function is only called if the note name is "FreeBSD", so
checking the name size is unnecessary.
bfd/ChangeLog:
* elf.c (elfcore_grok_freebsd_note): Remove checks for namesz.
Include the language identifier emitted by gas in the set of ones where
no mangled names are expected. Even if there could be "hand-mangled"
names, gas doesn't emit DW_AT_linkage_name in the first place.
Prior to entering the enclosing "else if()" the earlier associated if()
checks function->is_linkage and, if set, uses function->name. The
comment in patch context precedes (and explains) the setting
function->is_linkage. Yet with the flag set, we should then also return
the function name, just like said earlier if() would do when we came
here a 2nd time for the same "addr". And indeed passing the same address
twice on addr2line's command line would resolve the function for the 2nd
instance, but not for the 1st (if this code path is taken). (This,
obviously, is particularly relevant when there's no ELF symbol table in
the first place, like would be the case - naturally - in PE/COFF
binaries, for example.)
My previous nm patch handled all cases but one -- if the user set NM in
the environment to a path which contained an option, libtool's nm
detection tries to run nm against a copy of nm with the options in it:
e.g. if NM was set to "nm --blargle", and nm was found in /usr/bin, the
test would try to run "/usr/bin/nm --blargle /usr/bin/nm --blargle".
This is unlikely to be desirable: in this case we should run
"/usr/bin/nm --blargle /usr/bin/nm".
Furthermore, as part of this nm has to detect when the passed-in $NM
contains a path, and in that case avoid doing a path search itself.
This too was thrown off if an option contained something that looked
like a path, e.g. NM="nm -B../prev-gcc"; libtool then tries to run
"nm -B../prev-gcc nm" which rarely works well (and indeed it looks
to see whether that nm exists, finds it doesn't, and wrongly concludes
that nm -p or whatever does not work).
Fix all of these by clipping all options (defined as everything
including and after the first " -") before deciding whether nm
contains a path (but not using the clipped value for anything else),
and then removing all options from the path-modified nm before
looking to see whether that nm existed.
NM=my-nm now does a path search and runs e.g.
/usr/bin/my-nm -B /usr/bin/my-nm
NM=/usr/bin/my-nm now avoids a path search and runs e.g.
/usr/bin/my-nm -B /usr/bin/my-nm
NM="my-nm -p../wombat" now does a path search and runs e.g.
/usr/bin/my-nm -p../wombat -B /usr/bin/my-nm
NM="../prev-binutils/new-nm -B../prev-gcc" now avoids a path search:
../prev-binutils/my-nm -B../prev-gcc -B ../prev-binutils/my-nm
This seems to be all combinations, including those used by GCC bootstrap
(which, before this commit, fails to bootstrap when configured
--with-build-config=bootstrap-lto, because the lto plugin is now using
--export-symbols-regex, which requires libtool to find a working nm,
while also using -B../prev-gcc to point at the lto plugin associated
with the GCC just built.)
Regenerate all affected configure scripts.
* libtool.m4 (LT_PATH_NM): Handle user-specified NM with
options, including options containing paths.
At least x86-64's x32 sub-mode and RISC-V's 32-bit mode calculate
addends as 64-bit values, but store them in signed 32-bit fields when
generating the file without encountering any earlier error. When the
relocated field is a 64-bit one, the value resulting after processing
the relocation record when linking (or the latest when loading) may
thus be wrong due to the truncation.
With the code change in place, one x32 testcase actually triggers the
new diagnostic. That one case of too large a (negative) addend is being
adjusted alongside the addition of a new testcase to actually trigger
the new error. (Note that due to internal BFD behavior the relocation in
.data doesn't get processed anymore after the errors in .text.)
Note that in principle it is possible to express 64-bit relocations in
ELF32, but this would require .rel relocations, i.e. with the addend
stored in the 64-bit field being relocated. But I guess it would be a
lot of effort for little gain to actually support this.
PR 28978
* dwarf2.c (scan_unit_for_symbols): When performing second pass,
check to see if the function or variable being processed is the
same as the previous one.
Some test cases about ifunc.
bfd/
* elfnn-loongarch.c
* elfxx-loongarch.h
=== ld Summary ===
of expected passes 1430
of expected failures 11
of untested testcases 1
of unsupported tests 154
Replace the magic numbers in gas(tc-loongarch.c) and
bfd(elfnn-loongarch.c) with the functions defined in
the howto table(elfxx-loongarch.c).
gas/
* config/tc-loongarch.c: use functions.
bfd/
* elfnn-loongarch.c: use functions.
* elfxx-loongarch.c: define functions.
* elfxx-loongarch.h
With "name" a char*, the length at name[0] might be negative, escaping
buffer limit checks.
* vms-alpha.c (evax_bfd_print_dst): Make name an unsigned char*.
(evax_bfd_print_emh): Likewise.
In the process of fixing a buffer overflow in commit fe69d4fcf0,
I managed to introduce a fairly obvious NULL pointer dereference..
* peXXigen.c (_bfd_XX_bfd_copy_private_bfd_data_common): Don't
segfault on not finding section. Wrap overlong lines.
Add support for the AMDGCN architecture to BFD.
This is the bare minimum to get
$ ./configure --target=amdgcn-hsa-amdhsa --disable-gas
$ make all-binutils
working later in this series.
The specific AMDGCN models added here are a bit arbitrary, based on
what we intend to initially support in GDB. This list will need to be
updated in the future anyway. The complete up-to-date list of existing
AMDGPU models can be found here:
https://llvm.org/docs/AMDGPUUsage.html#processors
The ELF format for this architecture is documented here:
https://llvm.org/docs/AMDGPUUsage.html#elf-code-object
The flags for the "HSA" OS ABI are properly versioned and documented on
that page. But the NONE, PAL and MESA3D OS ABIs are not well documented
nor versioned. Taking a peek at the LLVM source code, we see that they
encode their flags the same way as HSA v3. For example, for PAL:
c8b614cd74/llvm/lib/Target/AMDGPU/MCTargetDesc/AMDGPUTargetStreamer.cpp (L601)
So at least, we know that all AMDGPU objects (of which AMDGCN objects
are a subset of) at the time of writing encode the specific GPU model in
the EF_AMDGPU_MACH field of e_flags.
bfd/ChangeLog:
* Makefile.am (ALL_MACHINES, ALL_MACHINES_CFILES):
Add cpu-amdgcn.c.
(BFD64_BACKENDS): Add elf64-amdgcn.lo.
(BFD64_BACKENDS_CFILES): Add elf64-amdgcn.c.
* Makefile.in: Re-generate.
* cpu-amdgcn.c: New.
* elf64-amdgcn.c: New.
* archures.c (bfd_architecture): Add bfd_arch_amdgcn and related
mach defines.
(bfd_amdgcn_arch): New.
(bfd_archures_list): Add bfd_amdgcn_arch.
* bfd-in2.h: Re-generate.
* config.bfd: Handle amdgcn* target.
* configure.ac: Handle amdgcn_elf64_le_vec.
* configure: Re-generate.
* elf-bfd.h (elf_target_id): Add AMDGCN_ELF_DATA.
* targets.c (amdgcn_elf64_le_vec): New.
(_bfd_target_vector): Add amdgcn_elf64_le_vec.
include/ChangeLog:
* elf/amdgpu.h: New.
* elf/common.h (ELFOSABI_AMDGPU_HSA): Add.
Change-Id: I969f7b14960797e88891c308749a6e341eece5b2
