DW_FORM_flag_present dwarf attribute, so they do not print errors or
warnings on files that contain it. (This attribute can be emitted by
newer versions of clang and gcc.)
MFC after: 1 week
register added to the symbol table by the assembler. On further
investigation it was found the problem was with the my_get_expression
function. This is called by parse_big_immediate.
Fix this by moving the call to parse_big_immediate to the end of the if,
else if, ..., else block.
This fixes the problem on amd64 miscompiling mpboot.s causing boot
issues... We are still using gas for a few files in the kernel...
Submitted by: kib
MFC after: 1 month
Thanks to Mike Belopuhov for the pointer to the OpenBSD patch, though
OpenBSD's gcc is very different that it only helped w/ where to modify,
not how... Thanks to jhb for some early reviews...
Reviewed by: imp, kib
MFC after: 1 month
.note.ABI-tag section.
This helps on ARM EABI where the OS/ABI field is zero. It would be better
to use the NOTES program header however this would require a more invasive
change.
should never do so. This can cause global constructors and destructors
to not be executed at run-time, resulting in crashes and other strange
behaviour.
Reported by: rene
MFC after: 1 week
share/mk/sys.mk instead.
This is part of a medium term project to permit deterministic builds of
FreeBSD.
Submitted by: Erik Cederstrand <erik@cederstrand.dk>
Reviewed by: imp, toolchain@
Approved by: cperciva
MFC after: 2 weeks
encounters a DT_RUNPATH entry, the global dynamic_info[] array is
overrun, causing some other global variable to be overwritten.
In my testcase, this was the section_headers variable, leading to
segfaults or jemalloc assertions when it was freed later on.
Thanks to Koop Mast for providing samples of a few "bad" .so files.
MFC after: 1 week
r238211:
Support TARGET_ARCH=armv6 and TARGET_ARCH=armv6eb
This adds a new TARGET_ARCH for building on ARM
processors that support the ARMv6K multiprocessor
extensions. In particular, these processors have
better support for TLS and mutex operations.
This mostly touches a lot of Makefiles to extend
existing patterns for inferring CPUARCH from ARCH.
It also configures:
* GCC to default to arm1176jz-s
* GCC to predefine __FreeBSD_ARCH_armv6__
* gas to default to ARM_ARCH_V6K
* uname -p to return 'armv6'
* make so that MACHINE_ARCH defaults to 'armv6'
It also changes a number of headers to use
the compiler __ARM_ARCH_XXX__ macros to configure
processor-specific support routines.
Submitted by: Tim Kientzle <kientzle@freebsd.org>
adding appropriate table entries, the assembler had to be adjusted as
these are the first non-SSE instructions to use a 3-byte opcode (and a
mandatory prefix to boot).
MFC after: 1 month
instructions. I reimplemented this from scratch based on the Intel
manuals and the existing support for handling the fxsave and fxrstor
instructions. This will let us use these instructions natively with GCC
rather than hardcoding the opcodes in hex.
Reviewed by: kib
MFC after: 1 month
The binutils update in r218822 caused the MIPS n64 dynamic binaries to
fail because the ".interp" section is not in the initial sections.
This happens because elf64bmip-defs.sh overrides INITIAL_READONLY_SECTIONS
to add ".MIPS.options" sections instead of the ".reginfo" section used
by n32.
This used to work fine, but after r218822, INITIAL_READONLY_SECTIONS also
contains the .interp section, so the override has to be done differently.
Reported by : aduane at juniper
Obtained from: gonzo (Initial version)
* 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.
