The current situation/behavior is:
1) llvm-readelf doesn't need a string that is specified by `DT_SONAME`.
2) llvm-readobj/elf always tries to read it, even when there is no `DT_SONAME` tag.
3) Because of that both tools reports a warning for many our test cases.
This patch delays getting a SOName string and changes the behavior (llvm-readobj) to
only report a warning when there is a `DT_SONAME` and a string cab't be read.
Warning is not reported for llvm-readelf, as it never tries to dump it.
Differential revision: https://reviews.llvm.org/D89384
This broke Chromium's PGO build, it seems because hot-cold-splitting got turned
on unintentionally. See comment on the code review for repro etc.
> This patch adds -f[no-]split-cold-code CC1 options to clang. This allows
> the splitting pass to be toggled on/off. The current method of passing
> `-mllvm -hot-cold-split=true` to clang isn't ideal as it may not compose
> correctly (say, with `-O0` or `-Oz`).
>
> To implement the -fsplit-cold-code option, an attribute is applied to
> functions to indicate that they may be considered for splitting. This
> removes some complexity from the old/new PM pipeline builders, and
> behaves as expected when LTO is enabled.
>
> Co-authored by: Saleem Abdulrasool <compnerd@compnerd.org>
> Differential Revision: https://reviews.llvm.org/D57265
> Reviewed By: Aditya Kumar, Vedant Kumar
> Reviewers: Teresa Johnson, Aditya Kumar, Fedor Sergeev, Philip Pfaffe, Vedant Kumar
This reverts commit 273c299d5d.
The prefix given to --prefix will be added to GNU absolute paths when
used with --source option (source interleaved with the disassembly).
This matches GNU's objdump behavior.
GNU and C++17 rules for absolute paths are different.
Differential Revision: https://reviews.llvm.org/D85024
Fixes PR46368.
Differential Revision: https://reviews.llvm.org/D85024
If you use -stop-after or similar options, llc will normally print MIR.
This patch checks for -filetype=null as a special case to disable MIR
printing. As the comment says, "The Null output is intended for use for
performance analysis ...", and I found this useful for timing a subset
of the passes that llc runs without the significant overhead of printing
MIR just to send it to /dev/null.
Differential Revision: https://reviews.llvm.org/D89476
This reverts commit c2bd20ef652 and the follow up fix 16605bba6fb.
The tools/llvm-cov/warnings.h continues to fail on Windows platforms even
after the follow up, for example on the llvm-clang-win-x-armv7l builder:
http://lab.llvm.org:8011/#/builders/60/builds/94
`/dev/null` is treated as regualar file on Windows.
native_separators.c line 11 used relative path which was not correct but worked before because when `SourceFiles` is empty, it add all source files into `SourceFiles`.
When all provided source files are filtered out either due to `--ignore-filename-regex` or not part of binary, don't generate coverage reults for all source files. Because if users want to generate coverage results for all source files, they don't even need to provid selected source files or `--ignore-filename-regex`.
Differential Revision: https://reviews.llvm.org/D89359
This patch adds -f[no-]split-cold-code CC1 options to clang. This allows
the splitting pass to be toggled on/off. The current method of passing
`-mllvm -hot-cold-split=true` to clang isn't ideal as it may not compose
correctly (say, with `-O0` or `-Oz`).
To implement the -fsplit-cold-code option, an attribute is applied to
functions to indicate that they may be considered for splitting. This
removes some complexity from the old/new PM pipeline builders, and
behaves as expected when LTO is enabled.
Co-authored by: Saleem Abdulrasool <compnerd@compnerd.org>
Differential Revision: https://reviews.llvm.org/D57265
Reviewed By: Aditya Kumar, Vedant Kumar
Reviewers: Teresa Johnson, Aditya Kumar, Fedor Sergeev, Philip Pfaffe, Vedant Kumar
In a7b209a6d4, llvm-symbolizer was adjusted to return a failure status
code when it produced an error, to flag up DWARF parsing problems. The
test for missing PDB file is analogous, and returns a failure status now
too.
This should fix the llvm-clang-win-x-armv7l buildbot croaking:
http://lab.llvm.org:8011/#/builders/60/builds/77
Currently we have a few sections that
does not support specifying no keys for them. E.g. it is required that one
of "Content", "Size" or "Entries" key is present. There is no reason to
have this restriction. We can allow this and emit an empty section instead.
This opens road for a simplification and generalization of the code in `validate()`
that is discussed in the D89039 thread.
Depends on D89039.
Differential revision: https://reviews.llvm.org/D89391
Many sections either do not have a support of `Size`/`Content` or support just a
one of them, e.g only `Content`.
`Section` is the base class for sections. This patch adds `Content` and `Size` members
to it and removes similar members from derived classes. This allows to cleanup and
generalize the code and adds a support of these keys for all sections (`SHT_MIPS_ABIFLAGS`
is a only exception, it requires unrelated specific changes to be done).
I had to update/add many tests to test the new functionality properly.
Differential revision: https://reviews.llvm.org/D89039
(this doesn't cover all cases - libDebugInfoDWARF has a default error
handler that prints errors without any exit code handling - I'll be
following up with a patch for that after this)
dsymutil was incorrectly ignoring aliases to private extern symbols in
the MachODebugMapParser. This resulted in spurious warnings about not
being able to find symbols.
rdar://49652389
Differential revision: https://reviews.llvm.org/D89444
There's no way to know whether there's a loclist contribution to parse
if there's no loclistx encoding - and if there is one, there's no need
to walk back from the loclist_base (or, uin the case of
info.dwo/loclist.dwo - starting at 0 in the contribution) to parse the
header, instead rely on the DWARF32/64 and address size in the CU
that's already available.
This would come up in split DWARF (non-split wouldn't try to read a
loclist header in the absence of a loclist_base) when one unit had
location lists and another does not (because the loclists.dwo section
would be non-empty in that case - in the case where it's empty the
parsing would silently skip).
Simplify the testing a bit, rather than needing a whole dwp, etc - by
creating a malformed loclists.dwo section (and use single file Split
DWARF) that would trip up any attempt to parse it - but no attempt
should be made.
llvm-cov reports a poor error message when the -arch specifier is
missing or invalid, and a binary has multiple slices. Make the error
message more specific.
(This version of the patch avoids using llvm::none_of -- the way I used
the utility caused compile errors on many bots, possibly because the
wrong overload of `none_of` was selected.)
rdar://40312677
llvm-cov reports a poor error message when the -arch specifier is
missing or invalid, and a binary has multiple slices. Make the error
message more specific.
rdar://40312677
Adds more testing in basic-assembly.s and a new test tables.s.
Adds support to yaml reading and writing of tables as well.
Differential Revision: https://reviews.llvm.org/D88815
This diff is similar to what D71394 did for `llvm-objdump` -- it avoids
trying to look up a section name for STABS symbols, since some STABS
symbol types (like `N_OSO`) use the `n_sect` field to store other data
instead of a section index.
Differential Revision: https://reviews.llvm.org/D88468
Specification for `SHT_HASH` table says (https://refspecs.linuxbase.org/elf/gabi4+/ch5.dynamic.html#hash)
that it contains `Elf32_Word` entries for both `32/64` bit objects.
But there is a problem with `EM_S390` and `ELF::EM_ALPHA` platforms: they use 8-bytes entries.
(see the issue reported: https://bugs.llvm.org/show_bug.cgi?id=47681).
Currently we might infer the size of the dynamic symbols table from hash table,
but because of the issue mentioned, the calculation is wrong. And also we don't dump the hash table
properly.
I am not sure if we want to support 8-bytes entries as they violates specification and also the
`.hash` table is kind of deprecated by itself (the `.gnu.hash` table is used nowadays).
So, the solution this patch suggests is to ban using of the hash table on `EM_S390/EM_ALPHA` platforms.
Differential revision: https://reviews.llvm.org/D88817
At AMD, in an internal audit of our code, we found some corner cases
where we were not quite differentiating targets enough for some old
hardware. This commit is part of fixing that by adding three new
targets:
* The "Oland" and "Hainan" variants of gfx601 are now split out into
gfx602. LLPC (in the GPUOpen driver) and other front-ends could use
that to avoid using the shaderZExport workaround on gfx602.
* One variant of gfx703 is now split out into gfx705. LLPC and other
front-ends could use that to avoid using the
shaderSpiCsRegAllocFragmentation workaround on gfx705.
* The "TongaPro" variant of gfx802 is now split out into gfx805.
TongaPro has a faster 64-bit shift than its former friends in gfx802,
and a subtarget feature could be set up for that to take advantage of
it. This commit does not make that change; it just adds the target.
V2: Add clang changes. Put TargetParser list in order.
V3: AMDGCNGPUs table in TargetParser.cpp needs to be in GPUKind order,
so fix the GPUKind order.
Differential Revision: https://reviews.llvm.org/D88916
Change-Id: Ia901a7157eb2f73ccd9f25dbacec38427312377d
This removes the precompiled binary and rewrites test to use YAML.
After this change we'll have no more precompiled inputs in `llvm-readobj/ELF/Inputs`.
Differential revision: https://reviews.llvm.org/D89097
This patch rewrites test case verify_die_ranges.s in YAML which helps
simplify the test.
Reviewed By: jhenderson, JDevlieghere, dblaikie
Differential Revision: https://reviews.llvm.org/D88200
This patch makes the opcode_base and the standard_opcode_lengths fields
of the line table optional. When both of them are not specified,
yaml2obj emits them according to the line table's version.
Reviewed By: jhenderson
Differential Revision: https://reviews.llvm.org/D88355
It fixes possible scenarios when we crash/assert with `--hash-symbols` when
dumping an invalid GNU hash table which has a broken value in the buckets array.
This fixes a crash reported in comments for
https://bugs.llvm.org/show_bug.cgi?id=47681
Differential revision: https://reviews.llvm.org/D88561
This makes tests stricter and adds cases to verify what
we do when:
1) there is no `DT_HASH` tag (but there is a `SHT_HASH` section in sections header)
2) the sh_entsize of the `SHT_HASH` section is not equal to 4.
Differential revision: https://reviews.llvm.org/D88812
We have `--addrsig` implemented for `llvm-readobj`.
Usually it is convenient to use a single tool for dumping,
so it seems we might want to implement `--addrsig` for `llvm-readelf` too.
I've selected a simple output format which is a bit similar to one,
used for dumping of the symbol table. It looks like:
```
Address-significant symbols section '.llvm_addrsig' contains 2 entries:
Num: Name
1: foo
2: bar
```
Differential revision: https://reviews.llvm.org/D88835
This diff adds support for universal binaries to llvm-objcopy.
This is a recommit of 32c8435ef7 with the asan issue fixed.
Test plan: make check-all
Differential revision: https://reviews.llvm.org/D88400
This removed 2 last precompiled binaries from the mips-got.test.
YAML descriptions are used instead.
Differential revision: https://reviews.llvm.org/D88565
It's not possible to do this in complete generality - a CU using a
sec_offset DW_AT_ranges has no way of knowing where its rnglists
contribution starts, so should not attempt to parse any full rnglist
table/header to do so. And even using FORM_rnglistx there's no need to
parse the header - the offset can be computed using the CU's DWARF
format (32 or 64) to compute offset entry sizes, and then the list
parsed at that offset without ever trying to find a rnglist contribution
header immediately prior to the rnglists_base.
Georgii Rymar