#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 anevilyak): Replying to [comment:7 bonefish]: > 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? I'd guess bug, but I haven't had a chance to go through the mailing lists and announcements to find anything yet. For now I simply changed it as I did so we'd adapt to whatever the current situation happens to be. > 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? > We do indeed have that problem, though gdb does as well iirc. If memory serves, we actually hit the issue up front while parsing the DIEs though, would need to try again to see. In any case, will file an enhancement ticket for lazy evaluation/loading. -- Ticket URL: <http://dev.haiku-os.org/ticket/8508#comment:8> Haiku <http://dev.haiku-os.org> Haiku - the operating system.