* elf64-sparc.c (sparc64_elf_relocate_section): Adjust addend of
dynamic relocs against section symbols for the output section vma.
However, with the addition of TLS support in the upstream rev. 1.104
this fix was essentially reverted. After factoring out the common parts
of elf32-sparc.c and elf64-sparc.c a comment was added to elfxx-sparc.c
in the upstream rev. 1.27 as part of unrelated changes, saying that the
fix from elf64-sparc.c rev. 1.61 indeed should be implemented, but given
that some unspecified OS has a broken ld.so expecting broken relocations
deliberately is omitted.
As the current behavior actually violates the SPARC ABI, FreeBSD never
had such a broken ld.so and this is actually causing problems with at
least kernel modules linked with binutils 2.17.50 committed in r218822
without the workaround committed in r219340 in place, re-implement the
above fix in a way so that is only applied if the output format is
ELFOSABI_FREEBSD. In the upstream version it probably would make sense
to invert this check and only skip adjusting the addend for the OS with
the broken ld.so, once it's determine which one that is.
Approved by: dim
x86 CPU support, better support for powerpc64, some new directives, and
many other things. Bump __FreeBSD_version, and add a note to UPDATING.
Thanks to the many people that have helped to test this.
Obtained from: projects/binutils-2.17
'linker stubs'. Add .note.GNU-stack for the stubs objects. Without this,
final binary will have RWE mode for PT_GNU_STACK regardless of the
actual requirements.
Tested by: nwhitehorn
Reviewed by: dim, nwhitehorn
it should also be MI. The problem here arises when ld ends up linking a
link-once section with relocations against sections that point back to it
that are as yet unresolved. Instead of piecemeal finding sections we
think are potentially subject to this issue, just defer processing for
sections that have yet to be relocated instead of immediately bailing.
thread specific informations.
In order to do that, and in order to avoid KBI breakage with existing
infrastructure the following semantic is implemented:
- For live programs, a new member to the PT_LWPINFO is added (pl_tdname)
- For cores, a new ELF note is added (NT_THRMISC) that can be used for
storing thread specific, miscellaneous, informations. Right now it is
just popluated with a thread name.
GDB, then, retrieves the correct informations from the corefile via the
BFD interface, as it groks the ELF notes and create appropriate
pseudo-sections.
Sponsored by: Sandvine Incorporated
Tested by: gianni
Discussed with: dim, kan, kib
MFC after: 2 weeks
into it. Prior to this commit the .gnu_debuglink section can have up
to 3 bytes of uninitialized garbage; as a result, .ko files could
change vary between builds.
Approved by: dim
MFC after: 7 days
us up to version 2.17.50.20070703, at the last GPLv2 commit.
Amongst others, this added upstream support for some FreeBSD-specific
things that we previously had to manually hack in, such as the OSABI
label support, and so on.
There are also quite a number of new files, some for cpu's (e.g. SPU)
that we may or may not be interested in, but those can be cleaned up
later on, if needed.
64-bit PowerPC when linking multiple C++ files referencing the same
method, defined in a common header, when that method had a switch
statement with more than 4 cases. This change fixes compilation of LLVM
tblgen on 64-bit PPC with binutils 2.17.
Lots of help from: dim
Upstream after: more testing
(still under GPLv2 at that time):
Author: H.J. Lu <hjl@lucon.org>
Date: Wed Sep 27 04:18:16 2006 +0000
PR ld/3223
PR ld/3267
* bfd/elf.c (assign_file_positions_for_non_load_sections): Don't warn
zero size allocated sections.
* ld/ldlang.h (lang_output_section_statement_type): Add
section_relative_symbol.
* ld/ldlang.c (strip_excluded_output_sections): Don't strip a section
with a symbol relative to it.
(lang_size_sections_1): Mark if an output section has a symbol symbol
relative to it.
This prevents warnings like the following during stripping of debug info
from kernel modules on i386:
===> zlib (all)
...
objcopy --only-keep-debug zlib.ko.debug zlib.ko.symbols
objcopy --strip-debug --add-gnu-debuglink=zlib.ko.symbols zlib.ko.debug zlib.ko
BFD: zlib.ko: warning: allocated section `.plt' not in segment
BFD: zlib.ko: warning: allocated section `.got' not in segment
(still under GPLv2 at that time):
Author: Nick Clifton <nickc@redhat.com>
Date: Thu Aug 24 14:59:24 2006 +0000
* ldlang.c (lang_size_sections_1, lang_assignment_statement_enum):
Adjust the current address of DEFAULT_MEMORY_REGION even when dot
hasn't changed.
This is a prerequisite for the fix coming just after this.
moved from ld/emultempl/elf32.em to ld/ldlang.c, so apply approximately
the same change as upstream, which has description:
* ldlang.c (lang_insert_orphan): Add __start_<section> symbol assignment
inside output section statement. Ensure only one set of symbols per
output section.
* emultempl/pe.em (gld_${EMULATION_NAME}_place_orphan): Add non-dollar
sections before dollar sections. Correct add_child list insertion.
Taken from upstream git commit 7e01d69a19a8fd079887f26853c8565da15ff340,
with permission to use it under GPLv2 from the author.
The change made to bfd/elf.c in upstream revision 1.217.4.3 (which was a
revert of an earlier change), caused objcopy on powerpc to fail to copy
debug info from kernel modules. This had to be fixed by applying the
diff from upstream revision 1.243 on top of it.
__start_SECNAME and __stop_SECNAME symbols are automatically generated
by ld for orphan sections, i.e. those not explicitely referenced by a
linker script. The symbols are supposed to be placed correspondingly
at the start and the end of the section in output file. In some cases
__start_SECNAME may be placed at the address after the end of the
previous section (if any) and before the start the section. This
happens when following conditions are met:
1. the orphan section is found in more than one input file
2. the orphan section has different alignment requirements across input
files
3. the first instance of the section encountered doesn't have the
greatest alignment requirement
In these conditions resulting output section will be placed at address
after the end of the previous section aligned to the greatest alignment
requirement in the inputs, but __start_SECNAME will be placed at address
after the end of the previous section aligned to the alignment
requirement of the first input in which the section is encountered.
See commit message of r196118 for a concrete example of problems caused
by this bug.
The fix is to place __start_SECNAME inside the section and use ABSOLUTE
directive, rather than placing __start_SECNAME outside the section and
trying to guess address alignment.
This fix is in line with upstream binutils change/fix made between
versions 2.19 and 2.20 in revision of 1.307 ldlang.c.
MFC after: 3 weeks
a variety of bugs in binutils related to handling of 64-bit PPC ELF,
provides a GCC configuration for 64-bit PowerPC on FreeBSD, and
associated build systems tweaks.
Obtained from: projects/ppc64
o) Add TARGET_ABI to the MIPS toolchain build process. This sets the default
ABI to one of o32, n32 or n64. If it is not set, o32 is assumed as that is
the current default.
o) Set the default GCC cpu type to any specified TARGET_CPUTYPE. This is
necessary to have a working "cc" if e.g. mips64 is specified, as binutils
will refuse to link objects using different ISAs in some cases.
o) Add support for n32 and n64 ABIs to binutils and GCC.
o) Add additional required libgcc2 stubs for n32 and n64.
o) Add support for the "mips64r2" architecture to GCC. Add the "octeon"
o) When static linking, wrap default libraries in --start-group and
--end-group. This is required for static linking to work on n64 with the
interdependencies between libraries there. This is what other OSes that
support n64 seem to do, as well.
o) Fix our GCC spec to define __mips64 for 64-bit targets, not __mips64__, the
former being what libgcc, etc., check and the latter seemingly being a
misspelling of a hand merge from a Linux spec.
o) When no TARGET_CPUTYPE is specified at build time, make GCC take the default
ISA from the ABI. Our old defaults were too liberal and assumed that 64-bit
ABIs should default to the MIPS64 ISA and that 32-bit ABIs should default to
the MIPS32 ISA, when we are supporting or will support some systems based on
earlier 32-bit and 64-bit ISAs, most notably MIPS-III.
o) Merge a new opcode file (and support code) from a later version of binutils
and add flags and code necessary to support Octeon-specific instructions.
This should also make merging opcodes for other modern architectures easier.
Reviewed by: imp
Binutils has a "contrib" subdirectory - thus flattening cannot happen
without renaming the upper level contrib directory in a first pass.
Also, don't record this move and remove any keyword expansion.
cplus_demangle_type. This is the rev 1.50-1.51 change.
Our addr2line, etc.. would crash if used on C++ code that contains
certain symbol types. One example is
_ZN13PatternDriver23StringScalarDeleteValueC1ERKNS_25ConflateStringScalarValueERKNS_25AbstractStringScalarValueERKNS_12TemplateEnumINS_12pdcomplementELZNS_16complement_namesEELZNS_14COMPLEMENTENUMEEEE
non-shared object, do not reserve space in .plt and .rela.plt
for regular symbols neither defined nor referenced in shared objects.
This is a backport of rev. 1.101 (sourceware.org repository) to
Binutils 2.15 which fixes the creation of bogus relocations in the
PLT of Firefox and Thunderbird binaries and which in turn caused
them to segfault in rtld(1). This is committed to the vendor branch
as it doesn't represent a local change but the original vendor fix
is from after elf_link_hash_flags was replaced with bitfields.
PR: sparc64/89486
Approved by: maintainer timeout
Obtained from: NetBSD
MFC after: 1 week
(Note this makes the vendor branch not represent Binutils in the vendor's
CVS repository at any point in time. Portmgr did not like the state of
Binutils on Sparc that represented the point in time the vendor fixed this
issue. I'd rather have fixed this on RELENG_6.)
Approved by: re
