Hello, fellow developers!
I’m trying to debug Unreal Engine 4 sample on Android with LLDB 3.8 build from source - Win32 x86 liblldb.dll and Android ARM lldb-server : it can’t match the stripped module libUE4.so running on the device with a full version which is available on a host.
Unreal Build Tool don’t add the .note.gnu.build-id or .gnu_debuglink sections to ELF files – and it looks that only if the stripped ELF .so running on a target does have one of these than it could be matched with a full ELF module located on a host - is that true?
My reasoning is based on examination of
If so, I need to modify UBT to add the .build-id or .gnu_debuglink to a stripped libUE4.so
Modifying the build tool to include the build ID would probably be the
easiest solution to your problem. Please not that both the stripped
AND unstripped versions of the module need to have the (same)
.note.gnu.build-id section. I am not familiar with the build tool, but
"fixing" this should be as simple as adding "-Wl,--build-id" to your
compiler arguments for building the full .so. The subsequent strip
step should not remove the build-id (unless the tool uses some very
aggressive strip arguments).
Other possible solution would be to fix lldb to work in a
build-id-less scenario. We have been discussing trying to support this
just yesterday, but it's not yet clear when/if will that happen. The
problem there is that currently LLDB (in the ObjectFileELF snippet you
posted) falls back to computing a CRC of the whole module as its
"identity" if it cannot find a build it, which is not really working
as the CRC changes during stripping. One possible solution would be to
just do a checksum of only the allocatable ELF sections of the module,
which should hopefully create a strip-resistible identifier. If you're
interested in making this work, I think this would be a nice
improvement to lldb in general, and it should fix your problem.
let me know if you have further questions,
Well, after I've added .gnu_debuglink section to stripped libUE4.so LLDB managed to resolve the symbols.
But sometimes it asserts with the following message:
So, from the error message it looks like lldb is getting confused by
the debug information inside the executable. I don't have any special
hints for debugging that, I think the usual process of attaching the
debugger, examining the backtrace, and seeing what data is triggering
the assert would work best.
Alternatively, if you can create a list of steps to reproduce this
bug, we may be able to look at it for you. We're interested in making
this use case work, so we'll try to fix it soon.