marshmallow dynamic loader

[krnlyng]

we have put together a working version for marshmallow based ports (mal-, ghosalmartin, Notkit)
#326 is required
it was suggested to add https://github.com/ghosalmartin/libhybris/commit/cd5aacba761fdec27f2232c982d06b43d26daadb
and some of https://github.com/ghosalmartin/libhybris/commits/master?author=vicamo maybe in a different PR.

if it is not merged it shall be at least for reference, since we have been spreading code over many repositories
if one other hand it is considered for merging, let me know what needs to change.

the hooks might be confusing:

• i removed some duplicates
• moved some to their header comment
• fixed a typo

the linker is not build with -std=gnu++11 but with -std=c++0x (only a minor tweak was required)

[ghosalmartin]

lgtm, the arm64 stuff can wait, I don't think its vital since I've run this on a pure arm64 rootfs with no issues arising from the lack of commits

[ghosalmartin]

also we need to hook into:
{"__progname", &program_invocation_name},
{"pthread_getspecific", my_pthread_getspecific},

and implement

void *my_pthread_getspecific(pthread_key_t key) { if(key == 0) return 0; return pthread_getspecific(key); }

Due to https://github.com/CyanogenMod/android_bionic/blob/cm-13.0/tests/pthread_test.cpp#L185

worked all this out with lots and lots of help from krnlyng :D

[krnlyng]

those two are specific to specific egl implementations, should these be added in this pr or later?
also the __progname hook is necessary since some android lib tried to strcmp(__progname, "zygote") and __progname was 0 which caused a crash.

[ghosalmartin]

Either or really, I see no advantage of giving it even more visibility in this instance, but I could be wrong

[morphis]

Actually my plan was to merge https://code.launchpad.net/~libhybris-maintainers/libhybris/+git/libhybris/+ref/master at some point into the official upstream as this one has multiple improvements to make the life with libhybris a lot easier. One of its main advantages is dynamic-linker loading.

What do you guys think about this?

[krnlyng]

thats why i wrote so defensive "if it is considered for merging"

there are several advantages for this version too:

1. it works with qualcomm devices (the referenced version crashes sometime during link time)

2. the referenced version adds _hybris_hook to every hooked function, making functions that could be directly hooked slower

3. it is here now

3 has an obvious solution, 1 can probably done with both versions eventually, 2 is probably nitpicking but a similar thing can be done with a tiny wrapper generator that is only active when a specific env variable is set i have accidentally put the output of that into a comment inside #325 one additional advantage of this tracing functionality is that it can print even unhooked functions when they are called

the dynamic linker loading is neat but is it necessary? i would assume the 6.0 linker can handle 5.0 binaries since i am using blobs written for 5.0 just fine with the marshmallow linker, the only real reason why the marshmallow linker is necessary seems to be android specific compressed relocations

i know there are other fixes and improvements that should be added here too, or we can merge the referenced versions and add fixes the other way round

[morphis]

It is sadly not true that the Android 6 linker can handle all Android 5 binaries. We came across some real problems we couldn't figure out.

My overall aim is that we all (Canonical, Jolla, Community) combine our efforts again around libhybris and work on a single code base, which didn't worked really well. Sadly we diverged quite a bit due to imminent product requirements and release schedule but I would like to come back and bring things back together.

The dynamic linker loading is quite essential for us as we build a single Ubuntu rootfs which is the exactly the same on all devices we support. That way we can't include different libhybris versions for different devices. Also we don't want to risk too much on devices using older Android versions as they are already in the field and doing things like switching the hybris linker is not really what we want to do in terms of maintenance.

I agree with 1. and 2. For 2. we can find a better solution and 1. is just about porting a fix over. 3. is the actual problem, give the small amount of time I have for this I would like to get as much as possible over and then let us work on a code base together.

So my proposed way of combining things would be:

1. Merge https://code.launchpad.net/~libhybris-maintainers/libhybris/+git/libhybris/+ref/master with keepign debian packaging etc. We can add rpm packaging in here too which then allows us to get rid as much as possible of possible packaging branches.

2. Merge any relevant patches for you guys on top and improve things where needed.

What do you think about this?

[sledges]

@morphis, could you please make a PR that merges your work? It is a truly welcome initiative to unify the codebase, so that we get more eyes and hands on the same bugs and challenges of the future.

We could then clearly see what the things that you need are, and how they're implemented.

[morphis]

@sledges Yes I can do that. However it will be a merge-all PR which will do a big giant merge to preserve history but ignores all conflicts.

[morphis]

@sledges Done, see #328