[ELF] Map the ELF header at imageBase
If there is no readonly section, we map:
* The ELF header at imageBase+maxPageSize
* Program headers at imageBase+maxPageSize+sizeof(Ehdr)
* The first section .text at imageBase+maxPageSize+sizeof(Ehdr)+sizeof(program headers)
Due to the interaction between Writer<ELFT>::fixSectionAlignments and
LinkerScript::allocateHeaders,
`alignDown(p_vaddr(R PT_LOAD)) = alignDown(p_vaddr(RX PT_LOAD))`.
The RX PT_LOAD will override the R PT_LOAD at runtime, which is not ideal:
```
// PHDR at 0x401034, should be 0x400034
PHDR 0x000034 0x00401034 0x00401034 0x000a0 0x000a0 R 0x4
// R PT_LOAD contains just Ehdr and program headers.
// At 0x401000, should be 0x400000
LOAD 0x000000 0x00401000 0x00401000 0x000d4 0x000d4 R 0x1000
LOAD 0x0000d4 0x004010d4 0x004010d4 0x00001 0x00001 R E 0x1000
```
* createPhdrs allocates the headers to the R PT_LOAD.
* fixSectionAlignments assigns `imageBase+maxPageSize+sizeof(Ehdr)+sizeof(program headers)` (formula: `alignTo(dot, maxPageSize) + dot % config->maxPageSize`) to addrExpr of .text
* allocateHeaders computes the minimum address among SHF_ALLOC sections, i.e. addr(.text)
* allocateHeaders sets address of ELF header to `addr(.text)-sizeof(Ehdr)-sizeof(program headers) = imageBase+maxPageSize`
The main observation is that when the SECTIONS command is not used, we
don't have to call allocateHeaders. This requires an assumption that
the presence of PT_PHDR and addresses of headers can be decided
regardless of address information.
This may seem natural because dot is not manipulated by a linker script.
The other thing is that we have to drop the special rule for -T<section>
in `getInitialDot`. If -Ttext is smaller than the image base, the headers
will not be allocated with the old behavior (allocateHeaders is called)
but always allocated with the new behavior.
The behavior change is not a problem. Whether and where headers are
allocated can vary among linkers, or ld.bfd across different versions
(--enable-separate-code or not). It is thus advised to use a linker
script with the PHDRS command to have a consistent behavior across
linkers. If PT_PHDR is needed, an explicit --image-base can be a simpler
alternative.
Differential Revision: https://reviews.llvm.org/D67325
llvm-svn: 371957
This causes "ld: error: output file too large: 18446744073707016908
bytes" when linking our loader_4th and loader_lua. Clearly, something
is wrong when using -Ttext 0x0: I will file an upstream bug report for
this.
Fix the following -Werror warning from clang 10.0.0 in binutils:
contrib/binutils/bfd/peicode.h:1356:3: error: misleading indentation; statement is not part of the previous 'if' [-Werror,-Wmisleading-indentation]
if (efi)
^
contrib/binutils/bfd/peicode.h:1353:8: note: previous statement is here
if (pe_arch (bfd_target_efi_arch (*target_ptr)) != arch)
^
contrib/binutils/bfd/peicode.h:1370:3: error: misleading indentation; statement is not part of the previous 'if' [-Werror,-Wmisleading-indentation]
if (!efi)
^
contrib/binutils/bfd/peicode.h:1367:8: note: previous statement is here
if (pe_arch (bfd_target_pei_arch (*target_ptr)) != arch)
^
MFC after: 3 days
contrib/binutils/bfd/peicode.h:1356:3: error: misleading indentation; statement is not part of the previous 'if' [-Werror,-Wmisleading-indentation]
if (efi)
^
contrib/binutils/bfd/peicode.h:1353:8: note: previous statement is here
if (pe_arch (bfd_target_efi_arch (*target_ptr)) != arch)
^
contrib/binutils/bfd/peicode.h:1370:3: error: misleading indentation; statement is not part of the previous 'if' [-Werror,-Wmisleading-indentation]
if (!efi)
^
contrib/binutils/bfd/peicode.h:1367:8: note: previous statement is here
if (pe_arch (bfd_target_pei_arch (*target_ptr)) != arch)
^
MFC after: 3 days
The current code clearly intended for these to be octal based on the values
used, but the octal prefix was forgotten. Add it now for correctness, but
note that we don't currently execute these tests.
This has been submitted upstream as misc/54902, so I've omitted the standard
FreeBSD markers that we tend to put into netbsd-tests for upstream-candidate
identification.
Reviewed by: ngie
MFC after: 3 days
- Two changes to encoder options:
encoder options may use plus or colon, but only one
encoder names can be specified as "@name"
This results in the syntax:
df --libxo @csv:no-header:leafs=name.available-blocks /
- If xo_set_program is called before xo_parse_args, honor the requested value
- add xo_errorn* function; repair newline-adding-on-xo_error bug
- test programs now use fixed name, since linux libtool prefixs "lt-"
- Fix "horse butt" comment in source code
- update test cases
PR: 242686
Add 8548 CPU definition and attributes
8548 CPU is GCC's name for the e500v2, so accept this in clang. The
e500v2 doesn't support lwsync, so define __NO_LWSYNC__ for this as
well, as GCC does.
Differential Revision: https://reviews.llvm.org/D67787
Merge commit ff0311c4b from llvm git (by Justin Hibbits):
[PowerPC]: Add powerpcspe target triple subarch component
Summary:
This allows the use of '-target powerpcspe-unknown-linux-gnu' or
'powerpcspe-unknown-freebsd' to be used, instead of '-target
powerpc-unknown-linux-gnu -mspe'.
Reviewed By: dim
Differential Revision: https://reviews.llvm.org/D72014
Merge commit ba91dffaf from llvm git (by Fangrui Song):
[Driver][PowerPC] Move powerpcspe logic from cc1 to Driver
Follow-up of D72014. It is more appropriate to use a target feature
instead of a SubTypeArch to express the difference.
Reviewed By: #powerpc, jhibbits
Differential Revision: https://reviews.llvm.org/D72433
commit 36eedfcb3 from llvm git (by Justin Hibbits):
[PowerPC] Fix powerpcspe subtarget enablement in llvm backend
Summary:
As currently written, -target powerpcspe will enable SPE regardless
of disabling the feature later on in the command line. Instead,
change this to just set a default CPU to 'e500' instead of a generic
CPU.
As part of this, add FeatureSPE to the e500 definition.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D72673
These are needed to unbreak the build for powerpcspe.
Requested by: jhibbits
MFC after: 1 week
[MIPS][ELF] Use PC-relative relocations in .eh_frame when possible
When compiling position-independent executables, we now use
DW_EH_PE_pcrel | DW_EH_PE_sdata4. However, the MIPS ABI does not define a
64-bit PC-relative ELF relocation so we cannot use sdata8 for the large
code model case. When using the large code model, we fall back to the
previous behaviour of generating absolute relocations.
With this change clang-generated .o files can be linked by LLD without
having to pass -Wl,-z,notext (which creates text relocations).
This is simpler than the approach used by ld.bfd, which rewrites the
.eh_frame section to convert absolute relocations into relative references.
I saw in D13104 that apparently ld.bfd did not accept pc-relative relocations
for MIPS ouput at some point. However, I also checked that recent ld.bfd
can process the clang-generated .o files so this no longer seems true.
Reviewed By: atanasyan
Differential Revision: https://reviews.llvm.org/D72228
Merge commit 8e8ccf47 from llvm git (by me)
[MIPS] Don't emit R_(MICRO)MIPS_JALR relocations against data symbols
The R_(MICRO)MIPS_JALR optimization only works when used against functions.
Using the relocation against a data symbol (e.g. function pointer) will
cause some linkers that don't ignore the hint in this case (e.g. LLD prior
to commit 5bab291) to generate a relative branch to the data symbol
which crashes at run time. Before this patch, LLVM was erroneously emitting
these relocations against local-dynamic TLS function pointers and global
function pointers with internal visibility.
Reviewers: atanasyan, jrtc27, vstefanovic
Reviewed By: atanasyan
Differential Revision: https://reviews.llvm.org/D72571
These two changes should allow using lld for MIPS64 (and maybe also MIPS32)
by default.
The second commit is not strictly necessary for clang+lld since LLD9 will
not perform the R_MIPS_JALR optimization (it was only added for 10) but it
is probably required in order to use recent ld.bfd.
Reviewed By: dim, emaste
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D23203
[mips] Use less registers to load address of TargetExternalSymbol
There is no pattern matched `add hi, (MipsLo texternalsym)`. As a
result, loading an address of 32-bit symbol requires two registers
and one more additional instruction:
```
addiu $1, $zero, %lo(foo)
lui $2, %hi(foo)
addu $25, $2, $1
```
This patch adds the missed pattern and enables generation more
effective set of instructions:
```
lui $1, %hi(foo)
addiu $25, $1, %lo(foo)
```
Differential Revision: https://reviews.llvm.org/D66771
llvm-svn: 370196
Merge commit 59bb3609f from llvm git (by Simon Atanasyan):
[mips] Fix 64-bit address loading in case of applying 32-bit mask to
the result
If result of 64-bit address loading combines with 32-bit mask, LLVM
tries to optimize the code and remove "redundant" loading of upper
32-bits of the address. It leads to incorrect code on MIPS64 targets.
MIPS backend creates the following chain of commands to load 64-bit
address in the `MipsTargetLowering::getAddrNonPICSym64` method:
```
(add (shl (add (shl (add %highest(sym), %higher(sym)),
16),
%hi(sym)),
16),
%lo(%sym))
```
If the mask presents, LLVM decides to optimize the chain of commands.
It really does not make sense to load upper 32-bits because the
0x0fffffff mask anyway clears them. After removing redundant commands
we get this chain:
```
(add (shl (%hi(sym), 16), %lo(%sym))
```
There is no patterns matched `(MipsHi (i64 symbol))`. Due a bug in
`SYM_32` predicate definition, backend incorrectly selects a pattern
for a 32-bit symbols and uses the `lui` instruction for loading
`%hi(sym)`.
As a result we get incorrect set of instructions with unnecessary
16-bit left shifting:
```
lui at,0x0
R_MIPS_HI16 foo
dsll at,at,0x10
daddiu at,at,0
R_MIPS_LO16 foo
```
This patch resolves two problems:
- Fix `SYM_32/SYM_64` predicates to prevent selection of patterns
dedicated to 32-bit symbols in case of using N64 ABI.
- Add missed patterns for 64-bit symbols for `%hi/%lo`.
Fix PR42736.
Differential Revision: https://reviews.llvm.org/D66228
llvm-svn: 370268
These two commits fix a miscompilation of the kernel for mips64, and
should allow clang to be used as the default compiler for mips64.
Requested by: arichards
MFC after: 3 days
config.h as a guide. In practice contributed software maintains a copy
of config.h within its build directory tree containing its Makefile.
usr.sbin/unbound is the home for its config.h.
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D22983
The patch is untested and is almost certainly insufficient. Per the
author's request, revert until someone with access to sparc64 hardware
can test and report.
sparc64 is the only architecture currently using the DWARF unwinder from
GCC 4.2.1. Old GCC and related libraries are being removed soon; absent
other changes sparc64 would be left with no unwinder when that happens.
Instead, commit these changes which should at least allow the LLVM
unwinder to build. Someone with access to the obolete sparc64 hardware
supported by FreeBSD will need to test the result.
PR: 233405
Submitted by: cem
[lld][RISCV] Use an e_flags of 0 if there are only binary input files.
Summary:
If none of the input files are ELF object files (for example, when
generating an object file from a single binary input file via "-b
binary"), use a fallback value for the ELF header flags instead of
crashing with an assertion failure.
Reviewers: MaskRay, ruiu, espindola
Reviewed By: MaskRay, ruiu
Subscribers: kevans, grimar, emaste, arichardson, asb, rbar,
johnrusso, simoncook, sabuasal, niosHD, kito-cheng, shiva0217,
zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o,
rkruppe, PkmX, jocewei, psnobl, benna, Jim, lenary, s.egerton,
pzheng, sameer.abuasal, apazos, luismarques, llvm-commits, jrtc27
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71101
This is a prerequisite for building and linking hard- and soft-float
riscv worlds with clang and lld.
Requested by: jhb
MFC after: 1 week
X-MFC-With: r353358
[RISCV] Handle fcopysign(f32, f64) and fcopysign(f64, f32)
Summary: Adds tablegen patterns to explicitly handle fcopysign where
the magnitude and sign arguments have different types, due to the
sign value casts being removed the by DAGCombiner. Support for RV32IF
follows in a separate commit. Adds tests for all relevant scenarios
except RV32IF.
Reviewers: lenary
Reviewed By: lenary
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D70678
This is a prerequisite for building and linking hard- and soft-float
riscv worlds with clang and lld.
Requested by: jhb
MFC after: 1 week
X-MFC-With: r353358
[RISCV] Fix wrong CFI directives
Summary: Removes CFI CFA directives that could incorrectly propagate
beyond the basic block they were inteded for. Specifically it removes
the epilogue CFI directives. See the branch_and_tail_call test for an
example of the issue. Should fix the stack unwinding issues caused by
the incorrect directives.
Reviewers: asb, lenary, shiva0217
Reviewed By: lenary
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D69723
This is a prerequisite for building and linking hard- and soft-float
riscv worlds with clang and lld.
Requested by: jhb
MFC after: 1 week
X-MFC-With: r353358
[RISCV] Don't force Local Exec TLS for non-PIC
Summary:
Forcing Local Exec TLS requires the use of copy relocations. Copy
relocations need special handling in the runtime linker when being
used against TLS symbols, which is present in glibc, but not in
FreeBSD nor musl, and so cannot be relied upon. Moreover, copy
relocations are a hack that embed the size of an object in the ABI
when it otherwise wouldn't be, and break protected symbols (which are
expected to be DSO local), whilst also wasting space, thus they
should be avoided whenever possible. As discussed in D70398, RISC-V
should move away from forcing Local Exec, and instead use Initial
Exec like other targets, with possible linker relaxation to follow.
The RISC-V GCC maintainers also intend to adopt this
more-conventional behaviour (see
https://github.com/riscv/riscv-elf-psabi-doc/issues/122).
Reviewers: asb, MaskRay
Reviewed By: MaskRay
Subscribers: emaste, krytarowski, hiraditya, rbar, johnrusso,
simoncook, sabuasal, niosHD, kito-cheng, shiva0217, zzheng,
edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, rkruppe,
PkmX, jocewei, psnobl, benna, Jim, lenary, s.egerton, pzheng,
sameer.abuasal, apazos, llvm-commits, bsdjhb
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D70649
This is a prerequisite for building and linking hard- and soft-float
riscv worlds with clang and lld.
Requested by: jhb
MFC after: 1 week
X-MFC-With: r353358
[RISCV] Fix evaluation of %pcrel_lo
The following testcase
function:
.Lpcrel_label1:
auipc a0, %pcrel_hi(other_function)
addi a1, a0, %pcrel_lo(.Lpcrel_label1)
.p2align 2 # Causes a new fragment to be emitted
.type other_function,@function
other_function:
ret
exposes an odd behaviour in which only the %pcrel_hi relocation is
evaluated but not the %pcrel_lo.
$ llvm-mc -triple riscv64 -filetype obj t.s | llvm-objdump -d -r -
<stdin>: file format ELF64-riscv
Disassembly of section .text:
0000000000000000 function:
0: 17 05 00 00 auipc a0, 0
4: 93 05 05 00 mv a1, a0
0000000000000004: R_RISCV_PCREL_LO12_I other_function+4
0000000000000008 other_function:
8: 67 80 00 00 ret
The reason seems to be that in RISCVAsmBackend::shouldForceRelocation
we only consider the fragment but in RISCVMCExpr::evaluatePCRelLo we
consider the section. This usually works but there are cases where
the section may still be the same but the fragment may be another
one. In that case we end forcing a %pcrel_lo relocation without any
%pcrel_hi.
This patch makes RISCVAsmBackend::shouldForceRelocation use the
section, if any, to determine if the relocation must be forced or
not.
Differential Revision: https://reviews.llvm.org/D60657
This is a prerequisite for building and linking hard- and soft-float
riscv worlds with clang and lld.
Requested by: jhb
MFC after: 1 week
X-MFC-With: r353358
[X86] Add X87 FCMOV support to X86FlagsCopyLowering.
Fixes PR44396
Merge commit 86f48999f from llvm git (by Craig Topper):
[X86] Fix typo in getCMovOpcode.
The 64-bit HasMemoryOperand line was using CMOV32rm instead of
CMOV64rm. Not sure how to test this. We have no test coverage that
passes true for HasMemoryOperand.
This fixes 'Assertion failed: (MI.findRegisterDefOperand(X86::EFLAGS) &&
"Expected a def of EFLAGS for this instruction!"), function
runOnMachineFunction' when compiling the misc/gpsim port for i386.
Reported by: yuri
Upstream PR: https://bugs.llvm.org/show_bug.cgi?id=44396
MFC after: 1 week
Update libarchive to 3.4.1
Relevant vendor changes since last update:
Issue #351: Refactor and implement private state logic for write filters
PR #1252: RAR5 reader - verify window size for solid files (OSS-Fuzz 15482)
PR #1255: zip writer - don't append unused NUL for directories
PR #1260: Fix sparse file offset overflow on 32-bit systems
PR #1263: UNICODE filename support for reading lha/lzh format
Issue #1276: Bugfix and optimize archive_wstring_append_from_mbs()
PR #1288: Add the "xattrhdr" option to pax write options
PR #1295: 7z reader - fix reading archives with digests in PackInfo
PR #1296: RAR5 reader - verify window size for multivolume archives
PR #1297: ZIP reader - support LZMA_STREAM_END marker in 'lzma alone' files
Issue #1298: Fix a heap-buffer-overflow in archive_string_append_from_wcs()
OSS-Fuzz 19360, 19362: LHA reader - plug two memory leaks on error
Fix possible off-by-one when dealing with readlink(2)
MFC after: 2 weeks
This changes the LLVM default powerpc64 ABI to ELFv2, if target OS is
FreeBSD >= 13.0
This will also be sent upstream.
Submitted by: alfredo.junior_eldorado.org.br
Reviewed by: dim, luporl
Relnotes: YES
Differential Revision: https://reviews.freebsd.org/D20383
lock/lock_free decisions in compiled time
Summary:
Enables atomic.c in compiler_rt and forces clang to not emit a call for runtime
decision about lock/lock_free. At compiling time, if clang can't decide if
atomic operation can be lock free, it emits calls to external functions like
`__atomic_is_lock_free`, `__c11_atomic_is_lock_free` and
`__atomic_always_lock_free`, postponing decision to a runtime check. According
to LLVM code documentation, the mechanism exists due to differences between
x86_64 processors that can't be decided at runtime.
On PowerPC and PowerPCSPE (32 bits), we already know in advance it can't be lock
free, so we force the decision at compile time and avoid having to implement it
in an external library.
This patch was made after 32 bit users testing the PowePC32 bit ISO reported
llvm could not be compiled with in-base llvm due to `__atomic_load8` not
implemented.
Submitted by: alfredo.junior_eldorado.org.br
Reviewed by: jhibbits, dim
Differential Revision: https://reviews.freebsd.org/D22549
[PowerPC] Only use PLT annotations if using PIC relocation model
Summary:
The default static (non-PIC, non-PIE) model for 32-bit powerpc does
not use @PLT annotations and relocations in GCC. LLVM shouldn't use
@PLT annotations either, because it breaks secure-PLT linking with
(some versions of?) GNU LD.
Update the available-externally.ll test to reflect that default mode
should be the same as the static relocation, by using the same check
prefix.
Reviewed by: sfertile
Differential Revision: https://reviews.llvm.org/D70570
Reviewed by: jhibbits
Differential Revision: https://reviews.freebsd.org/D22913
[libc++] Cleanup and enable multiple warnings.
Too many warnings are being disabled too quickly. Warnings are
important to keeping libc++ correct. This patch re-enables two
warnings: -Wconstant-evaluated and -Wdeprecated-copy.
In future, all warnings disabled for the test suite should require an
attached bug. The bug should state the plan for re-enabling that
warning, or a strong case why it should remain disabled.
This should fix a number of new g++ 9 warnings.
Requested by: rlibby
MFC after: 3 days
