This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.
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 29/05/2013 12:01 AM, Ian Lance Taylor wrote:
Hmm... How recent is "modern" ? Because the only obvious __cxa_allocate_exception in the gcc-4.8 sources (libstdc++-v3/libsupc++/eh_alloc.cc) sure seems to call malloc, and the traces I got from throwing in code compiled by both gcc-4.6 and gcc-4.8 (gold linker) show calls to malloc as well.On Tue, May 28, 2013 at 8:50 PM, Ryan Johnson <ryan.johnson@cs.utoronto.ca> wrote:For example, it should be reasonably safe to let __cxa_allocate_exception call dl_iterate_phdr in order to build a list of object headers valid at the time unwind begins. It already calls malloc, so allocating space for a cache (holding pointers to at most a few dozen object headers) wouldn't be so terrible; __cxa_free_exception could release the space after the dust settles. In order to optimize non-throw uses of unwinding, it might make sense to build the cache somewhere besides __cxa_allocate_exception, but the basic concept doesn't change.Actually, when everything is working correctly with modern tools on a GNU/Linux system, the unwind code never calls malloc. That is a good thing, as otherwise it would be unsafe to throw from a signal handler.
Assuming my system is somehow out of date, though, what is the preferred mechanism I'm missing out on? The code has enough #define tricks that I've been having trouble learning how things work in a stock gnu/linux system just by inspecting the code.
Thanks, Ryan
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |