The Apple compiler and debugger teams are seeking exceptional engineers (to
work on LLVM, Clang and LLDB) who are passionate about improving software
development tools. Detailed job descriptions follow. Please send all
responses to llvm-job-ap...@group.apple.com, including the relevant job tit
Hi,
When user tries to stop debugging, we call SBDebugger.Destroy(), then
SBDebugger.Terminate() and exit the python process. This works well on mac,
but on linux in running mode. However, I found if the debugger hits
breakpoint first, then user stops debugging, the inferior is killed with
siginal
Thanks, I will try this escape mechanism for the returned C string.
On Mon, Mar 28, 2016 at 1:04 PM, Greg Clayton wrote:
>
> > On Mar 28, 2016, at 11:38 AM, Jeffrey Tan
> wrote:
> >
> > Thanks Greg for the detailed explanation, very helpful.
> > 1. Just to confirm, the weird string displayed is
How did you install swig? Sounds like it isn't installed correctly. If you used
homebrew, install "swig" and "swig-python". And if that doesn't work email Todd
Fiala directly.
Just for kicks, here is a list of files that we install for swig to give you an
idea of everything we install (director
> On Mar 28, 2016, at 11:38 AM, Jeffrey Tan wrote:
>
> Thanks Greg for the detailed explanation, very helpful.
> 1. Just to confirm, the weird string displayed is because 'data_' points to
> some random memory?
Yes.
> So what gdb displays is also some random memory content not something that
And btw, to get the obvious out of the way, I do have swig installed, and
"which swig" finds it in /opt/local/bin/swig
On Mon, Mar 28, 2016 at 12:48 PM Zachary Turner wrote:
> Trying to get an Xcode build working, and I keep getting this error:
>
> ERROR:root:Unable to find swig executable: 'mod
Trying to get an Xcode build working, and I keep getting this error:
ERROR:root:Unable to find swig executable: 'module' object has no attribute
'OSError'
Command /bin/sh failed with exit code 250
Does anyone know how to diagnose this? There's no other useful information
in the log file.
I t
Sorry, the current status is that lldb-server is no longer needed, however
the debuggee process hangs and the lldb.exe is "froze" (i.e. it does not
accept user input)
Here is the backtrace: http://pastebin.com/mbLFgCA6
I will try and get lldb built in debug mode for better debugging... but
this wi
I was able to locate the problematic code: ProcessWindowsLive::Initialize()
was not called due to wrong macros
http://reviews.llvm.org/D18520
On Mon, Mar 28, 2016 at 9:31 PM, Eran Ifrah wrote:
> Done.
>
> http://reviews.llvm.org/D18519
>
>
> On Mon, Mar 28, 2016 at 9:28 PM, Zachary Turner
> wr
Yes, that should work too. The thing that doesn't work is to just let the C++
destructor chain tear down the debuggers you've made. It should be possible to
make that work, but nobody's had time to make that happen, and given you can
avoid the crashes if you exit cleanly, it hasn't been a terr
Ah, Thanks adding Debugger::Destroy at the end of my code made the
segfaults disappear.
Also as far as I understood the lldb code (Core/Debugger.cpp) it
should also be possible to call SBDebugger::Terminate() for "destroy"
all instances of lldb related objects.
2016-03-28 20:22 GMT+02:00 Jim Ingha
Thanks Greg for the detailed explanation, very helpful.
1. Just to confirm, the weird string displayed is because 'data_' points to
some random memory? So what gdb displays is also some random memory content
not something that more meaningful than us? I thought we(lldb) did not
display std::string
This is kind of orthogonal to your problem, but the reason why you are not
seeing the kind of simplified printing Greg is suggesting, is because your
std::string doesn’t look like any of the kinds we recognize
Specifically, LLDB data formatters work by matching against type names, and
once they
Done.
http://reviews.llvm.org/D18519
On Mon, Mar 28, 2016 at 9:28 PM, Zachary Turner wrote:
> Almost, there's one more step. Click Create a New Revision on that
> screen, then give it a title and a description. For reviewers put zturner,
> and for subscribers put lldb-commits
>
> On Mon, Mar
Almost, there's one more step. Click Create a New Revision on that screen,
then give it a title and a description. For reviewers put zturner, and for
subscribers put lldb-commits
On Mon, Mar 28, 2016 at 11:20 AM Eran Ifrah wrote:
> Is this what you meant:
> http://reviews.llvm.org/differential
lldb doesn't currently work if you leave the process of cleaning up to the C++
destructor chain. You need to call Debugger::Destroy on your way out.
I think there's a bunch more cleanup than just the broadcaster/listener stuff
before we'll do this right.
Jim
> On Mar 28, 2016, at 8:55 AM, P
Is this what you meant:
http://reviews.llvm.org/differential/diff/51809/
Thanks
On Mon, Mar 28, 2016 at 8:58 PM, Zachary Turner wrote:
> For the patch, can you create an account on reviews.llvm.org, and upload
> your patch there? This makes interactive reviewing / commenting much
> easier. Le
If you compile with MSVC or Clang-cl it wouldn't ask for lldb-server. So
most likely there is some code that is using #if defined(_MSC_VER) when it
should be using #if defined(LLVM_ON_WINDOWS).
You'll have to hunt that down, but a good starting point might be to put a
breakpoint in ProcessWindows
For the patch, can you create an account on reviews.llvm.org, and upload
your patch there? This makes interactive reviewing / commenting much
easier. Let me know if you need help getting that set up.
On Mon, Mar 28, 2016 at 10:58 AM Zachary Turner wrote:
> If you compile with MSVC or Clang-cl
Thanks Greg. Yes, as I tried in another thread, the error seems to go away
after patching with this fix.
On Mon, Mar 28, 2016 at 9:33 AM, Greg Clayton wrote:
> This seems to have been fixed with the http://reviews.llvm.org/D18008.
>
> > On Mar 28, 2016, at 9:31 AM, Greg Clayton via lldb-dev <
>
So you need to be prepared to escape any text that can have special characters.
A "std::string" or any container can contain special characters. If you are
encoding stuff into JSON, you will either need to escape any special
characters, or hex encode the string into ASCII hex bytes.
In debugge
This seems to have been fixed with the http://reviews.llvm.org/D18008.
> On Mar 28, 2016, at 9:31 AM, Greg Clayton via lldb-dev
> wrote:
>
> Is it possible for me to see the "biggrep_master_server_async" binary? I
> would like to look at the DWARF and try to figure out what is wrong. It seems
Is it possible for me to see the "biggrep_master_server_async" binary? I would
like to look at the DWARF and try to figure out what is wrong. It seems that
this code is what is causing the problem:
CompilerType member_clang_type = member_type->GetLayoutCompilerType ();
if (!member_clang_type.Is
On Mon, Mar 28, 2016 at 6:56 PM, Zachary Turner wrote:
> Patches welcome. If you can split it into independent pieces that would be
> helpful, but it's not always possible.
>
> Patch is attached, I think you will find it quite straight forward - feel
free to comment and send it back for revise
Patches welcome. If you can split it into independent pieces that would be
helpful, but it's not always possible.
The NativeProcessProtocol error, that's the interface that converts
debugging events that occur on the inferior into packets that can be sent
to the server, and vice versa. Since Windo
Hey again,
I've noticing segfaults after r262863
(dc5ef2da510f3adba99cd8b2fe18c2e6d417227d).
Could you try reproducing this bug with this code please?
int main() {
using namespace lldb;
SBDebugger::Initialize();
SBDebugger debugger = SBDebugger::Create(true);
if(!debugger.IsValid()) {
On Mon, Mar 28, 2016 at 6:10 PM, Zachary Turner wrote:
> I'm the main Windows maintainer,
Hi
> and while We've gotten things working pretty well on Windows, our effort
> has been 100% on building with msvc and/or clang-cl. Building with mingw
> has a different set of pre processor defines an
I'm the main Windows maintainer, and while We've gotten things working
pretty well on Windows, our effort has been 100% on building with msvc
and/or clang-cl. Building with mingw has a different set of pre processor
defines and some other subtle differences, so it doesn't surprise me that
things do
28 matches
Mail list logo
