You need to specify the executable to debug before attempting to connect
to the remote machine:
lldb-mi --interpreter
-file-exec-and-symbols local/path/to/executable
-target-select remote host:port
Note that the file-exec-and-symbols command has some non-standard
extensions in LLDB-MI that
Is there any MI command for connecting remote target ?
Using platform and target command with lldb, It works fine as follows:
-host log--
twoflower@js1-desktop ~/local-hello> ls
a.out* hello.cpp
twoflower@js1-desktop ~/local-hello> lldb-3.8.1
(lldb) platform select remote-linux
Pla
Thank you for kind help.
It seems to work nicely(from lldb4.0(win) to lldbserver3.8) for me.
나의 iPhone에서 보냄
2016. 9. 22. 오후 7:45 Pavel Labath 작성:
> On 22 September 2016 at 04:51, Chunseok Lee via lldb-dev
> wrote:
>> Actually, I am trying to remote-debug from lldb(win host) to
>> lldb-server
https://llvm.org/bugs/show_bug.cgi?id=30492
Bug ID: 30492
Summary: On Linux, lldb lit tests fail
Product: lldb
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
I like the JSON approach. We might need to include the mangled name for the
function or specify where arguments go if we aren't going to expect a canned
function to be in each dylib. That is a bit harder, but something we should
think about.
If we look at __cxa_demangle:
char* abi::__cxa_dema
I put it up for review. I don't expect anyone to actually review it since
it's quite large and 99% of it is the same exact thing. I'm running tests
on Linux and Windows right now. Will also test on Mac if beanz's new lldb
framework thing works out for me. I'm going to try to commit sometime
aft
On Wed, Sep 21, 2016 at 4:13 PM, Greg Clayton via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
> You could have a setting that allows you to specify prefix as the key with
> a dylib path as a value. Would you expect a function with certain name or
> would you need to specify the function name (proba
> On Sep 22, 2016, at 1:48 AM, Johan Engelen wrote:
>
> It'd be great if an external lib could be used for the demangling.
>
> Zooming out a little:
> `Mangled::GetDemangledName(lldb::LanguageType language)` takes a language as
> parameter (unused), which to me looks like the plan was to move
That sounds like a good patch. I look forward to seeing it.
> On Sep 21, 2016, at 11:48 PM, Zachary Turner via lldb-dev
> wrote:
>
> I have a patch I'd like to submit tomorrow which converts all of the global
> command option tables from C-style arrays to llvm ArrayRefs.
>
> Actually they are
https://llvm.org/bugs/show_bug.cgi?id=30488
Bug ID: 30488
Summary: boost::shared_ptr type show as 'element_type *' in GUI
mode
Product: lldb
Version: 3.6
Hardware: PC
OS: Linux
Status: NEW
I am a bit late to the party, but anyways, here are my thoughts on the
issues here:
On 19 September 2016 at 21:18, Zachary Turner via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
> Difficulty / Effort: 3 (5 if we have to add enhanced mode support)
>
> Use llvm streams instead of lldb::StreamString
>
On 22 September 2016 at 04:51, Chunseok Lee via lldb-dev
wrote:
> Actually, I am trying to remote-debug from lldb(win host) to
> lldb-server(arm/x64 linux). In my case, The problem is that no
> lldb-sever-4.0 is available(I only have lldb-server 3.8 for arm/x64 linux).
> Q) lldb 4.0 and lldb-serve
https://llvm.org/bugs/show_bug.cgi?id=30485
Bug ID: 30485
Summary: lldb assertion "Architecture or OS not supported" when
loading Ubuntu core dump
Product: lldb
Version: 3.9
Hardware: PC
OS: Linux
It'd be great if an external lib could be used for the demangling.
Zooming out a little:
`Mangled::GetDemangledName(lldb::LanguageType language)` takes a language
as parameter (unused), which to me looks like the plan was to move this
into the language plugins?
Then D could have its own language p
14 matches
Mail list logo
