[lldb-dev] Linux ELF header e_ident[EI_OSABI] value

[Greg Clayton via lldb-dev]

> On Aug 30, 2016, at 7:33 AM, Howard Hellyer via lldb-dev <lldb-dev at lists.llvm.org> wrote:
> 
> "Ted Woodward" <ted.woodward at codeaurora.org> wrote on 26/08/2016 16:17:18:
> 
> > That works fine for host debug, but not so much for embedded. On 
> > Hexagon, we support 2 OS cases – standalone (which means no OS, or 
> > an OS that lldb doesn’t know anything about) and Linux. Both our 
> > standalone simulator and our Linux generate core dumps using 
> > ELFOSABI_NONE. We run lldb on both x86 Linux and Windows, and our 
> > core dumps need to work on both. 
> 
> Ah, cross compiling/debugging makes that an even worse idea. 
>   
> > Doesn’t lldb get the correct OS from the target when you load them together? 
> 
> Yes, I'm just used to getting dumps from customers which don't always come with the executable, or the right executable, and was testing that scenario when I started looking into this. 

Unfortunately there isn't enough of any ELF file in memory that allows us to load any symbols or anything sense of anything without having all of the binaries. Linux core files must have the executables otherwise they are not very useful. For instance there are no symbol tables in memory when using ELF, so there isn't a way to create symbols so that LLDB can find out the function bounds so that we can actually backtrace correctly. Many Linux systems have a shell script that can be run on the linux system that is creating the core file and these shell scripts are often tasked with using the core file _and_ all the files on the machine itself to make a useful crash log. These tools often get the core file streamed to it and then the core file will go away afterward. That is the place to actually do the hard work of symbolicating if you are not going to have access to the exact machine later. One could create a shell tool that links against LLDB.framework which can load the core file on that machine and actually symbolicate the crash for you and dump it out in some nice structured data format (JSON, XML, Yaml, etc).