[llvm] r202486 - [docs] Add a big section with details about how to go about acquiring

[Hal Finkel]

----- Original Message -----
> From: "Eric Christopher" <echristo at gmail.com>
> To: "Hal Finkel" <hfinkel at anl.gov>
> Cc: "Chandler Carruth" <chandlerc at gmail.com>, "Commit Messages and Patches for LLVM" <llvm-commits at cs.uiuc.edu>
> Sent: Tuesday, March 4, 2014 4:14:59 PM
> Subject: Re: [llvm] r202486 - [docs] Add a big section with details about how to go about acquiring
> 
> On Tue, Mar 4, 2014 at 2:09 PM, Hal Finkel <hfinkel at anl.gov> wrote:
> > ----- Original Message -----
> >> From: "Chandler Carruth" <chandlerc at gmail.com>
> >> To: "Hal Finkel" <hfinkel at anl.gov>
> >> Cc: "Chandler Carruth" <chandlerc at gmail.com>, "Commit Messages and
> >> Patches for LLVM" <llvm-commits at cs.uiuc.edu>
> >> Sent: Tuesday, March 4, 2014 3:14:26 PM
> >> Subject: Re: [llvm] r202486 - [docs] Add a big section with
> >> details about how to go about acquiring
> >>
> >>
> >>
> >>
> >>
> >> On Tue, Mar 4, 2014 at 1:06 PM, Hal Finkel < hfinkel at anl.gov >
> >> wrote:
> >>
> >>
> >>
> >>
> >> > Because Clang/LLVM 3.4 don't provide an installed-out-of-the-box
> >> > well
> >> > tested standard library implementation for Linux, and as
> >> > mentioned
> >> > at the start of the comment section, this is largely a Linux
> >> > section.
> >>
> >> So the issue is just that libc++'s build system is wacky? I've
> >> never
> >> built libc++ with cmake -- preferring instead my patched version
> >> of
> >> the 'buildit' script ;) -- , but is the cmake setup from 3.4
> >> usable?
> >> Or is testing on Linux the major issue?
> >> The build setup with cmake is getting better, but not perfect yet.
> >> The testing on linux is also an issue. I think these are *all*
> >> show
> >> stopper problems for recommending this as the one stop host
> >> toolchain on Linux.
> >
> > Fair enough.
> >
> > Different issue, having done this (used gcc 4.8), is it worth
> > warning people that, unless they also upgrade their gdb, they'll
> > have trouble debugging the resulting binaries?
> >
> 
> Eh? What problems have you run in to there?

When I compiled LLVM with gcc 4.8.0 (without optimizations), and attempted to debug llc using the system gdb (version 7.4-2012.04-0ubuntu2.1), while the line table information seemed fine, I was unable to print the values of any local variables. I installed gdb 7.7, and with the same binaries, everything worked as expected. This is on an x86_64 host.

For example, with the system gdb:

#4  0x0000000000e67ded in llvm::PPCTargetLowering::DAGCombineTruncBoolExt(llvm::SDNode*, llvm::TargetLowering::DAGCombinerInfo&) const () at /src/llvm-trunk/lib/Target/PowerPC/PPCISelLowering.cpp:8114
8114	  assert(PPCSubTarget.useCRBits() &&
(gdb) p N->dump()
No symbol "N" in current context.

with gdb 7.7:

#4  0x0000000000e67ded in llvm::PPCTargetLowering::DAGCombineTruncBoolExt (this=0x29233d8, N=0x2975a20, DCI=...)
    at /src/llvm-trunk/lib/Target/PowerPC/PPCISelLowering.cpp:8114
8114	  assert(PPCSubTarget.useCRBits() &&
(gdb) call N->dump()
0x2975a20: v8i1 = setcc 0x2975420, 0x2975920, 0x2975520 [ORD=4]

 -Hal

> 
> -eric
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory