This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: sysroot option handling

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
Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]