History log of /llvm-project/llvm/tools/dsymutil/MachODebugMapParser.cpp (Results 76 – 98 of 98)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 9ccfddc3 22-Jul-2015 Frederic Riss <friss@apple.com>

[dsymutil] Check archive members timestamps.

The debug map contains the timestamp of the object files in references.
We do not check these in the general case, but it's really useful if
you have arc

[dsymutil] Check archive members timestamps.

The debug map contains the timestamp of the object files in references.
We do not check these in the general case, but it's really useful if
you have archives where different versions of an object file have been
appended. This allows llvm-dsymutil to find the right one.

llvm-svn: 242965

show more ...


Revision tags: llvmorg-3.7.0-rc1
# be8b0ea8 07-Jul-2015 Rafael Espindola <rafael.espindola@gmail.com>

Delete UnknownAddress. It is a perfectly valid symbol value.

getSymbolValue now returns a value that in convenient for most callers:
* 0 for undefined
* symbol size for common symbols
* offset/addre

Delete UnknownAddress. It is a perfectly valid symbol value.

getSymbolValue now returns a value that in convenient for most callers:
* 0 for undefined
* symbol size for common symbols
* offset/address for symbols the rest

Code that needs something more specific can check getSymbolFlags.

llvm-svn: 241605

show more ...


# 7e7be92c 07-Jul-2015 Rafael Espindola <rafael.espindola@gmail.com>

Common symbols don't have a value.

At least not in the interface exposed by ObjectFile. This matches what ELF and
COFF implement.

Adjust existing code that was expecting them to have values. No ove

Common symbols don't have a value.

At least not in the interface exposed by ObjectFile. This matches what ELF and
COFF implement.

Adjust existing code that was expecting them to have values. No overall
functionality change intended.

Another option would be to change the interface and the ELF and COFF
implementations to say that the value of a common symbol is its size.

llvm-svn: 241593

show more ...


# e2df87f2 03-Jul-2015 Rafael Espindola <rafael.espindola@gmail.com>

Replace a few more MachO only uses of getSymbolAddress.

llvm-svn: 241365


# 5d0c2ffa 02-Jul-2015 Rafael Espindola <rafael.espindola@gmail.com>

Return ErrorOr from SymbolRef::getName.

This function can really fail since the string table offset can be out of
bounds.

Using ErrorOr makes sure the error is checked.

Hopefully a lot of the boil

Return ErrorOr from SymbolRef::getName.

This function can really fail since the string table offset can be out of
bounds.

Using ErrorOr makes sure the error is checked.

Hopefully a lot of the boilerplate code in tools/* can go away once we have
a diagnostic manager in Object.

llvm-svn: 241297

show more ...


# 2fa80cc5 26-Jun-2015 Rafael Espindola <rafael.espindola@gmail.com>

Simplify getSymbolType.

This is still a really odd function. Most calls are in object format specific
contexts and should probably be replaced with a more direct query, but at least
now this is not

Simplify getSymbolType.

This is still a really odd function. Most calls are in object format specific
contexts and should probably be replaced with a more direct query, but at least
now this is not too obnoxious to use.

llvm-svn: 240777

show more ...


Revision tags: llvmorg-3.6.2
# d7a32ea4 24-Jun-2015 Rafael Espindola <rafael.espindola@gmail.com>

Change how symbol sizes are handled in lib/Object.

COFF and MachO only define symbol sizes for common symbols. Reflect that
in the class hierarchy by having a method for common symbols only in the b

Change how symbol sizes are handled in lib/Object.

COFF and MachO only define symbol sizes for common symbols. Reflect that
in the class hierarchy by having a method for common symbols only in the base
and a general one in ELF.

This avoids the need of using a magic value for the size, which had a few
problems
* Most callers didn't check for it.
* The ones that did could not tell the magic value from a file actually having
that value.

llvm-svn: 240529

show more ...


Revision tags: llvmorg-3.6.2-rc1
# f37964cc 05-Jun-2015 Frederic Riss <friss@apple.com>

[dsymutil] Apply clang-format. NFC

llvm-svn: 239186


# 4d0ba668 05-Jun-2015 Frederic Riss <friss@apple.com>

[dsymutil] Out-line the YAML serialization code. NFC

It will get a bit bigger in an upcoming commit. No need to have all
of that in the header.

Also move parseYAMLDebugMap() to the same place as th

[dsymutil] Out-line the YAML serialization code. NFC

It will get a bit bigger in an upcoming commit. No need to have all
of that in the header.

Also move parseYAMLDebugMap() to the same place as the serialization
code. This way it will be able to share a private Context object with
it.

llvm-svn: 239185

show more ...


# c0866ad2 05-Jun-2015 Frederic Riss <friss@apple.com>

[dsymutil] Handle the -oso-prepend-path option when the input is a YAML debug map

All the tests using a YAML debug map will need this.

llvm-svn: 239163


# 90e0bd96 03-Jun-2015 Frederic Riss <friss@apple.com>

Reapply r238941 - [dsymutil] Accept a YAML debug map as input instead of a binary.

With a couple more constructors that GCC thinks are necessary.

Original commit message:

[dsymutil] Accept a YAML

Reapply r238941 - [dsymutil] Accept a YAML debug map as input instead of a binary.

With a couple more constructors that GCC thinks are necessary.

Original commit message:

[dsymutil] Accept a YAML debug map as input instead of a binary.

To do this, the user needs to pass the new -y flag.
As it wasn't tested before, the debug map YAML deserialization was
completely buggy (mainly because the DebugMapObject has a dual
mapping that allows to search by name and by address, but only the
StringMap got populated). It's fixed and tested in this commit by
augmenting some test with a 2 stage dwarf link: a frist llvm-dsymutil
reads the debug map and pipes it in a second instance that does the
actual link without touching the initial binary.

llvm-svn: 238959

show more ...


# 28dbc5ab 03-Jun-2015 Frederic Riss <friss@apple.com>

Revert "[dsymutil] Accept a YAML debug map as input instead of a binary."

This reverts commit r238941 while I figure out the bot issues.

llvm-svn: 238943


# 063d674c 03-Jun-2015 Frederic Riss <friss@apple.com>

[dsymutil] Accept a YAML debug map as input instead of a binary.

To do this, the user needs to pass the new -y flag.
As it wasn't tested before, the debug map YAML deserialization was
completely bug

[dsymutil] Accept a YAML debug map as input instead of a binary.

To do this, the user needs to pass the new -y flag.
As it wasn't tested before, the debug map YAML deserialization was
completely buggy (mainly because the DebugMapObject has a dual
mapping that allows to search by name and by address, but only the
StringMap got populated). It's fixed and tested in this commit by
augmenting some test with a 2 stage dwarf link: a frist llvm-dsymutil
reads the debug map and pipes it in a second instance that does the
actual link without touching the initial binary.

llvm-svn: 238941

show more ...


Revision tags: llvmorg-3.6.1, llvmorg-3.6.1-rc1, llvmorg-3.5.2, llvmorg-3.5.2-rc1
# 912d0f12 15-Mar-2015 Frederic Riss <friss@apple.com>

[dsymutil] Add function size to the debug map.

The debug map embedded by ld64 in binaries conatins function sizes.
These sizes are less precise than the ones given by the debug information
(byte gra

[dsymutil] Add function size to the debug map.

The debug map embedded by ld64 in binaries conatins function sizes.
These sizes are less precise than the ones given by the debug information
(byte granularity vs linker atom granularity), but they might cover code
that is referenced in the line table but not in the DIE tree (that might
very well be a compiler bug that I need to investigate later).
Anyway, extracting that information is necessary to be able to mimic
dsymutil's behavior exactly.

llvm-svn: 232300

show more ...


# 9ac9a283 28-Feb-2015 Frederic Riss <friss@apple.com>

[dsymutil] clang-format a file

llvm-svn: 230822


Revision tags: llvmorg-3.6.0, llvmorg-3.6.0-rc4, llvmorg-3.6.0-rc3, llvmorg-3.6.0-rc2
# e4a6fef9 19-Jan-2015 Frederic Riss <friss@apple.com>

[dsymutil] Add the detected target triple to the debug map.

It will be needed to instantiate the Target object that we will
use to create all the MC objects for the dwarf emission.

llvm-svn: 226525


Revision tags: llvmorg-3.6.0-rc1
# db50b3d0 07-Jan-2015 Alexey Samsonov <vonosmas@gmail.com>

Fix uninitialized memory read in llvm-dsymutil for the second time.

This was already fixed by r224481, but apparently was accidentally
reverted in r225207.

llvm-svn: 225386


# 43988507 05-Jan-2015 Frederic Riss <friss@apple.com>

[dsymutil] Implement the BinaryHolder object and gain archive support.

This object is meant to own the ObjectFiles and their underlying
MemoryBuffer. It is basically the equivalent of an OwningBinar

[dsymutil] Implement the BinaryHolder object and gain archive support.

This object is meant to own the ObjectFiles and their underlying
MemoryBuffer. It is basically the equivalent of an OwningBinary
except that it efficiently handles Archives. It is optimized for
efficiently providing mappings of members of the same archive when
they are opened successively (which is standard in Darwin debug
maps, objects from the same archive will be contiguous).

Of course, the BinaryHolder will also be used by the DWARF linker
once it is commited, but for now only the debug map parser uses it.

With this change, you can run llvm-dsymutil on your Darwin debug build
of clang and get a complete debug map for it.

Differential Revision: http://reviews.llvm.org/D6690

llvm-svn: 225207

show more ...


Revision tags: llvmorg-3.5.1, llvmorg-3.5.1-rc2
# d927bd8d 18-Dec-2014 Alexey Samsonov <vonosmas@gmail.com>

[dsymutil] Fix missing member initializer.

This bug was found by the MSan bootstrap bot:
http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap/builds/5330/steps/check-llvm%20msan/logs/s

[dsymutil] Fix missing member initializer.

This bug was found by the MSan bootstrap bot:
http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap/builds/5330/steps/check-llvm%20msan/logs/stdio

llvm-svn: 224481

show more ...


# 19b68ddd 16-Dec-2014 Frederic Riss <friss@apple.com>

[dsymutil] Pass the verbosity flag down to the processing. NFC for now.

llvm-svn: 224361


# 896b2c53 16-Dec-2014 Frederic Riss <friss@apple.com>

[dsymutil] Avoid calling getStringTableData() for each symbol. NFC.

llvm-svn: 224360


# 231f714e 12-Dec-2014 Frederic Riss <friss@apple.com>

Initial dsymutil tool commit.

The goal of this tool is to replicate Darwin's dsymutil functionality
based on LLVM. dsymutil is a DWARF linker. Darwin's linker (ld64) does
not link the debug informat

Initial dsymutil tool commit.

The goal of this tool is to replicate Darwin's dsymutil functionality
based on LLVM. dsymutil is a DWARF linker. Darwin's linker (ld64) does
not link the debug information, it leaves it in the object files in
relocatable form, but embbeds a `debug map` into the executable that
describes where to find the debug information and how to relocate it.
When releasing/archiving a binary, dsymutil is called to link all the DWARF
information into a `dsym bundle` that can distributed/stored along with
the binary.

With this commit, the LLVM based dsymutil is just able to parse the STABS
debug maps embedded by ld64 in linked binaries (and not all of them, for
example archives aren't supported yet).

Note that the tool directory is called dsymutil, but the executable is
currently called llvm-dsymutil. This discrepancy will disappear once the
tool will be feature complete. At this point the executable will be renamed
to dsymutil, but until then you do not want it to override the system one.

Differential Revision: http://reviews.llvm.org/D6242

llvm-svn: 224134

show more ...


# 893c4f1e 09-Dec-2014 Frederic Riss <friss@apple.com>

Initial dsymutil tool commit.

The goal of this tool is to replicate Darwin's dsymutil functionality
based on LLVM. dsymutil is a DWARF linker. Darwin's linker (ld64) does
not link the debug informat

Initial dsymutil tool commit.

The goal of this tool is to replicate Darwin's dsymutil functionality
based on LLVM. dsymutil is a DWARF linker. Darwin's linker (ld64) does
not link the debug information, it leaves it in the object files in
relocatable form, but embbeds a `debug map` into the executable that
describes where to find the debug information and how to relocate it.
When releasing/archiving a binary, dsymutil is called to link all the DWARF
information into a `dsym bundle` that can distributed/stored along with
the binary.

With this commit, the LLVM based dsymutil is just able to parse the STABS
debug maps embedded by ld64 in linked binaries (and not all of them, for
example archives aren't supported yet).

Note that the tool directory is called dsymutil, but the executable is
currently called llvm-dsymutil. This discrepancy will disappear once the
tool will be feature complete. At this point the executable will be renamed
to dsymutil, but until then you do not want it to override the system one.

Differential Revision: http://reviews.llvm.org/D6242

llvm-svn: 223793

show more ...


1234