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

Ted Woodward via lldb-dev lldb-dev at lists.llvm.org
Fri Aug 26 09:40:51 PDT 2016


After the core file is loaded in ProcessElfCore::DoLoadCore, the logic under "target create" will merge the ArchSpec of the target and the core, replacing the "unknown" OS in the core ArchSpec with "linux" from the target ArchSpec.

Howard, are you loading a target executable, or just the core?

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project


-----Original Message-----
From: Greg Clayton [mailto:gclayton at apple.com] 
Sent: Friday, August 26, 2016 11:08 AM
To: Ted Woodward <ted.woodward at codeaurora.org>
Cc: Howard Hellyer <HHELLYER at uk.ibm.com>; Todd Fiala <todd.fiala at gmail.com>; LLDB <lldb-dev at lists.llvm.org>
Subject: Re: [lldb-dev] Linux ELF header e_ident[EI_OSABI] value

It is ok for a core file to not pledge allegiance to an OS, it is ok for the OS to be set to "*" or any OS. Linux core files are useless without the main executable anyway so these two things should used together to do the right thing. When creating the core files you use:

lldb::ProcessSP
ProcessElfCore::CreateInstance (lldb::TargetSP target_sp, lldb::ListenerSP listener_sp, const FileSpec *crash_file) {

So you are handed the target. You can get the executable file from the target and also check the target's architecture or the main executable's architecture. There shouldn't be a problem figuring this out right?

Greg

> On Aug 26, 2016, at 8:17 AM, Ted Woodward via lldb-dev <lldb-dev at lists.llvm.org> wrote:
> 
> 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.
>  
> Doesn’t lldb get the correct OS from the target when you load them together?
>  
> --
> Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
> a Linux Foundation Collaborative Project
>  
> From: Howard Hellyer [mailto:HHELLYER at uk.ibm.com]
> Sent: Friday, August 26, 2016 8:39 AM
> To: Todd Fiala <todd.fiala at gmail.com>
> Cc: LLDB <lldb-dev at lists.llvm.org>; Ted Woodward 
> <ted.woodward at codeaurora.org>
> Subject: Re: [lldb-dev] Linux ELF header e_ident[EI_OSABI] value
>  
> Todd Fiala <todd.fiala at gmail.com> wrote on 25/08/2016 20:42:31:
> 
> > FWIW, I've taken a few whacks at getting Linux detected better over 
> > the last few years, and haven't yet found a reliable way to detect 
> > it from quite a few samples of cores from a number of different 
> > systems.  We can spend more time looking into it, but that stone has 
> > been turned over several times.
> 
> I spent quite a lot of time looking at the output of readelf too. I was kind of hoping Linux was the only platform not using it's OSABI value, which would have worked. 
> 
> The only other thing I thought of suggesting was having the ELFOSABI_NONE case ifdef'd so that lldb defaults to the platform that it was built for - on the assumption that you are probably opening a core from the machine you are on. (So on Linux ELFOSABI_NONE would mean Linux, on FreeBSD it would mean FreeBSD.) That would have meant lldb behaved differently depending on where it was compiled which seems wrong and would introduce awkward to debug behaviour so I ended up talking myself out of it.
> 
> Howard Hellyer
> IBM Runtime Technologies, IBM Systems
> 
> 
> 
> 
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number 741598. 
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 
> 3AU _______________________________________________
> lldb-dev mailing list
> lldb-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev




More information about the lldb-dev mailing list