On Tue, Dec 20, 2016 at 5:05 PM, Teresa Johnson <tejohnson at google.com> wrote:> Hi Carsten, > > A few responses below, but first, can you get the link command for > lldb.so.3.9.1? Last time it was the lldb.so build that was using > ld.bfd with the gold plugin which was exposing this issue.Where would I find it in an otherwise already terminated process?> On Tue, Dec 20, 2016 at 5:49 AM, Carsten Mattner <carstenmattner at gmail.com>> No problem - I assumed no news was good news! Thanks for the > explicit feedback though!Sure, but it's important, and I've had my experience with never hearing back even after asking for confirmation of success. Same as drive-by patch drops.> > - Should I avoid any and all CFLAGS, CXXFLAGS, CPPFLAGS, LDFLAGS > > in favor of passing these exclusively as cmake's > > -Dsomething_something=<FLAGS>? Linux distros usually have an > > environment with CFLAGS etc. and use that building packages and > > this didn't interfere in the past in my builds, but I'm open to > > avoid this by unsetting any such variables first. > > > The problem I've had in the past setting *FLAGS on the cmake command > line is that sometimes the configure fails because it uses those > flags in various configuration checking compiles. So typically I > hand edit the resulting CMakeCache.txt if I want to pass specific > options to the build. Note that there are various flavors of e.g. > LINKER_FLAGS that get passed to different types of links though > (SHARED vs EXE etc). I haven't tried setting CFLAGS etc env > variables before kicking off the ninja build to pass args.I set the variables before running cmake and I didn't expect for it to be re-considered when running ninja, but it would of course more closely mirror make's behavior if it does/dit.> > - Is there a configuration in the CI matrix that builds all > > of LLVM with ThinLTO so that I can be reasonably sure > > any error is most likely local to my environment or > > because of operator (silly me) faults? > > > There is an lld based ThinLTO buildbot. I've been really remiss in > not setting up a gold based ThinLTO bot...note to self to get that > done asap! But the existing lld will be head not 3.9.Please have it build everything that's buildable in the llvm tree.> > I also pass these in LDFLAGS but they're not visible > > in the error trace below: > > -Wl,-plugin-opt,-function-sections \ > > -Wl,-plugin-opt,-data-sections \ > > > Hmm, looks like LDFLAGS doesn't work for passing to the resulting link line? > Try setting in the CMakeCache.txt as described above.It's a mystery (aka haven't traced/debugged CMake).> > Any idea why lldb-argdumper would fail to link reproducably? > > See suggestion above about looking at lldb.so.3.9.1 link line. Let's > make sure that looks ok first.Thanks.
On Tue, Dec 20, 2016 at 11:05 AM, Carsten Mattner <carstenmattner at gmail.com> wrote:> On Tue, Dec 20, 2016 at 5:05 PM, Teresa Johnson <tejohnson at google.com> > wrote: > > Hi Carsten, > > > > A few responses below, but first, can you get the link command for > > lldb.so.3.9.1? Last time it was the lldb.so build that was using > > ld.bfd with the gold plugin which was exposing this issue. > > Where would I find it in an otherwise already terminated process? >I think you can get this via "ninja -t commands bin/lldb-argdumper" (this will give you a lot of output, all of the compilation commands used to build that target). Or redo the build with -v to be sure. Teresa> > On Tue, Dec 20, 2016 at 5:49 AM, Carsten Mattner < > carstenmattner at gmail.com> > > > No problem - I assumed no news was good news! Thanks for the > > explicit feedback though! > > Sure, but it's important, and I've had my experience with never > hearing back even after asking for confirmation of success. Same as > drive-by patch drops. > > > > - Should I avoid any and all CFLAGS, CXXFLAGS, CPPFLAGS, LDFLAGS > > > in favor of passing these exclusively as cmake's > > > -Dsomething_something=<FLAGS>? Linux distros usually have an > > > environment with CFLAGS etc. and use that building packages and > > > this didn't interfere in the past in my builds, but I'm open to > > > avoid this by unsetting any such variables first. > > > > > > The problem I've had in the past setting *FLAGS on the cmake command > > line is that sometimes the configure fails because it uses those > > flags in various configuration checking compiles. So typically I > > hand edit the resulting CMakeCache.txt if I want to pass specific > > options to the build. Note that there are various flavors of e.g. > > LINKER_FLAGS that get passed to different types of links though > > (SHARED vs EXE etc). I haven't tried setting CFLAGS etc env > > variables before kicking off the ninja build to pass args. > > I set the variables before running cmake and I didn't expect for it to > be re-considered when running ninja, but it would of course more > closely mirror make's behavior if it does/dit. > > > > - Is there a configuration in the CI matrix that builds all > > > of LLVM with ThinLTO so that I can be reasonably sure > > > any error is most likely local to my environment or > > > because of operator (silly me) faults? > > > > > > There is an lld based ThinLTO buildbot. I've been really remiss in > > not setting up a gold based ThinLTO bot...note to self to get that > > done asap! But the existing lld will be head not 3.9. > > Please have it build everything that's buildable in the llvm tree. > > > > I also pass these in LDFLAGS but they're not visible > > > in the error trace below: > > > -Wl,-plugin-opt,-function-sections \ > > > -Wl,-plugin-opt,-data-sections \ > > > > > > Hmm, looks like LDFLAGS doesn't work for passing to the resulting link > line? > > Try setting in the CMakeCache.txt as described above. > > It's a mystery (aka haven't traced/debugged CMake). > > > > Any idea why lldb-argdumper would fail to link reproducably? > > > > See suggestion above about looking at lldb.so.3.9.1 link line. Let's > > make sure that looks ok first. > > Thanks. >-- Teresa Johnson | Software Engineer | tejohnson at google.com | 408-460-2413 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161221/1be8bd28/attachment.html>
On Wed, Dec 21, 2016 at 2:55 PM, Teresa Johnson <tejohnson at google.com> wrote:> I think you can get this via "ninja -t commands bin/lldb-argdumper" > (this will give you a lot of output, all of the compilation commands > used to build that target). Or redo the build with -v to be sure.Unfortunately the old build tree is gone for space reclaim reasons. Sorry, I'll make sure to not nuke it the next time. I guess I thought the detailed error message would be enough. I didn't build again, but I did configure with the settings posted yesterday, and there's a warning which I'm unsure how to interpret and if it's a concern: --- CMake Warning at tools/lldb/cmake/modules/LLDBConfig.cmake:409 (message): You appear to be linking to libstdc++ version lesser than 4.9 without exceptions enabled. These versions of the library have an issue, which causes occasional lldb crashes. See <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59656> for details. Possible courses of action are: - use libstdc++ version 4.9 or newer - use libc++ (via LLVM_ENABLE_LIBCXX) - enable exceptions (via LLVM_ENABLE_EH) - ignore this warning and accept occasional instability Call Stack (most recent call first): tools/lldb/CMakeLists.txt:4 (include) --- libstdc++ is 6.2.1 so the CMake check seems wrong. This prompted me to use -libstd=libc++ and -DLLVM_ENABLE_LIBCXX=ON, but for some reason Arch Linux packages llvm and clang in version 3.9.0 but libc++ in 3.8.0, so I skipped it. Unless the above libstdc++ warning is a problem, I will build and report back when done.