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:gclay...@apple.com] Sent: Friday, August 26, 2016 11:08 AM To: Ted Woodward <ted.woodw...@codeaurora.org> Cc: Howard Hellyer <hhell...@uk.ibm.com>; Todd Fiala <todd.fi...@gmail.com>; LLDB <lldb-dev@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@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:hhell...@uk.ibm.com] > Sent: Friday, August 26, 2016 8:39 AM > To: Todd Fiala <todd.fi...@gmail.com> > Cc: LLDB <lldb-dev@lists.llvm.org>; Ted Woodward > <ted.woodw...@codeaurora.org> > Subject: Re: [lldb-dev] Linux ELF header e_ident[EI_OSABI] value > > Todd Fiala <todd.fi...@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@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
