| Summary: | Exceptions cannot pass through uClibc functions | ||
|---|---|---|---|
| Product: | uClibc | Reporter: | Michael Deutschmann <michael> |
| Component: | Other | Assignee: | unassigned |
| Status: | NEW --- | ||
| Severity: | minor | CC: | uclibc-cvs |
| Priority: | P5 | ||
| Version: | 0.9.30.1 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Host: | i386-pc-linux-uclibc | Target: | |
| Build: | |||
| Attachments: | Test program | ||
there's no point in going half way. either all of the relevant files get compiled with -fexception support, or none of them do. looking at glibc shows that most of the I/O funcs use it, as well as a smattering of random functions. the question is, what determines whether a function needs exception support. i'm not familiar enough with C++ or the related documentation to figure that out ... POSIX doesnt cover this at all from what i can see. |
Created attachment 221 [details] Test program The attached test program works (exits with 0 returncode) on glibc, but aborts on uClibc. The problem is that the bsort module of uClibc is not compiled with "-fexceptions", thus stack unwinding through it fails. Compiling every relevant module with "-fexceptions" would bloat uClibc somewhat, especially on a threaded build where the many "cancellation point" functions would require this treatment. However, uClibc's headers, like glibc's, make sure not to declare __attribute ((nothrow)) on the relevant functions, which suggests that pass-through is supposed to work.