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

[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

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 >

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] 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] Object identities in the LLDB's C++ API

ven 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 nice to have consistent identity semantics f

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] 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

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

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

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

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

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

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

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

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 >

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

[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

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

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

[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

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

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) >> > >> > >> > On Jun 20, 2018, at 11:01 AM, Leonard Mosescu v

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

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 to compare the bytes (which is hopefully what

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

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

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@list

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

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

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 &

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> wrote: > &g

[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

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

pread (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 <lab...@google.com> wrote: > >> On

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

On Fri, Apr 27, 2018 at 2:11 AM, Pavel Labath <lab...@google.com> 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 that the 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] 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

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,

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

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 platfo

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

just do "target list" 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 > f

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

& 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 <clayb...@gmail.com> wrote: > > > On Apr 10, 2018, at 11:32 AM, Leonard Mosescu via lldb-dev < > lldb-dev@lis

[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, );

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

th 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 <clayb...@gmail.com> wrote: > > On Dec 13, 2017, at 11:44 AM, Leonard Mosescu via lldb-dev < > lldb-

[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

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