Re: [lldb-dev] I had to back out r313904, it causes lldb to assert on startup if you have a .lldbinit file

Thank you Jim! I'm at cppcon and I won't be able to work on it until Monday, but I can help with a code review if you're planning to take a stab at it. I was hoping we can avoid dealing with reentrancy but I was wrong. For handling reentrancy I was briefly considering either maintaining a full blo

Re: [lldb-dev] Unifying ctor+Clear() inits into in-class initializers?

> > void Clear() { > this->~ClassName(); > new (this) ClassName(); > } My 2c: this is clever, but not without downsides: 1. It may do more than intended (it will destroy all members / bases) 2. It forces construction and 'reset' to be exactly the same, which is

[lldb-dev] Object identities in the LLDB's C++ API

LLDB's C++ API deals with SBxxx objects, most of which are PIMPL-style wrappers around an opaque pointer to the internal implementation. These SBxxx objects act as handles and are passed/returned by value, which is generally convenient, except for the situations where one would need to keep track o

Re: [lldb-dev] Object identities in the LLDB's C++ API

efit of being additive (we can graft it on with minimal risk of breaking existing stuff), although it still seems nice to have consistent identity semantics for the SBxxx types. On Wed, Dec 13, 2017 at 12:40 PM, Greg Clayton wrote: > > On Dec 13, 2017, at 11:44 AM, Leonard Mosescu via lldb-dev &

[lldb-dev] postmortem debugging (core/minidump) & modules

I'm looking at how the LLDB minidump reader creates the list of modules: void ProcessMinidump::ReadModuleList() { ... const auto file_spec = FileSpec(name.getValue(), true); ModuleSpec module_spec = file_spec; Status error; lldb::ModuleSP module_sp = GetTarget().GetSharedModule(module_spec, &err

Re: [lldb-dev] postmortem debugging (core/minidump) & modules

rstand this one, core & minidumps are currently not using any of the the remote debugging machinery, right? Are you suggesting changing that? On Tue, Apr 10, 2018 at 11:56 AM, Greg Clayton wrote: > > > On Apr 10, 2018, at 11:32 AM, Leonard Mosescu via lldb-dev < > lldb-dev@

Re: [lldb-dev] postmortem debugging (core/minidump) & modules

t; and see the platform was selected for > you. Since the Minidump is specific to Windows, it should select the right > platform for you. If it doesn't we will need to fix that. > > Does the mini dump format have the UUID or some sort of checksum of the > file in it? > >

Re: [lldb-dev] postmortem debugging (core/minidump) & modules

inary knows how to tell LLDB what target triple it is. PECOFF >> files will always map to the host windows platform or remote-windows when >> not on a Windows host computer. If you say "file a.out" and give it a >> PECOFF file, just do "target list" and see the pla

Re: [lldb-dev] Proposal: Using LLD in tests

> > the PDB tests under lit/SymbolFile/PDB need a linker to produce the program > database With this proposal, would we preserve any coverage for MSVC produced debug information? On Thu, Apr 19, 2018 at 9:47 AM, Greg Clayton via lldb-dev < lldb-dev@lists.llvm.org> wrote: > > > > On Apr 19, 201

Re: [lldb-dev] Proposal: Using LLD in tests

> > we have some good coverage there that our PDBs are "as good as" Microsoft > PDBs, and in the future we have plans to have a debug info test suite that > tests LLD-generated PDBs with Microsoft debuggers. > Thanks Zach. What I was asking is exactly the other half of this equation. Testing LLDB

[lldb-dev] LLDB tests getting stuck on GDBRemoteCommunicationClientTest.GetMemoryRegionInfo ?

I just did a clean build (debug) on Linux, and I noticed that the LLDB tests seem to consistently get stuck: * -- Testing: 1002 tests, 12 threads -- * * 99% [

Re: [lldb-dev] LLDB tests getting stuck on GDBRemoteCommunicationClientTest.GetMemoryRegionInfo ?

hing obvious though. On Fri, Apr 27, 2018 at 2:11 AM, Pavel Labath wrote: > On Thu, 26 Apr 2018 at 22:58, Leonard Mosescu via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > > I just did a clean build (debug) on Linux, and I noticed t

Re: [lldb-dev] LLDB tests getting stuck on GDBRemoteCommunicationClientTest.GetMemoryRegionInfo ?

ead (unless my source tree > is in a broken state). > > This is the fist time I looked at this part of the code so it's possible I > missed something obvious though. > > > > On Fri, Apr 27, 2018 at 2:11 AM, Pavel Labath wrote: > >&

Re: [lldb-dev] LLDB tests getting stuck on GDBRemoteCommunicationClientTest.GetMemoryRegionInfo ?

7ee25 > > ProcessGdbRemoteTests`operator(__closure=0x56464d5636a8) at > > GDBRemoteCommunicationClientTest.cpp:339 > > > >> It seems that the client is attempting extra communication which is > not > > modeled in the mock HandlePacket(), so it simply

[lldb-dev] Making changes to the SB API

What is the governing philosophy around making changes to the SB API? The "SB API Coding Rules " page establishes the practices on how to avoid introducing accidental incompatibility, but what about the cases where there's a case for intentionally maki

Re: [lldb-dev] Making changes to the SB API

Thanks. I wasn't sure how well C++ overloading works with SWIG, that's definitely a more ergonomic solution. On Fri, Jun 8, 2018 at 1:16 PM, Greg Clayton wrote: > > > On Jun 8, 2018, at 12:54 PM, Leonard Mosescu via lldb-dev < > lldb-dev@lists.llvm.org> wrot

Re: [lldb-dev] Do we have any infrastructure for creating mini dump files from a loaded process or from a core file?

The minidump format is more or less documented in MSDN . That being said, it's not exactly trivial to produce a good minidump. Crashpad has a native & cross-platfo

Re: [lldb-dev] Do we have any infrastructure for creating mini dump files from a loaded process or from a core file?

> > That being said, it's not exactly trivial to produce a good minidump. > Crashpad has a > native & cross-platform minidump writer, that's what I'd start with. > Addendum: I realized after sending the email that if the goal is to convert core

Re: [lldb-dev] Do we have any infrastructure for creating mini dump files from a loaded process or from a core file?

> > What about the case where you already have a Unix core file and you aren't > in a debugger but just want to convert it? Just curious, would a small Python script using the LLDB SB API satisfy this requirement? We could move all the code for consuming and producing Windows minidumps > and Un

Re: [lldb-dev] Do we have any infrastructure for creating mini dump files from a loaded process or from a core file?

the program as a macOS flavor Crashlog file. It's in > examples/Python/crashlog.py. My guess is he had something similar to that > in mind, but writing a mini dump file instead. > > Jim > > > > On Jun 13, 2018, at 3:20 PM, Leonard Mosescu via lldb-dev < > lldb-dev

Re: [lldb-dev] LLDB does not support the default 8 byte build ID generated by LLD

I had made a local attempt at making UUID support arbitrary sizes (part of extracting the UUIDs from minidumps ). I ended up abandoning the UUID changes since there were not strictly in scope and I also had the same uneasy feeling about how flexible do we really wan

Re: [lldb-dev] LLDB does not support the default 8 byte build ID generated by LLD

Here's a snapshot of the old changes I had: https://reviews.llvm.org/D48381 (hopefully it helps a bit but caveat emptor: this is a quick merge from an old patch, so it's for illustrative purposes only) On Wed, Jun 20, 2018 at 10:26 AM, Pavel Labath wrote: > From the looks of it, the patch stall

Re: [lldb-dev] LLDB does not support the default 8 byte build ID generated by LLD

ID that is filled with zeroes, otherwise many matches will occur that we > don't want > > - 32 bit GNU debug info CRCs from ELF notes could be filled in as 4 byte > UUIDs > > - Comparing two UUIDs can start with the length field first the if they > match proceed

Re: [lldb-dev] LLDB does not support the default 8 byte build ID generated by LLD

debug info CRCs from ELF notes could be filled in as 4 >> byte UUIDs >> > - Comparing two UUIDs can start with the length field first the if they >> match proceed to compare the bytes (which is hopefully what is already >> happening) >> > >> > >> &g

[lldb-dev] The mysterious case of unsupported DW_FORMs

I'm sharing some notes on a strange LLDB issue I hit locally, in case anyone else hits the same problem. The symptoms are symbols unexpectedly not working for some modules and/or warning messages complaining about "unsupported DW_FORMs", ex: *warning: (x86_64) /lib/x86_64-linux-gnu/libz.so.1.2.8 u

Re: [lldb-dev] The mysterious case of unsupported DW_FORMs

Thanks Paul! I have a fix for the LLDB handling of compressed sections in an upcoming change (together with improved logging). The email was mostly in case some other poor soul hit the same problem (until I get a chance to commit the fixes) *(*) none of the tools bothered to make a note that the s

Re: [lldb-dev] LLDB nightly benchmarks and flamegraphs

+1, really nice. Any plans to add wall clock time? (I see you're using perf, right?) On Fri, Aug 3, 2018 at 3:59 PM, Zachary Turner via lldb-dev < lldb-dev@lists.llvm.org> wrote: > This is really cool. Maybe you could do it for all of LLVM too? It would > be nice if, instead of cycling through

[lldb-dev] Handling of the ELF files missing build-ids?

Greg, Mark, Looking at the code, LLDB falls back to a full file crc32 to create the module UUID if the ELF build-id is missing. This works, in the sense that the generated UUID does indeed identify the module. But there are a few problems with this approach: 1. First, runtime performance: a full

Re: [lldb-dev] [Bug 38453] New: lldb: new (unit)test failures in 7.0

This should be fixed by rL338949 On Mon, Aug 6, 2018 at 12:27 AM, via lldb-dev wrote: > Bug ID 38453 > Summary lldb: new (unit)test failures in 7.0 > Product lldb > Version 7.0 > Hardware PC > OS Linux > Status NEW > Severity enhancement > Priority P

Re: [lldb-dev] Handling of the ELF files missing build-ids?

> > I am fine with all the above except some reservations about case C. No > need to calculate something if it isn't useful. For case C it should be > fine to never match as if a file has a UUID to begin with it typically > isn't something that gets stripped in a stripped binary. So we should > eit

Re: [lldb-dev] The mysterious case of unsupported DW_FORMs

Great. Thanks for the reminder, here's the llvm-dwarfdump bug On Wed, Aug 8, 2018 at 7:11 AM, wrote: > I posted this suggestion on dwarf-discuss, where I would hope various tool > maintainers are watching. > > > > The maintainer of dwarfdump says t

Re: [lldb-dev] [GSoC] Re-implement lldb-mi on top of the LLDB public API

Nice to see great progress in this area! On Sun, Aug 12, 2018 at 2:49 PM, Александр Поляков via lldb-dev < lldb-dev@lists.llvm.org> wrote: > Hi LLVM folks, > > During this summer I was working on re-implementing of lldb-mi to > correctly use LLDB public API. You are welcome to read my final repor

Re: [lldb-dev] [GSoC] Re-implement lldb-mi on top of the LLDB public API

Can you please list the missing MI commands? This would be very valuable to both future contributors and also to the users of the LLDB MI. Thanks! On Mon, Aug 13, 2018 at 11:28 AM, Александр Поляков wrote: > Thank you, Leonard, > I'm going to keep contributing to LLVM, so I think this is not the

Re: [lldb-dev] [RFC] LLDB Reproducers

Sounds like a fantastic idea. How would this work when the behavior of the debugee process is non-deterministic? On Wed, Sep 19, 2018 at 6:50 AM, Jonas Devlieghere via lldb-dev < lldb-dev@lists.llvm.org> wrote: > Hi everyone, > > We all know how hard it can be to reproduce an issue or crash in L

Re: [lldb-dev] [RFC] LLDB Reproducers

Great, thanks. This means that the lldb-server issues are not in scope for this feature, right? On Wed, Sep 19, 2018 at 10:09 AM, Jonas Devlieghere wrote: > > > On Sep 19, 2018, at 6:49 PM, Leonard Mosescu wrote: > > Sounds like a fantastic idea. > > How would this work when the behavior of the

Re: [lldb-dev] Parsing Line Table to determine function prologue?

> > Even if we do need to parse the line table, could it be done just for the > function in question? The debug info tells us the function's address > range, so is there some technical reason why it couldn't parse the line > table only for the given address range? > My understanding is that there

Re: [lldb-dev] [RFC] OS Awareness in LLDB

Hi Alexander, are you interested in user-mode, kernel-mode debugging or both? Fore reference, the current state of the art regarding OS-awareness debugging is debugging tools for windows (windbg & co.). This is not surprisi

Re: [lldb-dev] [RFC] OS Awareness in LLDB

Conceptually it's different levels of abstraction: a user-mode debugger handles processes, threads as first class concepts. In kernel-mode (or kernel land), these are just data structures that the code (the kernel) is managing. From a more pragmatic perspective, the difference is in where the debug

Re: [lldb-dev] Debugging Python scripts (backtraces, variables) with LLDB

Not strictly related to LLDB but you might find this interesting: https://blogs.dropbox.com/tech/2018/11/crash-reporting-in-desktop-python-applications On Tue, Nov 20, 2018 at 8:51 AM Alexandru Croitor via lldb-dev < lldb-dev@lists.llvm.org> wrote: > Hello, > > It's been a while since I asked th

Re: [lldb-dev] Adding breakpad "symbol" file support

Yay! In case anyone is interested in the details, the Breakpad symbol format is documented here: https://chromium.googlesource.com/breakpad/breakpad/+/master/docs/symbol_files.md On Mon, Dec 3, 2018 at 5:39 AM Pavel Labath via lldb-dev < lldb-dev@lists.llvm.org> wrote: > Hello all, > > I'd like

Re: [lldb-dev] Object identities in the LLDB's C++ API

mall price - one pointer per > SBxxx instance even if this facility is not used. I personally like this > approach and in this particular case it has the additional benefit of being > additive (we can graft it on with minimal risk of breaking existing stuff), > although it still seems n

Re: [lldb-dev] Needs help contributing to lldb-vscode.

Greg, what do you think? On Tue, Mar 12, 2019 at 11:50 AM Qianli Ma wrote: > Hi lldb community, > > I am currently working on a project related to lldb. I'd like to write a > DAP RPC server similars to lldb-vscode.cc >

Re: [lldb-dev] Symbol Server for LLDB

Not exactly a full symbol server solution, but LLDB supports the GDB-style symbol lookup (search for the build-ID notes and nn/.debug). This, together with a simple NFS setup can get you close to a Microsoft-style symbol

Re: [lldb-dev] Symbol Server for LLDB

For macOS & dSym there's already a specialized solution: http://lldb.llvm.org/symbols.html On Mon, Mar 25, 2019 at 11:37 AM Murali Venu Thyagarajan < murali.thyagaraja...@gmail.com> wrote: > Another question that I had is, > > Can this GDB style be inferred for MacOS packages? Will there be a > b

[lldb-dev] The pre-built Windows LLDB binary has a dependency on an external python36.dll?

I just installed the pre-built LLVM9 binaries on a Windows machine and I noticed that LLDB.exe imports from python36.dll. Was this an intentional change from LLVM8? (which doesn't depend on external python DLLs) Trying to use the LLDB that comes with LLVM9, you'd get a pop-up complaining that p

Re: [lldb-dev] The pre-built Windows LLDB binary has a dependency on an external python36.dll?

What kind of behavior did you expect? I could be wrong, but I thought that previous versions of LLDB would use LoadLibrary() instead of linking to the import library? From: Pavel Labath Sent: Wednesday, November 20, 2019 11:32 PM To: Adrian McCarthy ; Leonard Mos