This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [patch] Support bionic's jmp_buf.
- From: Thiago Jung Bauermann <thiago dot bauermann at linaro dot org>
- To: Pedro Alves <palves at redhat dot com>
- Cc: gdb-patches ml <gdb-patches at sourceware dot org>
- Date: Mon, 21 May 2012 14:59:24 -0300
- Subject: Re: [patch] Support bionic's jmp_buf.
- References: <1337560528.4363.13.camel@hactar> <4FBA2920.4070909@redhat.com>
Hello Pedro,
Thanks for the quick response.
On Mon, 2012-05-21 at 12:38 +0100, Pedro Alves wrote:
> On 05/21/2012 01:35 AM, Thiago Jung Bauermann wrote:
> > I'm using the ELF interpreter field to identify an Android binary (the
> > program loader is /system/bin/linker).
>
>
> Urgh. Isn't there a better way? This doesn't work with shared libraries,
> for starters.
There is. I thought of adding an Android flag to .note.ABI-tag and I
even have a patch ready which adds it to Android binaries. I gave up on
it because I thought it was overkill but I can certainly use that if
using the interpreter field is a worse solution.
Regarding shared libraries, does it matter? If the executable uses
bionic, then the shared libraries can't be using something else, or can
they?
> But I think question number one is:
>
> - Shouldn't there be an "Android" or "Bionic/Linux" OSABI instead
> of abusing "GNU/Linux" ?
I think it shouldn't, and I think it's not abuse. Android has the same
ABI as GNU/Linux, the differences are in implementation details outside
the scope of the ABI:
"Note that the AAPCS standard defines 'EABI' as a moniker used to
specify a _family_ of similar but distinct ABIs. Android follows the
little-endian ARM GNU/Linux ABI as documented in the following
document:
http://www.codesourcery.com/gnu_toolchains/arm/arm_gnu_linux_abi.pdf
With the exception that wchar_t is only one byte. This should not matter
in practice since wchar_t is simply *not* really supported by the
Android platform anyway. This ABI does *not* support hardware-assisted
floating point computations. Instead, all FP operations are performed
through software helper functions that come from the compiler's libgcc.a
static library."
It also doesn't support C++ exceptions.
[1] http://www.kandroid.org/ndk/docs/CPU-ARCH-ABIS.html
--
[]'s
Thiago Jung Bauermann
Linaro Toolchain Working Group