Re: C++ exceptions for eCos on i386-elf

[Matthew J Fletcher <mfletcher at serck-controls dot co dot uk>]

On Friday 08 Jul 2005 5:22 pm, you wrote:
> Hello Matthew,

> I saw your post on the CrossGcc mail list
> (http://sourceware.org/ml/crossgcc/2005-05/msg00104.html). Would you
> please answer a couple of questions for me?

well i could but you would have to pay my fee !

ok, here goes,.. im also replying back to the crossgcc list.

> Gcc builds/works fine but at run time any C++ Exception results in the
> pthread aborting. I've traced the exception, and from what I can see
> _Unwind_Find_FDE() finishes having found no objects (seen or unseen).
> This then ultimately causes the thread to abort (I guess because the
> exception cannot be handled).
>
> First question: What is my problem here?
>
> It seems like for some reason the exception handling code isn't being
> initialized/setup properly. This then lead me to what you had to say in
> your post (as noted above). You seem to suggesting that a solution to
> this problem is to "manually" initialize the EH stuff. Is this true?

i dont know for sure about ecos, but for nucleus (another rtos) you have to do 
it yourself, i would suspect that if ecos does not have a consept of 
'processes' with seperate memory spaces, as appart from threads then you 
would have to fo it yourself.

the stack unwinding exception handling code is provided by gcc, but is setup 
by the os. Its upto the os to choose when to register the exception 
information, in the case of a linux system, should the dynamic loader do it 
before all linked against libs are loaded ? or before the programs main().

same for running the global constructors / destructors, you would have to run 
them manually as gcc cant deside when to do it for you.

the crossgcc list my correct me though.

> The code you have listed in that post can be found (for the most part)
> in the gcc source code (i.e. in crtstuff.c, libgcc2.c etc). So why not
> build gcc in such a fashion (i.e. with the proper config options) that
> it get automatically called/used?
>
> It also wasn't clear to me what context some of the code in your post
>
> was to be called. For example:
> >// header from gcc, that defines the dwarf2 object format used for stack
> > unwinding #include "unwind-dw2-fde.h"
> >
> >#define EH_FRAME_SECTION_ASM_OP ".section\t.eh_frame,\"aw\""
>

once only, on startup.

in my code i only have one process, and a flat memory space,.. the processor 
on startup jumps to its default start address which has a symbol called 
_start, the os then starts up, and the ip stack and filesystem etc, then we 
get to main() which is inside the os, then i jump to the entry point of my 
application code.


> What is this for? It's not used anywhere.
>
> >// pointer to begin of .eh_frame section
> >extern "C" void * __eh_frame_start;

i use a custom linker script (run during make like so '-Xlinker -L. -Xlinker 
-Tlinkerscript'), in there i have added some symbols to define the start of 
the global constructors list. '__eh_frame_start'  is a symbol i added so i 
could run them.

i have had better ways of doing this pointed out the me (and i think posted on 
crossgcc).

> This isn't defined anywhere in gcc. Something called __EH_FRAME_BEGIN__
> is though. (?)
>
> >static struct object object;
> >
> >// exception handling frame information
> >__register_frame_info ((void *)&__eh_frame_start, &object);
>


> Are you suggesting that this would need to be called from every thread
> before C++ Exceptions could be used?

no, its just test code.

> >// test code
> >	try
> >	{
> >		try
> >		{
> >			try
> >			{
> >				throw (float) 1.2;
> >			}
> >			catch (float)
> >			{
> >				throw (int) 1;
> >			}
> >		}
> >		catch (int)
> >		{
> >			throw;
> >		}
> >
> >	}
> >	catch (...)
> >	{
> >		double here;
> >	}
>

> Will enough for now. Thanks for any possible information you can give me
> about this.

maybe the best advice would be not to use c++ exception handling in embedded 
projects, its madness, but we all do it.

regards
---
Matthew J Fletcher
Embedded Software
Serck Controls Ltd
---
**********************************************************************
Serck Controls Ltd, Rowley Drive, Coventry, CV3 4FH, UK
Tel: +44 (0) 24 7630 5050   Fax: +44 (0) 24 7630 2437
Web: www.serck-controls.com  Admin: post@serck-controls.co.uk
A subsidiary of Serck Controls Pty. Ltd. Reg. in England No. 4353634
**********************************************************************
This email and files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the above. Any views or opinions presented are those of the author
and do not necessarily represent those of Serck Controls Ltd.


This message has been checked by MessageLabs
******************************************************************

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com