sysroot option handling

Fri Mar 9 18:12:00 GMT 2018

Hi David,

On Fri, 9 Mar 2018, David Smith wrote:

> Oh, one more thing here.
>
> I was chatting with Frank about this, and I think he's convinced me
> that one thing to help in the sysroot code is to always have one. If
> the user doesn't specify one, treat that case like "--sysroot=/". That
> should hopefully simplify the code a bit (we'd never have to check for
> an empty sysroot since it would always have a value).

But in some cases code really needs to know whether it is native
or cross compilation case. Check my patch 2 [1], existing code
already checking 's.sysroot == "/"' and I retained it and modified.
In this particular case handling of short kernel release, that
ultimately goes into dwfl_linux_kernel_report_offline, should be
different between native and cross compilation case, since 
dwfl_linux_kernel_report_offline does not have concept of sysroot
passing short version in case of cross build does not make sense,
in fact it is danegrous since it may pick up native kernel if version
coincide.

I think Frank's idea about --sysroot=/ would work cleanly everywhere
if elfutils library in its symbol files search algorithms would get and
understand notion of sysroot ... do you think in long term we can
push for it? But untill that is done we would need to have code that
plays around elfutils missing about sysroot. I.e debuginfo_path issue
that you caught in my patch 3, in principal suffers for the same
problem: elfutils symbol file lookup code does not know about sysroot.

Thanks,
Victor

[1] https://sourceware.org/ml/systemtap/2018-q1/msg00067.html

> On Fri, Mar 9, 2018 at 11:35 AM, David Smith <dsmith@redhat.com> wrote:
>> Victor,
>>
>> For testing, we need a solution that can be set up without any user
>> intervention and works across all tested architectures. I don't
>> believe qemu meets those requirements.
>>
>> Arkady, a docker container might work, but also wouldn't be available
>> on all arch/os combinations.
>>
>> Victor, I should have spelled out my bind mounts idea more fully. We'd
>> bind mount the kernel build tree to a new location (for example), then
>> bind mount an empty directory over the old directory location (so
>> there'd be no leaks). The advantage this idea has is that it is
>> supported on all arch/os combinations, (fairly) easily scriptable, and
>> doesn't require extra software.
>>
>>
>> On Fri, Mar 9, 2018 at 12:16 AM, Arkady <arkady.miasnikov@gmail.com> wrote:
>>> I did not read the whole thread - will a Docker container do the trick?
>>>
>>> On Fri, Mar 9, 2018 at 1:07 AM, Victor Kamensky <kamensky@cisco.com> wrote:
>>>> Hi David,
>>>>
>>>> On Thu, 8 Mar 2018, David Smith wrote:
>>>>
>>>>> Victor,
>>>>> k
>>>>> I'm working through your sysroot patches now,
>>>>
>>>>
>>>> I appreciate your time and attention to this!
>>>>
>>>>> but here's the problem
>>>>> we have with this code in general. Someone wanted this feature and the
>>>>> work got done. However, we never could figure a way of testing it. So,
>>>>> over time the functionality has gotten broken without anyone
>>>>> realizing. I'd imagine others have tried it, realized it didn't work
>>>>> properly, and abandoned it.
>>>>
>>>>
>>>> I reckon, that is something like this. Although I could not make it
>>>> work even when I went to the point when first --sysroot support
>>>> was committed, although I might be doing something wrong.
>>>>
>>>>> I'd love to find a way to test this on a "normal" system (without a
>>>>> real sysroot).
>>>>
>>>>
>>>> Real sysroot is not that bad :). If you find time please try
>>>> setup I aranged and pointed in my cover letter:
>>>>
>>>> https://github.com/victorkamensky/systemtap-oe-sysroot-manifest
>>>>
>>>> Since it uses qemu one can really run it on regular x86 Linux machine,
>>>> and inside of qemu one can run full Linux even of different CPU type.
>>>> Since it is cross mode, and target qemu Linux does not need to
>>>> run SystemTap translator, target limitted performance is not an
>>>> issue.
>>>>
>>>> It is quite fun IMHO, I advise to try it. It also will cover adjacent
>>>> testing needs like testing on other CPU types like armv7,
>>>> aarch64, ppc, and mips ... I am not sure what you do now to
>>>> cover those, Fedora/RedHat does cover some other CPU types but not all
>>>> that supported by SystemTap. BTW I did run into several quirks/errors on
>>>> different CPU types during my limitted testings, I did not have
>>>> time to look at them yet.
>>>>
>>>> I do work now in parallel on pushing patches as in above setup to
>>>> OpenEmbedded, I really care that cross compiled use of systemtap
>>>> in OE should be very smooth. I hope when it is accepted more people
>>>> will use it. It will give SystemTap --sysroot more coverage. Please
>>>> check:
>>>>
>>>> http://lists.openembedded.org/pipermail/openembedded-core/2018-March/148387.html
>>>>
>>>> In prinicipal DejaGnu framework that SystemTap uses for testing
>>>> can support cross build environment, where compilation happens
>>>> on host in cross mode but execution and test runs on target. I
>>>> once was sort of somewhat close of this thing working for
>>>> SystemTap. But did not follow up on it :(. Please check in your
>>>> systemtap git tree "git show 2fbd4ab" (it is on never completed
>>>> systemtap-1.6-cisco-patches, just for reference branch). It is
>>>> doable but quite a bit of work. I am not ready to commit to repeat
>>>> it yet :).
>>>>
>>>> Note but if one can get there and with combination with qemu machines
>>>> both --sysroot and non-x86 CPU testing could be covered.
>>>>
>>>>> Perhaps set up bind mounts to make it appear that the
>>>>> current kernel-devel tree is under a sysroot directory (we did
>>>>> something similar for server testing)?
>>>>
>>>>
>>>> The drawback of above approach that host and fake "target sysroot"
>>>> are not that different. I.e if one has problem
>>>> with --sysroot handling and it bleeds to host instead, if host
>>>> binary and DWARF symbols are
>>>> the same as on fake sysroot it is hard to notice it, since it would keep
>>>> working. For example I specifically choose "mkdir.coreutils" as
>>>> my testing target since such binary would not exist on my host.
>>>>
>>>>> If you've got any ideas here I'd love to hear them.
>>>>
>>>>
>>>> Sorry, I cannot give full solution, but I hope my responses
>>>> were somewhat helpful.
>>>>
>>>> Thanks,
>>>> Victor
>>>>
>>>>
>>>>> --
>>>>> David Smith
>>>>> Associate Manager
>>>>> Red Hat
>>>>>
>>>>
>>
>>
>>
>> --
>> David Smith
>> Associate Manager
>> Red Hat
>
>
>
> -- 
> David Smith
> Associate Manager
> Red Hat
>