Question about sysroot and fixincludes
Hi, I have a question about sysroot and fixincludes. On Android there are different API levels (like android-9, android-10 etc) that match different versions of OS. Gcc from NDK is configured using sysroot for android-9 and the convenient way for compiling for, say, android-19 was by providing the sysroot to android-19 as a command line option (--sysroot). However, the header from the sysroot with which gcc was configured could be "fixincluded", and, when I provide a different sysroot as a command line option, "fixincluded" header could replace the actual header from the specified sysroot - that is the root-cause of certain problems. Should search in 'include-fixed' be disabled when sysroot command line option is specified? --Alexander
[Android] The reason why -Bsymbolic is turned on by default
Hi, When compiling a shared library with "-mandroid -shared" the option -Bsymbolic for linker is turned on by default. What was the reason behind that default? Isn't using of -Bsymbolic somehow dangerous and should be avoided..? (as e.g. is explained in the mail from Richard Henderson http://gcc.gnu.org/ml/gcc/2001-05/msg01551.html). Since there is no (AFAIK) option like -Bno-symbolic we cannot use -fno-pic binary with COPY relocations in it (android dynamic loader will throw an error when there is COPY relocation against DT_SYMBOLIC library..) (I'm sorry for sending it twice to Maxim - new google interface made my text too "rich") thank you in advance, Alexander
Re: [Android] The reason why -Bsymbolic is turned on by default
Hi, Thank you for your answers, seems that the question about the reason with default -Bsymbolic is still open.. we are not clairvoyant, but it is implemented in GCC so we should understand the reason :) Having that in mind, we have: 1) All shared libraries for Android are built with -Bsymbolic 2) Dynamic loader throws an error if we are doing COPY relocation against DT_SYMBOLIC libs. So any COPY relocation is doomed to failure.. Ard, what was the reason for introducing the support of this type of relocations in dynamic loader in the first place? > range of the executable proper. However, a library built with > -Bsymbolic resolves all its internal references at build time, so any > reference held by the library itself is not preemptible, resulting in > two live instances of the same symbol. I totally agree that it is potentially dangerous situation and dynamic loader must somehow let the user know about that (btw linux dynamic loader silently allows copy against DT_SYMBOLIC). thanks, Alexander 2013/4/3 Andrew Haley : > On 03/29/2013 06:55 PM, Alexander Ivchenko wrote: > >> When compiling a shared library with "-mandroid -shared" the option >> -Bsymbolic for linker is turned on by default. What was the reason >> behind that default? Isn't using of -Bsymbolic somehow dangerous and >> should be avoided..? > > Yes indeed, -Bsymbolic is dangerous. > >> (as e.g. is explained in the mail from Richard >> Henderson http://gcc.gnu.org/ml/gcc/2001-05/msg01551.html). >> >> Since there is no (AFAIK) option like -Bno-symbolic we cannot use >> -fno-pic binary with COPY relocations in it (android dynamic loader >> will throw an error when there is COPY relocation against DT_SYMBOLIC >> library..) > > Sure, that's true. If a library is built with -Bsymbolic then you > must build executables PIC. That's just how it is. > > As to why Android turned it on by default -- we are not clairvoyant! > :-) > > Andrew. >
Re: [Android] The reason why -Bsymbolic is turned on by default
Thank you very much for clarification. >> > Having that in mind, we have: >> > 1) All shared libraries for Android are built with -Bsymbolic >> > 2) Dynamic loader throws an error if we are doing COPY relocation >> > against DT_SYMBOLIC libs. >> > >> > So any COPY relocation is doomed to failure.. Ard, what was the reason >> > for introducing the support of this type of relocations in dynamic >> > loader in the first place? > The original implementation allowed them, but was broken. Disallowing > them would break BC, so fixing them was considered the best option. > (I think the initial support predates the default Bsymbolic setting.) Oh, I see now. Since x86 port started when Bsymbolic was the default I don't see any point of implementing R_386_COPY relocation in dynamic loader for it. (same can be applied for R_MIPS_COPY) best regards, Alexander
[c++] Question about "write_unscoped_name (const tree decl)"
Hi, In gcc/cp/mangle.c (write_unscoped_name) we have: /* If not, it should be either in the global namespace, or directly in a local function scope. */ gcc_assert (context == global_namespace || context != NULL || TREE_CODE (context) == FUNCTION_DECL); Which doesn't look like a thought-out assert: e.g. TREE_CODE (context) will segfault when context==NULL. According to the comment before the assert supposed to look more like: gcc_assert (context == global_namespace || (context != NULL && TREE_CODE (context) == FUNCTION_DECL)); But it gives us an ICE with g++.dg/cpp0x/lambda/lambda-defarg3.C BTW: First the check was "|| context == NULL", then it was removed by r149964 and then came back as "|| context != NULL" by r153768. May be I am missing something here? Could somebody clarify that peace of code please. --Alexander
Re: [c++] Question about "write_unscoped_name (const tree decl)"
2013/7/29 Andreas Schwab : > Alexander Ivchenko writes: > >> BTW: First the check was "|| context == NULL", then it was removed by >> r149964 and then came back as "|| context != NULL" by r153768. > > Looks like r153734 got it wrong first. It was supposed to revert > r149964, but failed. Then r153742 reverted the revertion, and when > r153768 reintroduced it it was apparently modeled after r153734 instead > of the state before r149964. Sounds like a riddle :) Anyway, if we assume that r153734 got it wrong and hence it is now wrong in the mainline, we can pull up the r149964 state with: /* If not, it should be either in the global namespace, or directly in a local function scope. */ gcc_assert (context == global_namespace - || context != NULL + || context == NULL || TREE_CODE (context) == FUNCTION_DECL); but then we will get ICE with g++.dg/cpp0x/lambda/lambda-defarg3.C, which would be a problem itself. --Alexander
Re: [buildrobot] gcc/config/linux-android.c:40:7: error: ‘OPTION_BIONIC’ was not declared in this scope
Hi, thanks for cathing this.
I certainly missed that OPTION_BIONIC is not defined for linux targets
that do not include config/linux.h in their tm.h.
This patch fixed build for powerpc64le-linux and mn10300-linux.
linux_libc, LIBC_GLIBC, LIBC_BIONIC should be defined for all targets.
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 56e6fd4..6bb18f8 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,8 @@
+2013-08-20 Alexander Ivchenko
+
+ * config/linux-android.c (linux_android_libc_has_function): Fix
+ checks for libc.
+
2013-08-20 Zhouyi Zhou
* tree-ssa-ccp.c (get_default_value): Remove redundant condition
diff --git a/gcc/config/linux-android.c b/gcc/config/linux-android.c
index 4a4b48d..e9d9e9a 100644
--- a/gcc/config/linux-android.c
+++ b/gcc/config/linux-android.c
@@ -35,9 +35,9 @@ linux_android_has_ifunc_p (void)
bool
linux_android_libc_has_function (enum function_class fn_class)
{
- if (OPTION_GLIBC)
+ if (linux_libc == LIBC_GLIBC)
return true;
- if (OPTION_BIONIC)
+ if (linux_libc == LIBC_BIONIC)
if (fn_class == function_c94
|| fn_class == function_c99_misc
|| fn_class == function_sincos)
is it OK?
thanks,
Alexander
2013/8/19 Jan-Benedict Glaw :
> Hi!
>
> My build robot[1] catched this error[2] while cross-building for
> powerpc64le-linux:
>
> g++ -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions
> -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing
> -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic
> -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common
> -DHAVE_CONFIG_H -I. -I. -I../../../../gcc/gcc -I../../../../gcc/gcc/.
> -I../../../../gcc/gcc/../include -I../../../../gcc/gcc/../libcpp/include
> -I../../../../gcc/gcc/../libdecnumber
> -I../../../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber
> -I../../../../gcc/gcc/../libbacktrace-I. -I. -I../../../../gcc/gcc
> -I../../../../gcc/gcc/. -I../../../../gcc/gcc/../include
> -I../../../../gcc/gcc/../libcpp/include
> -I../../../../gcc/gcc/../libdecnumber
> -I../../../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber
> -I../../../../gcc/gcc/../libbacktrace \
> ../../../../gcc/gcc/config/linux-android.c
> ../../../../gcc/gcc/config/linux-android.c: In function ‘bool
> linux_android_libc_has_function(function_class)’:
> ../../../../gcc/gcc/config/linux-android.c:40:7: error: ‘OPTION_BIONIC’ was
> not declared in this scope
>if (OPTION_BIONIC)
>^
> make[2]: *** [linux-android.o] Error 1
>
> Probably introduced with r201838
> (http://gcc.gnu.org/viewcvs/gcc?view=revision&revision=201838). I
> guess it's just a forgotten chunk.
>
> MfG, JBG
> [1] http://toolchain.lug-owl.de/buildbot/
> [2] http://toolchain.lug-owl.de/buildbot/#job8903
>
> --
> Jan-Benedict Glaw jbg...@lug-owl.de +49-172-7608481
> Signature of: http://perl.plover.com/Questions.html
> the second :
Replacement of c99_runtime in testsuite
Hi, I have a little question Right now internally in gcc we flexibly check whether a particular function (or rather "function class", which could be easily extended) is present or not in libc by calling target hook "libc_has_function", however in the testsuite for c99 runtime we still check whether the full support of it is in place (in gcc.dg/builtins-config.h). And so some tests for some targets (e.g. gcc.dg/builtins-58.c for bionic) are unsupported right now, while actually they are OK. I wonder may be we can somehow get the value of libc_has_function hook for a particular function in the test so to flexibly define whether the test should be unsupported or not? E.g. by adding some debug options for gcc that will return the result of the hook? But I doubt that such option would be a pretty solution thanks --Alexander
[c++11] Question about __cxa_throw_bad_array_new_length
Hi,
When I compile the following code (modified version of
g++.dg/cpp0x/bad_array_new1.C without try/catch):
// { dg-options -std=c++11 }
// { dg-do run }
#include
void * f(int i)
{
return new int[i];
}
int main()
{
f(-1);
}
with -fno-exceptions option, I still get the call to
__cxa_throw_bad_array_new_length:
> nm ./bad_array_new1.o | grep cxa
U __cxa_throw_bad_array_new_length
The same goes for __cxa_throw_bad_array_length. Is it an expected behaviour?
May be I am missing something, but I would say that this is a bug and we should
add something like the following checks:
diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index 3ed73b8..c947484 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -3953,7 +3953,7 @@ build_operator_new_call (tree fnname, vec **args,
if (size_check != NULL_TREE)
{
tree errval = TYPE_MAX_VALUE (sizetype);
- if (cxx_dialect >= cxx11)
+ if (cxx_dialect >= cxx11 && flag_exceptions)
errval = throw_bad_array_new_length ();
*size = fold_build3 (COND_EXPR, sizetype, size_check,
original_size, errval);
diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index 80ceca1..d058e94 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -6390,7 +6390,9 @@ cp_finish_decl (tree decl, tree init, bool
init_const_expr_p,
&& TYPE_FOR_JAVA (type) && MAYBE_CLASS_TYPE_P (type))
error ("non-static data member %qD has Java class type", decl);
- if (cxx_dialect >= cxx1y && array_of_runtime_bound_p (type))
+ if (cxx_dialect >= cxx1y
+ && array_of_runtime_bound_p (type)
+ && flag_exceptions)
{
/* If the VLA bound is larger than half the address space, or less
than zero, throw std::bad_array_length. */
diff --git a/gcc/cp/init.c b/gcc/cp/init.c
index 8fabdcd..53046ab 100644
--- a/gcc/cp/init.c
+++ b/gcc/cp/init.c
@@ -2488,7 +2488,7 @@ build_new_1 (vec **placement, tree
type, tree nelts,
}
/* Perform the overflow check. */
tree errval = TYPE_MAX_VALUE (sizetype);
- if (cxx_dialect >= cxx11)
+ if (cxx_dialect >= cxx11 && flag_exceptions)
errval = throw_bad_array_new_length ();
if (outer_nelts_check != NULL_TREE)
size = fold_build3 (COND_EXPR, sizetype, outer_nelts_check,
@@ -3345,7 +3345,8 @@ build_vec_init (tree base, tree maxindex, tree init,
is big enough for all the initializers. */
if (init && TREE_CODE (init) == CONSTRUCTOR
&& CONSTRUCTOR_NELTS (init) > 0
- && !TREE_CONSTANT (maxindex))
+ && !TREE_CONSTANT (maxindex)
+ && flag_exceptions)
length_check = fold_build2 (LT_EXPR, boolean_type_node, maxindex,
size_int (CONSTRUCTOR_NELTS (init) - 1));
thanks,
Alexander
Re: [c++11] Question about __cxa_throw_bad_array_new_length
*ping*
thanks,
Alexander
2013/9/23 Alexander Ivchenko :
> Hi,
>
> When I compile the following code (modified version of
> g++.dg/cpp0x/bad_array_new1.C without try/catch):
>
> // { dg-options -std=c++11 }
> // { dg-do run }
>
> #include
>
> void * f(int i)
> {
> return new int[i];
> }
>
> int main()
> {
> f(-1);
> }
>
> with -fno-exceptions option, I still get the call to
> __cxa_throw_bad_array_new_length:
>
>> nm ./bad_array_new1.o | grep cxa
> U __cxa_throw_bad_array_new_length
>
>
> The same goes for __cxa_throw_bad_array_length. Is it an expected behaviour?
>
> May be I am missing something, but I would say that this is a bug and we
> should
> add something like the following checks:
>
>
> diff --git a/gcc/cp/call.c b/gcc/cp/call.c
> index 3ed73b8..c947484 100644
> --- a/gcc/cp/call.c
> +++ b/gcc/cp/call.c
> @@ -3953,7 +3953,7 @@ build_operator_new_call (tree fnname, vec va_gc> **args,
>if (size_check != NULL_TREE)
> {
>tree errval = TYPE_MAX_VALUE (sizetype);
> - if (cxx_dialect >= cxx11)
> + if (cxx_dialect >= cxx11 && flag_exceptions)
> errval = throw_bad_array_new_length ();
>*size = fold_build3 (COND_EXPR, sizetype, size_check,
>original_size, errval);
> diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
> index 80ceca1..d058e94 100644
> --- a/gcc/cp/decl.c
> +++ b/gcc/cp/decl.c
> @@ -6390,7 +6390,9 @@ cp_finish_decl (tree decl, tree init, bool
> init_const_expr_p,
>&& TYPE_FOR_JAVA (type) && MAYBE_CLASS_TYPE_P (type))
> error ("non-static data member %qD has Java class type", decl);
>
> - if (cxx_dialect >= cxx1y && array_of_runtime_bound_p (type))
> + if (cxx_dialect >= cxx1y
> + && array_of_runtime_bound_p (type)
> + && flag_exceptions)
> {
>/* If the VLA bound is larger than half the address space, or less
> than zero, throw std::bad_array_length. */
> diff --git a/gcc/cp/init.c b/gcc/cp/init.c
> index 8fabdcd..53046ab 100644
> --- a/gcc/cp/init.c
> +++ b/gcc/cp/init.c
> @@ -2488,7 +2488,7 @@ build_new_1 (vec **placement, tree
> type, tree nelts,
> }
> /* Perform the overflow check. */
> tree errval = TYPE_MAX_VALUE (sizetype);
> - if (cxx_dialect >= cxx11)
> + if (cxx_dialect >= cxx11 && flag_exceptions)
> errval = throw_bad_array_new_length ();
> if (outer_nelts_check != NULL_TREE)
> size = fold_build3 (COND_EXPR, sizetype, outer_nelts_check,
> @@ -3345,7 +3345,8 @@ build_vec_init (tree base, tree maxindex, tree init,
> is big enough for all the initializers. */
>if (init && TREE_CODE (init) == CONSTRUCTOR
>&& CONSTRUCTOR_NELTS (init) > 0
> - && !TREE_CONSTANT (maxindex))
> + && !TREE_CONSTANT (maxindex)
> + && flag_exceptions)
> length_check = fold_build2 (LT_EXPR, boolean_type_node, maxindex,
> size_int (CONSTRUCTOR_NELTS (init) - 1));
>
>
> thanks,
> Alexander
Re: [buildrobot] ia64-hpux
2013/11/27 Jeff Law : > On 11/26/13 19:50, Jan-Benedict Glaw wrote: >> >> On Tue, 2013-11-26 04:26:57 +0100, Jan-Benedict Glaw >> wrote: >>> >>> Build log at >>> http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=39052 >>> >>> g++ -c -DUSE_LIBUNWIND_EXCEPTIONS -g -O2 -DIN_GCC >>> -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti >>> -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings >>> -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long >>> -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common >>> -DHAVE_CONFIG_H -I. -I. -I../../../gcc/gcc -I../../../gcc/gcc/. >>> -I../../../gcc/gcc/../include -I../../../gcc/gcc/../libcpp/include >>> -I/opt/cfarm/mpc/include -I../../../gcc/gcc/../libdecnumber >>> -I../../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber >>> -I../../../gcc/gcc/../libbacktrace-o ia64.o -MT ia64.o -MMD -MP -MF >>> ./.deps/ia64.TPo ../../../gcc/gcc/config/ia64/ia64.c >>> In file included from ./tm.h:20:0, >>> from ../../../gcc/gcc/config/ia64/ia64.c:25: >>> ../../../gcc/gcc/config/ia64/hpux.h:185:34: error: >>> ‘default_c99_libc_has_function’ was not declared in this scope >>> #define TARGET_LIBC_HAS_FUNCTION default_c99_libc_has_function >>>^ >>> ./target-hooks-def.h:1140:5: note: in expansion of macro >>> ‘TARGET_LIBC_HAS_FUNCTION’ >>> TARGET_LIBC_HAS_FUNCTION, \ >>> ^ >>> ../../../gcc/gcc/config/ia64/ia64.c:659:29: note: in expansion of macro >>> ‘TARGET_INITIALIZER’ >>> struct gcc_target targetm = TARGET_INITIALIZER; >>> ^ >>> make[2]: *** [ia64.o] Error 1 >> >> >> I *guess* it should have been no_c99_libc_has_function instead of >> default_c99_libc_has_function, referring to an equal change to >> pa/hpux.h in r201838: >> >> http://gcc.gnu.org/viewcvs/gcc?view=revision&revision=201838 >> >> http://gcc.gnu.org/git/?p=gcc.git;a=commit;h=30f690e026ecdf99c68e777a48562b58afe37f43 >> >> But I don't actually know HP-UX's libc and whether or not it ships an >> equal set of functions on all target it runs on... "no_c99_libc_has_function" would be incorrect: before we switched to target hook implementation of checking the presence of builtin functions, we had for hpux: /* ia64 HPUX has the float and long double forms of math functions. */ #undef TARGET_C99_FUNCTIONS #define TARGET_C99_FUNCTIONS 1 And since now we assume that by default c99 functions are present, the correct version of the hook would be exactly the default one. > I approved a patch today that I think will fix this. > Jeff That's right, it is committed: http://gcc.gnu.org/ml/gcc-cvs/2013-11/msg01158.html thanks, Alexander
Re: GCC 4.9.0 Release Candidate available from gcc.gnu.org
Is it ok to port this patch to 4.9 branch:
commit 15bee5d49b1c746fd3e784432d7e4988941a671e
Author: bviyer
Date: Fri Apr 11 19:56:42 2014 +
Fix for PR other/60644.
+2014-04-11 Barry Tannenbaum
+
+ PR other/60644
+ * runtime/os-unix.c: Replaced all occurrances of ANDROID with
+ __ANDROID__.
+ * runtime/bug.h: Likewise.
+ * include/cilk/metaprogramming.h: Likewise.
+ * include/cilk/reducer_min_max.h: Likewise.
+
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@209324
138bc75d-0d04-0410-961f-82ee72b054a4
to fix http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60644 and cure
i686-pc-linux-android build?
thanks,
Alexander
2014-04-17 14:25 GMT+04:00 Paweł Sikora :
> W dniu 2014-04-17 12:13, Jonathan Wakely napisał(a):
>
>> On 17 April 2014 10:38, Paweł Sikora wrote:
>>>
>>> Hi,
>>>
>>> the opt_random.h header includes unconditionally and breaks
>>> crytopp build
>>> (redefinition of _mm_shuffle_epi8 in cpu.h).
>>> could you please add #ifdef __SSSE3__ around this include?
>>
>>
>> Do you mean __SSE3__ not __SSSE3__?
>
>
> yes, __SSE3__.
>
>
>> That's the macro that controls whether the
>> config/cpu/i486/opt/bits/opt_random.h header actually uses the
>> intrinsics or not:
>>
>> namespace std _GLIBCXX_VISIBILITY(default)
>> {
>> _GLIBCXX_BEGIN_NAMESPACE_VERSION
>>
>> #ifdef __SSE3__
>> template<>
>> template
>> void
>> normal_distribution::
>
>
Re: GCC 4.9.0 Release Candidate available from gcc.gnu.org
That fixes "--disable-shared" case only, which is important for NDK build. Without "--disable-shared" build fails because there is no -lpthread on Android and pthreads are in libc there. Apparently, cilkrts configure does not check that. I can fix that in 4.9, but I'm ok with fixing it in trunk later as well, depending on your decision. 2014-04-17 15:31 GMT+04:00 Jakub Jelinek : > On Thu, Apr 17, 2014 at 02:47:50PM +0400, Alexander Ivchenko wrote: >> Is it ok to port this patch to 4.9 branch: > > If it always fails to bootstrap with cilkrts on Android right now, then > the patch can't do more harm, so ok. >> >> commit 15bee5d49b1c746fd3e784432d7e4988941a671e >> Author: bviyer >> Date: Fri Apr 11 19:56:42 2014 + >> >> Fix for PR other/60644. >> +2014-04-11 Barry Tannenbaum >> + >> + PR other/60644 >> + * runtime/os-unix.c: Replaced all occurrances of ANDROID with >> + __ANDROID__. >> + * runtime/bug.h: Likewise. >> + * include/cilk/metaprogramming.h: Likewise. >> + * include/cilk/reducer_min_max.h: Likewise. > > Jakub
[Android] -fpic default option
By default in Android we always compile with -fpic or -fPIC, even when
compiling executable. Because of that we have some test fails on
Android:
For example:
gcc/testsuite/gcc.target/i386/pr47312.c
/* { dg-do run } */
/* { dg-options "-O2" } */
void exit (int);
void noreturn_autodetection_failed ();
__attribute__ ((noinline))
detect_noreturn ()
{
exit (0);
}
int
main (void)
{
detect_noreturn ();
noreturn_autodetection_failed ();
return 0;
}
If gcc knew, that we are not going to make a shared library (which is
implied if we are using pic option), then it would delete the call of
noreturn_autodetection_failed as a dead code. But in case of pic we
cannot rely on the fact that detect_noreturn () will not be
overwritten on runtime, eventhough we are compiling executable and
that will never happen! So in addition to several testfails, it seems
that we are losing an optimization opportunity here also.
I'm wondering, maybe we can use -fpie instead of -fpic by default in
the compiler (of course if there are no -shared or -c options; those
cases will mean that we cannot rely on the fact that we will have an
executable after linking)? It seems that it would solve the problem..
Of course we always can add something like { target nonpic } to all
tests that fail on Android, but probably the problem is deeper than
that and that would be only hiding our head in the sand.
Re: [Android] -fpic default option
>> The canonical way of building native applications for Android is to add
>> -fno-pic to the compiler flags.
That’s true for programs in userspace, but for Android system-level
programs (standalone executables) like system tools, console apps or
tests it seems -fpic doesn’t make much sense.
>> The intent was to make the most common behavior the default, and for Android
>> that
>> happens to be building shared libraries that can then be called through JNI.
Okay, but for building shared libs we either provide -shared to the
driver, or -c, right? In these cases
we can go with -fPIC by default. In other cases we can safely assume
that the executable will be created and
in such case it would be a good idea to use -fPIE.
That would solve the problem with a lot of tests that failed on
Android and also with native applications (executables, not libs) that
are built
with -fPIC now. What do you think?
2012/11/15 H.J. Lu :
> On Wed, Nov 14, 2012 at 5:26 AM, Alexander Ivchenko
> wrote:
>> By default in Android we always compile with -fpic or -fPIC, even when
>> compiling executable. Because of that we have some test fails on
>> Android:
>>
>> For example:
>> gcc/testsuite/gcc.target/i386/pr47312.c
>> /* { dg-do run } */
>> /* { dg-options "-O2" } */
>>
>> void exit (int);
>> void noreturn_autodetection_failed ();
>> __attribute__ ((noinline))
>> detect_noreturn ()
>> {
>> exit (0);
>> }
>> int
>> main (void)
>> {
>> detect_noreturn ();
>> noreturn_autodetection_failed ();
>> return 0;
>> }
>>
>> If gcc knew, that we are not going to make a shared library (which is
>> implied if we are using pic option), then it would delete the call of
>> noreturn_autodetection_failed as a dead code. But in case of pic we
>> cannot rely on the fact that detect_noreturn () will not be
>> overwritten on runtime, eventhough we are compiling executable and
>> that will never happen! So in addition to several testfails, it seems
>> that we are losing an optimization opportunity here also.
>> I'm wondering, maybe we can use -fpie instead of -fpic by default in
>> the compiler (of course if there are no -shared or -c options; those
>> cases will mean that we cannot rely on the fact that we will have an
>> executable after linking)? It seems that it would solve the problem..
>> Of course we always can add something like { target nonpic } to all
>
> We should add { target nonpic } independent of Android.
>
>> tests that fail on Android, but probably the problem is deeper than
>> that and that would be only hiding our head in the sand.
>
> Using -fPIE to compile executables is a good idea.
>
> --
> H.J.
Re: [Android] -fpic default option
You are right, we are talking about the same things. The only open question I see is regarding: >>>> In other cases we can safely assume >>>> that the executable will be created and >>>> in such case it would be a good idea to use -fPIE. >> I don't see why it would be a good idea to use -fPIE for most normal >> user-space applications when -fno-pic would >> suffice and provide better code. Do you agree that if the driver knows that the executable will be at the end of the build we can safely use -fno-pic or -fPIE to override -fpic default? I'm not quite sure which one is better for Android; -fPIE will give us all the security advantages of the position independent code and probably is a better option. 2012/11/16 Maxim Kuvyrkov : > On 15/11/2012, at 10:39 PM, Alexander Ivchenko wrote: > >>>> The canonical way of building native applications for Android is to add >>>> -fno-pic to the compiler flags. >> That’s true for programs in userspace, but for Android system-level >> programs (standalone executables) like system tools, console apps or >> tests it seems -fpic doesn’t make much sense. > > We seem to be saying the same thing, but it sounds like a disagreement. > Native (as in non-java) applications should be compiled with -fno-pic as > -fpic (and -fPIE) is unnecessary. > >> >>>> The intent was to make the most common behavior the default, and for >>>> Android that >>>> happens to be building shared libraries that can then be called through >>>> JNI. >> Okay, but for building shared libs we either provide -shared to the >> driver, or -c, right? In these cases >> we can go with -fPIC by default. > > Assuming normal build process (i.e., when one doesn't compile and link > application in one command), by the time you provide -shared to the driver > all the object files are already compiled. They /need/ to be compiled as PIC > for use in shared library or /can/ be compiled as non-PIC for use in native > executable. And there are also various games with partial linking. > >> In other cases we can safely assume >> that the executable will be created and >> in such case it would be a good idea to use -fPIE. > > I don't see why it would be a good idea to use -fPIE for most normal > user-space applications when -fno-pic would suffice and provide better code. > > Am I missing something? > > Thank you, > > -- > Maxim Kuvyrkov > CodeSourcery / Mentor Graphics >
Re: [Android] -fpic default option
> If the driver can be sure that an executable is being compiled
> (which is a challenge in general case, but simple cases --
> compilation of GCC testsuites -- can be accommodated)
I totally agree here that it could be a challenge. Also it could be
quite confusing: if the user wants to get assembler code we must
conservatively generate it with -fpic; However producing executable
with default options and then objdumping it will give us different
assembly with -fno-pic..
And although it could fix those testcases that are failing right now
on android that would indeed be hiding our head in the sand.
Considering all that, I believe that we are left with only one
solution: to carefully add "-fno-pic" or
"{ target nonpic }" to the affected tests as we discussed above.
Thank you very much for your help!
2012/11/18 Maxim Kuvyrkov :
> On 18/11/2012, at 7:50 AM, Alexander Ivchenko wrote:
>
>> You are right, we are talking about the same things. The only open
>> question I see is regarding:
>>
>>>>>> In other cases we can safely assume
>>>>>> that the executable will be created and
>>>>>> in such case it would be a good idea to use -fPIE.
>>
>>>> I don't see why it would be a good idea to use -fPIE for most normal
>>>> user-space applications when -fno-pic would
>>>> suffice and provide better code.
>>
>> Do you agree that if the driver knows that the executable will be at
>> the end of the build
>> we can safely use -fno-pic or -fPIE to override -fpic default?
>
> If the driver can be sure that an executable is being compiled (which is a
> challenge in general case, but simple cases -- compilation of GCC testsuites
> -- can be accommodated) then it is OK to revert to default for a particular
> -linux-gnu target. For most architectures that would mean reverting to
> -fno-pic, but at least mips-linux-gnu uses -fpic by default in certain
> configurations. This is me not picking on your proposal, just alerting that
> -fno-pic may not be the right choice for executables for all targets.
>
>> I'm not
>> quite sure which one is better for Android; -fPIE will
>> give us all the security advantages of the position independent code
>> and probably is a better option.
>
> Using -fPIE will also bring all the performance drawbacks of PIC, there is a
> reason why -fPIE is not the most common way of building applications. I
> don't think Android is too security-concious a platform to warrant -fPIE
> (does Android even use address-space randomization?). Performance is a more
> serious consideration for its target market.
>
> Alexander, I appreciate you looking into -fpic vs -fno-pic compilation for
> Android.
>
> Thank you,
>
> --
> Maxim Kuvyrkov
> CodeSourcery / Mentor Graphics
>
