New user self-registration is disabled due to spam. For an account please email bugs-admin@lists.llvm.org with your e-mail address and full name.

Bug 20400 - Ubuntu & Debian failing to find architecture for native binaries (and many other test failures)
Summary: Ubuntu & Debian failing to find architecture for native binaries (and many ot...
Status: RESOLVED FIXED
Alias: None
Product: lldb
Classification: Unclassified
Component: All Bugs (show other bugs)
Version: unspecified
Hardware: PC Linux
: P normal
Assignee: Chaoren Lin
URL:
Keywords:
: 20768 (view as bug list)
Depends on:
Blocks:
 
Reported: 2014-07-22 11:44 PDT by Todd Fiala
Modified: 2015-03-04 02:27 PST (History)
9 users (show)

See Also:
Fixed By Commit(s):


Attachments
Test results run from lldb built with make and gcc 4.9.1 on Ubuntu 12.04 x86_64 (20.13 KB, application/x-bzip2)
2014-07-23 15:25 PDT, Todd Fiala
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Todd Fiala 2014-07-22 11:44:49 PDT
Reported by Keno Fischer.

See thread here:
http://lists.cs.uiuc.edu/pipermail/lldb-dev/2014-July/004578.html
Comment 1 Todd Fiala 2014-07-22 11:45:22 PDT
I'm looking into this now.  Setting up an Ubuntu 12.04 VM.
Comment 2 Todd Fiala 2014-07-22 14:09:28 PDT
I just set up a clean Ubuntu 12.04 x86_64 vm.

I have not been able to reproduce this.

Steps:
1. Install Ubuntu 12.04 x86_64 VM.

2. Install these packages:
sudo apt-get install build-essential gcc-multilib git libedit-dev ncurses-dev libmpc-dev libmpfr-dev python-dev swig

3. Install gcc 4.9.1 source, build and install locally.

4. Do a git clone on the latest ninja source, build and install on path somewhere.

5. Grab the latest cmake 3.0.0 source, build and install locally.

6. Make sure ninja, cmake, and gcc/g++ 4.9.1 show up on path.  gcc/g++ must come on path before system gcc.

7. Grab latest llvm/clang/lldb code.  I'm synched to this revision on all 3:
r213671

8. create a directory alongside llvm for building:
mkdir build
cd build

9. configure with cmake
cmake -GNinja -DCMAKE_CXX_COMPILER=g++ -DCMAKE_C_COMPILER=gcc -DCMAKE_BUILD_TYPE=Debug ../llvm

10. Build
time ninja

11. Run the reported failure case
tfiala@ubuntu:~/lldb/git/build$ bin/lldb /bin/ls
Current executable set to '/bin/ls' (x86_64).
(lldb) run
Process 2282 launching
Process 2282 launched: '/bin/ls' (x86_64)
Process 2282 stopped
* thread #1: tid = 2282, 0x00007f0f0cea26b0, name = 'ls', stop reason = trace
    frame #0: 0x00007f0f0cea26b0
error: No such process
bin             cmake_install.cmake      examples         rules.ninja  utils
build.ninja     CPackConfig.cmake        include          share
cmake           CPackSourceConfig.cmake  lib              test
CMakeCache.txt  docs                     LLVMBuild.cmake  tools
CMakeFiles      DummyConfigureOutput     projects         unittests
Process 2282 exited with status = 0 (0x00000000) 
(lldb) 


Keno - can you have a look and see if you might be doing something different?  Also, can you try to use the steps above and see if that unblocks you?

Thanks!  I'm not able to repro this from the info you've given me.  I'll leave this open until I hear back that you are able to repeat this fix.

-Todd
Comment 3 Todd Fiala 2014-07-22 14:13:33 PDT
One more step to the setup:

Addition for step 6:
You'll want to make sure that LD_LIBRARY_PATH contains the gcc-4.9.1 install directory's lib64 directory on it.

For me, I installed gcc into /usr/local/gcc/gcc-4.9.1, with a link to that in /usr/local/gcc/gcc-current.

I then have my LD_LIBRARY_PATH set to:
/usr/local/gcc/gcc-current/lib64

-Todd
Comment 4 Todd Fiala 2014-07-23 12:44:18 PDT
I'm on Keno's machine now.

First update:
clean sync (source in ~/lldb/git/llvm) + clang-3.4-1ubuntu3~precise1 build using configure/make yields a boatload of test failures with 'make -C tools/lldb/test'.

I think this may be mirroring my frustration and eventual dropping of clang on Ubuntu 12.04 as a build compiler for lldb.

I'm going to put a gcc 4.9.1 on the box and see if this addresses the issues.  We should be getting a mostly clean test pass on this machine.  I'll wait until I can verify/refute that before I try anything else.
Comment 5 Todd Fiala 2014-07-23 15:24:43 PDT
For my next step, I went ahead and did the following:

1. Downloaded gcc-4.9.1 source.

2. Built that, installed with --prefix=$HOME/local.

3. Set LD_LIBRARY_PATH to $HOME/local/lib64:$LD_LIBRARY_PATH.

4. Added $HOME/local/bin to the front of the path: export PATH=$HOME/local/bin:$PATH

5. Made a new build directory and configured:
cd /my/llvm/dir
cd ..
mkdir build-make-gcc
CC=gcc CXX=g++ ../llvm/configure --install=$HOME/installs/install-make-gcc
make

6. Built
make -j60

7. Ran tests
make -C tools/lldb/test 2>&1 | tee test-results-gcc.log

8. Witnessed just one test failure.  In this case, it is one of my tests, that assumes all x86_64 linux boxes have AVX registers.  This box doesn't, so it doesn't pass the check for it.

9. Zip up test results.

bzip2 test-results-gcc.log
I'll attach this next.

10. Ran the initial test against this exe.

tfiala@julia:~/lldb/git/build-make-gcc$ Debug+Asserts/bin/lldb
(lldb) file /bin/ls
Current executable set to '/bin/ls' (x86_64).
(lldb) image list -A -t
[  0] x86_64 x86_64-unknown-linux
(lldb) exit

tfiala@julia:~/lldb/git/build-make-gcc$ Debug+Asserts/bin/lldb /bin/ls
Current executable set to '/bin/ls' (x86_64).
(lldb) run
Process 63745 launching
Process 63745 launched: '/bin/ls' (x86_64)
Process 63745 stopped
* thread #1: tid = 63745, 0x00007fc90ca276b0, name = 'ls', stop reason = trace
    frame #0: 0x00007fc90ca276b0
error: No such process
bindings       examples		Makefile.common		  tools
cmake	       include		Makefile.config		  unittests
config.log     lib		Makefile.llvmbuild	  utils
config.status  LLVMBuild.cmake	projects
Debug+Asserts  llvm.spec	test
docs	       Makefile		test-results-gcc.log.bz2
Process 63745 exited with status = 0 (0x00000000) 
(lldb) exit
tfiala@julia:~/lldb/git/build-make-gcc$ 

====

So - all this seems to point to the issue is choosing to use clang on Ubuntu 12.04 x86_64 LTS.  This build path just seems to be broken in this environment.

Here is the exact compiler info for clang:

tfiala@julia:~/lldb/git/build-make-gcc$ clang -v
Ubuntu clang version 3.4-1ubuntu3~precise1 (tags/RELEASE_34/final) (based on LLVM 3.4)
Target: x86_64-pc-linux-gnu
Thread model: posix
Found candidate GCC installation: /usr/bin/../lib/gcc/i686-linux-gnu/4.6
Found candidate GCC installation: /usr/bin/../lib/gcc/i686-linux-gnu/4.6.4
Found candidate GCC installation: /usr/bin/../lib/gcc/i686-linux-gnu/4.8
Found candidate GCC installation: /usr/bin/../lib/gcc/i686-linux-gnu/4.8.1
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.6
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.6.4
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8.1
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.6
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.6.4
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.8
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.8.1
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6.4
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8.1
Selected GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8
Comment 6 Todd Fiala 2014-07-23 15:25:31 PDT
Created attachment 12817 [details]
Test results run from lldb built with make and gcc 4.9.1 on Ubuntu 12.04 x86_64
Comment 7 Todd Fiala 2014-07-23 15:29:56 PDT
I'm taking myself off the bug.  The scope of the issue appears to be:
lldb doesn't create a functional lldb build with this clang version (or any that I know of) on Ubuntu 12.04.

The workarounds that I see are:

* Use gcc 4.8+ to build.  I've used 4.8.1, 4.8.2 and 4.9.1 successfully on Ubuntu 12.04 x86_64.

* Use a newer Ubuntu.  I've used Ubuntu 13.10 x86_64 and 14.04 x86_64 successfully with gcc and with clang to build lldb.

* Debug clang on Ubuntu 12.04 x86_64 and figure out what is going wrong with lldb in that scenario.

* Maybe try to bring in a newer clang that maybe fixes the issue.
Comment 8 Azat Khuzhin 2014-10-19 16:32:56 PDT
I got the same error with debian jessie (though it is not cleanly installed, it was upgraded from previous releases):

$ lldb-3.5 /bin/ls; echo
error: '/bin/ls' doesn't contain the architecture x86_64
(lldb)

$ apt-cache show lldb-3.5 | fgrep Version
Version: 1:3.5-4

Also if I build lldb from sources (3.6) it is ok, *but* if I build lldb from debian sources (3.5) than it is not works correctly:
$ apt-get source lldb-3.5
$ cd *
$ dpkg-buildpackage -rfakeroot -j50 -us -uc
...
gcc version 4.9.1 (Debian 4.9.1-16)
...

I've debug this for a while, and next function could be the problem:
- lldb_private::ArchSpec::IsExactMatch()
(gdb) bt
#0  lldb_private::ArchSpec::IsExactMatch (this=0x5bd468, rhs=...) at ArchSpec.cpp:791
#1  0x00007ffff690698f in lldb_private::Module::SetArchitecture (this=<optimized out>, new_arch=...) at Module.cpp:1593
#2  0x00007ffff6bbcd0d in lldb_private::ObjectFile::SetModulesArchitecture (this=<optimized out>, new_arch=...) at ObjectFile.cpp:317
#3  0x00007ffff6aebc93 in ObjectFileELF::CreateInstance (module_sp=<error reading variable: Cannot access memory at address 0x20>, 
    data_sp=<error reading variable: Cannot access memory at address 0x20>, data_offset=0, file=0x5bd4b0, file_offset=0, length=114032)
    at ObjectFileELF.cpp:327
#4  0x00007ffff6bbda62 in lldb_private::ObjectFile::FindPlugin (module_sp=std::shared_ptr (count 3, weak 2) 0x5bd420, file=0x5bd4b0, 
    file_offset=3, file_size=0, data_sp=std::shared_ptr (count 2, weak 0) 0x5bd850, data_offset=@0x7fffffff5ed8: 0)
    at ObjectFile.cpp:128
#5  0x00007ffff6903b86 in lldb_private::Module::GetObjectFile (this=0x5bd420) at Module.cpp:1299
#6  0x00007ffff690e49c in lldb_private::ModuleList::GetSharedModule (module_spec=..., 
    module_sp=std::shared_ptr (count 3, weak 2) 0x5bd420, module_search_paths_ptr=<optimized out>, old_module_sp_ptr=0x0, 
    did_create_ptr=<optimized out>, always_create=false) at ModuleList.cpp:969
#7  0x00007ffff767ac9b in lldb_private::PlatformLinux::ResolveExecutable (this=0x7fffffff7210, exe_file=..., exe_arch=..., 
    exe_module_sp=std::shared_ptr (count 3, weak 2) 0x5bd420, module_search_paths_ptr=0x5ba1d8) at PlatformLinux.cpp:213
#8  0x00007ffff6c2acbc in lldb_private::TargetList::CreateTarget (this=0x7b3010, debugger=..., user_exe_path=<optimized out>, 
    specified_arch=..., get_dependent_files=<optimized out>, platform_sp=std::shared_ptr (count 5, weak 0) 0x411200, 
    target_sp=std::shared_ptr (empty) 0x0) at TargetList.cpp:281
#9  0x00007ffff6c2bbd7 in lldb_private::TargetList::CreateTarget (this=0x7fffffff3d50, debugger=..., user_exe_path=0x5bcca8 "/bin/ls", 
    triple_cstr=0x7fffffffa7a0 "", get_dependent_files=216, platform_options=0x4f7378, target_sp=std::shared_ptr (empty) 0x0)
    at TargetList.cpp:190
#10 0x00007ffff6891c50 in CommandObjectTargetCreate::DoExecute (this=0x4f7200, command=..., result=...) at CommandObjectTarget.cpp:318
#11 0x00007ffff69f5e55 in lldb_private::CommandObjectParsed::Execute (this=0x4f7200, args_string=<optimized out>, result=...)
    at CommandObject.cpp:1031
#12 0x00007ffff69f299c in lldb_private::CommandInterpreter::HandleCommand (this=0x7a82c0, command_line=<optimized out>, 
    lazy_add_to_history=<optimized out>, result=..., override_context=<optimized out>, repeat_on_empty_command=<optimized out>, 
    no_context_switching=false) at CommandInterpreter.cpp:1875
#13 0x00007ffff67bf80a in lldb::SBCommandInterpreter::HandleCommand (this=0x7fffffffbd70, 
    command_line=0x7fffffffc2c0 "target create  \"/bin/ls\"", result=..., add_to_history=3) at SBCommandInterpreter.cpp:142
#14 0x00007ffff67c8577 in lldb::SBDebugger::HandleCommand (this=0x5bd468, command=0x7fffffff3d50 "H\321[") at SBDebugger.cpp:429
#15 0x00000000004049a0 in Driver::MainLoop() ()
#16 0x0000000000403b9e in main ()

(gdb) p *this
$73 = {
  m_triple = {
    Data = "x86_64-pc-linux", 
    Arch = llvm::Triple::x86_64, 
    SubArch = llvm::Triple::NoSubArch, 
    Vendor = llvm::Triple::PC, 
    OS = llvm::Triple::Linux, 
    Environment = llvm::Triple::UnknownEnvironment, 
    ObjectFormat = llvm::Triple::ELF
  }, 
  m_core = lldb_private::ArchSpec::eCore_x86_64_x86_64, 
  m_byte_order = lldb::eByteOrderLittle, 
  m_distribution_id = {
    m_string = 0x0
  }
}
(gdb) p rhs
$74 = (const lldb_private::ArchSpec &) @0x7fffffff3d50: {
  m_triple = {
    Data = "x86_64-unknown-linux", 
    Arch = llvm::Triple::x86_64, 
    SubArch = llvm::Triple::NoSubArch, 
    Vendor = llvm::Triple::UnknownVendor, 
    OS = llvm::Triple::Linux, 
    Environment = llvm::Triple::UnknownEnvironment, 
    ObjectFormat = llvm::Triple::ELF
  }, 
  m_core = lldb_private::ArchSpec::eCore_x86_64_x86_64, 
  m_byte_order = lldb::eByteOrderLittle, 
  m_distribution_id = {
    m_string = 0x0
  }
}

As you can see "x86_64-pc-linux" VS "x86_64-unknown-linux".

Also before digging this, I started from lldb_private::ArchSpec::SetTriple() and noticed that m_triple.Data has difference values:
- 3.6 (lldb_private::HostInfoBase::ComputeHostArchitectureSupport):
(gdb) p arch_name
$41 = {
  Data = 0x951fe8 "x86_64-unknown-linux-gnu", 
  Length = 6
}
- 3.5 (lldb_private::Host::GetArchitecture):
(gdb) p m_triple.getArchName()
$79 = {
  Data = 0x4118a8 "x86_64-pc-linux-gnu", 
  Length = 6
}

Also this could explain one comment in source/Plugins/Platform/Linux/PlatformLinux.cpp:342
// TODO find out why exe_module_sp might be NULL

Anyway I don't think that this is really matters now, since 3.6 is ok.
But I have one question does lldb_private::ArchSpec::IsExactMatch() really must be so strict?
Or ArchSpec::IsCompatibleMatch() could be used there instead?
Comment 9 llvm-bugzilla 2014-12-12 14:59:59 PST
This also affects Ubuntu 14.10 (see also: https://bugs.launchpad.net/ubuntu/+source/llvm-toolchain-3.5/+bug/1385876)

$ file /bin/ls
/bin/ls: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=9508b95ba96ff7e8535b452acb1313b08aa23c26, stripped
$ apt-cache show lldb-3.5 | fgrep Version
Version: 1:3.5-4ubuntu2
$ lldb-3.5 --version
lldb version 3.5.0 ( revision )
$ lldb-3.5 /bin/ls
error: '/bin/ls' doesn't contain the architecture x86_64
(lldb) quit
Comment 10 Sylvestre Ledru 2015-02-16 11:51:12 PST
*** Bug 20768 has been marked as a duplicate of this bug. ***
Comment 11 Vince Harron 2015-02-17 10:01:18 PST
Chaoren, can you see if you can repro this on your workstation with i386 target binaries with ToT?  If so, please fix.  If not, it's probably only a bug inolder versions.  Please reassign to lldb-commits.
Comment 12 Yury 2015-02-18 03:00:00 PST
I have just reproduced this issue on Ubuntu 14.10 32bit running in virtual box. I compiled using gcc 4.9.1. Used git pull to get latest from source repositories:
llvm - https://llvm.org/svn/llvm-project/llvm/trunk@229638
clang - https://llvm.org/svn/llvm-project/cfe/trunk@229639
lldb - https://llvm.org/svn/llvm-project/lldb/trunk@229592

Here is the copy&paste from my terminal window:
==========================================================
yury@VBoxUbuntu32:~/projects/llvm/build/Release+Asserts/bin$ ./lldb ~/projects/test/a.out 
(lldb) target create "/home/yury/projects/test/a.out"
error: a.out failed to load objfile for /home/yury/projects/test/a.out
error: '/home/yury/projects/test/a.out' doesn't contain the architecture i386
(lldb) q
==========================================================
Comment 13 Chaoren Lin 2015-02-26 00:27:35 PST
Configuring cmake with LLVM_DEFAULT_TARGET_TRIPLE=i386-linux-gnu seems to fix this issue on 32 bit builds. The default of i686-pc-linux-gnu is compatible but not necessarily identical to the inferior binaries, so I think it's better to apply Azat's solution of using ArchSpec::IsCompatibleMatch() instead to prevent this issue from resurfacing on other platforms in the future.
Comment 14 Sylvestre Ledru 2015-02-26 03:20:32 PST
I don't think the bug can be closed now.
This should be managed by the cmake and the autotools.

For now, building lldb on a recent ubuntu will fail and it is quite hard to debug.
Moreover, the bug is also affecting 64 bit linux.
Comment 15 Sylvestre Ledru 2015-02-26 04:02:16 PST
Pending patch:
http://reviews.llvm.org/D7897
Comment 16 Chaoren Lin 2015-02-26 11:54:47 PST
The bug never manifested in my 64 bit build. The patch should fix both in theory, but could someone please help me verify that it fixes the 64 bit build as well?
Comment 17 Sylvestre Ledru 2015-02-27 04:16:16 PST
Merged here:
http://reviews.llvm.org/differential/diff/20795/
Comment 18 Yury 2015-02-27 20:13:47 PST
64 bit build has always worked for me too. So I can't help with the testing.
It's 32 bit that I couldn't make work. I have tried the above patch on my Ubuntu 14.10 32bit and it worked. Thank you, guys!
Comment 19 Yury 2015-03-04 01:12:31 PST
After trying to work with lldb on my Ubuntu 14.10 32bit I can see many issues:
- Watchpoint catch makes lldb assert in POSIXThread.cpp:560
- backtrace doesn't show anything except "* frame #0 0xb7fdbc7c" when debugging a simple multi threaded application.

I am not sure if the issues are related to the patch published in this ticket. I know watchpoints work fine in lldb on my 64bit Ubuntu.
Comment 20 Sylvestre Ledru 2015-03-04 02:27:52 PST
(In reply to comment #19)
> I am not sure if the issues are related to the patch published in this
> ticket. I know watchpoints work fine in lldb on my 64bit Ubuntu.

That is unlikely, please report a new bug.