Right now Symbols must be either undefined or defined in a specific
section. Some symbols have section indexes like SHN_ABS however. This
change adds support for outputting symbols that have such section
indexes.
Patch by Jake Ehrlich
Differential Revision: https://reviews.llvm.org/D37391
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@312745 91177308-0d34-0410-b5e6-96231b3b80d8
Some kinds of relocations do not have symbols, like R_X86_64_RELATIVE
for instance. I would like to test this case in D36554 but currently
can't because symbols are required by yaml2obj. The other option is
using the empty symbol but that doesn't seem quite right to me.
This change makes the Symbol field of Relocation optional and in the
case where the user does not specify a symbol name the Symbol index is 0.
Patch by Jake Ehrlich
Differential Revision: https://reviews.llvm.org/D37276
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@312192 91177308-0d34-0410-b5e6-96231b3b80d8
This change adds basic support for program headers.
I need to do some testing which requires generating program headers but
I can't use ld.lld or clang to produce programs that have headers. I'd
also like to test some strange things that those programs may never
produce.
Patch by Jake Ehrlich
Differential Revision: https://reviews.llvm.org/D35276
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@308520 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
We were treating the GUIDs in TypeServer2Record as strings, and the
non-ASCII bytes in the GUID would not round-trip through YAML.
We already had the PDB_UniqueId type portably represent a Windows GUID,
but we need to hoist that up to the DebugInfo/CodeView library so that
we can use it in the TypeServer2Record as well as in PDB parsing code.
Reviewers: inglorion, amccarth
Subscribers: llvm-commits, hiraditya
Differential Revision: https://reviews.llvm.org/D35495
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@308234 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This allows tools like lld that process relocations
to apply data relocation correctly. This information
is required because relocation are stored as section
offset.
Subscribers: jfb, dschuff, jgravelle-google, aheejin
Differential Revision: https://reviews.llvm.org/D35234
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@307741 91177308-0d34-0410-b5e6-96231b3b80d8
This is a short-term fix for PR33650 aimed to get the modules build bots green again.
Remove all the places where we use the LLVM_YAML_IS_(FLOW_)?SEQUENCE_VECTOR
macros to try to locally specialize a global template for a global type. That's
not how C++ works.
Instead, we now centrally define how to format vectors of fundamental types and
of string (std::string and StringRef). We use flow formatting for the former
cases, since that's the obvious right thing to do; in the latter case, it's
less clear what the right choice is, but flow formatting is really bad for some
cases (due to very long strings), so we pick block formatting. (Many of the
cases that were using flow formatting for strings are improved by this change.)
Other than the flow -> block formatting change for some vectors of strings,
this should result in no functionality change.
Differential Revision: https://reviews.llvm.org/D34907
Corresponding updates to clang, clang-tools-extra, and lld to follow.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@306878 91177308-0d34-0410-b5e6-96231b3b80d8
This was originally reverted because of some non-deterministic
failures on certain buildbots. Luckily ASAN eventually caught
this as a stack-use-after-scope, so the fix is included in
this patch.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@305393 91177308-0d34-0410-b5e6-96231b3b80d8
This is causing failures on linux bots with an invalid stream
read. It doesn't repro in any configuration on Windows, so
reverting until I have a chance to investigate on Linux.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@305371 91177308-0d34-0410-b5e6-96231b3b80d8
This allows us to use yaml2obj and obj2yaml to round-trip CodeView
symbol and type information without having to manually specify the bytes
of the section. This makes for much easier to maintain tests. See the
tests under lld/COFF in this patch for example. Before they just said
SectionData: <blob> whereas now we can use meaningful record
descriptions. Note that it still supports the SectionData yaml field,
which could be useful for initializing a section to invalid bytes for
testing, for example.
Differential Revision: https://reviews.llvm.org/D34127
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@305366 91177308-0d34-0410-b5e6-96231b3b80d8
This adds support for Symbols, StringTable, and FrameData subsection
types. Even though these subsections rarely if ever appear in a PDB
file (they are usually in object files), there's no theoretical reason
why they *couldn't* appear in a PDB. The real issue though is that in
order to add support for dumping and writing them (which will be useful
for object files), we need a way to test them. And since there is no
support for reading and writing them to / from object files yet, making
PDB support them is the best way to both add support for the underlying
format and add support for tests at the same time. Later, when we go
to add support for reading / writing them from object files, we'll need
only minimal changes in the underlying read/write code.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@305037 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
I did this a long time ago with a janky python script, but now
clang-format has built-in support for this. I fed clang-format every
line with a #include and let it re-sort things according to the precise
LLVM rules for include ordering baked into clang-format these days.
I've reverted a number of files where the results of sorting includes
isn't healthy. Either places where we have legacy code relying on
particular include ordering (where possible, I'll fix these separately)
or where we have particular formatting around #include lines that
I didn't want to disturb in this patch.
This patch is *entirely* mechanical. If you get merge conflicts or
anything, just ignore the changes in this patch and run clang-format
over your #include lines in the files.
Sorry for any noise here, but it is important to keep these things
stable. I was seeing an increasing number of patches with irrelevant
re-ordering of #include lines because clang-format was used. This patch
at least isolates that churn, makes it easy to skip when resolving
conflicts, and gets us to a clean baseline (again).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@304787 91177308-0d34-0410-b5e6-96231b3b80d8
While it's not entirely clear why a compiler or linker might
put this information into an object or PDB file, one has been
spotted in the wild which was causing llvm-pdbdump to crash.
This patch adds support for reading-writing these sections.
Since I don't know how to get one of the native tools to
generate this kind of debug info, the only test here is one
in which we feed YAML into the tool to produce a PDB and
then spit out YAML from the resulting PDB and make sure that
it matches.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@304738 91177308-0d34-0410-b5e6-96231b3b80d8
Previously we would expect certain subsections to appear
in a certain order because some subsections would reference
other subsections, but in practice we need to support
arbitrary orderings since some object file and PDB file
producers generate them this way. This also paves the
way for supporting Yaml <-> Object File conversion of
CodeView, since Object Files typically have quite a
large number of subsections in their debug info.
Differential Revision: https://reviews.llvm.org/D33807
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@304588 91177308-0d34-0410-b5e6-96231b3b80d8
Object files have symbol records not aligned to any particular
boundary (e.g. 1-byte aligned), while PDB files have symbol
records padded to 4-byte aligned boundaries. Since they share
the same reading / writing code, we have to provide an option to
specify the alignment and propagate it up to the producer or
consumer who knows what the alignment is supposed to be for the
given container type.
Added a test for this by modifying the existing PDB -> YAML -> PDB
round-tripping code to round trip symbol records as well as types.
Differential Revision: https://reviews.llvm.org/D33785
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@304484 91177308-0d34-0410-b5e6-96231b3b80d8
The code was a mess and disorganized due to the sheer amount
of it being in one file. So I'm splitting this into three files.
One for CodeView types, one for CodeView symbols, and one for
CodeView debug subsections. NFC.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@304278 91177308-0d34-0410-b5e6-96231b3b80d8
CodeViewYAML.h attempts to hide the details of many of the
CodeView yaml structures and types, but at the same time it
exposes the mapping traits for them to external users of the
header.
This patch just hides these in the implementation files so that
the interface is kept as simple as possible.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@304263 91177308-0d34-0410-b5e6-96231b3b80d8
This continues the effort to get the CodeView YAML parsing logic
into ObjectYAML. After this patch, the only missing piece will
be the CodeView debug symbol subsections.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@304256 91177308-0d34-0410-b5e6-96231b3b80d8
This is the beginning of an effort to move the codeview yaml
reader / writer into ObjectYAML so that it can be shared.
Currently the only consumer / producer of CodeView YAML is
llvm-pdbdump, but CodeView can exist outside of PDB files, and
indeed is put into object files and passed to the linker to
produce PDB files. Furthermore, there are subtle differences
in the types of records that show up in object file CodeView
vs PDB file CodeView, but they are otherwise 99% the same.
By having this code in ObjectYAML, we can have llvm-pdbdump
reuse this code, while teaching obj2yaml and yaml2obj to use
this syntax for dealing with object files that can contain
CodeView.
This patch only adds support for CodeView type information
to ObjectYAML. Subsequent patches will add support for
CodeView symbol information.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@304248 91177308-0d34-0410-b5e6-96231b3b80d8
Previously we had only supported the importing and
exporting of functions and globals.
Also, add usefull overload of getWasmSymbol() and
getNumberOfSymbols() in support of lld port.
Differential Revision: https://reviews.llvm.org/D33011
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@302601 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Addends are used as offsets to addresses of globals
and can be both positive and negative. This change
prints libObject in line with the spec and the MC
layer.
Subscribers: jfb, dschuff
Differential Revision: https://reviews.llvm.org/D32507
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301369 91177308-0d34-0410-b5e6-96231b3b80d8
Associate the version-when-defined with definitions of standard DWARF
constants. Identify the "vendor" for DWARF extensions.
Use this information to verify FORMs in .debug_abbrev are defined as
of the DWARF version specified in the associated unit.
Removed two tests that had specified DWARF v1 (which essentially does
not exist).
Differential Revision: http://reviews.llvm.org/D30785
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@300875 91177308-0d34-0410-b5e6-96231b3b80d8
Mostly this change adds support converting to and from
YAML which will allow us to write more test cases for
the WebAssembly MC and lld ports.
Better support for objdump, readelf, and nm will be in
followup CLs.
I had to update the two wasm test binaries because they
used the old style 'name' section which is no longer
supported.
Differential Revision: https://reviews.llvm.org/D31099
Patch by Sam Clegg
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@299101 91177308-0d34-0410-b5e6-96231b3b80d8
In DWARF5 the Unit header added a new field, UnitType, and swapped the order of the address size and abbreviation offset fields.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@297183 91177308-0d34-0410-b5e6-96231b3b80d8
This patch adds support to the DWARF YAML reader and writer for the new DWARF5 abbreviation form, DW_FORM_implicit_const.
The attribute was added in r291599.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@297091 91177308-0d34-0410-b5e6-96231b3b80d8
In the DWARF 4 Spec section 7.2.2, data in many DWARF sections, and some DWARF structures start with "Initial Length Values", which are a 32-bit length, and an optional 64-bit length if the 32 bit value == UINT32_MAX.
This patch abstracts the Initial Length type in YAML, and extends its use to all the DWARF structures that are supported in the DWARFYAML code that have Initial Length values.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@296911 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Add a new load command LC_BUILD_VERSION. It is a generic version of
LC_*_VERSION_MIN load_command used on Apple platforms. Instead of having
a seperate load command for each platform, LC_BUILD_VERSION is recording
platform info as an enum. It also records SDK version, min_os, and tools
that used to build the binary.
rdar://problem/29781291
Reviewers: enderby
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D29044
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@292824 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: This patch adds some new APIs to enable using the YAML DWARF representation in unit tests. The most basic new API is DWARFYAML::EmitDebugSections which converts a YAML string into a series of owned MemoryBuffer objects stored in a StringMap. The string map can then be used to construct a DWARFContext for parsing in place of an ObjectFile.
Reviewers: dblaikie, clayborg
Subscribers: mgorny, fhahn, jgosnell, aprantl, llvm-commits
Differential Revision: https://reviews.llvm.org/D28828
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@292634 91177308-0d34-0410-b5e6-96231b3b80d8
This patch pulls the yaml2dwarf code out of yaml2obj into a new set of DWARF emitter functions in the DWARFYAML namespace. This will enable the YAML->DWARF code to be used inside DWARF tests by populating the DWARFYAML structs and calling the Emitter functions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@291828 91177308-0d34-0410-b5e6-96231b3b80d8
One more try... relanding r291541 with a fix to properly gate MaxOpsPerInst on DWARF version.
Description from r291541:
This patch re-lands r291470, which failed on Linux bots. The issue (I believe) was undefined behavior because the size of llvm::dwarf::LineNumberOps was not explcitly specified or consistently respected. The updated patch adds an explcit underlying type to the enum and preserves the size more correctly.
Original description:
This patch adds support for the DWARF debug_lines section. The line table state machine opcodes are preserved, so this can be used to test the state machine evaluation directly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@291546 91177308-0d34-0410-b5e6-96231b3b80d8
This patch re-lands r291470, which failed on Linux bots. The issue (I believe) was undefined behavior because the size of llvm::dwarf::LineNumberOps was not explcitly specified or consistently respected. The updated patch adds an explcit underlying type to the enum and preserves the size more correctly.
Original description:
This patch adds support for the DWARF debug_lines section. The line table state machine opcodes are preserved, so this can be used to test the state machine evaluation directly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@291541 91177308-0d34-0410-b5e6-96231b3b80d8
This patch adds support for the DWARF debug_lines section. The line table state machine opcodes are preserved, so this can be used to test the state machine evaluation directly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@291470 91177308-0d34-0410-b5e6-96231b3b80d8
This patch adds support for YAML<->DWARF for debug_info sections.
This re-lands r290147, reverted in 290148, re-landed in r290204 after fixing the issue that caused bots to fail (thank you UBSan!), and reverted again in r290209 due to failures on big endian systems.
After adding support for preserving endianness, this should be good now.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@290386 91177308-0d34-0410-b5e6-96231b3b80d8
This patch adds support to the macho<->yaml tools for preserving endianness in MachO structures and DWARF data.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@290381 91177308-0d34-0410-b5e6-96231b3b80d8
This patch adds support for YAML<->DWARF for debug_info sections.
This re-lands r290147, after fixing the issue that caused bots to fail (thank you UBSan!).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@290204 91177308-0d34-0410-b5e6-96231b3b80d8
This patch adds support for YAML<->DWARF round tripping for pub* section data. The patch supports both GNU and non-GNU style entries.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@290139 91177308-0d34-0410-b5e6-96231b3b80d8
Since all the DWARF classes are in a DWARFYAML namespace having every class start with DWARF seems like a bit of overkill.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289080 91177308-0d34-0410-b5e6-96231b3b80d8
