It returns just a section_iterator currently and have a report_fatal_error call inside.
This change adds a way to return errors and handle them on caller sides.
The patch also changes/improves current users and adds test cases.
Differential revision: https://reviews.llvm.org/D69167
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@375408 91177308-0d34-0410-b5e6-96231b3b80d8
Changes: no changes. A fix for the clang code will be landed right on top.
Original commit message:
SectionRef::getName() returns std::error_code now.
Returning Expected<> instead has multiple benefits.
For example, it forces user to check the error returned.
Also Expected<> may keep a valuable string error message,
what is more useful than having a error code.
(Object\invalid.test was updated to show the new messages printed.)
This patch makes a change for all users to switch to Expected<> version.
Note: in a few places the error returned was ignored before my changes.
In such places I left them ignored. My intention was to convert the interface
used, and not to improve and/or the existent users in this patch.
(Though I think this is good idea for a follow-ups to revisit such places
and either remove consumeError calls or comment each of them to clarify why
it is OK to have them).
Differential revision: https://reviews.llvm.org/D66089
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@368826 91177308-0d34-0410-b5e6-96231b3b80d8
SectionRef::getName() returns std::error_code now.
Returning Expected<> instead has multiple benefits.
For example, it forces user to check the error returned.
Also Expected<> may keep a valuable string error message,
what is more useful than having a error code.
(Object\invalid.test was updated to show the new messages printed.)
This patch makes a change for all users to switch to Expected<> version.
Note: in a few places the error returned was ignored before my changes.
In such places I left them ignored. My intention was to convert the interface
used, and not to improve and/or the existent users in this patch.
(Though I think this is good idea for a follow-ups to revisit such places
and either remove consumeError calls or comment each of them to clarify why
it is OK to have them).
Differential revision: https://reviews.llvm.org/D66089
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@368812 91177308-0d34-0410-b5e6-96231b3b80d8
The ARMDisassembler changes allow changing between ARM and Thumb mode
based on the MCSubtargetInfo, rather than the Target, which simplifies
the other changes a bit.
I'm not really happy with adding more target-specific logic to
tools/llvm-objdump/, but there isn't any easy way around it: the logic
in question specifically applies to disassembling an object file, and
that code simply isn't located in lib/Target, at least at the moment.
Differential Revision: https://reviews.llvm.org/D60927
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@363903 91177308-0d34-0410-b5e6-96231b3b80d8
For clients iterating the symbol table, none expects to handle index 0
(STN_UNDEF). Skip it to improve consistency with other binary formats.
Clients that need STN_UNDEF (e.g. lld) can use
getSectionContentsAsArray(). A test will be added in D62148.
Reviewed By: mtrent
Differential Revision: https://reviews.llvm.org/D62296
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@361506 91177308-0d34-0410-b5e6-96231b3b80d8
Change
std::error_code getSectionContents(DataRefImpl, StringRef &) const;
to
Expected<ArrayRef<uint8_t>> getSectionContents(DataRefImpl) const;
Many object formats use ArrayRef<uint8_t> as the underlying type, which
is generally better than StringRef to represent binary data, so change
the type to decrease the number of type conversions.
Reviewed By: ruiu, sbc100
Differential Revision: https://reviews.llvm.org/D61781
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@360648 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Previously, llvm-nm would report symbols for .debug and .note sections as: '?' with an empty section name:
```
00000000 ?
00000000 ?
...
```
With this patch the output more closely resembles GNU nm:
```
00000000 N .debug_abbrev
00000000 n .note.GNU-stack
...
```
This patch calls `getSectionName` for sections that belong to symbols of type `ELF::STT_SECTION`, which returns the name of the section from the section string table.
Reviewers: Bigcheese, davide, jhenderson
Reviewed By: davide, jhenderson
Subscribers: rupprecht, jhenderson, llvm-commits
Differential Revision: https://reviews.llvm.org/D57105
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@352785 91177308-0d34-0410-b5e6-96231b3b80d8
to reflect the new license.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@351636 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
llvm-size uses "isText()" etc. which seem to indicate whether the section contains code-like things, not whether or not it will actually go in the text segment when in a fully linked executable.
The unit test added (elf-sizes.test) shows some types of sections that cause discrepencies versus the GNU size tool. llvm-size is not correctly reporting sizes of things mapping to text/data segments, at least for ELF files.
This fixes pr38723.
Reviewers: echristo, Bigcheese, MaskRay
Reviewed By: MaskRay
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D54369
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@349074 91177308-0d34-0410-b5e6-96231b3b80d8
All of STB_GLOBAL/STB_WEAK/STB_GNU_UNIQUE are treated as export symbols, see:
glibc/elf/dl-lookup.c:do_lookup_x
musl/ldso/dynlink.c OK_BINDS
Though ld.so does not read binding, the currently used STV_DEFAULT or STV_PROTECTED is a good emulation of linker behavior.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@347481 91177308-0d34-0410-b5e6-96231b3b80d8
Reapply r346374 with the fixes for modules build.
Original summary:
This change implements assembler parser, code emitter, ELF object writer
and disassembler for the MSP430 ISA. Also, more instruction forms are added
to the target description.
Patch by Michael Skvortsov!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@346948 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This change implements assembler parser, code emitter, ELF object writer
and disassembler for the MSP430 ISA. Also, more instruction forms are added
to the target description.
Reviewers: asl
Reviewed By: asl
Subscribers: pftbest, krisb, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D53661
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@346374 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This affects what sections are displayed as "DATA" in llvm-objdump.
The other user llvm-size is unaffected.
Before, a "TEXT" section is also "DATA", which seems weird.
The sh_flags condition matches that of bfd's SEC_DATA but the sh_type
condition uses (== SHF_PROGBITS) instead of bfd's (!= SHT_NOBITS).
bfd's SEC_DATA is not appealing as so many sections will be shown as DATA.
Reviewers: jyknight, Bigcheese
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D48472
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@335405 91177308-0d34-0410-b5e6-96231b3b80d8
We've been running doxygen with the autobrief option for a couple of
years now. This makes the \brief markers into our comments
redundant. Since they are a visual distraction and we don't want to
encourage more \brief markers in new code either, this patch removes
them all.
Patch produced by
for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done
Differential Revision: https://reviews.llvm.org/D46290
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@331272 91177308-0d34-0410-b5e6-96231b3b80d8
Most of the -Wsign-compare warnings are due to the fact that
enums are signed by default in the MS ABI, while the
tautological comparison warnings trigger on x86 builds where
sizeof(size_t) is 4 bytes, so N > numeric_limits<unsigned>::max()
is always false.
Differential Revision: https://reviews.llvm.org/D41256
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@320750 91177308-0d34-0410-b5e6-96231b3b80d8
getRelocationAddend should never be called on non SHT_RELA sections,
but changing that requires changing RelocVisitor.h.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@315473 91177308-0d34-0410-b5e6-96231b3b80d8
With this all clients have to use the new create method which returns
an Expected.
Fixes a crash on invalid input.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@315376 91177308-0d34-0410-b5e6-96231b3b80d8
This forces every user to use the new create method that returns an
Expected. This in turn propagates better error messages.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@315371 91177308-0d34-0410-b5e6-96231b3b80d8
The style guide states that the explicit `inline`
should not be used with inline methods. classof is
very common inline method with a fair amount on
inconsistency:
$ git grep classof ./include | grep inline | wc -l
230
$ git grep classof ./include | grep -v inline | wc -l
257
I chose to target this method rather the larger change
since this method is easily cargo-culted (I did it at
least once). I considered doing the larger change and
removing all occurrences but that would be a much larger
change.
Differential Revision: https://reviews.llvm.org/D33906
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@306731 91177308-0d34-0410-b5e6-96231b3b80d8
This creates a new library called BinaryFormat that has all of
the headers from llvm/Support containing structure and layout
definitions for various types of binary formats like dwarf, coff,
elf, etc as well as the code for identifying a file from its
magic.
Differential Revision: https://reviews.llvm.org/D33843
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@304864 91177308-0d34-0410-b5e6-96231b3b80d8
With fix of uninitialized variable.
Original commit message:
This change is intended to use for LLD in D33183.
Problem we have in LLD when building .gdb_index is that we need to know section which address range belongs to.
Previously it was solved on LLD side by providing fake section addresses with use of llvm::LoadedObjectInfo
interface. We assigned file offsets as addressed. Then after obtaining ranges lists, for each range we had to find section ID's.
That not only was slow, but also complicated implementation and was the reason of incorrect behavior when
sections share the same offsets, like D33176 shows.
This patch makes DWARF parsers to return section index as well. That solves problem mentioned above.
Differential revision: https://reviews.llvm.org/D33184
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@304078 91177308-0d34-0410-b5e6-96231b3b80d8
This change is intended to use for LLD in D33183.
Problem we have in LLD when building .gdb_index is that we need to know section which address range belongs to.
Previously it was solved on LLD side by providing fake section addresses with use of llvm::LoadedObjectInfo
interface. We assigned file offsets as addressed. Then after obtaining ranges lists, for each range we had to find section ID's.
That not only was slow, but also complicated implementation and was the reason of incorrect behavior when
sections share the same offsets, like D33176 shows.
This patch makes DWARF parsers to return section index as well. That solves problem mentioned above.
Differential revision: https://reviews.llvm.org/D33184
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@304002 91177308-0d34-0410-b5e6-96231b3b80d8
With fix of test compilation.
Initial commit message:
This change is intended to use for LLD in D33183.
Problem we have in LLD when building .gdb_index is that we need to know section
which address range belongs to.
Previously it was solved on LLD side by providing fake section addresses
with use of llvm::LoadedObjectInfo interface. We assigned file offsets as addressed.
Then after obtaining ranges lists, for each range we had to find section ID's.
That not only was slow, but also complicated implementation and was the reason
of incorrect behavior when
sections share the same offsets, like D33176 shows.
This patch makes DWARF parsers to return section index as well.
That solves problem mentioned above.
Differential revision: https://reviews.llvm.org/D33184
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@303983 91177308-0d34-0410-b5e6-96231b3b80d8
