[CRIU] Need Help on Android ARM64

[Abdullah Yousafzai]

Hello Christopher,

is it possible that you can search in your collection the Android.mk file
you created so that I can re-use and not spend time in re-inventing the
wheel and one another minor question, the android you have tested was using
a custom kernel build with "CONFIG_CHECKPOINT_RESTORE" enabled ?. Also a
last question If my kernel is enabled with "CONFIG_CHECKPOINT_RESTORE",
than can I use a statically linked binary as right when I am using
statically compiled binary it gives the following error:

Error (sockets.c:128): Diag module missing (-2)
Error (sockets.c:128): Diag module missing (-2)
Error (sockets.c:128): Diag module missing (-2)
Error (kerndat.c:154): Can't stat self map_files 2: No such file or
directory
Error (cr-dump.c:1578): Dumping FAILED.

Best Regard -- ALLAH Hafiz, May Almighty ALLAH bless you



[image: --]

Abdullah Yousafzai
[image: https://]about.me/yousafzaiabdullah
<https://about.me/yousafzaiabdullah?promo=email_sig>


On Wed, Jan 27, 2016 at 11:47 PM, Christopher Covington <cov at codeaurora.org>
wrote:

> On 01/25/2016 09:39 PM, Abdullah Yousafzai wrote:
> > Hello Everybody,
> >
> > Thank you for your interest now it seems I can sort out this problem
> > with the help of you peoples.
> >
> > Christopher, does your version of CRIU on Android was statically linked
> > or dynamically linked.
>
> We've done both. My preference is for dynamic linking. Maybe building
> with bionic will just work the first time. But if it doesn't, I would
> guess that comparing against a working glibc based build would be the
> easiest way to debug.
>
> If you'd like to run CRIU that's dynamically linked against glibc, just
> make sure the following paths are valid for the expected GNU ld and libc
> components.
>
> aarch64-linux-gnu-readelf criu | grep -E '(interpreter|NEEDED)'
>
> If you get a mysterious not found error right at the beginning, it's
> probably because the linker/loader/interpreter path isn't valid.
>
> I've used the -Wl,-dynamic-linker=... and -Wl,-rpath=... build flags and
> the LD_LIBRARY_PATH=... environment variable at various times to help
> with paths.
>
> I don't know if I've reported this previously, but my recollection is
> that that <linker> <executable> style execution, such as `ld-linux.so
> criu`, doesn't work. Or maybe it was criu dump/restore of an
> `ld-linux.so loop` process, I don't remember exactly, sorry, just that
> it was a really obscure corner case.
>
> Hope that helps,
> Cov
>
> > Abdullah Yousafzai
> > https://about.me/yousafzaiabdullah
> >
> > <https://about.me/yousafzaiabdullah?promo=email_sig>
> >
> >
> > On Mon, Jan 25, 2016 at 9:45 PM, Christopher Covington
> > <cov at codeaurora.org <mailto:cov at codeaurora.org>> wrote:
> >
> >     Hi Abdullah,
> >
> >     On 01/25/2016 04:41 AM, Cyrill Gorcunov wrote:
> >     > On Mon, Jan 25, 2016 at 12:33:55PM +0300, Pavel Emelyanov wrote:
> >     >> On 01/22/2016 05:52 AM, Abdullah Yousafzai wrote:
> >     >>> Compiling CRIU for arm64 is straight and work as piece of cake
> >     but I need it to compile it for
> >     >>> android and specifically on ARM64. So for this reason I have to
> >     rewrite the Makefiles to
> >     >>> Android.mk in order to be understandable and in compliance with
> >     the android build environment.
> >     >>> I only need to checkpoint user apps and check the behavior on
> >     Android any help on breaking down
> >     >>> the existing Makefile and transforming it to Android.mk will be
> >     appreciated.
> >     >>
> >     >> I've CC-ed Christopher for help with ARM and Cyrill for help with
> >     Makefiles.
> >     >
> >     > Sorry for not replying early, managed to miss the mail. I'm ready
> >     to help but
> >     > the problem is that I've no clue about Android specifics. I've
> >     been playing with
> >     > andoid apps but they were using ant tool for building applications
> >     which is
> >     > very different from traditional make.
> >
> >     My suggestion would be to start with a stub Android.mk that calls the
> >     existing makefiles. I believe the Linux kernel Android.mk can be
> >     referred to as an example of this. There are burdens and benefits to
> >     writing and maintaining a parallel set of build instructions. I
> think a
> >     stub Android.mk could deliver many of the benefits with little of the
> >     burden. Once that's working, committed, and in use, I think it will
> be
> >     clearer what larger-scale changes and additions would be most useful.
> >
> >     I've run CRIU on Android (both AArch32 and AArch64), but it was built
> >     against the GNU C library, not the Android C library, Bionic. There
> have
> >     been some other Android efforts in the past. You could search the
> >     mailing list archives; I unfortunately don't remember the details.
> It's
> >     possible some Bionic porting will be required, in addition to
> handling
> >     Android-specific resources.
> >
> >     Regards,
> >     Christopher Covington
> >
> >     --
> >     Qualcomm Innovation Center, Inc.
> >     Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> >     a Linux Foundation Collaborative Project
> >
> >
>
>
> --
> Qualcomm Innovation Center, Inc.
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvz.org/pipermail/criu/attachments/20160128/39d377d3/attachment.html>