Re: [lldb-dev] [Openmp-dev] [cfe-dev] [llvm-dev] FYI: Landing the initial draft for an LLVM Code of Conduct
On 4 Jul 2016, at 12:27, Renato Golin via Openmp-dev wrote: > > On 4 July 2016 at 00:42, Robinson, Paul wrote: >> Daniel claimed it was not different, even though he proposed the text. >> I think it is better, as "egregious" (even though it is qualitative) >> helps identify what "rare" circumstances would come under the policy. >> As a non-lawyer I do think it's different. > > I personally agree with you, both on helping identify "rare" (as what, > not when), and for easing non-lawyers minds. The simplest solution would probably be to have a separate advisory document listing informally examples of things that would and wouldn’t be covered by the CoC. For example: Stalking a member of the LLVM community: Covered. Inciting harassment of a member of the LLVM community in social media: Covered Sending rude emails to a member of the LLVM community with whom you have a relationship outside of the project: Probably not covered, unless it’s directly related to LLVM Some example that people are worried would constitute overreach: Not covered Some other examples that people are concerned must be covered: Covered This document would provide guidance for the CoC enforcement committee, but would not be part of the official CoC. David smime.p7s Description: S/MIME cryptographic signature ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] Announce: Rust bindings for the LLDB public API
Hello all, I've been working on Rust bindings for the LLDB API and they're coming along pretty well. They aren't complete yet, but they're getting close: https://github.com/endoli/lldb.rs/ The documentation for these bindings can be found at https://endoli.github.io/lldb.rs/ I need to write more documentation, hook up more safe bindings for things like events, values and a few other things. Some very basic things already work though. These are using the C code / API that was submitted in a pull request in April of 2015 and subsequently seems to have been abandoned. My goal here is to have a very clean binding of the C++ API, but with some modifications to make it more idiomatic Rust in places. Examples of this are returning Option types instead of requiring that the caller check IsValid, as well as Result types when there might be an SBError. This is being done to power some of my other projects, but I'm willing to support this for others should the need arise and I'd love to see more people using this than just me. I've also got a Patreon ( https://patreon.com/endoli/) if anyone feels like helping to support this work in that way. I'm also happy to discuss any aspects of this work here or elsewhere. Cheers, - Bruce ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] Add support for OCaml native debugging
I would like to submit two patches for code review. They introduce concrete support for OCaml native debugging, granted that you have access to the native compiler with DWARF emission support (see https://github.com/ocaml/ocaml/pull/574) This adds about 2000 lines of code. The type system isn't particularly complex here, every value is considered as an unsigned integer, and interpretation of the value is left to an external debugging layer made in OCaml. The language plugin handles function name demangling for breakpoints too. No tests for now. Is it fine to commit binaries with the patchs? Elias Boutaleb ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [Openmp-dev] [cfe-dev] [llvm-dev] FYI: Landing the initial draft for an LLVM Code of Conduct
On 6 Jul 2016, at 16:16, Robinson, Paul wrote: > > As Daniel pointed out, an enumeration like that knows no bounds, and > starting a list invites endless what-if questions. That's why I settled > for a more qualitative statement; we have to acknowledge that ultimately > there's a judgement call on the part of the enforcement committee, but > the wording as it was felt a little too wide-open for me. That I was explicitly *not* what I was suggesting an enumeration of all possible cases, I was suggesting an additional document describing hypothetical case studies and whether they would be covered. There is ample precedent for this in law (for example, much of the tax code in the UK comes along with guidance notes, which are not considered legally binding but provide people with rough rules of thumb) and does not degenerate into an attempt to list every possible case. David smime.p7s Description: S/MIME cryptographic signature ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [Openmp-dev] [cfe-dev] [llvm-dev] FYI: Landing the initial draft for an LLVM Code of Conduct
> -Original Message- > From: Dr D. Chisnall [mailto:dc...@hermes.cam.ac.uk] On Behalf Of David > Chisnall > Sent: Wednesday, July 06, 2016 1:48 AM > To: Renato Golin > Cc: Robinson, Paul; Daniel Berlin; llvm-dev; openmp-dev (openmp- > d...@lists.llvm.org); LLDB; cfe-...@lists.llvm.org; Rafael Espíndola > Subject: Re: [Openmp-dev] [lldb-dev] [cfe-dev] [llvm-dev] FYI: Landing the > initial draft for an LLVM Code of Conduct > > On 4 Jul 2016, at 12:27, Renato Golin via Openmp-dev d...@lists.llvm.org> wrote: > > > > On 4 July 2016 at 00:42, Robinson, Paul wrote: > >> Daniel claimed it was not different, even though he proposed the text. > >> I think it is better, as "egregious" (even though it is qualitative) > >> helps identify what "rare" circumstances would come under the policy. > >> As a non-lawyer I do think it's different. > > > > I personally agree with you, both on helping identify "rare" (as what, > > not when), and for easing non-lawyers minds. > > The simplest solution would probably be to have a separate advisory > document listing informally examples of things that would and wouldn’t be > covered by the CoC. For example: As Daniel pointed out, an enumeration like that knows no bounds, and starting a list invites endless what-if questions. That's why I settled for a more qualitative statement; we have to acknowledge that ultimately there's a judgement call on the part of the enforcement committee, but the wording as it was felt a little too wide-open for me. --paulr > > Stalking a member of the LLVM community: Covered. > > Inciting harassment of a member of the LLVM community in social media: > Covered > > Sending rude emails to a member of the LLVM community with whom you have a > relationship outside of the project: Probably not covered, unless it’s > directly related to LLVM > > Some example that people are worried would constitute overreach: Not > covered > > Some other examples that people are concerned must be covered: Covered > > This document would provide guidance for the CoC enforcement committee, > but would not be part of the official CoC. > > David ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [Openmp-dev] [cfe-dev] [llvm-dev] FYI: Landing the initial draft for an LLVM Code of Conduct
> On 6 Jul 2016, at 16:16, Robinson, Paul wrote: > > > > As Daniel pointed out, an enumeration like that knows no bounds, and > > starting a list invites endless what-if questions. That's why I settled > > for a more qualitative statement; we have to acknowledge that ultimately > > there's a judgement call on the part of the enforcement committee, but > > the wording as it was felt a little too wide-open for me. > > That I was explicitly *not* what I was suggesting an enumeration of all > possible cases, I was suggesting an additional document describing > hypothetical case studies and whether they would be covered. There is > ample precedent for this in law (for example, much of the tax code in the > UK comes along with guidance notes, which are not considered legally > binding but provide people with rough rules of thumb) and does not > degenerate into an attempt to list every possible case. > > David Ah, okay! Like non-normative guidance/motivation text in a standards document. That works. --paulr ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] Debugging Python scripts (backtraces, variables) with LLDB
Hello, I've searched for information wether it is possible to debug a python script using LLDB, and haven't found anything so far. Specifically I'm interested in an LLDB counterpart to what GDB provides (the two main pages being https://wiki.python.org/moin/DebuggingWithGdb and http://fedoraproject.org/wiki/Features/EasierPythonDebugging ). So python stack traces, python values, etc. I assume this is not implemented, but are there any plans, or is it even feasible to implement? Regards, Alex. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Debugging Python scripts (backtraces, variables) with LLDB
Nothing of this sort has been done to my knowledge, and I haven't heard of any plans to do so either. It should certainly be possible, you just need to grub the C stack and recognize the pattern of a Python stack frame in it and where said frame stashes away the arguments & locals, and then re-present it as a Python frame. The SB API's should make that fairly straight forward. It looks like the Python work in gdb is based on a generic "frame filter" concept in the gdb Python API's. That's something Greg and I talked about when working on gdb way back, and has been a future goal for lldb from the start, but it hasn't ever gotten beyond discussion to date. We already have the notion of a "thread provider" which allows the Mach Kernel plugin to present its activations as threads in lldb. You could do much the same thing in lldb, where a thread would have the native unwind based stack frame and then pluggable StackFrame provider that would show different representations of the stack. If anybody is interested in taking on such a project, that would be very cool. Jim > On Jul 6, 2016, at 8:48 AM, Alexandru Croitor via lldb-dev > wrote: > > Hello, > > I've searched for information wether it is possible to debug a python script > using LLDB, and haven't found anything so far. > > Specifically I'm interested in an LLDB counterpart to what GDB provides (the > two main pages being https://wiki.python.org/moin/DebuggingWithGdb and > http://fedoraproject.org/wiki/Features/EasierPythonDebugging ). > > So python stack traces, python values, etc. > > I assume this is not implemented, but are there any plans, or is it even > feasible to implement? > > Regards, Alex. > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
