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

[Alexander Shaposhnikov via llvm-commits]

-fdebug-compilation-dir should do the same trick,
i will update the patch soon,
many thanks.

On Fri, Sep 1, 2017 at 10:49 PM, David Blaikie <dblaikie at gmail.com> wrote:

> 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/20170901/292dab87/attachment.html>