On Mon, Aug 9, 2010 at 17:45, Gibson, David wrote: > From: Mike Frysinger [[email protected]] >> On Mon, Aug 9, 2010 at 13:03, Gibson, David wrote: >>> I was hoping to debug the non-static build of the test to see what it does >>> but the exceptions handling functions are not debugable (as presumably >>> they’re part of a shared library/kernel). >> >>they should be ... but i'm not terribly familiar with how C++ >> exceptions are actually implemented. we arent using the old sjlj >> methods right ? we're using modern RT signals ? > > I don't know what the old sjlj method is (will have a hunt for some docs > tomorrow).
feel free to post any useful links you find to the list. i'd like to browse them for my own personal curiosity. i have found this: http://www.codesourcery.com/public/cxx-abi/ while it is a bit specific to the itanium (ia64) port, i think much is applicable across most ports including us > I've not prior experience of the C++ exceptions support used by GNU, and the > GNU Internals page has a "to be written" comment in it. sjlj is short for set-jump-long-jump. in the old days and/or with deficient ports today, this is how C++ exceptions were implemented. my understanding is that at the start of the try{} block, the generated code does a setjmp to save the current stack state. then when an exception is thrown, a longjmp to that point is made and the exception{} block is executed. due to the obvious overhead of having to save a lot of state to the stack even when no exceptions are thrown, the preferred method is to move to a signal based exception processing where the stack is manually unwound using DWARF information and assistance from the host OS. that way there is very little overhead in the normal code paths (no exceptions are thrown). but again, this is my passing understanding of the situation and i could possibly be talking out my ass ;). > But I'm making progress. Slowly. in case you hadnt noticed, this isnt an uncommon theme. companies want to pay for better compilers for their hardware, not for documentation ;). -mike _______________________________________________ Toolchain-devel mailing list [email protected] https://blackfin.uclinux.org/mailman/listinfo/toolchain-devel
