[haiku-bugs] Re: [Haiku] #8508: Various classes no longer appear to be resolving members with recent gcc upgrades

  • From: "bonefish" <trac@xxxxxxxxxxxx>
  • Date: Tue, 29 May 2012 13:33:29 -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
-------------------------------------+----------------------------

Comment (by bonefish):

 Replying to [comment:6 anevilyak]:
 > Do you think it'd be better to simply evaluate both sections for a
 potential match if they're present?

 Unless there's a good reason to do that -- like both sections containing
 different parts of the information -- I wouldn't do that. I wonder anyway
 why the .debug_frame is no longer correctly written. After all it is
 documented to contain the information. Have you read anything about this
 (e.g. in the changelog, some announcement, or discussion)? Or might this
 just be a bug?

 > 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.

 Or do that lazily/cache information. The startup already takes quite some
 time and doing more preprocessing will make that even worse. Although
 that's probably quite a bit of work, it might be necessary to preload even
 less information (load the CIEs on demand with caching). I may recall that
 incorrectly, but didn't debugging WebPositive (with full debug info for
 WebKit) even hit the address space limit?

-- 
Ticket URL: <http://dev.haiku-os.org/ticket/8508#comment:7>
Haiku <http://dev.haiku-os.org>
Haiku - the operating system.

Other related posts: