Re: sysroot option handling

[Arkady <arkady dot miasnikov at gmail dot com>]

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
>>
>