[haiku-bugs] Re: [Haiku] #8508: Various classes no longer appear to be resolving members with recent gcc upgrades
- From: "anevilyak" <trac@xxxxxxxxxxxx>
- Date: Tue, 29 May 2012 12:02:12 -0000
#8508: Various classes no longer appear to be resolving members with recent gcc
upgrades
-------------------------------------+----------------------------
Reporter: anevilyak | Owner: anevilyak
Type: bug | Status: closed
Priority: normal | Milestone: R1
Component: Applications/Debugger | Version: R1/Development
Resolution: fixed | Keywords:
Blocked By: | Blocking:
Has a Patch: 0 | Platform: All
-------------------------------------+----------------------------
Changes (by anevilyak):
* status: in-progress => closed
* resolution: => fixed
Comment:
One note: in the cases where .debug_frame is generated at all, I do notice
that it contains at least a CIE and maybe 3-4 CFI sections, though I
wasn't yet able to ascertain exactly what functions they resolve to (it's
observable with a debug build of libbe here at least). Do you think it'd
be better to simply evaluate both sections for a potential match if
they're present?
Also, I notice that currently we always do a brute force scan through all
the data to try and find a match when reconstructing a call frame. Would
it be worth filing an enhancement to perform a startup scan of the call
frame information in order to build a search tree by address range so we
can quickly locate the exact section we want? For larger libraries it
often takes a noticeable amount of time to find the right CFI via the
current methodology.
--
Ticket URL: <http://dev.haiku-os.org/ticket/8508#comment:6>
Haiku <http://dev.haiku-os.org>
Haiku - the operating system.
Other related posts:
