[PATCH] D37371: [llvm-dwp] Add command line option "-e"

[David Blaikie via llvm-commits]

Clang has a command line argument for specifying an arbitrary compilation
dir (-fdebug-compilation-dir, maybe?) - ideally I would've mentioned it in
the other DWP tests, maybe?

On Fri, Sep 1, 2017 at 10:38 PM Alexander Shaposhnikov <
alexander.v.shaposhnikov at gmail.com> wrote:

> "portable" in the following sense:
> for example, let's have a look at the binary "main".
> The debug info (inside "main") contains dwarf::DW_AT_comp_dir with the
> absolute path
> to the <build directory>, thus if you move this file to another machine
> this test can (likely will) fail.
> That's what i meant by saying that out-of-the box this binary is not
> suitable for llvm tests.
> Solution (unfortunately hacky) - replace the value of
> dwarf::DW_AT_comp_dir with the following string: ".////////".
> For more details please take a look at the comments inside the newly added
> test.
>
> On Fri, Sep 1, 2017 at 10:11 PM, David Blaikie <dblaikie at gmail.com> wrote:
>
>>
>>
>> On Fri, Sep 1, 2017 at 9:59 PM Alexander Shaposhnikov via Phabricator <
>> reviews at reviews.llvm.org> wrote:
>>
>>> alexshap updated this revision to Diff 113642.
>>> alexshap added a comment.
>>>
>>> Update the binaries used by the test and document the hack used to
>>> generate "portable" binaries.
>>>
>>
>> Why do they need to be portable? (I guess the original DWP tests that
>> just consume DWOs are portable already - because they're all ELF files, but
>> no executable code, etc - but now the executable has to be read? But does
>> it matter what target the executable is for if it's still ELF?)
>>
>>
>>>
>>> I have not committed this diff yet and will keep this open for some time
>>> since the problem with the test
>>> might be of independent interest.
>>> Notes:
>>>
>>> 1. obj2yaml + sed + yaml2obj doesn't seem to be an option at this point
>>>
>>> (we need to edit the debug info, obj2yaml dumps dwarf just as hex).
>>>
>>> 2. running the compiler + linker doesn't seem to be an option (since
>>> this is an llvm test).
>>> 3. the approach chosen below (while being hacky) only requires some
>>> efforts at the data preparation step and is quite simple,
>>>
>>> thus it seems to be the smaller evil than other options are,
>>> however i assume i could have missed something.
>>>
>>>
>>> Repository:
>>>   rL LLVM
>>>
>>> https://reviews.llvm.org/D37371
>>>
>>> Files:
>>>   test/tools/llvm-dwp/Inputs/dwos_list_from_exec/a.dwo
>>>   test/tools/llvm-dwp/Inputs/dwos_list_from_exec/b.dwo
>>>   test/tools/llvm-dwp/Inputs/dwos_list_from_exec/c.dwo
>>>   test/tools/llvm-dwp/Inputs/dwos_list_from_exec/d.dwo
>>>   test/tools/llvm-dwp/Inputs/dwos_list_from_exec/e.dwo
>>>   test/tools/llvm-dwp/Inputs/dwos_list_from_exec/main
>>>   test/tools/llvm-dwp/X86/dwos_list_from_exec_simple.test
>>>   tools/llvm-dwp/llvm-dwp.cpp
>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170902/f3cc7b62/attachment.html>