This is the mail archive of the glibc-bugs@sources.redhat.com mailing list for the glibc 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]

[Bug nptl/300] pthread_cond_timedwait does not reacquire the mutex on cancelation


------- Additional Comments From rth at gcc dot gnu dot org  2004-08-11 21:07 -------
To handle vdso's, I really only see a couple of solutions.

One, a dedicated column for the signal number.  We'd have to hack libgcc to
look for this column being set each frame, as well as hard-code the signal
numbers that stop before the pc, rather than after.

Two, a DW_GNU_CFA_foo that has an expression that evaluates non-zero when
the pc is before the instruction rather than after.  As you say, this causes
old libgcc's to abort.  Maybe we don't care, and backport the change (at least
to recognize and skip) to all gcc branches.  It's not like we need unwinding
in order to boot.

Three, a new augmentation letter that indicates the presence of an expression
that evaluates non-zero.  You'd probably want a uleb128 at the beginning that
gave the size of the expression, so that we could easily skip it to find data
for subsequent letters.  This last has the advantage that when we see an unknown
letter, we're *supposed* to skip processing the rest of the augmentation.  I
don't know that that code has been tested though; we'd have to see if we do or
don't actually handle that properly.

-- 


http://sources.redhat.com/bugzilla/show_bug.cgi?id=300

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]