Allow building linux_syscall_support with Android NDK

This patch contains (mostly) minor fixes for compiling linux_syscall_suport with the Android NDK. The assembly changes are required for building with -mthumb-interwork or some such compiler flag, I've been assured that compilers will ignore them if they're unnecessary (and that newer toolchains would autogenerate them where necessary, but alas, not the NDK GCC).

[Markus (顧孟勤), 2010-10-12 18:29:09]

http://codereview.chromium.org/3656004/diff/1/2
File linux_syscall_support.h (right):

http://codereview.chromium.org/3656004/diff/1/2#newcode111
linux_syscall_support.h:111: #include <sys/syscall.h>
Not sure why this is needed, but the change should be completely harmless on
non-Android systems. So, that's OK with me.

http://codereview.chromium.org/3656004/diff/1/2#newcode122
linux_syscall_support.h:122: /* The Android NDK #defines these. */
I don't understand why this is necessary. Can you give an example where these
macros cause conflicts.

http://codereview.chromium.org/3656004/diff/1/2#newcode2156
linux_syscall_support.h:2156: "it    ne\n"
If I understand correctly, this is necessary to generate the correct code when
using the Thumb instruction set.

Is this generally safe on all gcc versions, even when compiling for non-Thumb
targets? Or do we need the preprocessor to make this conditional code that is
only generated for Thumb?

[Ted Mielczarek, 2010-10-12 18:39:22]

http://codereview.chromium.org/3656004/diff/1/2
File linux_syscall_support.h (right):

http://codereview.chromium.org/3656004/diff/1/2#newcode111
linux_syscall_support.h:111: #include <sys/syscall.h>
On 2010/10/12 18:29:09, Markus (顧孟勤) wrote:
> Not sure why this is needed, but the change should be completely harmless on
> non-Android systems. So, that's OK with me.

For some reason the NDK doesn't have syscall.h, but does have sys/syscall.h.
(This does compile fine on normal Linux builds.)

http://codereview.chromium.org/3656004/diff/1/2#newcode122
linux_syscall_support.h:122: /* The Android NDK #defines these. */
On 2010/10/12 18:29:09, Markus (顧孟勤) wrote:
> I don't understand why this is necessary. Can you give an example where these
> macros cause conflicts.

The NDK does:
#define stat64 stat
etc. That causes a multiply-defined error because lss includes definitions for
both stat and stat64. I guess the alternative here would be to #ifdef around the
*64 declarations.

http://codereview.chromium.org/3656004/diff/1/2#newcode2156
linux_syscall_support.h:2156: "it    ne\n"
On 2010/10/12 18:29:09, Markus (顧孟勤) wrote:
> If I understand correctly, this is necessary to generate the correct code when
> using the Thumb instruction set.
> 
> Is this generally safe on all gcc versions, even when compiling for non-Thumb
> targets? Or do we need the preprocessor to make this conditional code that is
> only generated for Thumb?

I have been reassured that it won't cause any problems.

[Markus (顧孟勤), 2010-10-12 18:59:48]

http://codereview.chromium.org/3656004/diff/1/2
File linux_syscall_support.h (right):

http://codereview.chromium.org/3656004/diff/1/2#newcode122
linux_syscall_support.h:122: /* The Android NDK #defines these. */
I see. That's a little unfortunate. Can you at least make this code conditional
on __ANDROID__. And then include a comment that repeats what you have been
saying in your e-mail.

Also, your suggestion about removing the *64 declarations might be a little
nicer. This way, existing Android source code that might rely on having access
to things like stat64() won't break when including linux_syscall_support.h

I always feel a little uneasy when I have to #undef anything. It seems dangerous
and prone to result in subtle bugs.

On 2010/10/12 18:39:22, Ted Mielczarek wrote:
> On 2010/10/12 18:29:09, Markus (顧孟勤) wrote:
> > I don't understand why this is necessary. Can you give an example where
these
> > macros cause conflicts.
> 
> The NDK does:
> #define stat64 stat
> etc. That causes a multiply-defined error because lss includes definitions for
> both stat and stat64. I guess the alternative here would be to #ifdef around
the
> *64 declarations.

[Ted Mielczarek, 2010-10-12 23:54:53]

I attached a new patch, but apparently upload.py didn't send mail for me.

[Markus (顧孟勤), 2010-10-13 03:48:14]

Committed as http://codereview.chromium.org/3773001