This is the mail archive of the libc-hacker@sources.redhat.com mailing list for the glibc project.
Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.
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 Mon, 17 Nov 2003 10:12:22 -0800, Ulrich Drepper <drepper@redhat.com> said: Uli> But we already did unwind through signal handlers. It must be Uli> something new your patch adds. So likely the code in Uli> _dl_sysinfo_break, the .altrp etc. If a signal is received the Uli> thread is usually in a syscall so we have to unwind through the Uli> signal handler frame, the sigreturn stuff, and then the frame Uli> around the break instruction. It must be the step from Uli> sigreturn to _dl_sysinfo_break, everything else is the same. It's likely altrp but the ia64 unwinder in libgcc is rather broken so it could be a more complicated interaction (e.g., the unwinder won't work completely correctly with label_state/copy_state which is something the signal trampoline uses). In any case, my first priority is to get it to work with libunwind, since it's much easier to debug the code with it. Once that's working, I'll try to figure out what's holding up GCC's unwinder. If it's reasonably easy to fix, I'll make a patch. Otherwise, we may just want to give up on the builtin unwinder (it has already has at least one or two serious bugs, which would be hard to fix). --david
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |