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@lists.llvm.org> wrote: > "Ted Woodward" <ted.woodw...@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@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > > -- -Todd
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
