| Commit message (Collapse) | Author | Age | Files | Lines | |
|---|---|---|---|---|---|
| * | llvm-symbolizer: Extract individual test cases now that it's easier to use ↵ | David Blaikie | 2019-01-24 | 1 | -20/+0 |
| | | | | | | | | | | | directly (without a piped input file) Pulling out the split-dwarf tests by way of example of how I think llvm-symbolizer should be tested going forward. Open to debate/discussion, though. llvm-svn: 352004 | ||||
| * | llvm-symbolizer: prefer .dwo contents over fission-gmlt-like-data when .dwo ↵ | David Blaikie | 2016-04-22 | 1 | -5/+8 |
| | | | | | | | | | | | | | | | | | | | | | | file is present Rather than relying on the gmlt-like data emitted into the .o/executable which only contains the simple name of any inlined functions, use the .dwo file if present. Test symbolication with/without a .dwo, and the old test that was testing behavior when no gmlt-like data was present. (I haven't included a test of non-gmlt-like data + no .dwo (that would be akin to symbolication with no debug info) but we could add one for completeness) The test was simplified a bit to be a little clearer (unoptimized, force inline, using a function call as the inlined entity) and regenerated with ToT clang. For the no-gmlt-like-data case, I modified Clang back to its old behavior temporarily & the .dwo file is identical so it is shared between the two executables. llvm-svn: 267227 | ||||
| * | [DWARF parser] Fix nasty memory corruption in .dwo files handling. | Alexey Samsonov | 2014-09-05 | 1 | -0/+17 |
| Forge a test case where llvm-symbolizer has to use external .dwo file to produce the inlining information. llvm-svn: 217270 | |||||
 |
index : bcm5719-llvm | |
| Project Ortega BCM5719 LLVM | Raptor Computing Systems |
| summaryrefslogtreecommitdiffstats |
|