This is an archive of the discontinued LLVM Phabricator instance.

Fix [vdso] handling on Android (x86 and aarch64)
ClosedPublic

Authored by tberghammer on Jun 29 2015, 4:19 AM.

Details

Summary

Fix [vdso] handling on Android (x86 and aarch64)

  • Add in-memory object file handling to the core dynamic loader
  • Fix in memory object file handling in ObjectFileELF (previously only part of the file was loaded before parsing)
  • Fix load address setting in ObjectFileELF for 32-bit targets when the load bias is negative
  • Change hack in DYLDRendezvous.cpp to be more specific and not to interfere with object files with fixed load address

Diff Detail

Repository
rL LLVM

Event Timeline

tberghammer retitled this revision from to Fix [vdso] handling on Android (x86 and aarch64).
tberghammer updated this object.
tberghammer edited the test plan for this revision. (Show Details)
tberghammer added reviewers: labath, clayborg.
tberghammer added a subscriber: Unknown Object (MLST).

I investigated the problem on Linux a bit further and the issue causing us problems (with the missing path for the [vdso]) is not a bug, but a feature of the Linux linker. We have to add some code to LLDB in the future to handle the feature.

labath edited edge metadata.Jun 29 2015, 5:02 AM

The change looks reasonable to me, but i'll leave the decision to greg.

Would it be possible to add a test for this somehow? Check the output of image list? Look up a symbol in the vdso? Try to hit a breakpoint inside it?

The change looks reasonable to me, but i'll leave the decision to greg.

Would it be possible to add a test for this somehow? Check the output of image list? Look up a symbol in the vdso? Try to hit a breakpoint inside it?

It is quite complicated to test anything inside the [vdso] because as far as I know there is no specification about the list of functions what should be present in it. Checking the output of "image list" is possible but it won't give us too much coverage because it will be displayed there in several cases when it isn't loaded correctly.

Would it be possible to add a test for this somehow? Check the output of image list? Look up a symbol in the vdso? Try to hit a breakpoint inside it?

It is quite complicated to test anything inside the [vdso] because as far as I know there is no specification about the list of functions what should be present in it. Checking the output of "image list" is possible but it won't give us too much coverage because it will be displayed there in several cases when it isn't loaded correctly.

Yes, I suspect the contents of the vdso is highly platform-dependent. However, it (vdso) has to remain backward compatible with old binaries (and old versions of libc), therefore I think it's unlikely that a symbol will disappear from there overnight. I think the vdso support is very prone to accidental breakage at this point, so it would be good to get *any* coverage - it does not have to be exhaustive, but picking a symbol on one-or-two platforms and checking that should be possible.

clayborg accepted this revision.Jun 29 2015, 11:39 AM
clayborg edited edge metadata.

Looks good. I am very happy to see memory loading of ELF files.

This revision is now accepted and ready to land.Jun 29 2015, 11:39 AM

If you've fixed vdso handling, shouldn't some i386 tests be marked as passing?

If you've fixed vdso handling, shouldn't some i386 tests be marked as passing?

It is fixing it only on Android. There is a different between how the linker works on Linux and on Android and we need to solve one more additional issue to fix it on Linux also but it isn't trivial.

The problem is that the Linux linker don't fill in the file path in the rendezvous structure for the [vdso] because it isn't a file (it is treated as a feature in the code) but currently we use that path to find the load address of the file (based on /proc/<pid>/maps). To fix the issue on Linux also we need an other way to get the load address of an SO.

You can use the gdb remote get auxv command I think to get libvdso load
address.

This revision was automatically updated to reflect the committed changes.