similar to: [lldb] Error - Failed to launch or debug process

Hello again, It's been nearly six months since my first email, so it's a good time to recap what has been done here so far. I am happy to report that stages 1-3 (i.e. producer/consumer in llvm and integration with lldb) of my original plan are now complete with one caveat. The caveat is that the .debug_names section is presently not a full drop-in replacement for the .apple_*** sections.

> On Jun 13, 2018, at 11:18 AM, Jonas Devlieghere via lldb-dev <lldb-dev at lists.llvm.org> wrote: > > Hi Pavel, > >> On Jun 13, 2018, at 6:56 AM, Pavel Labath <labath at google.com <mailto:labath at google.com>> wrote: >> >> Hello again, >> >> It's been nearly six months since my first email, so it's a good time >> to

Hi, I notice you're running a 32-bit program; are you also on a 32-bit host, or do you have a 64-bit OS installed? We don't generally test on 32-bit hosts, so it's possible you found a new bug. In addition, there are some known bugs with debugging 32-bit programs (even on 64-bit hosts) which will we hopefully be resolving soon. Nonetheless, I was unable to reproduce the behaviour you

It is interesting that the stop reason on the thread that stopped is "trace". That's what you would expect returning from the single-step to step over the breakpoint. But it looks like we got a signal while single-stepping, but the stop reason was misreported by somebody. Jim > On Apr 17, 2018, at 6:00 AM, Pavel Labath via lldb-dev <lldb-dev at lists.llvm.org> wrote:

Sorry if asked before. I'm new to LLDB, try to use it according to the lldb project site. I write some very simple code like: #include <stdio.h> int main(int argc, char **argv) { int counter = 0; while ( counter < 10 ) counter++; printf("counter: %d\n", counter); return 0; } and the session like: $ clang -g main.c $ lldb-3.4 a.out (lldb)

[+lldb-dev] Hello Steve, thanks for the report. The fact that you see the rendezvous breakpoint being hit many times is not surprising. We get those every time the library is loaded (we need that to load relevant debug info and set potential breakpoints). However, they should generally not be surfaced to the user (unless you have the stop-on-sharedlibrary-events setting set, which you

On Wed, 17 Jan 2018 17:13:36 +0100, Pavel Labath via lldb-dev wrote: > so I'm writing this email to see if there's anyone > else interested in this topic, and to try to synchronize our efforts. I am sure interested in DWARF-5 .debug_names. I wrote its producer+consumer for GDB (but not producing/using DW_IDX_DIE_offset as GDB cannot use it). > 1. add .debug_names support to

Are there any plans to implement SDL2 support for libtheora? I've searched the internet for patches and I couldn't really find anything. I modified some of the files in libtheora-1.1.1 to use the SDL2 library instead of the SDL library. I'm pretty sure I did it wrong though. It compiles successfully. I was hoping someone else had done something similarly so I could compare my

This is Greg's area, he'll be able to answer in detail how the name chopper gets used. IIRC it chops demangled names, so it is indirectly a client of the demangler, but it doesn't use the demangler to do this directly. Name lookup is done by finding all the base name matches, then comparing the context. We don't do a very good job of doing fuzzy full name matches - for instance

Hi all, I’m working on improving the debugging experience for C++20 coroutines when compiled with LLVM/Clang, and I could use some help from someone who understands debug information and DWARF (knowledge of coroutines isn't necessary, I don't think). Specifically, I’m trying to improve lldb’s behavior when showing variables in the current stack frame, when that frame corresponds to a

On 04/03/2020 21:45, Jim Ingham via llvm-dev wrote: > As you have seen, different machine architectures do different things after hitting a trap. On x86_64, the trap instruction is executed, and then you stop, so the PC is left after the stop. On arm64, when execution halts the pc is still pointing at the trap instruction. > > I don't think lldb should be in the business of telling

Hi, I’d try the lldb-dev mailing list instead of the LLVM one. Best, — Mehdi > On Dec 26, 2016, at 11:14 PM, Toon Claes via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi, > > Reposting this message, because I never received a response. > > On the emacs-devel mailing list the question was raised to add support > the emacs for lldb. > Someone replied

On Wed, Nov 14, 2012 at 11:18 PM, Jeffrey Walton <noloader at gmail.com> wrote: > Hi All, > > Please forgive me if this is the wrong group. I did not see a > llvm-user group (). The User Guide also lacked a topic > (http://llvm.org/docs/userguides.html#userguides). > > I am an Xcode user. I want to set a breakpoint on malloc_error_break > all the time (it makes no

Hi, Reposting this message, because I never received a response. On the emacs-devel mailing list the question was raised to add support the emacs for lldb. Someone replied stating lldb does support MI, and emacs also support MI, so this should work out-of-the-box. So I took a moment to try it out. I started lldb like this: lldb-mi --interpreter=mi hello (btw, `hello` is written in swift)

I didn't get to work on this more last week, but I'll look at incorporating that suggestion. The other question of course is how to do this in LLDB. Right, now what I'm doing is going through and adjusting the load address of every leaf in the section tree. That basically works and gets me backtraces with the correct function names and the ability to set breakpoints at functions in

On Wed, 27 Jun 2018 at 01:14, Zachary Turner via lldb-dev <lldb-dev at lists.llvm.org> wrote: > > Yes that’s what I’ve been thinking about as well. > > One thing I’ve been giving a lot of thought to is whether to serialize the handling of trace events. I want to balance the “this is a library and you should be able to get it to work for you no matter what your use case is”

Hello lldb developers, I am running into a problem with lldb on Linux. I am currently running llvm 6.0.0. I have an executable that dynamically loads a large number of shared libraries at runtime. These are explicitly loaded via dlopen (they are specified in a configuration file), and after loading a few (typically a dozen or so, but the number varies) lldb will halt during dlopen. If I

I'm getting a segfault when I call `SDL_Init( SDL_INIT_VIDEO )` within the MCJIT.  If I compile the same program to an EXE I don't have a problem. Are there any general restrictions, or known issues, with loading a library like SDL2 via the MCJIT?  (LLVM-3.8 still) The stack trace, from GDB, is below. I noticed the error actually happens deep inside a transitively loaded GL drive module,

We don't currently apply any relocations (that I know of) for debug info in LLDB. > On Jun 2, 2014, at 12:35 PM, Keno Fischer <kfischer at college.harvard.edu> wrote: > > I think I'm getting closer. The debug_info section is being relocated correctly (I think): > > 0x00000000: Compile Unit: length = 0x00000045 version = 0x0003 abbr_offset = 0x00000000 addr_size =

Yep, as others have mentioned - using a linker-generated gdb-index is super helpful (10s for my machine to start debugging an unoptimized clang, set a breakpoint at llvm::StringRef::StringRef and run until that breakpoint is hit, as opposed to 1m26s without an index) That's also with/without split DWARF too, but I suspect most of the benefit is in the index there. Split DWARF might save you