|C++ exceptions||pltxtra||11/9/09 12:56 AM|
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..
|Re: C++ exceptions||Jack Palevich||11/9/09 1:46 AM|
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.
|Re: C++ exceptions||pltxtra||11/9/09 2:26 AM|
How would c++ exception support slow down C applications?
|Re: C++ exceptions||Marco Manfredini||11/9/09 4:25 AM|
Jack Palevich wrote: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
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.
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.
I don't think so.
|Re: C++ exceptions||pltxtra||11/9/09 7:57 AM|
I agree.. I've heard this argument before, but no explanation or reference to an explanation.
|Re: C++ exceptions||fadden||11/9/09 12:47 PM|
On Nov 9, 2:26 am, Anton Persson <don.juan...@gmail.com> wrote: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.
|Re: C++ exceptions||pltxtra||11/9/09 12:57 PM|
On Mon, Nov 9, 2009 at 9:47 PM, fadden <fad...@android.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.
The exception-enabled code generated for ARM by gcc was unacceptable
Well.. I miss it.. :-)
OTOH, I don't think
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...)
|Re: C++ exceptions||fadden||11/10/09 12:46 PM|
On Nov 9, 12:57 pm, Anton Persson <don.juan...@gmail.com> 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.
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
|Re: C++ exceptions||Hywel||11/10/09 8:31 AM|
I'm another developer in desperate need of C++ exceptions.
Is there any way that we might be able to use exceptions with the
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
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).
|Re: C++ exceptions||Marco Manfredini||11/10/09 4:38 PM|
fadden wrote: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.
>>=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 II 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.
|Re: C++ exceptions||David Turner||11/10/09 4:59 PM|
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.
|Re: C++ exceptions||David Phillip Oster||11/10/09 4:35 PM|
I'm another developer in desperate need of C++ exceptions.
On Nov 10, 12:46 pm, fadden <fad...@android.com> wrote: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
|Re: C++ exceptions||niko20||11/11/09 3:56 AM|
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
On Nov 10, 6:35 pm, David Phillip Oster <davidphillipos...@gmail.com>
|Re: C++ exceptions||Hywel||11/11/09 9:03 AM|
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)
|Re: C++ exceptions||fadden||11/11/09 4:38 PM|
On Nov 11, 9:03 am, Hywel <hywe...@googlemail.com> wrote: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
The VM has no awareness of C++ exceptions. Unrolling the native stack
across the VM will result in heartache and disappointment.
|Re: C++ exceptions||Dmitry Skiba||11/11/09 9:38 PM|
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 :)
|Re: C++ exceptions||Dmitry Skiba||11/12/09 1:38 AM|
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?
|Re: C++ exceptions||Dmitry Moskalchuk||12/6/09 3:50 AM|
any news on this?
|Re: C++ exceptions||KKK||12/11/09 12:48 AM|
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
> > the toolchain withexceptionson and then build a library with no
> > dependancies to the android shareds libraries? Will it load?> > > > withC++exception support enabled
> > > > was horrible: it created massive register spills to the stack frame, and> > > > 2/ That doesn't mean that we cannot supportC++exceptionsfor applicative
> > > > code, only that we don't want any system library> > > > > > throwingexceptionsacross it. One of the main motivations for native
> > > > > > code is re-use of existing code, so this is a real concern. Again,> > > > > 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.
|Re: C++ exceptions||zzeng||1/5/10 12:26 AM|
for our project I've written few simple classes to derive from
This is single thread version, you may enhance it yourself via ex:TLS
Use as :
|Re: C++ exceptions||Dmitry Moskalchuk||1/28/10 5:03 PM|
I've built my own version of android ndk which support full C++
|Re: C++ exceptions||Hywel||2/1/10 2:13 AM|
This is obviously a big deal for C++ developers, especially adding
I haven't tried this yet, but by the look of the diff it doesn't look
Question to NDK maintainers: would it be possible to support this
Presumably it would be possible to make a single ndk build that does
> 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.
|Re: C++ exceptions||Dmitry Moskalchuk||2/1/10 5:13 AM|
Just want to inform that windows build is also done - http://www.crystax.net/data/android-ndk-1.6_r1-windows-crystax.zip
01.02.2010, в 13:13, Hywel написал(а):
> --> 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
|Re: C++ exceptions||David Turner||2/1/10 10:48 AM|
On Mon, Feb 1, 2010 at 2:13 AM, Hywel <hyw...@googlemail.com> wrote:
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
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.
|Re: C++ exceptions||andjarnic||2/1/10 10:57 AM|
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?
|Re: C++ exceptions||Dmitry Moskalchuk||2/1/10 12:13 PM|
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.
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.
01.02.2010, в 21:48, David Turner написал(а):
|Re: C++ exceptions||Doug Schaefer||2/1/10 12:18 PM|
On Mon, Feb 1, 2010 at 3:13 PM, Dmitry Moskalchuk <cry...@gmail.com> wrote:
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.
|Re: C++ exceptions||Dmitry Moskalchuk||2/1/10 1:01 PM|
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:
> Back-port ARM stack unwinding from a newer gcc version than 4.2.1.
> This is not needed for gcc-4.3.
> Changed Files:
> Enable decloning of constructors and destructors. This is not
> patchable to gcc-4.3.
> Changed Files:
> 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:
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.
01.02.2010, в 23:18, Doug Schaefer написал(а):
|Re: C++ exceptions||David Turner||2/1/10 1:22 PM|
On Mon, Feb 1, 2010 at 12:13 PM, Dmitry Moskalchuk <cry...@gmail.com> wrote:
The idea is to make a detailed pass about all the stuff that is listed in the following documents:
- Generic C++ ABI (http://www.codesourcery.com/public/cxx-abi/abi.html)
- 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
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.
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
|Re: C++ exceptions||Dmitry Moskalchuk||2/1/10 11:25 AM|
Thank you David!
>> <mailto:crys...@gmail.com>> wrote:>> <mailto:andro...@googlegroups.com>.
|Re: C++ exceptions||KKK||2/9/10 5:57 PM|
"My general impression though is that many helper functions need to
This doesn't conclude any thing. Can we get a more conclusive answer
Thanks and regards,
> > On Jan 29, 1:03 am, Dmitry Moskalchuk <crys...@gmail.com> wrote:> >http://www.crystax.net/data/android-ndk-1.6_r1-linux-x86-crystax.tar......
> > > On Jan 5, 11:26 am, zzeng <zz...@mail.ru> wrote:
> > To post to this group, send email to andro...@googlegroups.com.> > android-ndk...@googlegroups.com<android-ndk%2Bunsubscribe@googlegr oups.com>
|Re: C++ exceptions||David Turner||2/9/10 6:06 PM|
On Tue, Feb 9, 2010 at 5:57 PM, KKK <kast...@gmail.com> wrote:
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.
|Re: C++ exceptions||David Turner||2/9/10 6:09 PM|
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.
|Re: C++ exceptions||KKK||2/9/10 7:32 PM|
Thank you David. will give a try.
Thank you Dmitry Moskalchuk for updating on this alternative.
On Feb 10, 7:09 am, David Turner <di...@android.com> wrote: