Commit Graph

5646 Commits

Author SHA1 Message Date
Fangrui Song bf535ac4a2 [ELF][AArch64] Support R_AARCH64_{CALL26,JUMP26} range extension thunks with addends
Fixes AArch64 part of PR40438

The current range extension thunk framework does not handle a relocation
relative to a STT_SECTION symbol with a non-zero addend, which may be
used by jumps/calls to local functions on some RELA targets (AArch64,
powerpc ELFv1, powerpc64 ELFv2, etc).  See PR40438 and the following
code for examples:

  // clang -target $target a.cc
  // .text.cold may be placed in a separate output section.
  // The distance between bar in .text.cold and foo in .text may be larger than 128MiB.
  static void foo() {}
  __attribute__((section(".text.cold"))) static int bar() { foo(); return
  0; }
  __attribute__((used)) static int dummy = bar();

This patch makes such thunks with addends work for AArch64. The target
independent part can be reused by PPC in the future.

On REL targets (ARM, MIPS), jumps/calls are not represented as
STT_SECTION + non-zero addend (see
MCELFObjectTargetWriter::needsRelocateWithSymbol), so they don't need
this feature, but we need to make sure this patch does not affect them.

Reviewed By: peter.smith

Differential Revision: https://reviews.llvm.org/D70637
2019-12-02 10:07:24 -08:00
Georgii Rymar 3b35603a56 [llvm-readobj] - Always print "Predecessors" for version definition sections.
This is a follow-up discussed in D70495 thread.

The current logic is unusual for llvm-readobj. It doesn't print predecessors
list when it is empty. This is not good for machine parsers.
D70495 had to add this condition during refactoring to reduce amount of changes,
in tests, because the original code also had a similar logic.

Now seems it is time to get rid of it. This patch does it.

Differential revision: https://reviews.llvm.org/D70717
2019-11-27 12:29:55 +03:00
Shoaib Meenai 75fd939bb9 [ELF] Adjust test to work for zlib 1.2.8
The previous data had the same length with compression levels 1 and 6
for zlib 1.2.8. Adjust the test to work for this library version. I've
also tested this with zlib 1.2.7 and zlib 1.2.11.
2019-11-26 17:19:02 -08:00
Fangrui Song 54a366f515 [ELF] Add a corrector for case mismatch problems
Reviewed By: grimar, peter.smith

Differential Revision: https://reviews.llvm.org/D70506
2019-11-26 09:11:56 -08:00
Georgii Rymar 19edd675c6 [LLD][ELF] - Make compression level be dependent on -On.
Currently LLD always use zlib compression level 6.
This patch changes it to use 1 for -O0, -O1 and 6 for -O2.

It fixes https://bugs.llvm.org/show_bug.cgi?id=44089.

There was also a thread in llvm-dev on this topic:
https://lists.llvm.org/pipermail/llvm-dev/2018-August/125020.html

Here is a table with results of building clang mentioned there:

```
Level   Time            Size
0       0m17.128s       2045081496   Z_NO_COMPRESSION
1       0m31.471s       922618584    Z_BEST_SPEED
2       0m32.659s       903642376
3       0m36.749s       890805856
4       0m41.532s       876697184
5       0m48.383s       862778576
6       1m3.176s        855251640    Z_DEFAULT_COMPRESSION
7       1m15.335s       853755920
8       2m0.561s        852497560
9       2m33.972s       852397408    Z_BEST_COMPRESSION
```

It shows that it is probably not reasonable to use values greater than 6.

Differential revision: https://reviews.llvm.org/D70658
2019-11-26 11:50:22 +03:00
Fangrui Song a71c1e2a57 [ELF] Support input section description .rel[a].dyn in /DISCARD/
Reviewed By: ruiu

Differential Revision: https://reviews.llvm.org/D70695
2019-11-25 21:49:46 -08:00
Fangrui Song 6b90f2bbec [ELF][test] Clean up some thunk tests
Use llvm-objdump --no-show-raw-insn --print-imm-hex
Prefer generic aarch64 triple to linux/freebsd specific triples.
2019-11-23 12:42:39 -08:00
Fangrui Song 4dc2fb123d [ELF] Error if -Ttext-segment is specified
In GNU ld, -Ttext sets the address of the .text section and -Ttext-segment sets the address of the text segment (RX).

gold only supports the -Ttext-segment semantic and treats -Ttext as an alias for -Ttext-segment.

lld only supports the -Ttext semantic and treats -Ttext-segment as an
alias for -Ttext.  The text segment will be assigned to an address less
than the specified -Ttext-segment value.

This patch drops the -Ttext-segment alias.

The text segment is traditionally the first segment. Users who specify
-Ttext-segment may actually want to specify --image-base, the lld way to
express this. Unfortunately currently this is supported by GNU ld's
COFF port but not by its ELF port. gold does not support this option.
With -z separate-code, the behavior of GNU ld -Ttext-segment is weird (see https://sourceware.org/bugzilla/show_bug.cgi?id=25207)

rL289827 introduced the alias for linking qemu's non-pie user mode
binaries. As explained previously, this actually assigns the text
segment to an address less than 0x60000000. I feel that a better fix is
on the qemu side:
https://lists.nongnu.org/archive/html/qemu-devel/2019-11/msg02480.html

Reviewed By: grimar, ruiu

Differential Revision: https://reviews.llvm.org/D70468
2019-11-21 09:41:55 -08:00
Alex Richardson 5bab291b7b Ignore R_MIPS_JALR relocations against non-function symbols
Summary:
Current versions of clang would erroneously emit this relocation not only
against functions (loaded from the GOT) but also against data symbols
(e.g. a table of function pointers). LLD was then changing this into a
branch-and-link instruction, causing the program to jump to the data
symbol at run time. I discovered this problem when attempting to boot
MIPS64 FreeBSD after updating the to the latest upstream master.

Reviewers: atanasyan, jrtc27, espindola

Reviewed By: atanasyan

Subscribers: emaste, sdardis, krytarowski, MaskRay, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D70406
2019-11-20 13:23:26 +00:00
Georgii Rymar 1cc78fdb6f [llvm-readobj/llvm-readelf] - Improve dumping of versioning sections.
Our elf-versioninfo.test is not perfect. It does not properly test how
flags are dumped and also we have a bug: they are dumped as enums in
LLVM style now, i.e not dumped properly.

GNU style uses a `versionFlagToString` method to build a string from flags
which seems is consistent with GNU readelf.

In this patch I fixed the issues mentioned.

Differential revision: https://reviews.llvm.org/D70399
2019-11-20 11:55:55 +03:00
Fangrui Song 6b0eb5a672 [ELF] Improve --gc-sections compatibility with GNU ld regarding section groups
Based on D70020 by serge-sans-paille.

The ELF spec says:

> Furthermore, there may be internal references among these sections that would not make sense if one of the sections were removed or replaced by a duplicate from another object. Therefore, such groups must be included or omitted from the linked object as a unit. A section cannot be a member of more than one group.

GNU ld has 2 behaviors that we don't have:

- Group members (nextInSectionGroup != nullptr) are subject to garbage collection.
  This includes non-SHF_ALLOC SHT_NOTE sections.
  In particular, discarding non-SHF_ALLOC SHT_NOTE sections is an expected behavior by the Annobin
  project. See
  https://developers.redhat.com/blog/2018/02/20/annobin-storing-information-binaries/
  for more information.
- Groups members are retained or discarded as a unit.
  Members may have internal references that are not expressed as
  SHF_LINK_ORDER, relocations, etc. It seems that we should be more conservative here:
  if a section is marked live, mark all the other member within the
  group.

Both behaviors are reasonable. This patch implements them.

A new field InputSectionBase::nextInSectionGroup tracks the next member
within a group. on ELF64, this increases sizeof(InputSectionBase) froms
144 to 152.

InputSectionBase::dependentSections tracks section dependencies, which
is used by both --gc-sections and /DISCARD/. We can't overload it for
the "next member" semantic, because we should allow /DISCARD/ to discard
sections independent of --gc-sections (GNU ld behavior). This behavior
may be reasonably used by `/DISCARD/ : { *(.ARM.exidx*) }` or `/DISCARD/
: { *(.note*) }` (new test `linkerscript/discard-group.s`).

Reviewed By: ruiu

Differential Revision: https://reviews.llvm.org/D70146
2019-11-19 08:54:06 -08:00
Reid Kleckner ce0f3ee5e4 [COFF] Don't error if the only inputs are from /wholearchive:
Fixes PR43744

Differential Revision: https://reviews.llvm.org/D69968
2019-11-15 16:09:07 -08:00
Rui Ueyama 000ff301e7 Warn on /align if used without /driver
/align is not supposed to be used without /driver, so it makes sense
to warn if only /align is passed. MSVC link.exe warns on this too.

Differential Revision: https://reviews.llvm.org/D70163
2019-11-14 13:13:07 +09:00
Rui Ueyama f95ed69641 Implement /driver, /driver:wdm and /driver:uponly
This patch implements /driver, /driver:wdm and /driver:uponly as
described in
https://docs.microsoft.com/en-us/cpp/build/reference/driver-windows-nt-kernel-mode-driver?view=vs-2019.

Differential Revision: https://reviews.llvm.org/D70162
2019-11-14 13:07:56 +09:00
Martin Storsjö 38bc9559ba [LLD] [COFF] Fix automatically importing data symbols from DLLs with LTO
This broke in 51dcb292cc, "[lld-link] diagnose undefined symbols
before LTO when possible" (very soon after the 9.0 branch, so
luckily the 9.0 release is unaffected).

The code for loading objects we believe might be needed for autoimport
(loadMinGWAutomaticImports()) does run before the new
reportUnresolvable() function, but it had a condition to only operate
on symbols from regular object files. This condition came from
resolveRemainingUndefines(), but as loadMinGWAutomaticImports() now
has to operate before the LTO, it has to operate on undefineds from
LTO objects as well.

Differential Revision: https://reviews.llvm.org/D70166
2019-11-13 22:48:36 +02:00
Fangrui Song 8f089f2099 [MC] Emit unused undefined symbol even if its binding is not set
Recommit r373168, which was reverted by r373242. This actually exposed a
boringssl bug which has been fixed for more than one month.

For the following two cases, we currently suppress the symbols. This
patch emits them (compatible with GNU as).

* `test2_a = undef`: if `undef` is otherwise unused.
* `.hidden hidden`: if `hidden` is unused. This is the main point of the
  patch, because omitting the symbol would cause a linker semantic
  difference.

It causes a behavior change that is not compatible with GNU as:

.weakref foo1, bar1

When neither foo1 nor bar1 is used, we now emit bar1, which is arguably
more consistent.

Another change is that we will emit .TOC. for .TOC.@tocbase .  For this
directive, suppressing .TOC. can be seen as a size optimization, but we
choose to drop it for simplicity and consistency.
2019-11-08 14:47:48 -08:00
Fangrui Song 59d3fbc227 [ELF] Suggest extern "C" when the definition is mangled while an undefined reference is not
The definition may be mangled while an undefined reference is not.
This may come up when (1) the reference is from a C file or (2) the definition
misses an extern "C".

(2) is more common. Suggest an arbitrary mangled name that matches the
undefined reference, if such a definition exists.

  ld.lld: error: undefined symbol: foo
  >>> referenced by a.o:(.text+0x1)
  >>> did you mean to declare foo(int) as extern "C"?
  >>> defined in: a1.o

Reviewed By: dblaikie, ruiu

Differential Revision: https://reviews.llvm.org/D69650
2019-11-08 09:46:45 -08:00
Fangrui Song 70e62a4fa6 [ELF] Suggest extern "C" when an undefined reference is mangled while the definition is not
When missing an extern "C" declaration, an undefined reference may be
mangled while the definition is not. Suggest the missing
extern "C" and the base name.

Reviewed By: ruiu

Differential Revision: https://reviews.llvm.org/D69592
2019-11-08 09:42:50 -08:00
Rui Ueyama f95273f75a Keep symbols passed by -init and -fini
Previously, symbols passed by -init and -fini look as if they are
not referenced by anyone, and the LTO might eliminate them.
This patch fixes the issue.

Fixes a bug reported in https://bugs.llvm.org/show_bug.cgi?id=43927

Differential Revision: https://reviews.llvm.org/D69985
2019-11-08 19:08:15 +09:00
Peter Collingbourne 2c6fae179e ELF: Discard .ARM.exidx sections for empty functions instead of misordering them.
The logic added in r372781 caused ARMExidxSyntheticSection::addSection()
to return false for exidx sections without a link order dep that passed
isValidExidxSectionDep(). This included exidx sections for empty functions. As
a result, such exidx sections would end up treated like ordinary sections and
would end up being laid out before the ARMExidxSyntheticSection, most likely in
the wrong order relative to the exidx entries in the ARMExidxSyntheticSection,
breaking the orderedness invariant relied upon by unwinders. Fix this by
simply discarding such sections.

Differential Revision: https://reviews.llvm.org/D69744
2019-11-04 09:11:14 -08:00
Reid Kleckner deaf121b65 Warn when an output section name is longer than 8 characters
Recent versions of Microsoft's dumpbin tool cannot handle such PE files.
LLVM tools and GNU tools can, and use this to encode long section names
like ".debug_info", which is commonly used for DWARF. Don't do this in
mingw mode or when -debug:dwarf is passed, since the user probably wants
long section names for DWARF sections.

PR43754

Reviewers: ruiu, mstorsjo

Differential Revision: https://reviews.llvm.org/D69594
2019-11-01 12:59:13 -07:00
Fangrui Song db8dad20b3 [ELF][test] Change references of %T to %t.dir
Test files in the same directory share the same %T.  %T is easy to
misuse and cause race conditions (when running concurrently) so it has
been deprecated since D48842 (see docs/CommandGuide/lit.rst).

While here, add `rm -rf %t.dir` so that tests cannot depend on old files lying around.

Reviewed By: jhenderson, ruiu

Differential Revision: https://reviews.llvm.org/D69572
2019-10-30 09:22:48 -07:00
Georgii Rymar d213da49e1 [LLD] - Fix a test after obj2yaml change.
I am not sure why obj2yaml is used to check the linkers output,
but anyways, the format was changed in https://reviews.llvm.org/rG6e779e953e9d.
2019-10-30 18:28:52 +03:00
Sam Clegg baff8ec2e1 [WebAssembly][lld] Fix for static linking of PIC code
When statically linking PIC code we create an internalized __memory_base
so that memory-base-relative relocation work correctly.  The value of
this global should be zero, and not the globalBase since the globalBase
offset is already taken into account by getVirtualAddress.

Fixes: https://github.com/emscripten-core/emscripten/issues/9013

Differential Revision: https://reviews.llvm.org/D69600
2019-10-29 18:58:56 -07:00
Nick Terrell 6814232429 [LLD][ELF] Support --[no-]mmap-output-file with F_no_mmap
Summary:
Add a flag `F_no_mmap` to `FileOutputBuffer` to support
`--[no-]mmap-output-file` in ELF LLD. LLD currently explicitly ignores
this flag for compatibility with GNU ld and gold.

We need this flag to speed up link time for large binaries in certain
scenarios. When we link some of our larger binaries we find that LLD
takes 50+ GB of memory, which causes memory pressure. The memory
pressure causes the VM to flush dirty pages of the output file to disk.
This is normally okay, since we should be flushing cold pages. However,
when using BtrFS with compression we need to write 128KB at a time when
we flush a page. If any page in that 128KB block is written again, then
it must be flushed a second time, and so on. Since LLD doesn't write
sequentially this causes write amplification. The same 128KB block will
end up being flushed multiple times, causing the linker to many times
more IO than necessary. We've observed 3-5x faster builds with
-no-mmap-output-file when we hit this scenario.

The bad scenario only applies to compressed filesystems, which group
together multiple pages into a single compressed block. I've tested
BtrFS, but the problem will be present for any compressed filesystem
on Linux, since it is caused by the VM.

Silently ignoring --no-mmap-output-file caused a silent regression when
we switched from gold to lld. We pass --no-mmap-output-file to fix this
edge case, but since lld silently ignored the flag we didn't realize it
wasn't being respected.

Benchmark building a 9 GB binary that exposes this edge case. I linked 3
times with --mmap-output-file and 3 times with --no-mmap-output-file and
took the average. The machine has 24 cores @ 2.4 GHz, 112 GB of RAM,
BtrFS mounted with -compress-force=zstd, and an 80% full disk.

| Mode    | Time  |
|---------|-------|
| mmap    | 894 s |
| no mmap | 126 s |

When compression is disabled, BtrFS performs just as well with and
without mmap on this benchmark.

I was unable to reproduce the regression with any binaries in
lld-speed-test.

Reviewed By: ruiu, MaskRay

Differential Revision: https://reviews.llvm.org/D69294
2019-10-29 15:49:08 -07:00
Michał Górny 2a0fcae3d4 [lld] [ELF] Add '-z nognustack' opt to suppress emitting PT_GNU_STACK
Add a new '-z nognustack' option that suppresses emitting PT_GNU_STACK
segment.  This segment is not supported at all on NetBSD (stack is
always non-executable), and the option is meant to be used to disable
emitting it.

Differential Revision: https://reviews.llvm.org/D56554
2019-10-29 17:54:23 +01:00
Sterling Augustine 118ceea5c3 Crt files are special cased by name when dealing with ctor and dtor
sections, but the current code misses certain variants. In particular, those
named when clang takes the code path in
clang/lib/Driver/ToolChain.cpp:416, where crtfiles are named:

clang_rt.<component>-<arch>-<env>.<suffix>

Previously, the code only handled:
clang_rt.<component>.<suffix>
<component>.<suffix>

This revision fixes that.
2019-10-25 11:04:56 -07:00
georgerim e3105e71f3 [LLD][ELF] - Update test case after yaml2obj change.
SHT_NOTE needs at least an empty "Content" in the YAML description.
Should fix http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast
2019-10-25 13:40:44 +03:00
Fangrui Song 56d81104f1 [ELF] -r: fix crash when processing a SHT_REL[A] that relocates a SHF_MERGE after D67504/r372734
Fix PR43767

In -r mode, when processing a SHT_REL[A] that relocates a SHF_MERGE, sec->getRelocatedSection() is a
MergeInputSection and its parent is an OutputSection but is asserted to
be a SyntheticSection (MergeSyntheticSection) in LinkerScript.cpp:addInputSec().
 ##
The code path is not exercised in non -r mode because the relocated
section changed from MergeInputSection to InputSection.

Reorder the code to make the non -r logic apply to -r as well, thus fix
the crash.

Reviewed By: peter.smith

Differential Revision: https://reviews.llvm.org/D69364
2019-10-24 11:35:29 -07:00
George Rimar c4107383e5 [LLD][ELF] - Update tests after yaml2obj tool update.
yaml2obj doesn't create .symtab by default anymore.

llvm-svn: 375360
2019-10-20 14:47:09 +00:00
Thomas Lively 393d0f799f [WebAssembly] Allow multivalue signatures in object files
Summary:
Also changes the wasm YAML format to reflect the possibility of having
multiple return types and to put the returns after the params for
consistency with the binary encoding.

Reviewers: aheejin, sbc100

Subscribers: dschuff, jgravelle-google, hiraditya, sunfish, arphaman, rupprecht, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D69156

llvm-svn: 375283
2019-10-18 20:27:30 +00:00
Martin Storsjo b38f577c01 [LLD] [COFF] Try to report source locations for duplicate symbols
This fixes the second part of PR42407.

For files with dwarf debug info, it manually loads and iterates
.debug_info to find the declared location of variables, to allow
reporting them. (This matches the corresponding code in the ELF
linker.)

For functions, it uses the existing getFileLineDwarf which uses
LLVMSymbolizer for translating addresses to file lines.

In object files with codeview debug info, only the source location
of duplicate functions is printed. (And even there, only for the
first input file. The getFileLineCodeView function requires the
object file to be fully loaded and initialized to properly resolve
source locations, but duplicate symbols are reported at a stage when
the second object file isn't fully loaded yet.)

Differential Revision: https://reviews.llvm.org/D68975

llvm-svn: 375218
2019-10-18 10:43:15 +00:00
Jordan Rupprecht ce88cdf096 [lld][test] Speculative fix for lld+windows failures
This updates some more places using `%T` to use `%/T` for path normalization.

If this does not work, this and r375126 should be reverted together.

llvm-svn: 375131
2019-10-17 16:29:03 +00:00
Jordan Rupprecht 1b6c3ca126 [lld][test] Fix use of escape character in an lld test on Windows
Summary:
Glob support was improved to accept `\` as an escape character in r375051, but reverted as r375052 due to a failure in this test on Windows.

The reason this failure seems Windows specific is because the path separator `\` is currently being relied on to be interpreted literally instead of as an escape character. Per documentation on linker input section wildcard patterns, this seems to be a bug in lld accepting `\` as a literal instead of an escape character.

For example:
```
SECTIONS{ .foo :{ /path/to/foo.o(.foo) }} # OK: standard UNIX path
SECTIONS{ .foo :{ C:/path/to/foo.o(.foo) }} # OK: windows accepts slashes in either direction
SECTIONS{ .foo :{ C:\\path\\to\\foo.o(.foo) }} # OK: escape character used to match a literal \
SECTIONS{ .foo :{ C:\path\to\foo.o(.foo) }} # BAD: this actually matches the path C:pathtofoo.o(.foo)
```

This avoids the problem in the test by using `%/T` in place of `%T` to normalize the path separator to `/`, which windows should also accept.

This patch just fixes the test, and glob support will be be relanded separately.

For a sample buildbot error, see: http://lab.llvm.org:8011/builders/clang-x64-windows-msvc/builds/11578/steps/stage%201%20check/logs/stdio

Reviewers: evgeny777, ruiu, MaskRay, espindola

Reviewed By: ruiu, MaskRay

Subscribers: emaste, arichardson, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D69074

llvm-svn: 375126
2019-10-17 15:35:28 +00:00
George Rimar 938db706fe [LLD][ELF] - Update test cases after llvm-readobj output format change.
The change was:

SHT_GNU_verdef { -> VersionDefinitions [
SHT_GNU_verneed { -> VersionRequirements [
Version symbols [ -> VersionSymbols [
EH_FRAME Header [ -> EHFrameHeader {

llvm-svn: 375096
2019-10-17 10:23:59 +00:00
Sam Clegg 67b055841f [lld][WebAssebmly] Preserve custom import attributes with LTO
Undefined symbols in WebAssembly can come with custom `import-module`
and `import-field` attributes.  However when reading symbols from
bitcode object files during LTO those curtom attributes are not
available.

Once we compile the LTO object and read in the symbol table from the
object file we have access to these custom attributes.  In this case,
when undefined symbols are added and a symbol already exists in the
SymbolTable we can't simple return it, we may need to update the
symbol's attributes.

Fixes: PR43211

Differential Revision: https://reviews.llvm.org/D68959

llvm-svn: 375081
2019-10-17 05:16:54 +00:00
Sam Clegg 6c393e9d74 [lld][WebAssembly] Fix for weak references to data symbols in archives
Fix a bug where were not handling relocations against weakly undefined
data symbol.  Add a test for this case.  Also ensure that the weak
references to data symbols are not pulled in from archive files by
default (but are if `-u <name>` is added to the command line).

Fixes: PR43696

Differential Revision: https://reviews.llvm.org/D69073

llvm-svn: 375077
2019-10-17 03:21:02 +00:00
Thomas Lively 190dacc3cc [WebAssembly] Elide data segments for .bss sections
Summary:
WebAssembly memories are zero-initialized, so when module does not
import its memory initializing .bss sections is guaranteed to be a
no-op. To reduce binary size and initialization time, .bss sections
are simply not emitted into the final binary unless the memory is
imported.

Reviewers: sbc100

Subscribers: dschuff, jgravelle-google, aheejin, sunfish, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D68965

llvm-svn: 374940
2019-10-15 19:05:11 +00:00
James Clarke 1ab27c74d4 [lld][WebAssembly] Fix static linking of -fPIC code with external undefined data
Reviewers: ruiu, sbc100

Reviewed By: sbc100

Subscribers: dschuff, jgravelle-google, aheejin, sunfish, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D68991

llvm-svn: 374913
2019-10-15 17:05:42 +00:00
Sid Manning ab50256544 [lld] Check for branch range overflows.
Differential Revision: https://reviews.llvm.org/D68875

llvm-svn: 374891
2019-10-15 14:12:54 +00:00
Jordan Rupprecht c526ff8a62 [llvm-objdump] Adjust spacing and field width for --section-headers
Summary:
- Expand the "Name" column past 13 characters when any of the section names are longer. Current behavior is a staggard output instead of a nice table if a single name is longer.
- Only print the required number of hex chars for addresses (i.e. 8 characters for 32-bit, 16 characters for 64-bit)
- Fix trailing spaces

Reviewers: grimar, jhenderson, espindola

Reviewed By: grimar

Subscribers: emaste, sbc100, arichardson, aheejin, seiya, llvm-commits, MaskRay

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D68730

llvm-svn: 374795
2019-10-14 17:47:17 +00:00
George Rimar a8346cee8a [LLD][ELF] - Update test cases after llvm-readobj change.
https://reviews.llvm.org/D68704 changed the output format.

llvm-svn: 374542
2019-10-11 12:27:20 +00:00
Amy Huang c9428a04fc Change test case so that it accepts backslashes in file path, in the case that the test runs on Windows
llvm-svn: 374473
2019-10-10 23:35:53 +00:00
Zachary Turner 02c5386811 [PDB] Fix bug when using multiple PCH header objects with the same name.
A common pattern in Windows is to have all your precompiled headers
use an object named stdafx.obj.  If you've got a project with many
different static libs, you might use a separate PCH for each one of
these.

During the final link step, a file from A might reference the PCH
object from A, but it will have the same name (stdafx.obj) as any
other PCH from another project.  The only difference will be the
path.  For example, A might be A/stdafx.obj while B is B/stdafx.obj.

The existing algorithm checks only the filename that was passed on
the command line (or stored in archive), but this is insufficient in
the case where relative paths are used, because depending on the
command line object file / library order, it might find the wrong
PCH object first resulting in a signature mismatch.

The fix here is to simply check whether the absolute path of the
PCH object (which is stored in the input obj file for the file that
references the PCH) *ends with* the full relative path of whatever
is specified on the command line (or is in the archive).

Differential Revision: https://reviews.llvm.org/D66431

llvm-svn: 374442
2019-10-10 20:25:51 +00:00
Rui Ueyama 37bf9bb405 Use error instead of fatal to report usage errors
Differential Revision: https://reviews.llvm.org/D68768

llvm-svn: 374297
2019-10-10 09:46:41 +00:00
Martin Storsjo 0226c35262 [LLD] [MinGW] Look for other library patterns with -l
GNU ld looks for a number of other patterns than just lib<name>.dll.a
and lib<name>.a.

GNU ld does support linking directly against a DLL without using an
import library. If that's the only match for a -l argument, point out
that the user needs to use an import library, instead of leaving the
user with a puzzling message about the -l argument not being found
at all.

Also convert an existing case of fatal() into error().

Differential Revision: https://reviews.llvm.org/D68689

llvm-svn: 374292
2019-10-10 08:52:39 +00:00
Martin Storsjo e742794ffa [LLD] [MinGW] Add a testcase for -l:name style library options. NFC.
Differential Revision: https://reviews.llvm.org/D68688

llvm-svn: 374291
2019-10-10 08:52:31 +00:00
Rui Ueyama d7ead5b58d Improve error message for bad SHF_MERGE sections
This patch adds a section name to error messages.

Differential Revision: https://reviews.llvm.org/D68758

llvm-svn: 374290
2019-10-10 08:32:12 +00:00
Rui Ueyama 07775b207a Use lld-link instead of llvm-dlltool to create an implib
Suggested by Martin Storsjö.

llvm-svn: 374142
2019-10-09 07:04:38 +00:00
Rui Ueyama c3c5e0fbbf [lld] Don't create hints-section if Hint/Name Table is empty
Fixes assert in addLinkerModuleCoffGroup() when using by-ordinal imports
only.

Patch by Stefan Schmidt.

Differential revision: https://reviews.llvm.org/D68352

llvm-svn: 374140
2019-10-09 06:48:24 +00:00