similar to: [LLVMdev] 3.4 build failure from lldb

Hi, I build llvm+clang+lldb 3.7 successfully on centos7, and lldb -p PID works pretty well. However when I tried lldb -c corefile executable_bin, lldb itself core dumpped. Attached the following core info which is debugged by gdb: [root at dn-cn-controller-4fbd4 data1]# lldb -c a.corefile /usr/local/myproject/bin/cnode *(lldb) target create "/usr/local/myproject/bin/cnode" --core

So, when performing expression evaluation, lldb trips over an assert in clang/lib/AST/RecordLayoutBuilder because ExternalFieldOffsets doesn't contain a FieldDecl that updateExternalFieldOffset expected. I found that the assert occurs when both static and non-static member variables are present. For instance, with the following, the lldb command 'expr my_test.length()' does not

FYI, this turned out to be an error of omission in LLDB in SymbolFileDWARF, because the case of a non-defining external (i.e. a static member variable) wasn't being handled with a variable lookup to dig up the location. I'll put a patch together for lldb-commits, - Ashok From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Thirumurthi, Ashok

On Wed, Feb 23, 2011 at 01:43:35PM -0800, Dan Gohman wrote: > On Feb 22, 2011, at 6:46 PM, Chris Lattner wrote: > > This leads to a number of problems in LLVM: > > - we have a bunch of duplication > > - we have confusion about what a triple is (normalized or not) > > - no good way to tell if a triple is normalized > > - no good, centralized way to reason about

On Feb 23, 2011, at 3:24 PM, Stephen Wilson wrote: >> >> On the other hand, if "Byte Order" makes sense to include, should >> other parts of targetdata be included? Pointer size seems the next >> most desirable -- endianness and pointer size would be sufficient for >> many elf tools, for example. However, the other parts of >> targetdata could

> But where is the flat set? Maybe I can debug and check what is going on. The MCInstrDesc are in a table in lib/Target/PowerPC/PPCGenInstrInfo.inc of your build directory. > Some additional information: > > MCInst opcode: 0x7cb > Decode Index: 0x1e I had assumed this would have dissembled to '// Inst #234 = BC' which does have the branch flag set, but I think that

The `isBranch` flag is already set on the branch instructions. Furthermore, we do use the `isBranch()` query in a few places in the PPC back end, so this does work. Perhaps there's something specific about the lldb usage? Is it somehow possible that the `isBranch()` query is called on the wrong instruction? Would you be able to provide a test case that reproduces the issue? On Thu, Nov 30,

Hi, While dogfooding our lldb based IDE on Linux, I am seeing a lot of variable evaluation errors related to DW_TAG_member which prevents us from release the IDE. Can anyone help to confirm if they are known issues? If not, any information you need to troubleshoot this issue? Here is one example: (lldb) fr v *error: biggrep_master_server_async 0x10b9a91a: DW_TAG_member '_M_pod_data'

If you're going to use clang built binaries with lldb, you'll want to pass -fstandalone-debug - this is the default on platforms where lldb is the primary debugger (Darwin and freebsd) Not sure if that is the problem you are seeing, but will be a problem sooner or later On Mar 26, 2016 4:16 PM, "Jeffrey Tan via llvm-dev" <llvm-dev at lists.llvm.org> wrote: > Hi, >

Thanks David. I meant to send to lldb maillist, but glad to hear response here. Our binary is built from gcc: String dump of section '.comment': [ 1] GCC: (GNU) 4.9.x-google 20150123 (prerelease) Is there any similar flags we should use? By doing "strings -a [binary] | grep -i gcc", I found the following flags being used: GNU C++ 4.9.x-google 20150123 (prerelease)

On Sat, Mar 26, 2016 at 11:31 PM, Jeffrey Tan <jeffrey.fudan at gmail.com> wrote: > Thanks David. I meant to send to lldb maillist, but glad to hear response > here. > > Our binary is built from gcc: > String dump of section '.comment': > [ 1] GCC: (GNU) 4.9.x-google 20150123 (prerelease) > > Is there any similar flags we should use? > If it's

On Feb 22, 2011, at 6:46 PM, Chris Lattner wrote: > This leads to a number of problems in LLVM: > - we have a bunch of duplication > - we have confusion about what a triple is (normalized or not) > - no good way to tell if a triple is normalized > - no good, centralized way to reason about which triples are allowed and valid > - the MC assembler has to link in the entire X86

Dear, I would like build lldb on linux but i fail, (thanks for any help): 1/ get llvm3.0 2/ get clang.3.0 and put it into llvm/tools/ 3/ checkout lldb rev 144573 put into llvm/tools/ build --------------------------------- $ ./configure --disable-assertions \ --enable-debug-runtime \ --enable-jit \ --enable-libffi \ --enable-shared $ make REQUIRES_RTTI=1 VERBOSE=1

Hi All, There is recently a discussion on the LLDB list about how to deal with targets, and our current mismash of llvm::Triple and the various subclasses of TargetSubtarget leave a lot to be desired. GNU target triples are really important as input devices to the compiler (users want to specify them) but they aren't detailed enough for internal clients. Anyway, in short, I think that we

Some doxygen annotations are attached to the wrong entry, which can be misleading. This patch fixes the mistake everywhere I could find it. --- include/llvm/InstrTypes.h | 54 ++++++++++++++++++++-------------------- include/llvm/MC/MCDirectives.h | 42 +++++++++++++++--------------- include/llvm/Pass.h | 10 +++--- 3 files changed, 53 insertions(+), 53 deletions(-) diff

Attached is a working patch set for llvm to be able to emit arm64 (currently as triple aarch64-apple-ios) mach-o object files, in case someone is interested. I'm not sure if the llvm maintainers want the patch given the previous message that there's going to be an official patch set from apple to support this, but here is mine. What works (tested on an iPhone 5S): * objc strings,

In llvm/lib/MC/MachObjectWriter.cpp, there's assert(OS.tell() - Start == is64Bit() ? macho::Header64Size : macho::Header32Size); Shouldn't that be assert(OS.tell() - Start == (is64Bit() ? macho::Header64Size : macho::Header32Size)); MSVC emits a warning, and it doesn't seem right to compare a boolean with a difference of two integers. Csaba -- GCS a+

Dear ladies and gentlemen, I have recently installed the latest version of R (4.3.3) for windows. Now I have the following problems with mutated vowels like ?, ?, etc. Here is an example: If I type the command: Dir <- "C/Users/macho/Documents/_LVn/Experimentelle ?bungen" in the R console there is no problem. However, if I put the same command into a source file (e.g. Test.r) and call

Hi! I think llvm-mc did amazing work and I'm stunned ;). - So I start reading source-code and making notes. To my question: At which state is the disassembly for PEcoff or ELF? I read the blog (http://blog.llvm.org/2010/04/intro-to-llvm-mc-project.html): """ The MC components have been designed to be object file independent (e.g. work for MachO, ELF, PE-COFF etc) but only have

So, for this test case: extern "C" void shouldBeUnconditional(); extern "C" void shouldBeConditional(); extern "C" void otherCall(); void testFn(bool Bool1, bool Bool2) { Bool1 |= Bool2; shouldBeUnconditional(); if (Bool1) shouldBeConditional(); if (Bool2) { otherCall(); if (Bool1) otherCall(); } } MSVC generates this buggy asm: $ cl -c