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