This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |