Re: [lldb-dev] Figure our what global and static variables are accessed by what functions (at runtime)

On 10/01/2019 17:16, Peng Yu via lldb-dev wrote: Hi, I think that I can use the watchpoint command to set watchpoints on all global and static variables. Then run the lldb and parse the screen output to see what global and static variables are read/write-accessed by what functions. Is this a goo

Re: [lldb-dev] LLDB bot health

On 14/01/2019 11:54, Tamas Berghammer wrote: +Pavel Labath Pavel and Me was owning the following bots: lldb-x86_64-ubuntu-14.04-buildserver: Builds lldb-server for various andoird architectures (doesn't run tests) lldb-x86_64-ubuntu-14.04-cmake      : Runs lldb tests wi

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

Thank you for the update Jonas. I haven't looked at the patch in detail, but (for better or worse) it seems more-or-less like what I would expect at a first glance. One of the things that occurred to me while looking at this is that it would be great to be able to test this code in greater iso

Re: [lldb-dev] [RFC]The future of pexpect

On 31/01/2019 02:32, Davide Italiano via lldb-dev wrote: As you probably know (I didn’t), lldb embeds its own version of `pexpect-2.4`, which doesn’t support python3. This is the (relatively short) list of tests relying on pyexpect: testcases/tools/lldb-mi/syntax/TestMiSyntax.py:import p

Re: [lldb-dev] [RFC]The future of pexpect

On 31/01/2019 19:26, Zachary Turner wrote: Was the test failing specifically in the keyboard handler for up arrow, or was it failing in the command history searching code?  Because if it's the latter, then we could have a command which searches the command history. The patch is r351313, if

Re: [lldb-dev] [RFC]The future of pexpect

On 31/01/2019 19:51, Zachary Turner wrote: > FileCheck the ansi escape codes seems like one possibility. > > In general I think you don't actually need to test true interactivity, > because the odds of there being a problem in the 2-3 lines of code that > convert the keyboard press to something el

Re: [lldb-dev] [RFC]The future of pexpect

On 31/01/2019 20:52, Zachary Turner wrote: It's worth mentioning that pexpect is basically unusable on Windows, so there's still that. Our interactive command line is basically unusable on windows, so there isn't anything to test anyway. I expect (pun intended) that getting a working pexpe

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

On 06/02/2019 23:11, Joshua Peraza via lldb-dev wrote: Adding a hashes where we need them SGTM. I think that's a reasonable approach. We can decide on the best hash and equality functions on a case-by-case basis. ___ lldb-dev mailing list lldb-dev@

[lldb-dev] RFC: Unwinding + Symbol Files: How To?

Hello all, currently I am at at stage where the only large piece of functionality missing from the Breakpad symbol file plugin is the unwind information. The PDB plugin has been in that state for a while. I'd like to rectify this situation, but doing that in the present lldb model is somewhat

Re: [lldb-dev] RFC: Unwinding + Symbol Files: How To?

Hello Jason, Greg, thank you for the feedback. Please find my responses inline. On 08/02/2019 04:06, Jason Molenda wrote: Hi Pavel, I'm open to this.  I don't think there was any specific reason why UnwindTable is in the ObjectFile over the Module - it was very likely not an intentional cho

Re: [lldb-dev] LLDB remote tests via LIT and specifying threads check-lldb

On 11/02/2019 10:33, Omair Javaid via lldb-dev wrote: Hi I am new to LIT and looking to run lldb testsuite in remote target configuration via lit (ninja check-lldb). Also I am looking to restrict check-lldb to run a specified number of threads at a time, something similar to LLDB_TEST_THREADS=8

Re: [lldb-dev] [RFC]The future of pexpect

On 21/02/2019 00:03, Davide Italiano wrote: I found out that there are tests that effectively require interactivity. Some of the lldb-mi ones are an example. A common use-case is that of sending SIGTERM in a loop to make sure `lldb-mi` doesn't crash and handle the signal correctly. This function

Re: [lldb-dev] [RFC]The future of pexpect

On 21/02/2019 15:35, Pavel Labath via lldb-dev wrote: So we may not even be able to get away with just using the system one and skipping tests when it's not present. s/may not/may/ ___ lldb-dev mailing list lldb-dev@lists.llvm.org

Re: [lldb-dev] [RFC]The future of pexpect

On 21/02/2019 19:48, Ted Woodward wrote: -Original Message- From: lldb-dev On Behalf Of Pavel Labath via lldb-dev Sent: Thursday, February 21, 2019 8:35 AM To: Davide Italiano Cc: LLDB Subject: [EXT] Re: [lldb-dev] [RFC]The future of pexpect On 21/02/2019 00:03, Davide Italiano

Re: [lldb-dev] [RFC]The future of pexpect

On 25/02/2019 22:15, Davide Italiano wrote: On Fri, Feb 22, 2019 at 6:32 AM Pavel Labath wrote: On 21/02/2019 19:48, Ted Woodward wrote: -Original Message- From: lldb-dev On Behalf Of Pavel Labath via lldb-dev Sent: Thursday, February 21, 2019 8:35 AM To: Davide Italiano Cc

Re: [lldb-dev] Unwinding call frames with separated data and return address stacks

On 04/03/2019 11:46, Thomas Goodfellow via lldb-dev wrote: I'm adding LLDB support for an unconventional platform which uses two stacks: one purely for return addresses and another for frame context (spilled registers, local variables, etc). There is no explicit link between the two stacks, i.e.

[lldb-dev] new tool (core2yaml) + a new top-level library (Formats)

Hello all, I have just posted a large-ish patch series for review (D58971, D58973, D58975, D58976), and I want to use this opportunity to draw more attention to it and highlight various bikeshedding opportunities^H^H^Htopics for discussion :). The new tool is called core2yaml, and it's goal

Re: [lldb-dev] new tool (core2yaml) + a new top-level library (Formats)

On 05/03/2019 22:52, Zachary Turner wrote: On Tue, Mar 5, 2019 at 1:47 PM Jonas Devlieghere via lldb-dev mailto:lldb-dev@lists.llvm.org>> wrote: I don't know much about the minidump format or code, but it sounds reasonable for me to have support for it in yaml2obj, which would be

Re: [lldb-dev] RFC: Eliminate LLDB_DISABLE_PYTHON

On 07/03/2019 19:27, Adrian McCarthy via lldb-dev wrote: We have a build option to build LLDB without Python.  This option is automatically set if Cmake can't find or "validate" your Python distribution. Since LLDB is rarely built with this option, nobody discovers when this configuration bre

Re: [lldb-dev] RFC: Eliminate LLDB_DISABLE_PYTHON

On 07/03/2019 20:29, Davide Italiano via lldb-dev wrote: I'm in favor of this. FWIW, I will be surprised if lldb works at all with that option. I would actually be also surprised if it works. However, the option I think is important to keep is to be able to build lldb-server without python a

Re: [lldb-dev] RFC: Eliminate LLDB_DISABLE_PYTHON

On 07/03/2019 20:52, Zachary Turner wrote: Does lldb-server for Android currently use this flag?  I was under the impression it just linked against Python anyway. No, it doesn't link against python. In fact, when targetting android, we default to disabling all external dependencies. LLDBConfig

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

On 12/03/2019 20:34, Leonard Mosescu via lldb-dev wrote: 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 t

Re: [lldb-dev] [cfe-dev] [GitHub] RFC: Enforcing no merge commit policy

On 21/03/2019 13:12, David Chisnall via lldb-dev wrote: On 20 Mar 2019, at 18:23, Arthur O'Dwyer via cfe-dev wrote: Server-side hooks are the answer to this problem. There is no problem. You just use a server-side hook. It is quite unlikely that GitHub will allow LLVM (or any other project

Re: [lldb-dev] Test suite failures on Fedora Linux?

On 25/03/2019 12:25, Raphael Isemann via lldb-dev wrote: The import-std-module patches are probably just llvm.org/pr35043, so I'll rename the variables there and that should fix it. Not sure about the others. - Raphael The remaining two failures look like they're down to the linux kernel ref

Re: [lldb-dev] Get source file name from Python API?

On 23/03/2019 22:20, Ian Fang via lldb-dev wrote: Hi Folks, Is there anyway to get the source file name for the current stop context? I am looking for something like the result of “source info”, but from Python API. Thanks! Ian ___ lldb-dev mailing

Re: [lldb-dev] Can we remove this platform?

On 26/03/2019 23:16, Jonas Devlieghere via lldb-dev wrote: Yesterday I stumbled upon the initialization code for the "Kalimba" platform. It looks like this was added in 2014 and never had any tests. If nobody is relying on this platform, I propose to remove it. Review: https://reviews.llvm.org

Re: [lldb-dev] Test suite failures on Fedora Linux?

On 26/03/2019 14:48, David Zarzycki via lldb-dev wrote: On Mar 26, 2019, at 3:07 AM, Jan Kratochvil wrote: On Mon, 25 Mar 2019 19:47:36 +0100, David Zarzycki via lldb-dev wrote: Also, given that two of the test failures are Intel specific (the mxcsr register write failures), what class of ha

Re: [lldb-dev] What is the correct behavior of SBModule::GetVersion with a version number of 0.0.0

On 28/03/2019 01:36, Jim Ingham wrote: If you have a library that has a version number of 0.0.0, uint32_t SBModule::GetVersion(uint32_t *versions, uint32_t num_versions) will return a result of 2 (which is the number of elements it put into num_versions) and the two elements it actually stuffe

Re: [lldb-dev] Test suite failures on Fedora Linux?

On 27/03/2019 16:38, Pavel Labath via lldb-dev wrote: On 26/03/2019 14:48, David Zarzycki via lldb-dev wrote: On Mar 26, 2019, at 3:07 AM, Jan Kratochvil wrote: On Mon, 25 Mar 2019 19:47:36 +0100, David Zarzycki via lldb-dev wrote: Also, given that two of the test failures are Intel

Re: [lldb-dev] Bugzilla default-assignee vs default-cc

On 12/04/2019 10:25, Jonas Devlieghere via lldb-dev wrote: I was talking to one of the Bugzilla admins (Kristof) earlier today and he pointed out that the default assignee for lldb bugs in the lldb-dev list, and that it might be better to change that from default-assignee to default-cc. That wa

Re: [lldb-dev] Bugzilla default-assignee vs default-cc

On 12/04/2019 10:55, Raphael Isemann wrote: Can't we just have a list like lldb-bugs (similar to llvm-bugs) as the default-cc? This way I would have all the bugzilla talk also available in my mail, which means I can use my mail client to read comments and search them. And people that don't care a

[lldb-dev] [RFC] Adding a clang-style LLVM.h (or, "Are you tired of typing 'llvm::' everywhere ?")

Hello all, some llvm classes, are so well-known and widely used, that qualifying them with "llvm::" serves no useful purpose and only adds visual noise. I'm thinking here mainly of ADT classes like String/ArrayRef, Optional/Error, etc. I propose we stop explicitly qualifying these classes. W

Re: [lldb-dev] [RFC] Adding a clang-style LLVM.h (or, "Are you tired of typing 'llvm::' everywhere ?")

Thanks for the replies. I was hoping to get more positive feedback for this, so given the current mixed-feelings replies, I think I'll just give up on this idea, unless a more vocal supporter appears (probably not the best idea to send this out just before the easter holidays). In the mean tim

Re: [lldb-dev] [RFC] Adding a clang-style LLVM.h (or, "Are you tired of typing 'llvm::' everywhere ?")

On 18/04/2019 20:03, Robbert Haarman via lldb-dev wrote: On Thu, Apr 18, 2019, at 7:31 AM, Pavel Labath via lldb-dev wrote: Out of interest, I took a look at what lld is doing. I've found that while it doesn't have a LLVM.h equivalent, it is a heavy user of "using namespace llv

Re: [lldb-dev] LLDB Website

On 24/04/2019 03:19, Jonas Devlieghere via lldb-dev wrote: On Tue, Apr 23, 2019 at 6:04 PM Jonas Devlieghere > wrote: On Tue, Apr 23, 2019 at 5:43 PM Tanya Lattner mailto:tanyalatt...@llvm.org>> wrote: On Apr 23, 2019, at 5:06 PM, Jonas Devliegh

Re: [lldb-dev] [RFC] Support for AArch64/Arm64 scalable vector extension (SVE)

On 25/04/2019 00:07, Omair Javaid via lldb-dev wrote: I would also like to open a discussion on how we can implement variable length registers in LLDB and what could be the consequences of those changes. I am not saying I am particularly happy with how it was implemented, but you should take

Re: [lldb-dev] [Lldb-commits] [lldb] r360757 - Group forward declarations in one namespace lldb_private {}

On 16/05/2019 01:10, Jim Ingham via lldb-dev wrote: When you add to them you are often adding some larger feature which would have required a rebuild anyway, and they go long times with no change... I have never found the rebuild required when these files are touched to be a drag on my produc

Re: [lldb-dev] Are overlapping ELF sections problematic?

On 03/06/2019 10:19, Thomas Goodfellow via lldb-dev wrote: I'm working with an embedded platform that segregates memory between executable code, RAM, and constant values. The three kinds occupy three separate address spaces, accessed by specific instructions (e.g. "load from RAM address #0" vs "l

Re: [lldb-dev] Are overlapping ELF sections problematic?

On 04/06/2019 11:21, Thomas Goodfellow wrote: Hi Pavel I can't say what's the situation in the rest of llvm, but right now lldb has zero test coverage for the flow you are using, so the fact that this has worked until now was pretty much an accident. It was a pleasant surprise that it worked

[lldb-dev] RFC: Removing SymbolVendor indirection

Hello all, we currently have an almost identical set of about 20-odd functions on ModuleList, Module, SymbolVendor and SymbolFile classes. The only thing that the SymbolVendor functions are doing is taking the Module mutex, and then calling the equivalent SymbolFile function to do the work. Th

Re: [lldb-dev] Trouble running Python tests on Windows

On 25/06/2019 17:00, Ted Woodward via lldb-dev wrote: The bug that makes swig before 4 fail with Python 3.7 may turn into a big issue, given that swig is now licensed under GPL v3. I believe Apple has said in the past that they can’t move past a certain version of swig 2.x, since the license ch

Re: [lldb-dev] [RFC] Removing lldb-mi

On 02/07/2019 00:09, Jonas Devlieghere via lldb-dev wrote: Hi everyone, After long consideration, I want to propose removing lldb-mi from the repository. It is basically unmaintained, doesn't match the LLDB code style, and worst of all the tests are unreliable if not already disabled. As far

[lldb-dev] STABS

Hello everyone, I recently found myself looking at ObjectFileMachO.cpp. I noticed that nearly half of that file (2700 LOC) is taken up by the ParseSymtab function, and that maybe one third of that is taken up by what appears to be STABS parsing code. Is anyone still using STABS debug info? I

Re: [lldb-dev] [llvm-dev] RFC: changing variable naming rules in LLVM codebase & git-blame

On 30/07/2019 01:57, Chris Lattner via llvm-dev wrote: On Jul 29, 2019, at 10:58 AM, JF Bastien > wrote: I think that Rui rolled this out in an incredibly great way with LLD, incorporating a lot of community feedback and discussion, and (as you say) this thread has ac

Re: [lldb-dev] [llvm-dev] RFC: changing variable naming rules in LLVM codebase & git-blame

On 30/07/2019 11:53, Raphael “Teemperor” Isemann wrote: Is the plan for LLDB to just adapt the code that is trying to follow the new code style or also the code using the LLDB code style? I don't think there's a "plan" at this moment, but I believe Chris meant all of LLDB. I’m in general

Re: [lldb-dev] STABS

On 26/07/2019 20:43, Jim Ingham wrote: Amplifying Fred's comments: Most of the code in ParseSymtab is parsing the nlist records in the binary. Only a tiny subset of those nlist records are "stabs". Most are just the format by which MachO expresses its symbol table. So all that needs to be t

Re: [lldb-dev] [RFC] Fast Conditional Breakpoints (FCB)

Hello Ismail, and wellcome to LLDB. You have a very interesting (and not entirely trivial) project, and I wish you the best of luck in your work. I think this will be a very useful addition to lldb. It sounds like you have researched the problem very well, and the overall direction looks good

Re: [lldb-dev] [RFC] Fast Conditional Breakpoints (FCB)

On 15/08/2019 20:15, Jim Ingham wrote: Thanks for your great comments. A few replies... On Aug 15, 2019, at 10:10 AM, Pavel Labath via lldb-dev wrote: I am wondering whether we really need to involve the memory allocation functions here. What's the size of this address structure? I

Re: [lldb-dev] [RFC] Fast Conditional Breakpoints (FCB)

On 20/08/2019 00:11, Ismail Bennani wrote: On Aug 19, 2019, at 2:30 PM, Frédéric Riss wrote: On Aug 16, 2019, at 11:13 AM, Ismail Bennani via lldb-dev wrote: Hi Pavel, Thanks for all your feedbacks. I’ve been following the discussion closely and find your approach quite interesting. A

Re: [lldb-dev] [RFC] Fast Conditional Breakpoints (FCB)

On 23/08/2019 00:58, Ismail Bennani via lldb-dev wrote: Hi Greg, Thanks for your suggestion! On Aug 22, 2019, at 3:35 PM, Greg Clayton wrote: Another possibility is to have the IDE insert NOP opcodes for you when you write a breakpoint with a condition and compile NOPs into your program. S

[lldb-dev] RFC: Support for unwinding on windows

Hello everyone, after a short recess, I have started to resume work on the breakpad symbols project. The project is "nearly" finished, but there is one more thing remaining to be done. This is to support stack unwinding for 32 bit windows targets. The unwinding info in breakpad is represente

Re: [lldb-dev] Breakpoint matching with -n seems to have gotten too generous

On 30/08/2019 02:33, Jim Ingham via lldb-dev wrote: If I have a program like: class A { public: int AMethod() { return 100; } }; class AA { public: int AMethod() { return 200; } }; int main() { A myA; AA myAA; myA.AMethod(); myAA.AMethod(); return 0; } Build and run it un

Re: [lldb-dev] help, how to get a debug build on windows (python37_d.lib)

On 22/09/2019 20:20, Larry D'Anna via lldb-dev wrote: Hi lldb-dev. I can’t seem to figure out how to build a debug lldb on windows.   It wants to link against a debug version of Python, which isn’t there. My cmake line looks like this: cmake -G Ninja `         "-DPYTHON_HOME=C:\Program File

Re: [lldb-dev] RFC: full support for python files, and avoid using FILE* internally

On 20/09/2019 17:35, Larry D'Anna via lldb-dev wrote: Hi lldb-dev. I want to be able to use LLDB inside of iPython, so I can have mixed python and LLDB debug session. To this end, I’d like to update LLDB to have full support for python file objects, so the outputs of debugger commands can b

Re: [lldb-dev] RFC: full support for python files, and avoid using FILE* internally

On 23/09/2019 20:54, Larry D'Anna wrote: On Sep 23, 2019, at 7:11 AM, Pavel Labath wrote: On 20/09/2019 17:35, Larry D'Anna via lldb-dev wrote: Hi lldb-dev. I want to be able to use LLDB inside of iPython, so I can have mixed python and LLDB debug session. To this end, I’d like to update L

Re: [lldb-dev] lldb warning or developer options

On 27/09/2019 07:52, Sourabh Singh Tomar via lldb-dev wrote: Hi Folks, Is their a developer switch or diagnostic switch, that we can set in lldb, to show warnings and other useful stuff when lldb process the binary, building table and utilizing DWARF. I stumble upon, a rather trivial test ca

Re: [lldb-dev] Rust support in LLDB, again

+1 to everything that Jonas said. On 30/09/2019 18:28, Jonas Devlieghere via lldb-dev wrote: Hi Vadim, On Sat, Sep 28, 2019 at 4:00 PM Vadim Chugunov via lldb-dev wrote: Hi, Last year there was an effort led by Tom Tromey to add Rust language support into LLDB. He had implemented a fairly

Re: [lldb-dev] [RFC] Adding a clang-style LLVM.h (or, "Are you tired of typing 'llvm::' everywhere ?")

On 08/10/2019 02:45, Larry D'Anna via lldb-dev wrote: Pavel Labath said some llvm classes, are so well-known and widely used, that qualifying them with "llvm::" serves no useful purpose and only adds visual noise. I'm thinking here mainly of ADT classes like String/ArrayRef, Optional/Error, etc

Re: [lldb-dev] issue with lldb9 and python3.5

On 29/10/2019 09:31, Serge Guelton via lldb-dev wrote: On Mon, Oct 28, 2019 at 10:09:53AM -0700, Adrian McCarthy wrote: +1 Yes, for Windows, I'd be happy if we said Python 3.6+. I investigated the bug yesterday, and filled some of my discoveries in https://bugs.llvm.org/show_bug.cgi?id=4

Re: [lldb-dev] issue with lldb9 and python3.5

On 29/10/2019 21:40, Christos Zoulas wrote: On Oct 29, 6:54pm, pa...@labath.sk (Pavel Labath) wrote: -- Subject: Re: [lldb-dev] issue with lldb9 and python3.5 | On 29/10/2019 09:31, Serge Guelton via lldb-dev wrote: | > On Mon, Oct 28, 2019 at 10:09:53AM -0700, Adrian McCarthy wrote: | >> +1 Ye

Re: [lldb-dev] issue with lldb9 and python3.5

On 30/10/2019 11:18, Kamil Rytarowski wrote: On 30.10.2019 11:06, Pavel Labath wrote: On 29/10/2019 21:40, Christos Zoulas wrote: On Oct 29,  6:54pm, pa...@labath.sk (Pavel Labath) wrote: -- Subject: Re: [lldb-dev] issue with lldb9 and python3.5 | On 29/10/2019 09:31, Serge Guelton via lldb-de

Re: [lldb-dev] https://reviews.llvm.org/D69273

(Just writing to say that tomorrow is a public holiday in most of Europe, so I wont be able to meaningfully reply to this until monday/tuesday. But if, in the mean time, you want to revert this, or just limit the scope of that patch somehow, then that's fine with me.) On 31/10/2019 20:51, Jim

Re: [lldb-dev] https://reviews.llvm.org/D69273

On 31/10/2019 20:51, Jim Ingham via lldb-dev wrote: It looks like this change is causing problems with swift. I was talking a little bit with Davide about this and it seems like it wasn't obvious how this was designed to work. So here's what this was intended to do (apologies if this is at t

Re: [lldb-dev] https://reviews.llvm.org/D69273

On 04/11/2019 18:19, Jim Ingham wrote: Sorry, my brain is not working this morning, I answered your question in the review comments… Jim NP, maybe let's continue the discussion there? I find it useful to have the actual code change around.. ___ l

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

On 20/11/2019 23:53, Adrian McCarthy via lldb-dev wrote: That said, I didn't expect an explicit dependency on python36.dll. What kind of behavior did you expect? pl ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mail

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

On 22/11/2019 01:26, Adrian McCarthy wrote: Yes, that sounds plausible, but I don't recall for sure.  I think there's a build-time option to say you don't want Python at all, but I can't remember if there was a load-as-needed option. I'm pretty sure we have never had explicit support for anyth

Re: [lldb-dev] Inconsistencies in CIE pointer in FDEs in .debug_frame

On 24/11/2019 23:16, Martin Storsjö via lldb-dev wrote: Hi, I'm looking into something that seems like an inconsistency in handling of the CIE pointer in FDEs in .debug_frame, between how debug info is generated in LLVM and consumed in LLDB. For FDEs in .eh_frame, the CIE pointer/cie_id fiel

Re: [lldb-dev] Inconsistencies in CIE pointer in FDEs in .debug_frame

On 25/11/2019 10:46, Martin Storsjö wrote: On Mon, 25 Nov 2019, Pavel Labath wrote: On 24/11/2019 23:16, Martin Storsjö via lldb-dev wrote: Hi, I'm looking into something that seems like an inconsistency in handling of the CIE pointer in FDEs in .debug_frame, between how debug info is gener

Re: [lldb-dev] SBValues referencing deallocated memory

On 27/11/2019 08:47, Raphael “Teemperor” Isemann via lldb-dev wrote: This can also be reproduced in the command line like this: (lldb) expr "foo" (const char [4]) $0 = "foo" (lldb) expr "bar" (const char [4]) $1 = "bar" (lldb) expr $0 (const char [4]) $0 = “bar” This however works just fine: (

Re: [lldb-dev] [RFC] Supporting Lua Scripting in LLDB

I think this would be a very interesting project, and would allow us to flesh out the details of the script interpreter interface. A lot of the complexity in our python code comes from the fact that python can be (a) embedded into lldb and (b) lldb can be embedded into python. It's been a while si

Re: [lldb-dev] [RFC] Supporting Lua Scripting in LLDB

On 09/12/2019 18:27, Jonas Devlieghere wrote: > On Mon, Dec 9, 2019 at 1:55 AM Pavel Labath wrote: >> >> I think this would be a very interesting project, and would allow us to >> flesh out the details of the script interpreter interface. >> >> A lot of the complexity in our python code comes from

Re: [lldb-dev] The future of modern-type-lookup in LLDB

Thanks for the nice summary Raphael, this isn't exactly my playground (though I may end up having to poke in this soon), but it overall, it sounds to me like this "modern" thingy is a better overall design. However, your penultimate bullet point seems pretty important to me. I don't think we can

Re: [lldb-dev] gdb-remote protocol questions

On 27/01/2020 19:43, Alexander Zhang via lldb-dev wrote: > Hi, > > Thanks for pointing me towards stack unwinding. I don't have debug > information much of the time, so I'm depending on the architecture rules > for backtracing. A look at the mips ABI plugin shows it uses dwarf > register numbers t

Re: [lldb-dev] How to tell if an address belongs to the heap?

In general, getting this kind of information is pretty hard, so lldb does not offer you an out-of-the-box solution for it, but it does give you tools which you can use to approximate that. If I wanted to do something like this, the first thing I'd try to do is run "image lookup -a 0xaddr". If this

Re: [lldb-dev] How to tell if an address belongs to the heap?

Thanks for the explanation, Vangelis. It sounds like binary instrumentation would be the best approach for this, as this is pretty much exactly what msan does. If recompilation is not an option, then you might be able to get something to work via lldb, but I expect this to be _incredibly_ slow (li

Re: [lldb-dev] Odd behavior with Python on Windows (loading 2 copies of liblldb.dll/_lldb.pyd)

On 21/02/2020 23:32, Ted Woodward via lldb-dev wrote: > Looking into differences, I’m using swig 3.0.12 and the bot is using > swig 3.0.2. I’m building with 3.0.2 on my machine right now, but it will > take a while to finish! I think this could very likely be the cause. We use a different mechanis

Re: [lldb-dev] [llvm-dev] Continuing from dbgtrap on different targets

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 sti

Re: [lldb-dev] LLDB problem about building with Python

On 12/03/2020 10:50, Rui Hong via lldb-dev wrote: > Hi LLDB devs, > > I'm working on porting LLDB to my own architecture. > I choose to use the target-definition-file(python) to let LLDB support > my architecture based on my situation(already have a workable GDB-stub > and the target is an embedde

Re: [lldb-dev] How to associate a bug and CL?

On 26/03/2020 00:36, Emre Kultursay via lldb-dev wrote: > llvm-project dev noob here. > > I opened a Bug  and have > some CLs  to fix them. How do I link > the CL with the bug so that the code reviewer sees what bug I'm

Re: [lldb-dev] Default script language

+1 for making this a cmake option. That said, I don't think we can implement this using #ifdefs. lldb-enumerations.h is a part of our public api, Config.h isn't (it theoretically could be, but I don't think we want that). I think the simplest way to achieve this would be to make eScriptLanguageDe

Re: [lldb-dev] Saving and restoring STDIN in the ScriptInterpreter

Hi Davide, I believe your guess about background processes is correct. I think that the lldb process is stopped (or is continually getting stopped and restarted) by SIGTTOU. Macro: int SIGTTOU This is similar to SIGTTIN, but is generated when a process in a background job attempts to wr

Re: [lldb-dev] [RFC] Upstreaming Reproducer Capture/Replay for the API Test Suite

Hi Jonas, Davide, I am not exactly thrilled by the ever-growing number of "modes" our test suite can be run in. However, it seems that's a battle I am destined to loose, so I'll just repeat what I've been saying for some time now. I don't believe that either of these funny "modes" should be the _

Re: [lldb-dev] Is there a just-my-code like debugging mode for LLDB?

Hi Emre, I have to say I'm pretty sceptical about this approach, for all the reasons that Jim already mentioned. Making it so that lldb pretends the other shared libraries don't exist (which is what I assume your prototype does) is fairly easy, but it does create a very long tail of "feature X doe

Re: [lldb-dev] Is there a just-my-code like debugging mode for LLDB?

On 14/05/2020 03:50, Emre Kultursay via lldb-dev wrote: > One thing I want to try is "settings set > plugin.process.gdb-remote.use-libraries-svr4 true". Isn't that the default? The reason this setting was added was so we could test the !svr code path without forcibly disabling xml support (and pos

Re: [lldb-dev] Is there a just-my-code like debugging mode for LLDB?

On 14/05/2020 11:56, Jaroslav Sevcik wrote: > > The svr4 support seems to be off by > default:  > https://github.com/llvm/llvm-project/blob/2974b3c566d68f1d7c907f891137cf0292dd35aa/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemoteProperties.td#L14 > > It would definitely make sense to turn

Re: [lldb-dev] Pre-merge lldb testing

I believe pre-merge testing would be very useful. The thing which I would find very useful (let's call it a feature request) is to be able to get some sort of an overview/dashboard of all the runs on this infrastructure and their results. It doesn't have to be super detailed -- the question which

[lldb-dev] RFC: -flimit-debug-info + frame variable

Hello all, With the expression evaluation part of -flimit-debug-info nearly completed, I started looking at doing the same for the "frame variable" command. I have thought this would be simpler than the expression evaluator, since we control most of that code. However, I have hit one snag, hence

Re: [lldb-dev] RFC: -flimit-debug-info + frame variable

On 20/07/2020 23:25, Jim Ingham wrote: > It seems like you are having to work hard in the ValueObject system because > you don’t want to use single AST Type for the ValueObject’s type. Seems like > it be much simpler if you could cons up a complete type in the > ScratchASTContext, and then use

Re: [lldb-dev] Break setting aliases...

I use "b" for file+line breakpoints and "br set -n" for function breakpoints, mainly because I couldn't be bothered to figure out how that works with the "b" command. Now that I have studied the command once again, I may try using it for function breakpoints as well... I don't have any hard object

Re: [lldb-dev] Break setting aliases...

On 22/07/2020 19:50, Jim Ingham wrote: >> On Jul 22, 2020, at 12:34 AM, Pavel Labath wrote: >> >> The "--" is slightly unfortunate, but it's at least consistent with our >> other commands taking raw input. We could avoid that by making the >> command not take raw input. I think most of the "modes"

Re: [lldb-dev] RFC: -flimit-debug-info + frame variable

On 22/07/2020 01:31, Jim Ingham wrote: > > >> On Jul 21, 2020, at 9:27 AM, Pavel Labath > > wrote: >> I do see the attractiveness of constructing of a full compiler type. The >> reason I am hesitant to go that way, because it seems to me that this >> would negate the two m

Re: [lldb-dev] [RFC] Listing files in remote directory

On 26/07/2020 21:02, Raphael “Teemperor” Isemann via lldb-dev wrote: > I think classifying into local/platform isn't an issue (I think we > always know if we're doing remote or local completion), but the bigger > problem is that I'm not sure if we can easily list files/subdirs in a > remote directo

Re: [lldb-dev] Deprecating Python2 and adding type-annotations to the python API

On 04/08/2020 02:37, Jonas Devlieghere via lldb-dev wrote: > Hi Nathan, > > Thanks for bringing this up. I've been expecting this question for a > while now.  > > Python 2 is end-of-life and we should move to Python 3. I'm pretty sure > nobody here disagrees with that. Unfortunately though, we st

Re: [lldb-dev] LLDB got SIGCHLD on hitting the breakpoint

When you say "execute binary code", where exactly is this code being executed? Is it executed by launching another process? Lldb will not automatically debug all child process spawned by your process -- they will run freely. The SIGCHLDs are not coming from lldb -- they are signals which all proc

Re: [lldb-dev] RFC: Processor Trace Support in LLDB

Thank you for writing this Walter. I think this document will be a useful reference both now and in the future. The part that's not clear to me is what is the story with multi-process traces. The file format enables those, but it's not clear how are they going be created or used. Can you elaborate

Re: [lldb-dev] RFC: Processor Trace Support in LLDB

On 01/10/2020 22:32, Walter wrote: > After a chat with Greg, we agreed on this set of commands > > > trace load /path/to/json process trace start/stop process trace save > /path/to/json thread trace start/stop thread trace dump [instructions | > functions] > Thanks. The new commands look good t

Re: [lldb-dev] Deadlock loading DWARF symbols

On 02/10/2020 23:13, Greg Clayton wrote: Yes this is bad, and GetDescription() is used as a convenience to print out the module path (which might be a .o file within a .a file) and optionally architecture of the module. It probably shouldn't be taking the module lock as the only member variabl

Re: [lldb-dev] lldb 11.0.0-rc2 different behavior then gdb.

On 07/10/2020 20:42, Jim Ingham via lldb-dev wrote: There isn’t a built-in summary formatter for two dimensional arrays of chars, but the type is matching the regex for the one-dimensional StringSummaryFormat, but that doesn’t actually know how to format two dimensional arrays of chars.  The ty

Re: [lldb-dev] lldb 11.0.0-rc2 different behavior then gdb.

On 07/10/2020 21:01, Jim Ingham wrote: On Oct 7, 2020, at 11:44 AM, Pavel Labath > wrote: On 07/10/2020 20:42, Jim Ingham via lldb-dev wrote: There isn’t a built-in summary formatter for two dimensional arrays of chars, but the type is matching the regex for the one-d

Re: [lldb-dev] [RFC] Segmented Address Space Support in LLDB

There's a lot of things that are unclear to me about this proposal. The mechanics of representing an segmented address are one thing, but I I think that the really interesting part will be the interaction with the rest of lldb. Like - What's going to be the source of this address space informati

<    1   2   3   4   5   6   >