On 20190826 21:41, Jim Ingham wrote:
The GUI is built into lldb, it is not a separate entity.
Oh, right, so a "AUI" or "CUI" rather than something properly graphical. Sorry,
not very useful to me.
R.
___
lldb-dev mailing list
lldb-dev@lists.llvm.or
On Monday August 26 2019 11:18:28 Raphael “Teemperor” Isemann via lldb-dev
wrote:
>> On 25. Aug 2019, at 02:02, Greg Clayton via lldb-dev
>> wrote:
>>
>> I know many people use it.
Count me among those who didn't even know it existed - is it even packaged in
any of the official LLVM (.deb) p
Hi,
clang has this nice runtime OS version checker but I cannot seem to find if
this is useable anywhere except on Apple OSes.
For ObjC (and thus @available()) one can still argue that the language isn't of
much use anywhere else, but that (lousy) argument doesn't fly
for__builtin_available() .
On Tuesday May 30 2017 11:07:10 Laghzaoui Mohammed via lldb-dev wrote:
>when i try to build LLDB in xcode , i get this error:
>"The specified item could not be found in the keychain"
Did you follow the instructions on how to set up your build environment and in
particular on how to generate (or o
Greg Clayton via lldb-dev wrote:
> Please do submit this for review, yes.
Just a bump to observe that debug information still behaves as if it's not
there
in binaries built with LTO on Mac (except possibly in very simple executables
that don't link to any shared libraries).
R.
__
Hi,
I'm working on a crash reporter tool that invokes and controls lldb through a
batchfile. As described
(http://stackoverflow.com/questions/26267289/how-can-i-exit-lldb-after-running-commands-with-o)
it is tricky to get older lldb versions to exit cleanly because they don't
react as they sho
On Tuesday September 13 2016 11:09:11 Chris Bieneman wrote:
>> - fix finding CheckAtomic.cmake (or just install it with LLVM)
>
>CheckAtomic is installed with LLVM on trunk, and will be this way in future
>releases.
Good, thanks for confirming that the tentative solution I adopted in my 3.9.0
p
On Saturday September 10 2016 17:26:26 Michał Górny wrote:
Re: MIUtilParse: I'm building the 3.9.0 release so no worries that the class
has been added back supposing it was removed *after* the release.
>> Agree that a standalone build would be great to have working, it just
>> requires someone w
There's another issue with the standalone build.
I call cmake with -DDCMAKE_INSTALL_PREFIX=/opt/local/libexec/llvm-3.9, so that
lldb gets installed with the rest of llvm 3.9, into /opt/local/libexec/llvm-3.9
. It looks like liblldb.${version} is generated with the wrong install path
recorded:
On Friday September 09 2016 20:00:34 Zachary Turner wrote:
>To be completely honest with you I don't even know why this class exists.
>All it needs to do is use llvm's regex class. The entire MIUtilParse.h /
>.cpp files can be deleted as far as I'm concerned.
That clearly needs a bit more work, i
Hi,
I wanted to see how far I could get with a standalone build, so I copied the
missing CheckAtomic.cmake file into the installed cmake/llvm directory, and
tried to build lldb.
It aborted at 93% because it tried to include a headerfile from the llvm source:
{{{
In file included from
/opt/loc
On Friday September 09 2016 10:34:37 Greg Clayton wrote:
Hi,
>The biggest issue with trying to use cmake on macOS is that there is no
>support for building frameworks, please correct me if I am wrong. The xcode
>build will build a "LLDB.framework" that contains all headers and the shared
>libr
On Friday September 09 2016 10:42:34 Pavel Labath wrote:
Hi Pavel
Thanks for pointing me to
> Hi Rene,
> lldb/cmake/modules/LLDBStandalone.cmake for how to set it up. As far
> as I know, the main trick is pointing your build to the llvm-config
> binary installed by the llvm package
So, adding
Hi,
I've been working on a MacPorts port for lldb (MacPorts already provides ports
for llvm and clang; cf. https://trac.macports.org/ticket/45251). Using the
Xcode project isn't really an option here, so I've based my approach on the
instructions for building using CMake on *n*x.
In short:
-
On Thursday September 01 2016 10:55:50 Jim Ingham wrote:
>You don't have to reboot after every attempt to sign an executable. You only
>have to reboot after making the code signing identity and, doing the little
>command line trick to get the system to accept it. That still seems
>necessary,
On Thursday September 01 2016 13:44:36 René J.V. Bertin wrote:
Here's a thought for the code-signing.txt document, following suggestions at
https://sourceware.org/gdb/wiki/BuildingOnDarwin :
Try a `killall -1 taskgated` before attempting a reboot. Wait a bit and then do
`ps -axlww | fgrep taskg
> Don't forget that the debugger can attach to an already running
> processes as well. without setuid, it could presumably attach only to
> own processes, but if it's running as root...
Good catch, you're right (on OS X, haven't tried on Linux yet).
R.
On Thursday September 01 2016 10:14:16 Pavel Labath wrote:
> security safeguards on osx (there certainly aren't any on linux), but
There's the codesigning bit. But that's just more a nuisance than a real
protection, from what I can tell, at least against code you build and install
yourself.
>
Hi,
MacPorts has long had ports for llvm and clang which are very practical. Ports
for lldb have been missing until now, so I've been trying to create one based
on the existing clang port. That wasn't particularly difficult, except (who'd
guess) for the codesigning bit.
Two questions:
- to w
Hi,
FYI ...
When I asked about supporting lldb in IDEs year or so ago the consensus was
that the best approach involved writing a dedicated front-end (driver) rather
than communicating with an existing driver. I've let that slip for various
reasons including not having the time and energy to s
On Monday April 25 2016 20:37:00 Philippe Lavoie via lldb-dev wrote:
>Hello,
>
>We noticed an issue with dwarf parsing when debugging a large application
>compiled with LTO.
I don't know if this is related or not, but on OS X it seems that using LTO
causes debug info to be lost altogether (thoug
21 matches
Mail list logo
