search for: archspec

...alizeLLVM::InitializeLLVM()’: /home/sam/src/llvm/tools/lldb/source/Expression/ClangExpressionParser.cpp:199:13: error: ‘DisablePrettyStackTrace’ is not a member of ‘llvm’ [ 84%] Building CXX object tools/lldb/source/Core/CMakeFiles/lldbCore.dir/Baton.cpp.o /home/sam/src/llvm/tools/lldb/source/Core/ArchSpec.cpp:157:41: error: ‘CPUTypeARM’ is not a member of ‘llvm::MachO’ /home/sam/src/llvm/tools/lldb/source/Core/ArchSpec.cpp:158:41: error: ‘CPUTypeARM’ is not a member of ‘llvm::MachO’ /home/sam/src/llvm/tools/lldb/source/Core/ArchSpec.cpp:159:41: error: ‘CPUTypeARM’ is not a member of ‘llvm::MachO’ /h...

...5700 (LWP 64) 0x00007f81c9ed46d5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 2 Thread 0x7f81ce580740 (LWP 59) 0x00007f81c9ed46d5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 * 1 Thread 0x7f81c3f94700 (LWP 65) 0x00007f81cbe00630 in lldb_private::ArchSpec::GetMachine() const () from /opt/dependency/tools/bin/../lib64/liblldb.so.3.7 *(gdb) bt* #0 0x00007f81cbe00630 in lldb_private::ArchSpec::GetMachine() const () from /opt/dependency/tools/bin/../lib64/liblldb.so.3.7 #1 0x00007f81cc20458f in RegisterContextPOSIX_x86::RegisterContextPOSIX_x86(...

.... Another possible reason is to allow otherwise > architecture-independent strings to encode an endianness. However, > that's not a concept that LLVM currently has. And without more > targetdata parts, it's not obvious how useful it is by itself. In LLDB we currently have an "ArchSpec" class that llvm::TargetSpec could eventually replace. Currently, one of the main applications for having a "byte order" bit in LLDB is to allow sensible construction of default specifications: for example ARM is almost always little endian, but there are board configurations where...

...ould allow making endianness be a predicate instead of being an encoded part of the data structure. The *only* downside I see to that is that we couldn't form a TargetSpec that *just* contains an endianness, at least without introducing a "unknown-64bit" and "unknown-32bit" archspec, which seems silly. -Chris

...usage, but it’s obtaining the > disassembler as it is. > > When lldb tries to instantiate the disassembler, it checks many > information in > > llvm/tools/lldb/source/Plugins/Disassembler/llvm/DisassemblerLLVMC.cpp:1014 > = > > “DisassemblerLLVMC::DisassemblerLLVMC(const ArchSpec &arch, const char > *flavor_string)”, > > which I couldn’t find if it’s doing correct. Is there a place that > explains the “flavor” and > > “features_str” variables used at DisassemblerLLVMC.cpp:1163 > > (“newLLVMCDisassembler(triple_str, cpu, features_str.c_str(), flav...

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,

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

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