Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
marshmallow dynamic loader #327
we have put together a working version for marshmallow based ports (mal-, ghosalmartin, Notkit)
if it is not merged it shall be at least for reference, since we have been spreading code over many repositories
the hooks might be confusing:
the linker is not build with -std=gnu++11 but with -std=c++0x (only a minor tweak was required)
also we need to hook into:
worked all this out with lots and lots of help from krnlyng :D
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?
thats why i wrote so defensive "if it is considered for merging"
there are several advantages for this version too:
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
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:
What do you think about this?
@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.
Bug: https://bugs.launchpad.net/avila-private/+bug/1516902 Signed-off-by: You-Sheng Yang <email@example.com>
pthread_condattr_setclock() was first introduced in Android 5.0 and is directly called by libbacktrace, which is then linked into libutil. Signed-off-by: You-Sheng Yang <firstname.lastname@example.org>
libhybris previously stores memory addresses of shared mutexes in a unsigned integer. When running on arm64 or any other __LP64__ systems, this results in wrong pointer addresses returned. In this patch we re-type to storage type to uintptr_t, which guarantees sufficient space for holding a memory address, and then corretly set HYBRIS_SHM_MASK and HYBRIS_SHM_MASK_TOP to valid values on both systems.