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

[Todd Fiala via lldb-dev]

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.

On Tue, Aug 23, 2016 at 6:49 AM, Howard Hellyer via lldb-dev <
lldb-dev at lists.llvm.org> wrote:

> "Ted Woodward" <ted.woodward at codeaurora.org> wrote on 22/08/2016 21:03:02:
>
> > We don't want to make ELFOSABI_NONE mean Linux. ELFOSABI_NONE is
> > historically ELFOSABI_SYSV, and used by a lot of things. So not all
> > core files identified as ELFOSABI_NONE are Linux.
>
> I agree that other OS's may use it or have used it in the past but I don't
> know if any of those are supported by LLDB at the moment. (If they are then
> they probably have the same problem.)
> It's definitely annoying that Linux doesn't seem to use the value that
> makes sense but as it stands the case statement in ArchSpec.cpp won't
> actually hit its Linux case at the moment (which is quite confusing). I
> guess I just didn't want to bypass the trivial fix if it didn't affect
> anything else in practise.
>
> > ObjectFileELF::RefineModuleDetailsFromNote looks for a note with
> > type NT_FILE, then looks in that for a path that starts with "/lib/
> > x86_64-linux-gnu". If it finds that, it will set the core file's OS
> > to Linux. Teaching that to speak the Linux dialect you're interested
> > in is probably the right way to go.
>
> The problem with that is the Redhat cores I have to hand (from various
> test machines) have the FILE note section but the library files are in
> /usr/lib (32 bit) or  /usr/lib64 (64 bit). That looks sufficiently generic
> that identifying the OS as Linux based on those would probably have the
> same effect as using ELFOSABI_NONE. The paths LLDB currently knows about
> (and match my Ubuntu box) are /lib/i386-linux-gnu and
> /lib/x86_64-linux-gnu. Since they have "linux" in them they a much safer
> bet.
>
> I also have some other cores taken from Ubuntu running in a containerised
> environment where the library path in the core is actually the full path
> from outside the container, so it only ends in /lib/x86_64-linux-gnu, the
> full path is /packages/rootfs_cflinuxfs2/[very long UID
> value]/rootfs/lib/x86_64-linux-gnu/[library].so. (This may be a container
> problem though, I'm not sure if using core dumps to discover this path is
> actually a bug.)
> *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
>
>


-- 
-Todd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20160825/1c30ad5e/attachment.html>