Linux: "doesn't contain the architecture x86_64"

I just rebuilt lldb on a linux machine (usually I'm on mac), and I'm
seeing this (for all programs on the machine). Has anybody seen this
before (before I dive into debugging)?

usr/bin/lldb /bin/ls

error: '/bin/ls' doesn't contain the architecture x86_64

Keno

Hi Keno,

Which Linux distribution and bitness (64/32) are you on?

I’ve seen similar behavior when platforms or object files inappropriately identify (or mis-identify) which files they can do something with.

This is on

64-bit Ubuntu 12.04.4 LTS (GNU/Linux 3.2.0-61-generic x86_64)

I started a bisect. I can confirm that this worked on Feb 28 (I chose that arbitrarily for the start of the bisect), so it must have broken since.

Can you send me your /bin/ls? (Direct send to me, might need to .tar.gz it). I can see if we’re identifying it correctly at the object file level.

With recent platform additions, we may have borked something.

Have you tried running the tests on your end? There are a few tests in test/functionalities/object-file that will verify if we’re parsing the object files correctly.

FWIW - I just tried this on Ubuntu 14.04 with a build at r213575 (earlier today):

tfiala@tfiala2:/mnt/ssd/work/macosx.sync/mbp-git/build-debug$ bin/lldb
(lldb) file /bin/ls
Current executable set to '/bin/ls' (x86_64).
(lldb) run
Process 20313 launching
Process 20313 launched: '/bin/ls' (x86_64)
Process 20313 stopped
* thread #1: tid = 20313, 0x00007fdaa88d42d0, name = 'ls', stop reason = trace
    frame #0: 0x00007fdaa88d42d0
error: No such process
2014-06-29-23_22_22  CMakeFiles               examples          rules.ninja
2014-06-29-23_22_40  cmake_install.cmake      include           share
bin                  CPackConfig.cmake        lib               test
build.ninja          CPackSourceConfig.cmake  lldb-test-traces  tools
cmake                docs                     LLVMBuild.cmake   unittests
CMakeCache.txt       DummyConfigureOutput     projects          utils
Process 20313 exited with status = 0 (0x00000000) 
(lldb)

That seemed to work, but is Ubuntu 14.04 vs. 12.04.

-Todd

Hi again,

Keno - what revision of lldb are you synched to? I recall seeing some platform changes go in today, I think after my last sync/build.

Thanks,
Todd

According to bisect, the culprit is:

Author: Todd Fiala <todd.fiala@gmail.com>

Fix ObjectFileELF to determine architectures independent of host.

Previously ObjectFileELF was simplifying and assuming the object file it was
looking at was the same as the host architecture/triple. This would break
attempts to run, say, lldb on MacOSX against lldb-gdbserver on Linux since
the MacOSX lldb would say that the linux elf file was really an Apple MacOSX
architecture. Chaos would ensue.

This change allows the elf file to parse ELF notes for Linux, FreeBSD and
NetBSD, and determine the OS appropriately from them. It also initializes
the OS type from the ELF header OSABI if it is set (which it is for FreeBSD
but not for Linux).

Added a test with freebsd and linux images that verify that
‘(lldb) image list -t -A’ prints out the expected architecture for each.

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@211907 91177308-0d34-0410-b5e6-96231b3b80d8

Haha ok. That’s me :slight_smile:

Looks like something about Ubuntu 12.04 is different on Ubuntu 14.04.

I’ll install a 12.04 and see what’s broken and fix it.

BTW - the /bin/ls seems to detect fine on Ubuntu 14.04 and MacOSX. Interesting…

I’ll look at this today.

-Todd

(And thanks for tracking that down.)

Hey Keno,

I just posted more info on the bug here:
http://llvm.org/bugs/show_bug.cgi?id=20400

The details of the setup are there. The short version: I set up an Ubuntu 12.04 x86_64 system, built lldb with gcc-4.9.1, could not repro. You can see my install instructions there to see if you differ significantly somewhere.

It would be great if you can repro that setup and see if you still hit the issue.

Thanks!

-Todd

The differences that I can see are that I built lldb with clang 3.4 and Makefiles rather than gcc and cmake also a Debug+Asserts build rather than just a debug build.

Ok. The Debug+Asserts I typically use but didn’t for this scenario. I don’t think that’ll be the diff.

I’ve rarely found a clang-based build that worked well for Ubuntu 12.04 - that was the reason I was on gcc until recently when we finally updated to Ubuntu 14.04 over here. (And now I use clang almost exclusively for lldb builds since debug builds are faster with it for my environments). That might be it.

I will do a configure/make build over here to see if that makes a difference in the output.

-Todd