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

[Eric Christopher]

On Tue, Mar 4, 2014 at 2:23 PM, Hal Finkel <hfinkel at anl.gov> wrote:
> ----- 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]
>

Awesome. Well, ok, I guess I'd suggest 7.6 or newer myself.

-eric