Ubuntu & Debian failing to find architecture for native binaries (and many other test failures)

Quuxplusone commented 10 years ago


Bugzilla Link	PR20400
Status	RESOLVED FIXED
Importance	P normal
Reported by	Todd Fiala (tfiala@google.com)
Reported on	2014-07-22 11:44:49 -0700
Last modified on	2015-03-04 02:27:52 -0800
Version	unspecified
Hardware	PC Linux
CC	a3at.mail@gmail.com, emaste@freebsd.org, keno@alumni.harvard.edu, lldb-dev@lists.llvm.org, llvm-bugzilla@ca.sh13.net, qbvui+9baubb2cfhobc@sharklasers.com, sylvestre@debian.org, vince@nethacker.com, yury.meshkov@yahoo.com
Fixed by commit(s)
Attachments	`test-results-gcc.log.bz2` (20614 bytes, application/x-bzip2)
Blocks
Blocked by
See also	http://bugs.debian.org/778562, http://bugs.debian.org/777616, https://launchpad.net/bugs/1385876

Reported by Keno Fischer.

See thread here:
http://lists.cs.uiuc.edu/pipermail/lldb-dev/2014-July/004578.html

Quuxplusone commented 10 years ago

I'm looking into this now. Setting up an Ubuntu 12.04 VM.

Quuxplusone commented 10 years ago

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

Quuxplusone commented 10 years ago

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

Quuxplusone commented 10 years ago

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.

Quuxplusone commented 10 years ago

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

Quuxplusone commented 10 years ago

Attached test-results-gcc.log.bz2 (20614 bytes, application/x-bzip2): Test results run from lldb built with make and gcc 4.9.1 on Ubuntu 12.04 x86_64

Quuxplusone commented 10 years ago

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.

Quuxplusone commented 10 years ago

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?