[PATCH] D80168: For --relativenames, handle dwarf absolute include directories similarly to compilation directories.

[James Henderson via Phabricator via llvm-commits]

jhenderson added a comment.

In D80168#2061590 <https://reviews.llvm.org/D80168#2061590>, @echristo wrote:

> In D80168#2061323 <https://reviews.llvm.org/D80168#2061323>, @labath wrote:
>
> > In D80168#2060851 <https://reviews.llvm.org/D80168#2060851>, @saugustine wrote:
> >
> > > In D80168#2060753 <https://reviews.llvm.org/D80168#2060753>, @aprantl wrote:
> > >
> > > > Why is it necessary to check in the binary? Could we just assemble the input with llvm-mc on the fly?
> > >
> > >
> > > Because when you assemble with llvm-mc in the usual test suite, it sets the compilation directory, include directory, and input file like so:
> > >
> > > comp_dir: location where llvm-mc is run.
> > >  include_dir: absolute path to relativenames.s in the source tree
> > >  filename: "relativenames.s"
> > >
> > > So, after the comments above that we *don't* want the remove the include dir, even if it is an absolute path, the difference between the output with relative names and without is nothing: We still get the absolute path.
> >
> >
> > You don't actually have to use the `.loc`/`.file`/etc. directives to create the line table. You can go lower level and spell out the debug_lines content directly (`.byte` et al.). That way, you should be able to create any line table you want. There are a bunch of existing tests for llvm-dwarfdump line table functionality that do this so you can get some inspiration from those.
>
>
> I think if we're worried about the behavior changing when creating and want to make sure we can still handle it then we should check in binary input (and a note to say what it came from), if not then we can assemble it up using .loc just fine? Pavel: What kinds of tests were the dwarfdump .byte ones coming from?


I've written many of the llvm-dwarfdump .byte ones myself (see several test cases in tools/llvm-dwarfdump/X86), mostly to test odd code paths, like broken inputs, or specific behaviours where we can't rely on the input always being built the same way via .loc etc directives. It allows us fine-grained control over what ends up in the output of the debug line table, and is in some ways is easier to see what is going on because the specific debug line header entries are spelt out. I do lean heavily on comments though to help with the readability. The advantage is that it can easily be read and tweaked to match any new behaviour we want to test, unlike a canned binary. It's also friendlier to git in that way, and can be kept inline with the test file itself.

In my most recent work though, I've tended to lean on gtest unit tests, for which I wrote/expanded a generator that allows us to build up any input we want more or less, using a default prologue which can also be overridden if people want to test specific aspects of it. I think this is actually more preferable for testing the library code, since library code can be shared between multiple executables, as long as there are some higher-level lit tests.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D80168/new/

https://reviews.llvm.org/D80168