Prelink issues on Froyo

[cyanogen]

We are running into some strange issues on Froyo when building for
Sapphire. Notably, issues with prelinked libraries not loading into
the right address space. libaudio was the first, and a quick fix there
was to just disable prelinking for it. Now it gets stranger with
libcamera/liboemcamera..

E/QualcommCameraHardware( 64): FATAL ERROR: could not dlopen
liboemcamera.so: Cannot load library: reserve_mem_region[831]:
OOPS: 64 prelinked library 'liboemcamera.so' mapped at
0x40b0c000, not at 0xa9400000

When the linker mmaps the library, it's ending up in the wrong place.
The isprelinked tool says that it's OK though:

shade@toxygene: sapphire/proprietary $ isprelinked liboemcamera.so
liboemcamera.so: 0xa9400000

For some reason this is only happening on Sapphire/Dream. Passion
builds work just fine.

Ideas?

[aBiNg]

Hi, cyanogen

I can confirm this issue, which also came up on my Tattoo. Hope the
devs from google can fix it.

[aBiNg]

Here is the logcat while libspeech.so dlopen-ed after I set the
DLINKER_DEBUG to 1:

E/linker ( 523): bionic/linker/linker.c:672| WARNING: `/system/lib/
libspeech.so` is not a prelinked library
E/linker ( 523): 59 mapping library 'libspeech.so' at 80900000
(index 00000009) through buddy allocator.
E/linker ( 523): bionic/linker/linker.c:1280| ERROR: 59 cannot
locate '_ZN7android11AudioRecordC1EijiiijPFviPvS1_ES1_i'...
E/linker ( 523):
E/linker ( 523): bionic/linker/linker.c:1995| ERROR: failed to link
libspeech.so
E/linker ( 523):
I/dalvikvm( 523): Unable to dlopen(/system/lib/libspeech.so): Cannot
load library: link_image[1995]: failed to link libspeech.so

There seems to be some illogic codes in linker.c file.


Regards,

[cyanogen]

Your issue looks like a different problem (missing symbols), but I
could be wrong.

[David Turner]

I would assume that some of the prelinked libraries loaded are larger than what the prelink

map expects, resulting in overlaps/conflicts. You will probably need to modify the prelink map.

A prelinked library cannot be relocated to a different address (on purpose, the goal

is to get rid of all internal relocations, to speed up loading and reduce code size),

which is why the linker is complaining with a fatal error.

isprelinked returns true for your library because it detects that it has already been

"pre-relocated" for 0xa94000000, but that doesn't mean it can always be loaded

into a process' address space.

Hope this helps

--
You received this message because you are subscribed to the Google Groups "android-platform" group.
To post to this group, send email to android-...@googlegroups.com.
To unsubscribe from this group, send email to android-platfo...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-platform?hl=en.

[cyanogen]

Thanks for the response. I checked this, but the alloted space in the
prelink map is 2MB and the library in question is only 300k. The same
problem happens with a different library (libaudio) and there is
plenty of space for it as well. Everything is fine on Passion builds,
it's only happening when building for Dream/Sapphire.

I found this regarding a similar problem but haven't yet looked into
if/why it's "growing":
http://groups.google.com/group/android-porting/browse_thread/thread/299cdc69348279ff/67ec96e78812de05?lnk=gst&q=prelink+mapped+oops#67ec96e78812de05

> > android-platfo...@googlegroups.com<android-platform%2Bunsubscrib e...@googlegroups.com>
> > .

[fadden]

On Jun 30, 11:11 am, cyanogen <steve.kon...@gmail.com> wrote:
> Thanks for the response.  I checked this, but the alloted space in the
> prelink map is 2MB and the library in question is only 300k.  The same
> problem happens with a different library (libaudio) and there is
> plenty of space for it as well.  Everything is fine on Passion builds,
> it's only happening when building for Dream/Sapphire.

Did you check the library *below* the library that's failing? The
address-specific mmap() call would fail if another library had been
loaded below it and exceeded its bounds.

0x40b0c000 is in the right area for a "next available" space
allocation. Looking at linker.c, we're not specifying MAP_FIXED, so
this behavior is expected.

[cyanogen]

Checked that, and I also added some extra debug code to print si->size
in reserve_mem_region, and I can't see anywhere it's overrunning the
prelink space. Something is fishy.

[Sean Hodges]

Is there a chance something, like a system update, might have
disturbed your toolchain?

Do other releases build for the Dream OK?

> --
> You received this message because you are subscribed to the Google Groups "android-platform" group.
> To post to this group, send email to android-...@googlegroups.com.

> To unsubscribe from this group, send email to android-platfo...@googlegroups.com.

[cyanogen]

There's nothing wrong with my toolchain. This problem is reproducible
by anyone who tries to build AOSP for Dream or Sapphire.

[aBiNg]

Hi,

You are right, my libspeech.so issue has been fixed.

As for the liboemcamera.so issue, we have the exactly same problem.
logcat is here:

E/QualcommCameraHardware( 60): FATAL ERROR: could not dlopen
liboemcamera.so: Cannot load library: reserve_mem_region[810]:
OOPS: 60 prelinked library 'liboemcamera.so' mapped at
0x40d0c000, not at 0xa9400000

The corresponding address of 0xa9400000 is referred to
libvorbisidec.so library. Are they overlapped, as fadden said?
And I read reports by other people that dynamic libraries would be
inflated while being called. Is this true?

Regards,

[DJones]

I posted this issue on mahalo to get some exposure for it.

http://www.mahalo.com/answers/help-solve-android-linux-build-problem-on-cyanogenmod-froyo-for-g1-and-magic

Hope this is not counterproductive. and hope we find a fix soon.

[DJones]

I posted this issue on mahalo, i hope its not counterproductive.

http://www.mahalo.com/answers/help-solve-android-linux-build-problem-on-cyanogenmod-froyo-for-g1-and-magic

On Jun 30, 8:33 pm, cyanogen <steve.kon...@gmail.com> wrote:

[cyanogen]

Nice catch.

It appears they have reorganized the prelink map in Froyo! Some of the
proprietary blobs date back to Donut and are hacked up in various ways
for our custom builds.

Rearranging the prelink map should do the job. There are other blobs
that need adjusted too.