https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111731
Thomas Neumann <tneumann at users dot sourceforge.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #57679|0 |1
is obsolete| |
--- Comment #18 from Thomas Neumann <tneumann at users dot sourceforge.net> ---
Created attachment 57692
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57692&action=edit
patch with separate btrees
We will have to do that, I have updated the patch to use a separate lookup
structure for the tables.
Which prevents the original problem and hopefully fixes the issue. The only
thing that makes me nervous is that if some JITer comes up with the idea of
placing an unwind tuple inside some code range, what prevents them from placing
code from one table within code from another table? Which would break the
assumption that code ranges do not overlap.
Note that the non-fast-path code also makes the assumption that code ranges do
not overlap, see the comment in _Unwind_Find_FDE. Thus perhaps no JIT code
emitter will do that. But if somebody does we should probably store the fde
instead of the object inside the lookup structure. The fde ranges really must
not overlap, otherwise everything breaks. But I would like to not do that
because we have more fdes than objects and storing each fde individually would
make frame registration more expensive (even though lookup became faster,
because we would no longer have to traverse the object).
