[Lldb-commits] [PATCH] Update ObjectFileELF to detect ELF triple based on ELF notes and the ELF header.

[Todd Fiala]

> error: Unable to find process plug-in for core file '/data/emaste/src/llvm/build/sleep.core'
> Looking into it...

Hey Ed,

I'm not sure how you were doing the entire setup above, but here's what I need to do on the MacOSX side when debugging a Linux exe (over llgs):

# Enable some logging
log enable -T -f /tmp/xcode_gdbremote.log gdb-remote packets process
log enable -T -f /tmp/xcode_module.log lldb module

# Syncing over files from my Mac box to my Linux box
platform shell rsync -av /Users/tfiala/play/loop_test tfiala2.mtv.corp.google.com:play

# This obviously only works in the llgs branch for now, but: fire up llgs
platform shell ssh tfiala2.mtv.corp.google.com 'lldb/macosx.sync/git-s02-macpro/build-debug/bin/lldb-gdbserver --log-file /tmp/llgs.log --lldb-command "log enable -T -f /tmp/llgs.log lldb process host" --lldb-command "log enable -T -f /tmp/llgs_packets.log gdb-remote packets" tfiala-macpro.mtv.corp.google.com:1234' &

# This may be the critical part you're missing - se the platform for whatever ELF object files you were trying to load.
platform select --sysroot tfiala2.mtv.corp.google.com remote-linux

# And then create the target for the given architecture
target create --arch x86_64-pc-linux /Users/tfiala/play/loop_test/bin/linux-x86_64/main --remote-file /usr/local/google/home/tfiala/play/loop_test/bin/linux-x86_64/main

# GDB remote in.
gdb-remote tfiala2.mtv.corp.google.com:1234

# Set a breakpoint.
b main.cpp:10

# And go.
run


Those LLDB commands represent how I'm able to successfully run a Linux x86_64 Linux ELF (2.6.26 ABI IIRC, from Ubuntu 12.04 LTS) on the llgs side and somewhat play with it on the MacOSX side.

It's possible there are little bits that the llgs branch has in it that are making this more possible.  I did not try running from FreeBSD to a Linux llgs side.

These ObjectFileELF changes were necessary to get to the point where I could do a "(lldb) file /some/elf/from/other/platform" to show up right with an "(lldb) image list -t -f" command.

================
Comment at: source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp:1075
@@ -983,1 +1074,3 @@
+        // Process FreeBSD ELF notes.
+        if (note.n_namesz == LLDB_NT_OWNER_FREEBSD_LENGTH && note.n_name == LLDB_NT_OWNER_FREEBSD)
         {
----------------
Ed Maste wrote:
> n_name is a std::string and the length (namesz) should be handled in the note parser so you should be able to just do note.n_name == LLDB_NT_OWNER_FREEBSD, no?
> 
> Also for the purpose of this parsing we'll generally have just one case in each of the switch statements - maybe it'd be more concise to just check note.n_type == LLDB_NT_FREEBSD_ABI_TAG in the if() as well?
> Also for the purpose of this parsing we'll generally have just one case in each of the switch statements - maybe it'd be more concise to just check note.n_type == LLDB_NT_FREEBSD_ABI_TAG in the if() as well?

Sure, I think it's only GNU that is using multiple ones.   I can change that for the others.

> n_name is a std::string and the length (namesz) should be handled in the note parser so you should be able to just do note.n_name == LLDB_NT_OWNER_FREEBSD, no?

Yes, but I was looking to avoid the string compare if the length wasn't equal.  That would stop needing to get the string length of the constant.  Overall this is likely very minor compared to the cost of scanning the entire contents though, so probably worth the simplification.

http://reviews.llvm.org/D4302