jasonmolenda wrote: This has always been a small perf issue with stripped binaries, but there is an unusual case where it became a big problem: wine, the windows environment, has a symbol at a low address like 0x1000, and it reserves the first 4GB of address space to load 32-bit windows binaries (without lldb's knowledge). lldb has a backtrace where there is a saved pc near the high end of this range, we find the nearest symbol at 0x1000, and proceed to analyze 4GB of instructions which is quite slow.
I don't know how to represent this in a test case, unfortunately. We do have a similar limit over in UnwindAssemblyInstEmulation::GetNonCallSiteUnwindPlanFromAssembly where we limit the disassembly to 99999 instructions, this is not an entirely new idea. But there are codepaths that will not go through this method and still try to disassemble any size "function". https://github.com/llvm/llvm-project/pull/105890 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
