\On Sat, May 29, 2021 at 10:57 PM Raphael Isemann
wrote:
> And I think the best way to propose a new API is maybe just making a
> dummy patch that adds the API + documentation (doesn't need an actual
> implementation or tests). And if everyone agrees the new API is fine
> you can add the tests an
Hello,
I've recently been working on and with my Rust bindings to the public LLDB
API after a break of a couple of years.
A couple of things that I'm noticing or re-noticing:
We need more SB API coverage of logging functionality. We can't list
channels, categories via the SB API. We also don't h
On Fri, Dec 7, 2018 at 6:11 PM Raphael Isemann via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
> I think if we want to actually lower the entry barrier for
> contributing/fixing things on the website, then the server should do
> this. From what I know the other LLVM projects also generate the HTML
I like this a lot!
I commented on the patch since I didn't see this thread at the time, but
it'd be interesting to perhaps replace Epydoc with Sphinx as well.
- Bruce
On Fri, Dec 7, 2018 at 12:02 AM Jonas Devlieghere via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
> Hi everyone,
>
> The curren
Hello,
I was adding support for `SBStructuredData` to my Rust bindings for the
LLDB API and noticed a couple of things.
Since 5.0 isn't out yet and these are newer API additions, I was hoping
there might still be time to fix this.
`SBStructuredData::GetFloatValue` returns a `double`, but other t
Hello,
SBAttachInfo exposes a bunch of getters and setters for user ID, groupID,
parent process ID, effective user ID, effective group ID.
It doesn't seem like one would set these to anything prior to attaching,
but I also don't see in the code where they might get set in the event of a
successfu
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 mor
Stepping one step back further in the thread ...
On Wed, Nov 18, 2015 at 8:35 AM, Zachary Turner via lldb-commits <
lldb-comm...@lists.llvm.org> wrote:
> Moving this back over to the list since I'm sure others have some input
> here. Also +lldb-dev since it has more visibility than lldb-commits.
On Fri, Nov 6, 2015 at 1:00 AM, Greg Clayton wrote:
>
> > On Nov 5, 2015, at 1:21 AM, Bruce Mitchener via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >
> > Greg et al:
> >
> > When linking (cmake on OS X), I get a lot of warnings like this:
> >
Greg et al:
When linking (cmake on OS X), I get a lot of warnings like this:
ld: warning: cannot export hidden symbol lldb::endian::InlHostByteOrder()
from
lib/liblldbPluginProcessUtility.a(RegisterContextDarwin_arm64.cpp.o)
Should this function be in the public namespace?
It is an inli
In the LLDB project, you have 3 different defines:
LLDB_CONFIGURATION_DEBUG
LLDB_CONFIGURATION_RELEASE
LLDB_CONFIGURATION_BUILD_AND_INTEGRATION
I can easily set this up to be set for the various build types in cmake,
but I'd like to make sure we all agree about what should happen first:
CMAKE_BU
Howdy!
I was looking at some of the CompilerType changes and had some questions
related to the recent cleanups and renamings.
- clang_type_t is a typedef for void* and is used for the opaque qual
type code among other things. However, the m_type on CompilerType is just a
void*. Should
The error that Ted was seeing is now fixed on SVN HEAD.
- Bruce
On Thu, Sep 10, 2015 at 12:51 AM, Zachary Turner via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
> The community's current plan of record is still to kill the autoconf build
> but there is no definitive timeline on when it will be
There were 2 changes made this week that broke both the cmake and one that
broke the Makefile builds. I checked in fixes for the cmake build, but no
one has done similar for the Makefile build (as far as I've noticed).
(Notably, there's no Makefile support for
source/Plugins/ExpressionParser/Clang
The change for the ExpressionParser plugin didn't have changes in it for
the cmake or Makefile-based build systems.
I'll check in the cmake changes once my test build completes successfully.
- Bruce
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
htt
e this.
>
> If we can do that, we'd want to include "llvm/Support/Compiler.h" in just
> about everything to pick up the LLVM_LIBRARY_VISIBILITY definition. Would
> we be able to put that in one of the LLDB headers that is already included
> everywhere?
>
> - Bruc
n. Would
we be able to put that in one of the LLDB headers that is already included
everywhere?
- Bruce
On Fri, Aug 14, 2015 at 11:14 PM, Greg Clayton wrote:
>
> > On Aug 13, 2015, at 6:43 PM, Bruce Mitchener via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >
&g
Hello,
On Mac OS X, when using the xcode projects, there is some machinery to
manage what symbols are exported from various things:
- liblldb only exports the public API.
- debugserver only exports _DNB* and __DNB*
- argdumper exports nothing
- lldb-server exports nothing
This machi
Just in case the below came out with a resolution of "Let's remove it", I
submitted this for review:
http://reviews.llvm.org/D11971
- Bruce
On Wed, Aug 12, 2015 at 11:21 AM, Bruce Mitchener wrote:
> Hello!
>
> This is probably for the Apple People since it relates to debugserver...
>
> I
Hello!
This is probably for the Apple People since it relates to debugserver...
I was going to fix an issue with the cmake build on Mac OS X related to the
mig generation step and DNBConfig.h, but when I started digging into
things, I noticed that DNBConfig.h isn't needed any longer.
The only te
20 matches
Mail list logo
