Re: [lldb-dev] Linux ELF header e_ident[EI_OSABI] value
On 22 August 2016 at 16:03, Ted Woodward via lldb-dev wrote: > > 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. Indeed, and that's true for binaries and libraries too. For one specific example, FreeBSD/arm64 binaries have ELFOSABI_NONE (as specified by the AArch64 ABI). LLDB's OS detection from binaries and core files is (or was?) rather awkward and I hope we can clean it up, but treating ELFOSABI_NONE as Linux is a nonstarter. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] LLDB Evolution: Next Phase
On 19 August 2016 at 17:10, Kate Stone via lldb-dev wrote: > > Sept 5th Trunk closes for commits while reformatting takes place and is > validated before re-opening trunk. This is fine with me. As for validation, from my perspective I want to make sure the FreeBSD build-only buildbot is green: http://lab.llvm.org:8011/builders/lldb-amd64-ninja-freebsd11 and I will build and run the test suite locally. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Linux ELF header e_ident[EI_OSABI] value
> I would change it so that the "os" doesn't get set to anything when > it detects this in the core file. When an OS is not specified, the > llvm::Triple will return OSUnknown as the enumeration value for the > OS _and_ the llvm::StringRef value will return an empty string. This > is known in LLDB term as a "unspecified unknown". This means the > triple will be "x86_64-*-". An unspecified unknown is a > wildcard. Any plugins that are trying to load a core file should > watch for this and use it accordingly. > > So the answer is not "treat ELF files with ELFOSABI_NONE set as > Linux", but "treat ELF files with ELFOSABI_NONE set as *". Please > submit a patch that implements this when you get the chance. Let me > know if you have any questions. I think that's the current behaviour in ArchSpec.cpp. Setting it deliberately to UnknownOS prevents the code later on from refining it any further from the notes section of the core file. (Unless you meant somewhere else in which case I'll take a look.) 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
Re: [lldb-dev] Linux ELF header e_ident[EI_OSABI] value
"Ted Woodward" 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
Re: [lldb-dev] LLDB Evolution: Next Phase
Should we consider adding git hyper-blame to llvm and recommending its usage? https://commondatastorage.googleapis.com/chrome-infra-docs/flat/depot_tools/docs/html/git-hyper-blame.html On Tue, Aug 23, 2016 at 6:44 AM Ed Maste via lldb-dev < lldb-dev@lists.llvm.org> wrote: > On 19 August 2016 at 17:10, Kate Stone via lldb-dev > wrote: > > > > Sept 5th Trunk closes for commits while reformatting takes place and is > > validated before re-opening trunk. > > This is fine with me. > > As for validation, from my perspective I want to make sure the FreeBSD > build-only buildbot is green: > http://lab.llvm.org:8011/builders/lldb-amd64-ninja-freebsd11 > and I will build and run the test suite locally. > ___ > 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
Re: [lldb-dev] LLDB Evolution: Next Phase
On 23 August 2016 at 11:55, Zachary Turner wrote: > > Should we consider adding git hyper-blame to llvm and recommending its usage? Nifty, I hadn't encountered git hyper-blame before. Thanks Zach. If I understand correctly all we need to do is add a `.git-blame-ignore-revs` file to the lldb root directory which lists git revision IDs to ignore, correct? And that's something we'd do after the reformatting commit goes in (and it would not affect any tool other than git hyper-blame). If so it sounds good to me. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] LLDB Evolution: Next Phase
Pretty much, yea. On Tue, Aug 23, 2016 at 12:24 PM Ed Maste wrote: > On 23 August 2016 at 11:55, Zachary Turner wrote: > > > > Should we consider adding git hyper-blame to llvm and recommending its > usage? > > Nifty, I hadn't encountered git hyper-blame before. Thanks Zach. > > If I understand correctly all we need to do is add a > `.git-blame-ignore-revs` file to the lldb root directory which lists > git revision IDs to ignore, correct? And that's something we'd do > after the reformatting commit goes in (and it would not affect any > tool other than git hyper-blame). If so it sounds good to me. > ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
