[lsb-discuss] .note.ABI-tag extension for Android

[Carlos O'Donell]

On Thu, Apr 19, 2012 at 10:49 PM, Thiago Jung Bauermann
<thiago.bauermann at linaro.org> wrote:
> Hello,
>
> I'm discussing with Google engineers about adding a .note.ABI-tag to
> Android binaries, and extending the note format to allow identifying an
> Android application.
>
> I'd like to ask for comments about my proposed extension before
> implementing and deploying it. Since the only formal definition I found
> of the .note.ABI-tag is in LSB, I suppose this is the right place to
> discuss this?
>
> My goal is to allow distinguishing between an ELF file containing a
> regular GNU/Linux program and an Android program.
>
> This is so that GDB can know when it's debugging an Android application.
> A few details which are not defined by the ABI differ between the two,
> like the longjump buffer format and the signal handler trampoline.
>
> The format of the ELF note is as follows:
>
> name size: 4
> desc size: 24
> type: 1
> name: "GNU"
> desc: as as defined by the LSB standard:
>
> "The first 32-bit word of the desc field shall be 0 (this signifies a
> Linux executable). The second, third, and fourth 32-bit words of the
> desc field contain the earliest compatible kernel version. For example,
> if the 3 words are 2, 2, and 5, this signifies a 2.2.5 kernel."
>
> And extended to contain the following two words right after the kernel
> version:
>
> os_variant: 1
> android_api: 15
>
> I arbitrarily chose os_variant = 1 to mean Android.
>
> So the idea is that if desc size is >= 20, then the fifth 32-bit word
> will be examined. If it is 1, then this is an Android ELF file. The
> sixth word will then tell you the API level the application expects.
>
> What do you think?
>
> Ps: please Cc: me since I'm not subscribed to this list.

You haven't identified your use cases:

* Is this only for gdb?

* Is this checking going to be done by a dynamic linker (or
equivalent) at runtime?

* Is it going to be done by a tool in an offline fashion?

Each has performance implications.

In the case of an offline tool you could use detailed object
attributes to encode the information[1]. There is already precedent in
gdb for reading these[1] to identify different ARM variants.

For a runtime check you don't want to use object attributes, they are
not allocatable sections, and are generally overkill. Thus in the case
of a runtime check it seems like what you describe is useful. I
remember that Google NaCl were trying to do something similar but with
the ELF header (OSABI/VERSION) which is not correct (that describes
changes to the *ELF* standard itself not the runtime).

I would suggest talking to ARM's EABI committee, they may be able to
provide better guidance.

You might also reach out to Google NaCl people to see how they solved
or haven't solved this issue (CC'd Roland McGrath for help).

Cheers,
Carlos.

[1] http://sourceware.org/binutils/docs-2.22/as/Object-Attributes.html#Object-Attributes
[2] http://www.eglibc.org/archives/patches/msg01019.html