C++ exceptions

3,884 views
Skip to first unread message

Anton Persson

unread,
Nov 9, 2009, 3:56:50 AM11/9/09
to android-ndk
Hi,

is there any work going on to get C++ exceptions working in the NDK? Having C++ support without exceptions is like having Java without exceptions.. In short, no exceptions is bad..

   Best Regards
     Anton

Jack Palevich

unread,
Nov 9, 2009, 4:46:56 AM11/9/09
to andro...@googlegroups.com
Sorry, no, we have no plans to support exceptions in the NDK, or in the Android platform C/C++ runtime.

We understand that many C++ developers find exceptions a very useful tool. Unfortunately exceptions
are expensive in terms of runtime time and space. Supporting exceptions would complicate and slow down the C
runtime even for pure C applications that do not use exceptions. Because of these performance penalties we
chose to not support exceptions in the Android C/C++ runtime.

--

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

Anton Persson

unread,
Nov 9, 2009, 5:26:29 AM11/9/09
to andro...@googlegroups.com
How would c++ exception support slow down C applications?

Marco Manfredini

unread,
Nov 9, 2009, 7:25:54 AM11/9/09
to andro...@googlegroups.com
Jack Palevich wrote:
> Sorry, no, we have no plans to support exceptions in the NDK, or in the
> Android platform C/C++ runtime.
>
> We understand that many C++ developers find exceptions a very useful
> tool.

It's not just a useful tool - it's essential for the implementation of
some fundamental C++ programming idioms and eventually a lot of existing
C++ code that has been *written in this century* simply requires
exceptions. There might be reasons for some to reject exceptions
(http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Exceptions)
but there is no reason to impose this restriction upon others - just
throw in the bits for libsupc++ and the runtime linker and let the
people decide if they want C++ exceptions in *their* code or not.

> Unfortunately exceptions
> are expensive in terms of runtime time and space. Supporting exceptions

GCC Dwarf2 exceptions usually have zero time costs. There are extra
space requirements and the flow graph has some extra buckles which make
optimization harder, but if you weight that against the necessity to
employ manual error checks everywhere instead, you might end up with
faster code if you use exceptions.

> would complicate and slow down the C
> runtime even for pure C applications that do not use exceptions.

I don't think so.


Anton Persson

unread,
Nov 9, 2009, 10:57:59 AM11/9/09
to andro...@googlegroups.com
I agree.. I've heard this argument before, but no explanation or reference to an explanation.

fadden

unread,
Nov 9, 2009, 3:47:39 PM11/9/09
to android-ndk
On Nov 9, 2:26 am, Anton Persson <don.juan...@gmail.com> wrote:
> How would c++ exception support slow down C applications?

Any code across which an exception can be thrown must be able to clean
up after itself. If a bit of C code is bracketed by C++ code that
throws and catches, and the C code calls malloc()/free() for a
temporary allocation, a memory leak is possible. You have to write
everything with either the understanding that exceptions can't cross
over you, or understanding that they can happen and you may have to
handle cleanup by other means.

The exception-enabled code generated for ARM by gcc was unacceptable
when we first started on Android, so we built the system without it,
and I don't think anybody has really missed it. OTOH, I don't think
anybody has evaluated the size and performance costs in a while. If
you wanted to make a case for exceptions, hard numbers on core/
external libraries would be a good place to start.

Anton Persson

unread,
Nov 9, 2009, 3:57:49 PM11/9/09
to andro...@googlegroups.com
On Mon, Nov 9, 2009 at 9:47 PM, fadden <fad...@android.com> wrote:
On Nov 9, 2:26 am, Anton Persson <don.juan...@gmail.com> wrote:
> How would c++ exception support slow down C applications?

Any code across which an exception can be thrown must be able to clean
up after itself.  If a bit of C code is bracketed by C++ code that
throws and catches, and the C code calls malloc()/free() for a
temporary allocation, a memory leak is possible.  You have to write
everything with either the understanding that exceptions can't cross
over you, or understanding that they can happen and you may have to
handle cleanup by other means.

Well, memory leaks are an inherent risk not only in that case but in all cases where you call code that does not do garbage collect. So by implementing JNI you have the risk of memory leaks. So I can't really buy that argument.
 
The exception-enabled code generated for ARM by gcc was unacceptable
when we first started on Android, so we built the system without it,
and I don't think anybody has really missed it.

Well.. I miss it.. :-)
 
 OTOH, I don't think
anybody has evaluated the size and performance costs in a while.  If
you wanted to make a case for exceptions, hard numbers on core/
external libraries would be a good place to start.


OK, I don't have such numbers, and I don't have the knowledge to do it at the moment... However, can you tell me about how big these performance and size hits you talk about where? Was it comparable to the kind of performance hit you get by using floats without an FPU or what? :-) (Because that is something I can relate to...)
 

fadden

unread,
Nov 10, 2009, 3:46:22 PM11/10/09
to android-ndk
On Nov 9, 12:57 pm, Anton Persson <don.juan...@gmail.com> wrote:
> Well, memory leaks are an inherent risk not only in that case but in all
> cases where you call code that does not do garbage collect. So by
> implementing JNI you have the risk of memory leaks. So I can't really buy
> that argument.

It's possible to take solid, working code and cause it to leak by
throwing exceptions across it. One of the main motivations for native
code is re-use of existing code, so this is a real concern. Again,
though, the real motivation is code size and performance.

> >  OTOH, I don't think
> > anybody has evaluated the size and performance costs in a while.  If
> > you wanted to make a case for exceptions, hard numbers on core/
> > external libraries would be a good place to start.
>
> OK, I don't have such numbers, and I don't have the knowledge to do it at
> the moment... However, can you tell me about how big these performance and
> size hits you talk about where?

It's been >= 4 years, so I don't remember numbers. I remember looking
at the disassembly of some compiled ARM code that had fared badly
(twice as many registers being saved, bunch of extra code generated).
I also have a vague memory of a similar experience on SPARC from about
10 years ago.

Looking at the code generated now on a couple of trivial functions I
don't see much of a difference. We have "-funwind-tables" enabled
already, for the benefit of crash stack trace disassembly, so the net
difference on exception-riddled code is probably pretty small. We'd
need to fiddle with the gcc options, rebuild the entire system (or at
least the massive native libs like webkit and opencore), and examine
the results.

Hywel

unread,
Nov 10, 2009, 11:31:29 AM11/10/09
to android-ndk
I'm another developer in desperate need of C++ exceptions.

Is there any way that we might be able to use exceptions with the
existing NDK?

I don't know enough about the implementation of exceptions to be able
to guess at how it might be possible. Would it be enough if we could
obtain a library that contained the missing __cxa_begin_catch(),
__cxa_end_catch(), __cxa_etc_etc() functions, calls to which the
compiler inserts when you write code that uses exceptions, but are not
present in the NDK libraries or on the device? This wouldn't seem to
interfere with the operation of existing libraries or programs (would
it?).

I don't need to throw exceptions across libraries or across C
functions that do callbacks in bionic, I just need to throw and catch
within a single JNI wrapped library (and I can catch everything before
it gets as far as the JNI wrapper).

Any suggestions?

Hywel.

Marco Manfredini

unread,
Nov 10, 2009, 7:38:07 PM11/10/09
to andro...@googlegroups.com
fadden wrote:
>
> It's possible to take solid, working code and cause it to leak by
> throwing exceptions across it. One of the main motivations for native
> code is re-use of existing code, so this is a real concern. Again,
> though, the real motivation is code size and performance.
>
1. Solid, working C-code can leak in the presence of setjmp/longjmp too
(and setjmp.h is in the NDK).

2. Letting an exception propagate through C code is clearly a bug.
Pleading against a language feature designed to improve error handling
and code correctness, in order to avoid infrequent bugs of unversed
programmers is ironic.
>
> It's been >= 4 years, so I don't remember numbers. I remember looking
> at the disassembly of some compiled ARM code that had fared badly
> (twice as many registers being saved, bunch of extra code generated).
> I also have a vague memory of a similar experience on SPARC from about
> 10 years ago.
>
>=4 is a long time in GCC development. GCC-4.0.0 was released in April
2005 and it didn't even had EABI support. Also, we are talking about
what the compiler does to my code.
> Looking at the code generated now on a couple of trivial functions I
> don't see much of a difference. We have "-funwind-tables" enabled
> already, for the benefit of crash stack trace disassembly, so the net
> difference on exception-riddled code is probably pretty small. We'd
> need to fiddle with the gcc options, rebuild the entire system (or at
> least the massive native libs like webkit and opencore), and examine
> the results.
>
I dont't think that this would affect the whole system. There is no
requirement that the system libraries must understand exceptions at all
(except for the runtime support), as long as we don't throw exceptions
through them. What we want is C++ exception support in the NDK.



David Turner

unread,
Nov 10, 2009, 7:59:19 PM11/10/09
to andro...@googlegroups.com
OK, here's the most official answer you will get on this topic, since I'm the guy handling this aspect of the system:

1/ When the Android project started, the machine code generated by gcc 3.x with C++ exception support enabled
was horrible: it created massive register spills to the stack frame, and elongated the code path significantly. On the puny
ARM CPU that was used at the time (which had only 16 KB of *combined* I and D cache, if I remember correctly),
this significantly slowed down execution of even the most trivial loop.

It's only later that zero-cost exception handling was implemented in the compiler. Even early releases of GCC
boasting this feature were notoriously buggy in the ARM OABI/EABI department, and nobody wants to use a buggy
toolchain to build such a complex system as a whole operating system.

For this reason, the system was designed from the start to *not* use exceptions. Today is still the case and this situation
is not going to change, even if we have much better toolchains. Note that it's only very recently that GCC 4.x provided
a workable ARM EABI implementation, much too late in the game for the project anyway.

2/ That doesn't mean that we cannot support C++ exceptions for applicative code, only that we don't want any system library
to depends on them. However, properly supporting this requires adding some subtle changes to the C library / C++ support
library and/or dynamic linker. This work has not been done because the system doesn't need it at all, we've been busy with
other more important stuff, and we don't have a good and extensive test case for the implementation.

That doesn't mean it may never happen, just that the required support is not there yet. Contributions to r.android.com are
welcomed and will be duly reviewed. I can point interested parties to the relevant documentation if they want to.

--

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



David Phillip Oster

unread,
Nov 10, 2009, 7:35:58 PM11/10/09
to android-ndk
I'm another developer in desperate need of C++ exceptions.

On Nov 10, 12:46 pm, fadden <fad...@android.com> wrote:
> It's possible to take solid, working code and cause it to leak by
> throwing exceptions across it.

Yes, but that would be a client programmer error. Consider: your
working code isn't exception-safe C++ or this wouldn't be an issue.
The only way an exception could potentially be thrown across your code
is if I pass in a callback to some of my code, you call it, and my
code throws an exception. But I know going in that your code isn't C+
+. so all my callbacks MUST catch exceptions, record some error state,
and return to your code. This is the way every C++ programmer copes
with non-C++ frameworks.

> One of the main motivations for native code is re-use of existing code.

Yes. Exactly. I have a large body of C++ that I want to reuse. It uses
exceptions, because exceptions are a key part of the C++ language. If
you don't support exceptions, then you aren't supporting C++, but some
cut-down toy language.

It is well known how to implement C++ exceptions so they cost you
nothing unless the code actually throws: http://www.google.com/search?q=zerocost+exceptions

niko20

unread,
Nov 11, 2009, 6:56:47 AM11/11/09
to android-ndk
Um,

Correct me if I'm wrong, but if the C++ lib actually "threw" an
exception (because of an error of some type, divide by zero for
instance), wouldn't that be passed back up to the java layer anyway,
which could then handle it?

I think this is an important question to know the answer to at
least...


-niko

On Nov 10, 6:35 pm, David Phillip Oster <davidphillipos...@gmail.com>
wrote:

Hywel

unread,
Nov 11, 2009, 12:03:35 PM11/11/09
to android-ndk

On Nov 11, 11:56 am, niko20 <nikolatesl...@yahoo.com> wrote:
> Um,
>
> Correct me if I'm wrong, but if the C++ lib actually "threw" an
> exception (because of an error of some type, divide by zero for
> instance), wouldn't that be passed back up to the java layer anyway,
> which could then handle it?
>
> I think this is an important question to know the answer to at
> least...

If you mean would the exception naturally pass up from the C++ lib
through the JNI interface into the java code _without_ writing any JNI
special wrapper code, I don't think that works because java exceptions
and C++ exceptions are made of different stuff.

C++ exceptions could be arbitrary classes (and they couldn't be
std::exception in android anyway as there isn't any library for it) -
and they need to map to the java namespace somehow.

What you would need to do is to catch the C++ exception in your C++
library and do one of two things:
1) pass a return code that signifies an error condition through JNI,
and then check for it and throw an exception in the java code
2) call the JNI function ThrowNew() in your C++ code to set up a
pending exception before returning back into java code (but I've not
tried that one)

fadden

unread,
Nov 11, 2009, 7:38:28 PM11/11/09
to android-ndk
On Nov 11, 9:03 am, Hywel <hywe...@googlemail.com> wrote:
> What you would need to do is to catch the C++ exception in your C++
> library and do one of two things:
>   1) pass a return code that signifies an error condition through JNI,
> and then check for it and throw an exception in the java code
>   2) call the JNI function ThrowNew() in your C++ code to set up a
> pending exception before returning back into java code (but I've not
> tried that one)

Either of these will work. #2 is a better choice if you have some
sort of detail in the C++ exception that should be carried over to the
Java exception.

The VM has no awareness of C++ exceptions. Unrolling the native stack
across the VM will result in heartache and disappointment.

Dmitry.Skiba

unread,
Nov 12, 2009, 12:38:07 AM11/12/09
to android-ndk
I'm interested in building toolchain with exception handling on. Can
you point me where to start?
Also, if efficiency of exception handling is not important, maybe use
of sjlj handling model can simplify the task? (This opinion is based
on brief reading of google output on the naive search string, so it is
probably very wrong :)

Dmitry.Skiba

unread,
Nov 12, 2009, 4:38:40 AM11/12/09
to android-ndk
And maybe there is no need to link to android libs, what if I build
the toolchain with exceptions on and then build a library with no
dependancies to the android shareds libraries? Will it load?

Dmitry Moskalchuk

unread,
Dec 6, 2009, 6:50:12 AM12/6/09
to android-ndk
Hi all,

any news on this?

KKK

unread,
Dec 11, 2009, 3:48:36 AM12/11/09
to android-ndk
hi ,

Any news on this - C++ exception handling in NDK.
can some one tell what would be the best way to go ahead for porting C+
+ code(with exceptions)?
If rewriting the code is the only way,is there any known/successfully
followed practice(for this purpose)? Ideally what would be better
approach ?

Thanks,
KKK.

On Dec 6, 4:50 pm, Dmitry Moskalchuk <crys...@gmail.com> wrote:
> Hi all,
>
> any news on this?
>
> On Nov 12, 12:38 pm, "Dmitry.Skiba" <dmitry.sk...@gmail.com> wrote:
>
>
>
> > And maybe there is no need to link to android libs, what if I build
> > the toolchain withexceptionson and then build a library with no
> > dependancies to the android shareds libraries? Will it load?
>
> > On 12 ноя, 11:38, "Dmitry.Skiba" <dmitry.sk...@gmail.com> wrote:
>
> > > I'm interested in building toolchain with exception handling on. Can
> > > you point me where to start?
> > > Also, if efficiency of exception handling is not important, maybe use
> > > of sjlj handling model can simplify the task? (This opinion is based
> > > on brief reading of google output on the naive search string, so it is
> > > probably very wrong :)
>
> > > On 11 ноя, 06:59, David Turner <di...@android.com> wrote:
>
> > > > OK, here's the most official answer you will get on this topic, since I'm
> > > > the guy handling this aspect of the system:
>
> > > > 1/ When the Android project started, the machine code generated by gcc 3.x
> > > > withC++exception support enabled
> > > > was horrible: it created massive register spills to the stack frame, and
> > > > elongated the code path significantly. On the puny
> > > > ARM CPU that was used at the time (which had only 16 KB of *combined* I and
> > > > D cache, if I remember correctly),
> > > > this significantly slowed down execution of even the most trivial loop.
>
> > > > It's only later that zero-cost exception handling was implemented in the
> > > > compiler. Even early releases of GCC
> > > > boasting this feature were notoriously buggy in the ARM OABI/EABI
> > > > department, and nobody wants to use a buggy
> > > > toolchain to build such a complex system as a whole operating system.
>
> > > > For this reason, the system was designed from the start to *not* use
> > > >exceptions. Today is still the case and this situation
> > > > is not going to change, even if we have much better toolchains. Note that
> > > > it's only very recently that GCC 4.x provided
> > > > a workable ARM EABI implementation, much too late in the game for the
> > > > project anyway.
>
> > > > 2/ That doesn't mean that we cannot supportC++exceptionsfor applicative
> > > > code, only that we don't want any system library
> > > > to depends on them. However, properly supporting this requires adding some
> > > > subtle changes to the C library /C++support
> > > > library and/or dynamic linker. This work has not been done because the
> > > > system doesn't need it at all, we've been busy with
> > > > other more important stuff, and we don't have a good and extensive test case
> > > > for the implementation.
>
> > > > That doesn't mean it may never happen, just that the required support is not
> > > > there yet. Contributions to r.android.com are
> > > > welcomed and will be duly reviewed. I can point interested parties to the
> > > > relevant documentation if they want to.
>
> > > > On Tue, Nov 10, 2009 at 4:38 PM, Marco Manfredini <m...@phoyd.net> wrote:
> > > > > fadden wrote:
>
> > > > > > It's possible to take solid, working code and cause it to leak by
> > > > > > throwingexceptionsacross it.  One of the main motivations for native
> > > > > > code is re-use of existing code, so this is a real concern.  Again,
> > > > > > though, the real motivation is code size and performance.
>
> > > > > 1. Solid, working C-code can leak in the presence of setjmp/longjmp too
> > > > > (and setjmp.h is in the NDK).
>
> > > > > 2. Letting an exception propagate through C code is clearly a bug.
> > > > > Pleading against a language feature designed to improve error handling
> > > > > and code correctness, in order to avoid infrequent bugs of unversed
> > > > > programmers is ironic.
>
> > > > > > It's been >= 4 years, so I don't remember numbers.  I remember looking
> > > > > > at the disassembly of some compiled ARM code that had fared badly
> > > > > > (twice as many registers being saved, bunch of extra code generated).
> > > > > > I also have a vague memory of a similar experience on SPARC from about
> > > > > > 10 years ago.
>
> > > > >  >=4 is a long time in GCC development. GCC-4.0.0 was released in April
> > > > > 2005 and it didn't even had EABI support. Also, we are talking about
> > > > > what the compiler does to my code.
> > > > > > Looking at the code generated now on a couple of trivial functions I
> > > > > > don't see much of a difference.  We have "-funwind-tables" enabled
> > > > > > already, for the benefit of crash stack trace disassembly, so the net
> > > > > > difference on exception-riddled code is probably pretty small.  We'd
> > > > > > need to fiddle with the gcc options, rebuild the entire system (or at
> > > > > > least the massive native libs like webkit and opencore), and examine
> > > > > > the results.
>
> > > > > I dont't think that this would affect the whole system. There is no
> > > > > requirement that the system libraries must understandexceptionsat all
> > > > > (except for the runtime support), as long as we don't throwexceptions
> > > > > through them. What we want isC++exception support in the NDK.

zzeng

unread,
Jan 5, 2010, 3:26:17 AM1/5/10
to android-ndk
Hi all,

for our project I've written few simple classes to derive from
and supporting stuff.
I published this as unwind.cpp & unwind.h in the group files.
Tested under MS VS 2005 & NDK 1.6.

This is single thread version, you may enhance it yourself via ex:TLS
or pthreads keys.
There are some restrictions, derived classes may not be allocated via
NEW operator or created as a class-member, only stack variable.
But this is enough for mutex handling, ref-countering, auto-ptrs etc.

Use as :
----------------------
TRY_BLOCK {

}
CATCH_BLOCK_FIN
{
std::cerr << exc;
}
FIN_BLOCK;

Regards,
Boris

Dmitry Moskalchuk

unread,
Jan 28, 2010, 8:03:03 PM1/28/10
to android-ndk
Hi all,

I've built my own version of android ndk which support full C++
standard library (including STL), exceptions and RTTI. I did it using
official ndk build scripts and sources, just little patched them.
Actually I was wonder how easy it was. I've used exceptions in massive
piece of code which I have now ported to android (libstdc++ linked
statically) and seems all works fine.
Only linux and darwin variants ready for now -
http://www.crystax.net/data/android-ndk-1.6_r1-linux-x86-crystax.tar.bz2,
http://www.crystax.net/data/android-ndk-1.6_r1-darwin-x86-crystax.tar.bz2.
Diff I've created to build customized ndk -
http://www.crystax.net/data/android-ndk-1.6_r1-crystax.diff.
Hope it would help to you guys :)

Hywel

unread,
Feb 1, 2010, 5:13:13 AM2/1/10
to android-ndk
Congratulations Dmitry!

This is obviously a big deal for C++ developers, especially adding
support for exceptions which is otherwise pretty tricky to work-
around.

I haven't tried this yet, but by the look of the diff it doesn't look
like a big change.

Question to NDK maintainers: would it be possible to support this
build in the next release?

Presumably it would be possible to make a single ndk build that does
exactly what the current ndk build does at the moment (i.e. no
overhead for supporting exceptions as previously mentioned), and only
adds full C++ support when enabled via compiler flags? (maybe that is
what Dmitry's build already does?).

Hywel.


On Jan 29, 1:03 am, Dmitry Moskalchuk <crys...@gmail.com> wrote:
> Hi all,
>
> I've built my own version of android ndk which support full C++
> standard library (including STL), exceptions and RTTI. I did it using
> official ndk build scripts and sources, just little patched them.
> Actually I was wonder how easy it was. I've used exceptions in massive
> piece of code which I have now ported to android (libstdc++ linked
> statically) and seems all works fine.

> Only linux and darwin variants ready for now -http://www.crystax.net/data/android-ndk-1.6_r1-linux-x86-crystax.tar.bz2,http://www.crystax.net/data/android-ndk-1.6_r1-darwin-x86-crystax.tar....
> Diff I've created to build customized ndk -http://www.crystax.net/data/android-ndk-1.6_r1-crystax.diff.

Dmitry Moskalchuk

unread,
Feb 1, 2010, 8:13:59 AM2/1/10
to andro...@googlegroups.com
Hi,

Just want to inform that windows build is also done - http://www.crystax.net/data/android-ndk-1.6_r1-windows-crystax.zip


Dmitry Moskalchuk

01.02.2010, в 13:13, Hywel написал(а):

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

> To unsubscribe from this group, send email to android-ndk...@googlegroups.com
> .
> For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en
> .
>

David Turner

unread,
Feb 1, 2010, 1:48:38 PM2/1/10
to andro...@googlegroups.com


On Mon, Feb 1, 2010 at 2:13 AM, Hywel <hyw...@googlemail.com> wrote:
Congratulations Dmitry!

Seconded !
 
This is obviously a big deal for C++ developers, especially adding
support for exceptions which is otherwise pretty tricky to work-
around.

I haven't tried this yet, but by the look of the diff it doesn't look
like a big change.

Question to NDK maintainers: would it be possible to support this
build in the next release?

Not the next release, which is pretty well done at this point, but I hope to have
something for the one after that (no ETA, as usual). I still need to check that everything
is properly implemented in the system. There are a couple of really nasty things to take
care of.
 
Presumably it would be possible to make a single ndk build that does
exactly what the current ndk build does at the moment (i.e. no
overhead for supporting exceptions as previously mentioned), and only
adds full C++ support when enabled via compiler flags? (maybe that is
what Dmitry's build already does?).


Yes, the idea is to allow third-party applications to use C++ exceptions and RTTI if they need them,
even though the system doesn't use or require them. If something can be done without needing to
change the platform, there is no reason to restrict this.

My general impression though is that many helper functions need to be provided by the system
to have things to work correctly. I'd be glad if this was not the case.
 

Kevin Duffey

unread,
Feb 1, 2010, 1:57:33 PM2/1/10
to andro...@googlegroups.com
Question on this guys.. I've yet to mess with NDK.. but this change.. which seems to benefit all of us NDK potential users, does this mean I would need to get the NDK source from google directly, build it (with this new script) every time a new update occurs? Or was this more a test/for fun trial to get it working, now that you have it, google/android team will incorporate this in to the next release of NDK (2.1?) and we all will not have to build the entire source?

Thanks.

Dmitry Moskalchuk

unread,
Feb 1, 2010, 3:13:27 PM2/1/10
to andro...@googlegroups.com
Hi David,

I really would like to get feedback about my attempt - there of course could be problems I've not seen yet even after using my code with exceptions and STL on android. Tests can only find problems if they exists but can not assert there are no more them.
These nasty things you've mentioned - could you explain more detailed? I'm very concerned to know them - quality of my code will depend on that.

My general impression though is that many helper functions need to be provided by the system
to have things to work correctly. I'd be glad if this was not the case.

As I know, GCC uses table approach to handle exceptions which means it has no runtime overhead in case if exception was not thrown. No exception setup code at start/finish of each frame. The only overhead is little bit larger data segment size. Also there are no hardware-specific bindings in exception support code because GCC supports too much hardware platform to allow this. Please correct me if I'm wrong.


Dmitry Moskalchuk

01.02.2010, в 21:48, David Turner написал(а):

Doug Schaefer

unread,
Feb 1, 2010, 3:18:51 PM2/1/10
to andro...@googlegroups.com
On Mon, Feb 1, 2010 at 3:13 PM, Dmitry Moskalchuk <cry...@gmail.com> wrote:
Hi David,

I really would like to get feedback about my attempt - there of course could be problems I've not seen yet even after using my code with exceptions and STL on android. Tests can only find problems if they exists but can not assert there are no more them.
These nasty things you've mentioned - could you explain more detailed? I'm very concerned to know them - quality of my code will depend on that.

My general impression though is that many helper functions need to be provided by the system
to have things to work correctly. I'd be glad if this was not the case.

As I know, GCC uses table approach to handle exceptions which means it has no runtime overhead in case if exception was not thrown. No exception setup code at start/finish of each frame. The only overhead is little bit larger data segment size. Also there are no hardware-specific bindings in exception support code because GCC supports too much hardware platform to allow this. Please correct me if I'm wrong.

The MinGW crowd run into this all the time as well when using gcc in combination with DLLs created with Visual C++. The setjmp/longjmp method of exception handling works in that case, but it is slower when exceptions are actually thrown. I assume mileage would be the same with Android's runtime.
 

Dmitry Moskalchuk

unread,
Feb 1, 2010, 4:01:43 PM2/1/10
to andro...@googlegroups.com
Well, thats sounds reasonable, but I've not seen corresponding changes in changelog provided by android developers. The only three things I've seen there which are more or less intact with exception support are these:

> 2008-06-19  Doug Kwan  <doug...@google.com>
>   Back-port ARM stack unwinding from a newer gcc version than 4.2.1.
>   This is not needed for gcc-4.3.
>   Changed Files:
>   gcc/config/arm/libunwind.S
>   gcc/config/arm/libgcc-bpabi.ver
>   gcc/config/arm/unwind-arm.c
>   gcc/config/arm/unwind-arm.h
> 2008-06-19  Doug Kwan  <doug...@google.com>
>   Enable decloning of constructors and destructors.  This is not
>   patchable to gcc-4.3.
>   Changed Files:
>   gcc/c.opt
>   gcc/cp/class.c
>   gcc/cp/cp-gimplify.c
>   gcc/cp/cp-tree.h
>   gcc/cp/semantics.c
> 2008-06-19  Doug Kwan  <doug...@google.com>
>   Stack protector bug fix.  The bug has not been fixed in gcc trunk
>   and this patch is required in 4.2, 4.3 and trunk.
>   Changed Files:
>   gcc/cfgrtl.c
>   gcc/config/arm/arm.c
>   gcc/rtl.h


I've inspected them and have not found modifications which could point to such fundamental exception mechanism rewriting. Moreover, I just don't see any reasons why android team would need to rewrite such well designed and efficient implementation instead of patching some separate bugs (it looks much, MUCH more easier!).
So still waiting for David's answer.


Dmitry Moskalchuk

01.02.2010, в 23:18, Doug Schaefer написал(а):

David Turner

unread,
Feb 1, 2010, 4:22:42 PM2/1/10
to andro...@googlegroups.com
On Mon, Feb 1, 2010 at 12:13 PM, Dmitry Moskalchuk <cry...@gmail.com> wrote:
Hi David,

I really would like to get feedback about my attempt - there of course could be problems I've not seen yet even after using my code with exceptions and STL on android. Tests can only find problems if they exists but can not assert there are no more them.
These nasty things you've mentioned - could you explain more detailed? I'm very concerned to know them - quality of my code will depend on that.


The idea is to make a detailed pass about all the stuff that is listed in the following documents:

   - C++ ABI for the ARM Architecture                 (a.k.a. CPPABI)
   - Runtime ABI for the ARM Architecture             (a.k.a. RTABI)

And probably a few others. These define a set of helper functions that may be provided either by the system or
toolchain-specific libraries. I just want to be sure that everything that is supposed to be provided by the system
will be, once we officially support it, and has the correct behaviour.

I'm not directly responsible for the toolchain sources, so I don't know exactly why it was disabled at first. A very long
time ago a toolchain engineer told me there was no guarantee that re-enabling these would work correctly. I plan to talk
with the toolchain team about this soon anyway. I have not tried to experiment heavily in this direction due to other
priorities.

Note also that the next NDK release will come with GCC 4.4.0 (as well as 4.2.1 as an option for compatibility
reason). This toolchain generates better code. However, the upstream maintainers have broken the mangling of the
std::va_list type (the mangling was invalid in previous releases because of a bug in the ARM spec, I believe).
I know that this does *not* affect machine code generated with existing NDKs (I have researched the issue),
but I cannot comment on code generated with modified toolchains at this point.w for the rest.

My concern is being able to give you the guarantee that the code you generate with an official NDK will work
on all future releases of the platform for the next 10 years, even if we change the toolchain again. As such, I simply
don't know if this is possible with your modified version.

That does *not* mean it is not possible, just that we don't know that yet.
 
My general impression though is that many helper functions need to be provided by the system
to have things to work correctly. I'd be glad if this was not the case.

As I know, GCC uses table approach to handle exceptions which means it has no runtime overhead in case if exception was not thrown. No exception setup code at start/finish of each frame. The only overhead is little bit larger data segment size. Also there are no hardware-specific bindings in exception support code because GCC supports too much hardware platform to allow this. Please correct me if I'm wrong.


I don't think there is anything wrong or related to the exception handling implementation. It's all about providing the right
helper functions with the right name and behaviour in the system.
 
Hope this helps

Dmitry Moskalchuk

unread,
Feb 1, 2010, 2:25:00 PM2/1/10
to andro...@googlegroups.com
Thank you David!

Dmitry Moskalchuk

>> <mailto:crys...@gmail.com>> wrote:
>> > Hi all,
>> >
>> > I've built my own version of android ndk which support full C++
>> > standard library (including STL), exceptions and RTTI. I
>> did it using
>> > official ndk build scripts and sources, just little patched
>> them.
>> > Actually I was wonder how easy it was. I've used exceptions
>> in massive
>> > piece of code which I have now ported to android (libstdc++
>> linked
>> > statically) and seems all works fine.
>> > Only linux and darwin variants ready for now
>> -http://www.crystax.net/data/android-ndk-1.6_r1-linux-x86-crystax.tar.bz2,http://www.crystax.net/data/android-ndk-1.6_r1-darwin-x86-crystax.tar....
>> > Diff I've created to build customized ndk
>> -http://www.crystax.net/data/android-ndk-1.6_r1-crystax.diff.
>> > Hope it would help to you guys :)
>> >
>> > On Jan 5, 11:26 am, zzeng <zz...@mail.ru

>> <mailto:andro...@googlegroups.com>.


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

>> <mailto:android-ndk%2Bunsu...@googlegroups.com>.


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

>> <mailto:andro...@googlegroups.com>.


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

>> <mailto:android-ndk...@googlegroups.com>.


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

> <mailto:andro...@googlegroups.com>.


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

> <mailto:android-ndk%2Bunsu...@googlegroups.com>.

KKK

unread,
Feb 9, 2010, 8:57:50 PM2/9/10
to android-ndk
"My general impression though is that many helper functions need to
be
provided by the system
to have things to work correctly. I'd be glad if this was not the
case"

This doesn't conclude any thing. Can we get a more conclusive answer
on this, 'not possible without system support' or 'static linking with
libstdc++' is going to work'. While we look for NDK team to release
its next version with full C++ support, we are looking for
intermediate solutions provided in this group (like stlport ..., which
seemed to work properly). I am not sure if i can rely on the above or
avoid it?

Thanks and regards,
KKK


On Feb 1, 11:48 pm, David Turner <di...@android.com> wrote:

> >http://www.crystax.net/data/android-ndk-1.6_r1-linux-x86-crystax.tar......

> > android-ndk...@googlegroups.com<android-ndk%2Bunsubscribe@googlegr oups.com>

David Turner

unread,
Feb 9, 2010, 9:06:19 PM2/9/10
to andro...@googlegroups.com
On Tue, Feb 9, 2010 at 5:57 PM, KKK <kast...@gmail.com> wrote:
"My general impression though is that many helper functions need to
be
provided by the system
to have things to work correctly. I'd be glad if this was not the
case"

This doesn't conclude any thing. Can we get a more conclusive answer
on this, 'not possible without system support' or 'static linking with
libstdc++' is going to work'. While we look for NDK team to release
its next version with full C++ support, we are looking for
intermediate solutions provided in this group (like stlport ..., which
seemed to work properly). I am not sure if i can rely on the above or
avoid it?

I am not sure either. You could still try to test it and see if it works correctly for you.
If not, this will be one interesting data point, to say the least.
 
To unsubscribe from this group, send email to android-ndk...@googlegroups.com.

David Turner

unread,
Feb 9, 2010, 9:09:25 PM2/9/10
to andro...@googlegroups.com
To be more precise, if you have a solution that works 100% reliably on currently
deployed Android devices, and only use the stable ABIs exposed by the NDK,
the chances that a platform update will break it are pretty slim (because all the
code required would have been statically linked to your executable).

It's really people trying to link to non-stable libraries that worry me the most.

What I'm concerned about the proposed solution is that it may not work correctly
in a few corner cases (and I'm not saying this is the case, just that I'm not confident
enough to guarantee it, otherwise I would gladly integrate this into the NDK itself).

If you use it and that it works for you, in the limits of the NDK, please go for it.

KKK

unread,
Feb 9, 2010, 10:32:31 PM2/9/10
to android-ndk
Thank you David. will give a try.
Thank you Dmitry Moskalchuk for updating on this alternative.

KKK.

On Feb 10, 7:09 am, David Turner <di...@android.com> wrote:
> To be more precise, if you have a solution that works 100% reliably on
> currently
> deployed Android devices, and only use the stable ABIs exposed by the NDK,
> the chances that a platform update will break it are pretty slim (because
> all the
> code required would have been statically linked to your executable).
>
> It's really people trying to link to non-stable libraries that worry me the
> most.
>
> What I'm concerned about the proposed solution is that it may not work
> correctly
> in a few corner cases (and I'm not saying this is the case, just that I'm
> not confident
> enough to guarantee it, otherwise I would gladly integrate this into the NDK
> itself).
>
> If you use it and that it works for you, in the limits of the NDK, please go
> for it.
>
>
>
> On Tue, Feb 9, 2010 at 6:06 PM, David Turner <di...@android.com> wrote:
>

Reply all
Reply to author
Forward
0 new messages