[UE5][Linux] LLDB won't show inherited members.
Followed by 4 people
There is an old post about similar issue here but it's old and abandoned by the OP so I've decided to start a new one. The title says it all, when looking at the variables in the debugger I can't see members inherited from the engine parent class. I did run "fr v *this" suggested in the old thread and engine members where not visible. What's interesting is that engine members are accessible if I specify them by name ( trying to evaluate NamePrivate will give me a proper result ). LLDB appears to be working correctly but it can't list engine members on it's own.
Now the twist, I know how to fix it but the fix has a price. UE has an option called bTuneDebugInfoForLLDB which will use -glldb option to tune debug info for lldb. Once that option is enabled engine members will be visible, but the engine size goes from 66.8GiB to 149.9GiB and linking time goes up by 5-10 times ( build+link goes from ~2.5s to ~16s for any change ). It's the increased linking time that hurts the most, is there any way to work around it? Any way to force LLDB to iterate inherited members without bTuneDebugInfoForLLDB? Any help would be appreciated.
Please sign in to leave a comment.
Hello Eryk Dykiel,
We've added the bTuneDebugInfoForLLDB (-EnableLLDB) option to UBT specifically to improve the engine debugging experience. I'm afraid there might not be a solution that would reduce the engine size, build time and allow you to debug the engine on Linux, but you might want to try bUseIncrementalLinking to see if it helps reduce the build/link time in your case.
Hi Kirill, bUseIncrementalLinking didn't result in any improvements in this case. I've tried to figure out where the time is being spent and it looks like the vast majority is taken by dump_syms. Out of ~35s for the whole build/link ~26s is taken by that process. Seems excessive but I don't know much about that tool, perhaps it's normal. If you have any more ideas let me know and if not then it can't be helped.
Hi Eryk Dykiel,
I ran a few tests on smaller projects in a testing environment, and my numbers are about the same – dump_syms is the longest step in the build process, and it takes about half the total build time in my case. I don't think shortening the build time is possible by changing UE build configuration (without degrading the debugging experience) and there is nothing Rider can do about it.
Hi Kirill, thank you for the update. For now I will continue switching bTuneDebugInfoForLLDB on and off depending on what I'm doing.
Hi Eryk Dykiel,
I took a another look into the build process and it seems that there might be a performance issue in breakpad's demangling. There are a couple of ways to speed it up, but the easiest (and probably the least risky) one is to turn off demangling when running UBT. You can do it like this:
This change should speed up the build process by around 20-30%. Please note that mangled names might make debugging crash dumps difficult or even impossible so I suggest reverting this change if you are debugging crashes.
Please let me know if it helps.
It seems I forgot to post my response, little late but thanks Kirill, your answer was helpful. I'd like to add that since UE5.3 there is a built-in option to skip dump_syms called bDisableDumpSyms. It can be enabled it in the BuildConfiguration.xml file.
I can't see ACharacter or UPawnMovementComponent from the constructor of a derived class even with bTuneDebugInfoForLLDB on. (Try test with a component class override)
It says “<incomplete type>” in these rows.
While in the constructor of ACharacter itself, I can see members of APawn, AActor, UCharacterMovement and UPawnMovementComponent.
Update: I solved this by changing the build configuration to DebugGame.