> On Aug 30, 2016, at 7:33 AM, Howard Hellyer via lldb-dev 
> <lldb-dev@lists.llvm.org> wrote:
> 
> "Ted Woodward" <ted.woodw...@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).


_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Reply via email to