summaryrefslogtreecommitdiffstats
path: root/llvm/tools/dsymutil/MachODebugMapParser.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* Return ErrorOr from SymbolRef::getName.Rafael Espindola2015-07-021-6/+13
| | | | | | | | | | | | 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
* Simplify getSymbolType.Rafael Espindola2015-06-261-3/+2
| | | | | | | | 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
* Change how symbol sizes are handled in lib/Object.Rafael Espindola2015-06-241-5/+4
| | | | | | | | | | | | | | 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
* [dsymutil] Apply clang-format. NFCFrederic Riss2015-06-051-1/+0
| | | | llvm-svn: 239186
* [dsymutil] Out-line the YAML serialization code. NFCFrederic Riss2015-06-051-19/+6
| | | | | | | | | | | 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
* [dsymutil] Handle the -oso-prepend-path option when the input is a YAML ↵Frederic Riss2015-06-051-3/+3
| | | | | | | | debug map All the tests using a YAML debug map will need this. llvm-svn: 239163
* Reapply r238941 - [dsymutil] Accept a YAML debug map as input instead of a ↵Frederic Riss2015-06-031-3/+23
| | | | | | | | | | | | | | | | | | | | | 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
* Revert "[dsymutil] Accept a YAML debug map as input instead of a binary."Frederic Riss2015-06-031-23/+3
| | | | | | This reverts commit r238941 while I figure out the bot issues. llvm-svn: 238943
* [dsymutil] Accept a YAML debug map as input instead of a binary.Frederic Riss2015-06-031-3/+23
| | | | | | | | | | | | | 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
* [dsymutil] Add function size to the debug map.Frederic Riss2015-03-151-5/+18
| | | | | | | | | | | | 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
* [dsymutil] clang-format a fileFrederic Riss2015-02-281-3/+2
| | | | llvm-svn: 230822
* [dsymutil] Add the detected target triple to the debug map.Frederic Riss2015-01-191-1/+8
| | | | | | | 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
* Fix uninitialized memory read in llvm-dsymutil for the second time.Alexey Samsonov2015-01-071-1/+2
| | | | | | | This was already fixed by r224481, but apparently was accidentally reverted in r225207. llvm-svn: 225386
* [dsymutil] Implement the BinaryHolder object and gain archive support.Frederic Riss2015-01-051-34/+17
| | | | | | | | | | | | | | | | | | | 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
* [dsymutil] Fix missing member initializer.Alexey Samsonov2014-12-181-1/+2
| | | | | | | 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
* [dsymutil] Pass the verbosity flag down to the processing. NFC for now.Frederic Riss2014-12-161-1/+2
| | | | llvm-svn: 224361
* [dsymutil] Avoid calling getStringTableData() for each symbol. NFC.Frederic Riss2014-12-161-2/+3
| | | | llvm-svn: 224360
* Initial dsymutil tool commit.Frederic Riss2014-12-121-0/+247
| | | | | | | | | | | | | | | | | | | | | | | | 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
* Revert "Initial dsymutil tool commit."Frederic Riss2014-12-091-194/+0
| | | | | | This reverts commit r223793. The review thread wasn't concluded. llvm-svn: 223794
* Initial dsymutil tool commit.Frederic Riss2014-12-091-0/+194
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
OpenPOWER on IntegriCloud