This is an archive of the discontinued LLVM Phabricator instance.

Rewrite TestTargetSymbolsBuildidCase to be more focused
ClosedPublic

Authored by labath on Feb 5 2018, 9:23 AM.

Details

Summary

The test was failing in remote debugging scenario with windows as a host
as cmd.exe is not able to parse the complicated shell commands in the
Makefile.

The test seemed like a perfect candidate for a more focused testing
approach, so I have tried rewriting it this way. It uses two yaml
files which represent "stripped" and "unstripped" versions of a binary.
The unstripped version defines a symbol "main" while the stripped one
doesn't. The test works by creating an SBModule pointing the the
stripped file and verifies that we are able to locate the unstripped one
by looking up the "main" symbol.

Diff Detail

Repository
rL LLVM

Event Timeline

labath created this revision.Feb 5 2018, 9:23 AM
davide added a subscriber: davide.Feb 5 2018, 9:39 AM

Nice :)
This looks already fine as-is, but I wonder whether we can get rid of the python boilerplate altogether?
There has been quite a bit of discussion about using lldb-test for this sort of more focused testing, so I wonder whether you gave it a try? (just a random thought, didn't see whether this is feasible).
FWIW, I'm working on extending lldb-test as an experiment to test new functionalities so that we can test in a way that's more akin to llvm.

FYI it FAILs for me on Fedora 27 x86_64, it cannot find "main", debugging it. The .build-id/ separate debug info does work with GDB but not with LLDB.

Yea this seems like a good candidate for an lldb-test test. Something like this.

RUN: yaml2obj %S/Inputs/stripped.yaml > %t.stripped.out
RUN: yaml2obj %S/Inputs/unstripped.yaml > %t/.build-id/1b/8a73ac238390e32a7ff4ac8ebe4d6a41ecf5c9.debug
RUN: lldb-test symbols %t.stripped.out | FileCheck %s

CHECK: main

Yea this seems like a good candidate for an lldb-test test. Something like this.

RUN: yaml2obj %S/Inputs/stripped.yaml > %t.stripped.out
RUN: yaml2obj %S/Inputs/unstripped.yaml > %t/.build-id/1b/8a73ac238390e32a7ff4ac8ebe4d6a41ecf5c9.debug
RUN: lldb-test symbols %t.stripped.out | FileCheck %s

CHECK: main

Indeed. It wasn't 100% clear how to do this in my mind, thanks for clarifying :)

Davide

jankratochvil accepted this revision.Feb 5 2018, 2:27 PM

It does work for me also with: r324254 - Fix parsing of object files with "early" section headers

This revision is now accepted and ready to land.Feb 5 2018, 2:27 PM
labath added a comment.Feb 6 2018, 2:47 AM

Heh, no good deed goes unpunished, right.. :)

It occured to me that this could be testable using the existing lldb-test module-sections functionality (I don't need to use a symbol, I can easily use a section name to recognise that a debug info was loaded from the other file), but I ran into approximately two bugs that make that hard right now:

  1. Module::GetSectionList will not return the extra sections unless some other call has been made to initialize the symbol vendor
  2. the .debug_frame section (which i chose to use for the test) seems to be added twice

I'll try to take a look at how hard is it to resolve those...

This revision was automatically updated to reflect the committed changes.
lldb/trunk/packages/Python/lldbsuite/test/linux/buildidcase/Makefile