Re: [lldb-dev] LLDB /w Windows and MinGW64
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 don't work quite right. You can try getting lldb-server to build and run under Windows, or you can try to get it to use the non lldb server codepath on MinGW, but you may still run into some issues after that as well, since you're the first person afaik to try building with MinGW On Sun, Mar 27, 2016 at 10:29 PM Eran Ifrah via lldb-dev < lldb-dev@lists.llvm.org> wrote: > Hi, > > I have built LLDB on Windows 7 using MinGW64/4.9.2 (took some effort to > get the job done...) > When I tried to debug a simple hello world executable, I get this output: > > D:\software\msys-for-clang\1.0\home\PC\build-release-64-lldb\bin>lldb.exe > HelloWorld.exe > (lldb) target create "HelloWorld.exe" > Current executable set to 'HelloWorld.exe' (x86_64). > (lldb) b main.cpp:7 > Breakpoint 1: where = HelloWorld.exe`main + 26 at main.cpp:7, address = > 0x0040154a > (lldb) r > error: process launch failed: unable to locate lldb-server > (lldb) > > I can't seem to locate lldb-server anywhere, and according > to LLDBConfig.cmake, this target should not get built on Windows: > > # Figure out if lldb could use lldb-server. If so, then we'll > # ensure we build lldb-server when an lldb target is being built. > if ((CMAKE_SYSTEM_NAME MATCHES "Darwin") OR > (CMAKE_SYSTEM_NAME MATCHES "FreeBSD") OR > (CMAKE_SYSTEM_NAME MATCHES "Linux") OR > (CMAKE_SYSTEM_NAME MATCHES "NetBSD")) > set(LLDB_CAN_USE_LLDB_SERVER 1) > else() > set(LLDB_CAN_USE_LLDB_SERVER 0) > endif() > > and in the tools/CMakeLists.txt file we have this: > > if (LLDB_CAN_USE_LLDB_SERVER) > add_subdirectory(lldb-server) > endif() > > > Any ideas? > > Thanks, > > -- > Eran Ifrah, > Author of > CodeLite > , a cross platform open source C/C++ IDE: http://www.codelite.org > CodeLite IDE Blog: http://codeliteide.blogspot.com/ > ___ > 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
Re: [lldb-dev] LLDB /w Windows and MinGW64
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 and some other subtle
> differences, so it doesn't surprise me that things don't work quite right.
>
> I got it to compile (I have a big patch that I can send you if you are
interested)
mainly involves blocking code under __MINGW32__ and some updates to the
various CMakeLists.txt and AddLLDB.cmake module files
Some functions are missing in MinGW implementations (like gets_s and others
:/)
> You can try getting lldb-server to build and run under Windows, or you can
> try to get it to use the non lldb server codepath on MinGW, but you may
> still run into some
I got lldb-server to compile and run on Windows, however, it crashes
immediately and the backtrace shows this:
0 0x00724615
lldb_private::NativeProcessProtocol::Launch(lldb_private::ProcessLaunchInfo&,
lldb_private::NativeProcessProtocol::NativeDelegate&,
lldb_private::MainLoopBase&,
std::shared_ptr&)
1 0x005f815d
lldb_private::process_gdb_remote::GDBRemoteCommunicationServerLLGS::LaunchProcess()
2 0x004020e5
handle_launch(lldb_private::process_gdb_remote::GDBRemoteCommunicationServerLLGS&,
int, char const* const*)
3 0x0040335e main_gdbserver(int, char**)
4 0x0188329c main
I had to #ifndef __MINGW32__ around lldb-platform.cpp as it contains too
much Linux code that can not be compiled under Windows (fork, exec*)
and basically lldb-server calls the main_gdbserver instead of main_platform
function
Looking at the function that crashes, I see this:
llvm_unreachable("Platform has no NativeProcessProtocol support");
Any ideas?
Thanks!
issues after that as well, since you're the first person afaik to try
> building with MinGW
>
> On Sun, Mar 27, 2016 at 10:29 PM Eran Ifrah via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
>> Hi,
>>
>> I have built LLDB on Windows 7 using MinGW64/4.9.2 (took some effort to
>> get the job done...)
>> When I tried to debug a simple hello world executable, I get this output:
>>
>> D:\software\msys-for-clang\1.0\home\PC\build-release-64-lldb\bin>lldb.exe
>> HelloWorld.exe
>> (lldb) target create "HelloWorld.exe"
>> Current executable set to 'HelloWorld.exe' (x86_64).
>> (lldb) b main.cpp:7
>> Breakpoint 1: where = HelloWorld.exe`main + 26 at main.cpp:7, address =
>> 0x0040154a
>> (lldb) r
>> error: process launch failed: unable to locate lldb-server
>> (lldb)
>>
>> I can't seem to locate lldb-server anywhere, and according
>> to LLDBConfig.cmake, this target should not get built on Windows:
>>
>> # Figure out if lldb could use lldb-server. If so, then we'll
>> # ensure we build lldb-server when an lldb target is being built.
>> if ((CMAKE_SYSTEM_NAME MATCHES "Darwin") OR
>> (CMAKE_SYSTEM_NAME MATCHES "FreeBSD") OR
>> (CMAKE_SYSTEM_NAME MATCHES "Linux") OR
>> (CMAKE_SYSTEM_NAME MATCHES "NetBSD"))
>> set(LLDB_CAN_USE_LLDB_SERVER 1)
>> else()
>> set(LLDB_CAN_USE_LLDB_SERVER 0)
>> endif()
>>
>> and in the tools/CMakeLists.txt file we have this:
>>
>> if (LLDB_CAN_USE_LLDB_SERVER)
>> add_subdirectory(lldb-server)
>> endif()
>>
>>
>> Any ideas?
>>
>> Thanks,
>>
>> --
>> Eran Ifrah,
>> Author of
>> CodeLite
>> , a cross platform open source C/C++ IDE: http://www.codelite.org
>> CodeLite IDE Blog: http://codeliteide.blogspot.com/
>> ___
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>
>
--
Eran Ifrah,
Author of codelite, a cross platform open source C/C++ IDE:
http://www.codelite.org
CodeLite IDE Blog: http://codeliteide.blogspot.com/
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] SBListener not using a shared_ptr internally? (Update: Segfault after r262863)
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()) {
return 1;
}
SBTarget target = debugger.CreateTarget("/home/dev/helloWorld/main");
if(!target.IsValid()) {
return 1;
}
const char* args[] = { "/home/dev/helloWorld/main", 0 };
const char* env[] = { 0 };
SBLaunchInfo launch_info(args);
launch_info.SetEnvironmentEntries(env, true);
launch_info.SetWorkingDirectory("/home/dev/helloWorld");
launch_info.SetLaunchFlags(eLaunchFlagStopAtEntry);
SBError error;
SBProcess process = target.Launch(launch_info, error);
return 0;
}
I tried to build lldb with and without the above commit and it turns
out that the revision is causing the segfault when simply running that
code (When it's exiting).
This is the backtrace:
#0 0x55b03b00 in ?? ()
#1 0x771be1aa in
lldb_private::Broadcaster::BroadcasterImpl::RestoreBroadcaster() ()
from /usr/lib/liblldb.so.3.8.0
#2 0x7748b674 in
lldb_private::process_gdb_remote::GDBRemoteCommunicationClient::SendPacketAndWaitForResponse(char
const*, unsigned long, StringExtractorGDBRemote&, bool) () from
/usr/lib/liblldb.so.3.8.0
#3 0x7748e89d in
lldb_private::process_gdb_remote::GDBRemoteCommunicationClient::SendGDBStoppointTypePacket(lldb_private::process_gdb_remote::GDBStoppointType,
bool, unsigned long, unsigned int) () from /usr/lib/liblldb.so.3.8.0
#4 0x7746fdab in
lldb_private::process_gdb_remote::ProcessGDBRemote::DisableBreakpointSite(lldb_private::BreakpointSite*)
() from /usr/lib/liblldb.so.3.8.0
#5 0x7733938b in std::_Function_handler::_M_invoke(std::_Any_data
const&, lldb_private::BreakpointSite*&&) () from
/usr/lib/liblldb.so.3.8.0
#6 0x7716ae4f in
lldb_private::BreakpointSiteList::ForEach(std::function const&) () from
/usr/lib/liblldb.so.3.8.0
#7 0x7733ba9f in
lldb_private::Process::DisableAllBreakpointSites() () from
/usr/lib/liblldb.so.3.8.0
#8 0x7734a58c in lldb_private::Process::Destroy(bool) () from
/usr/lib/liblldb.so.3.8.0
#9 0x7734aa2d in lldb_private::Process::Finalize() () from
/usr/lib/liblldb.so.3.8.0
#10 0x771d3fe0 in lldb_private::Debugger::Clear() () from
/usr/lib/liblldb.so.3.8.0
#11 0x771d97cf in lldb_private::Debugger::~Debugger() () from
/usr/lib/liblldb.so.3.8.0
#12 0x771da0c8 in
std::_Sp_counted_ptr::_M_dispose() () from
/usr/lib/liblldb.so.3.8.0
#13 0x771cdceb in
std::vector,
std::allocator > >::~vector()
() from /usr/lib/liblldb.so.3.8.0
#14 0x760d9c38 in __run_exit_handlers () from /usr/lib/libc.so.6
#15 0x760d9c85 in exit () from /usr/lib/libc.so.6
#16 0x760c4717 in __libc_start_main () from /usr/lib/libc.so.6
#17 0x4f69 in _start ()
2016-03-25 22:42 GMT+01:00 Jim Ingham :
> What version of the lldb sources are you working with? I changed the
> SBListener over to using only the ListenerSP internally
> in r262863.
>
> Jim
>
>> On Mar 25, 2016, at 1:03 PM, Paul Peet via lldb-dev
>> wrote:
>>
>> Hey,
>>
>> I am currently working on lldb bindings for javascript (v8) but it
>> seems that the API is giving me some troubles.
>>
>> What I am doing is to basically wrap SB* objects into V8 objects, and
>> since SB objects contain a shared_ptr into an internal class I think I
>> can simply copy construct them.
>>
>> To return a wrapped SB object by some Javascript function, I am simply
>> copy constructing the SB object into the wrapper object which is
>> dynamically allocated and when the Javascript object is garbage
>> collected it will also destroy the SBObject (And also the shared_ptr,
>> So it should be save I guess?).
>>
>> Okay, so far so good but I detected some inconsistency when trying to
>> wrap SBListener. The deal was to make SBListener::WaitForEvent
>> non-blocking, to do that I am creating a new thread which calls
>> WaitForEvents, when it returns and the event is valid, the callbacks
>> given from the Javascript code is called.
>>
>> There is a catch when doing this. I have to track the threads which
>> belong to a specific SBListener. But there is not actually easy way to
>> do this because SB objects are just simply shared_ptr. I noticed the
>> GetSP function which returns the shared_ptr of an SBListener, this
>> would be a way to solve this issue as I could use a map which maps the
>> internal SBListener pointer to a Class object which manages the thread
>> and stuff (SBListenerWorker).
>>
>> // etc. mutex, ...
>> static std::unordered_map ListenerWorkers;
>>
>> GetSP is protected so I had to create a new derived class:
>>
>> class SBListener_Internal : public lldb::SBListener {
>> public:
>> SBListener_Internal() = default;
>> SBListener_Internal(const lldb::SBListener& listener)
>> : lldb::SBListen
Re: [lldb-dev] LLDB /w Windows and MinGW64
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 Windows doesn't currently use lldb
server, this piece has never been written for Windows
On Mon, Mar 28, 2016 at 8:41 AM Eran Ifrah wrote:
> 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 and some other subtle
>> differences, so it doesn't surprise me that things don't work quite right.
>>
>> I got it to compile (I have a big patch that I can send you if you are
> interested)
> mainly involves blocking code under __MINGW32__ and some updates to the
> various CMakeLists.txt and AddLLDB.cmake module files
> Some functions are missing in MinGW implementations (like gets_s and
> others :/)
>
>
>
>> You can try getting lldb-server to build and run under Windows, or you
>> can try to get it to use the non lldb server codepath on MinGW, but you may
>> still run into some
>
> I got lldb-server to compile and run on Windows, however, it crashes
> immediately and the backtrace shows this:
>
> 0 0x00724615
> lldb_private::NativeProcessProtocol::Launch(lldb_private::ProcessLaunchInfo&,
> lldb_private::NativeProcessProtocol::NativeDelegate&,
> lldb_private::MainLoopBase&,
> std::shared_ptr&)
> 1 0x005f815d
>
> lldb_private::process_gdb_remote::GDBRemoteCommunicationServerLLGS::LaunchProcess()
>
> 2 0x004020e5
>
> handle_launch(lldb_private::process_gdb_remote::GDBRemoteCommunicationServerLLGS&,
> int, char const* const*)
> 3 0x0040335e main_gdbserver(int, char**)
> 4 0x0188329c main
>
>
> I had to #ifndef __MINGW32__ around lldb-platform.cpp as it contains too
> much Linux code that can not be compiled under Windows (fork, exec*)
> and basically lldb-server calls the main_gdbserver instead of
> main_platform function
>
> Looking at the function that crashes, I see this:
>
> llvm_unreachable("Platform has no NativeProcessProtocol support");
>
> Any ideas?
> Thanks!
>
> issues after that as well, since you're the first person afaik to try
>> building with MinGW
>>
>
>
>> On Sun, Mar 27, 2016 at 10:29 PM Eran Ifrah via lldb-dev <
>> lldb-dev@lists.llvm.org> wrote:
>>
>>> Hi,
>>>
>>> I have built LLDB on Windows 7 using MinGW64/4.9.2 (took some effort to
>>> get the job done...)
>>> When I tried to debug a simple hello world executable, I get this output:
>>>
>>> D:\software\msys-for-clang\1.0\home\PC\build-release-64-lldb\bin>lldb.exe
>>> HelloWorld.exe
>>> (lldb) target create "HelloWorld.exe"
>>> Current executable set to 'HelloWorld.exe' (x86_64).
>>> (lldb) b main.cpp:7
>>> Breakpoint 1: where = HelloWorld.exe`main + 26 at main.cpp:7, address =
>>> 0x0040154a
>>> (lldb) r
>>> error: process launch failed: unable to locate lldb-server
>>> (lldb)
>>>
>>> I can't seem to locate lldb-server anywhere, and according
>>> to LLDBConfig.cmake, this target should not get built on Windows:
>>>
>>> # Figure out if lldb could use lldb-server. If so, then we'll
>>> # ensure we build lldb-server when an lldb target is being built.
>>> if ((CMAKE_SYSTEM_NAME MATCHES "Darwin") OR
>>> (CMAKE_SYSTEM_NAME MATCHES "FreeBSD") OR
>>> (CMAKE_SYSTEM_NAME MATCHES "Linux") OR
>>> (CMAKE_SYSTEM_NAME MATCHES "NetBSD"))
>>> set(LLDB_CAN_USE_LLDB_SERVER 1)
>>> else()
>>> set(LLDB_CAN_USE_LLDB_SERVER 0)
>>> endif()
>>>
>>> and in the tools/CMakeLists.txt file we have this:
>>>
>>> if (LLDB_CAN_USE_LLDB_SERVER)
>>> add_subdirectory(lldb-server)
>>> endif()
>>>
>>>
>>> Any ideas?
>>>
>>> Thanks,
>>>
>>> --
>>> Eran Ifrah,
>>> Author of
>>> CodeLite
>>> , a cross platform open source C/C++ IDE: http://www.codelite.org
>>> CodeLite IDE Blog: http://codeliteide.blogspot.com/
>>> ___
>>> lldb-dev mailing list
>>> lldb-dev@lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>>
>>
>
>
> --
> Eran Ifrah,
> Author of codelite, a cross platform open source C/C++ IDE:
> http://www.codelite.org
> CodeLite IDE Blog: http://codeliteide.blogspot.com/
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] LLDB /w Windows and MinGW64
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
> 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 Windows doesn't currently use lldb
> server, this piece has never been written for Windows
So this raises the question: how come lldb asks for it? (see my first emai
inl this conversation)
I would have build LLDB in debug mode, but it seems that MinGW as.exe fails
to write some of the files "File too big"
>
> On Mon, Mar 28, 2016 at 8:41 AM Eran Ifrah wrote:
>
>> 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 and some other subtle
>>> differences, so it doesn't surprise me that things don't work quite right.
>>>
>>> I got it to compile (I have a big patch that I can send you if you are
>> interested)
>> mainly involves blocking code under __MINGW32__ and some updates to the
>> various CMakeLists.txt and AddLLDB.cmake module files
>> Some functions are missing in MinGW implementations (like gets_s and
>> others :/)
>>
>>
>>
>>> You can try getting lldb-server to build and run under Windows, or you
>>> can try to get it to use the non lldb server codepath on MinGW, but you may
>>> still run into some
>>
>> I got lldb-server to compile and run on Windows, however, it crashes
>> immediately and the backtrace shows this:
>>
>> 0 0x00724615
>>
>> lldb_private::NativeProcessProtocol::Launch(lldb_private::ProcessLaunchInfo&,
>> lldb_private::NativeProcessProtocol::NativeDelegate&,
>> lldb_private::MainLoopBase&,
>> std::shared_ptr&)
>> 1 0x005f815d
>>
>> lldb_private::process_gdb_remote::GDBRemoteCommunicationServerLLGS::LaunchProcess()
>>
>> 2 0x004020e5
>>
>> handle_launch(lldb_private::process_gdb_remote::GDBRemoteCommunicationServerLLGS&,
>> int, char const* const*)
>> 3 0x0040335e main_gdbserver(int, char**)
>> 4 0x0188329c main
>>
>>
>> I had to #ifndef __MINGW32__ around lldb-platform.cpp as it contains too
>> much Linux code that can not be compiled under Windows (fork, exec*)
>> and basically lldb-server calls the main_gdbserver instead of
>> main_platform function
>>
>> Looking at the function that crashes, I see this:
>>
>> llvm_unreachable("Platform has no NativeProcessProtocol support");
>>
>> Any ideas?
>> Thanks!
>>
>> issues after that as well, since you're the first person afaik to try
>>> building with MinGW
>>>
>>
>>
>>> On Sun, Mar 27, 2016 at 10:29 PM Eran Ifrah via lldb-dev <
>>> lldb-dev@lists.llvm.org> wrote:
>>>
Hi,
I have built LLDB on Windows 7 using MinGW64/4.9.2 (took some effort to
get the job done...)
When I tried to debug a simple hello world executable, I get this
output:
D:\software\msys-for-clang\1.0\home\PC\build-release-64-lldb\bin>lldb.exe
HelloWorld.exe
(lldb) target create "HelloWorld.exe"
Current executable set to 'HelloWorld.exe' (x86_64).
(lldb) b main.cpp:7
Breakpoint 1: where = HelloWorld.exe`main + 26 at main.cpp:7, address =
0x0040154a
(lldb) r
error: process launch failed: unable to locate lldb-server
(lldb)
I can't seem to locate lldb-server anywhere, and according
to LLDBConfig.cmake, this target should not get built on Windows:
# Figure out if lldb could use lldb-server. If so, then we'll
# ensure we build lldb-server when an lldb target is being built.
if ((CMAKE_SYSTEM_NAME MATCHES "Darwin") OR
(CMAKE_SYSTEM_NAME MATCHES "FreeBSD") OR
(CMAKE_SYSTEM_NAME MATCHES "Linux") OR
(CMAKE_SYSTEM_NAME MATCHES "NetBSD"))
set(LLDB_CAN_USE_LLDB_SERVER 1)
else()
set(LLDB_CAN_USE_LLDB_SERVER 0)
endif()
and in the tools/CMakeLists.txt file we have this:
if (LLDB_CAN_USE_LLDB_SERVER)
add_subdirectory(lldb-server)
endif()
Any ideas?
Thanks,
--
Eran Ifrah,
Author of
CodeLite
, a cross platform open source C/C++ IDE: http://www.codelite.org
CodeLite IDE Blog: http://codeliteide.blogspot.com/
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>>
>>
>>
>> --
>> Eran Ifrah,
>> Author of codelite, a cross platform open source C/C++ IDE:
>> http://www.codelite.org
>> CodeLite IDE Bl
Re: [lldb-dev] DW_TAG_member extends beyond the bounds error on Linux
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.IsCompleteType())
member_clang_type.GetCompleteType();
{
// Older versions of clang emit array[0] and array[1] in the same way
().
// If the current field is at the end of the structure, then there is
definitely no room for extra
// elements and we override the type to array[0].
CompilerType member_array_element_type;
uint64_t member_array_size;
bool member_array_is_incomplete;
if (member_clang_type.IsArrayType(&member_array_element_type,
&member_array_size,
&member_array_is_incomplete) &&
!member_array_is_incomplete)
{
uint64_t parent_byte_size =
parent_die.GetAttributeValueAsUnsigned(DW_AT_byte_size, UINT64_MAX);
if (member_byte_offset >= parent_byte_size)
{
if (member_array_size != 1 && (member_array_size != 0 ||
member_byte_offset > parent_byte_size))
{
module_sp->ReportError ("0x%8.8" PRIx64 ": DW_TAG_member '%s'
refers to type 0x%8.8" PRIx64 " which extends beyond the bounds of 0x%8.8"
PRIx64,
die.GetID(),
name,
encoding_form.Reference(),
parent_die.GetID());
}
member_clang_type =
m_ast.CreateArrayType(member_array_element_type, 0, false);
}
}
}
So we are parsing a member variable, and the member variable's type is an array
type, and the offset of the member is beyond the parent's type's size and yet
the array claims to have a valid size.
This code is trying to correctly create an CompilerType for a struct such as
this:
struct MyStruct
{
size_t num_entries;
Entry entries[0];
};
Older versions of clang would emit the same DWARF for:
struct MyStruct
{
size_t num_entries;
Entry entries[0];
};
or
struct MyStruct
{
size_t num_entries;
Entry entries[1];
};
This is bad because in the DWARFASTParserClang we are trying to faithfully
re-create the type as the user initially created it.
This error is trying to say that you have a structure where the byte size of
"MyStruct" is something like 8 bytes, but "entries" is an array that has a
valid size (not zero or one) and that the offset of "entries" is greater than
or equal to 8. If "entries" has a size like:
struct MyStruct
{
size_t num_entries;
Entry entries[1];
};
You would expect the member offset for "entries" to be less than or equal to
the sizeof(MyStruct). If "Entry" is 8 bytes in size, you might expect the byte
size of "MyStruct" to be 16, and the offset of "num_entries" to be 0 and
"entries" to be 8. Both offsets are less than or equal to the byte size of 16.
If I can see the DWARF file I can tell you more. If I can't, you will need to
step through this code and see why this is triggering. The error message is
telling you all you need to know to dump the problem. So for this error message:
error: biggrep_master_server_async 0x10b9a91a: DW_TAG_member '_M_pod_data'
refers to type 0x10bb1e99 which extends beyond the bounds of 0x10b9a901
So if you dump the DWARF and look for the DIE at 0x10b9a91a, you will be able
to see the DWARF that is causing the problem. On MacOSX, I would do this:
% dwarfdump --debug-info=0x10b9a91a --show-children --show-parents
biggrep_master_server_async
llvm-dwarfdump will dump your entire file and you will need to look through a
ton of DWARF in the output. You will need to search for "0x10b9a91a:" (the
offset followed by a colon).
So LLDB believes it is pointing out an error in the DWARF that needs to be
fixed in the compiler. It could be an incorrect error, but I would need to see
the DWARF in question to know more. Debugging can happen just fine if you
ignore this error, it is actually more of a warning, but we emit an error so
users know to file a bug and hopefully get the compiler fixed.
Greg
> On Mar 26, 2016, at 5:10 PM, Jeffrey Tan via lldb-dev
> wrote:
>
> Sorry, sent to the wrong alias.
>
> -- Forwarded message --
> From: Jeffrey Tan
> Date: Sat, Mar 26, 2016 at 3:19 PM
> Subject: DW_TAG_member extends beyond the bounds error on Linux
> To: llvm-...@lists.llvm.org
>
>
> Hi,
>
> While dogfooding our lldb based IDE on Linux, I am seeing a lot of variable
> evaluation errors related to DW_TAG_member which prevents us from release the
> IDE. Can anyone help to confirm if they are known issues? If not, any
> information you need to troubleshoot this issue?
>
> Here is one example:
>
> (lldb) fr v
> error: biggrep_master_server_async 0x10b9a91a: DW_TA
Re: [lldb-dev] DW_TAG_member extends beyond the bounds error on Linux
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
> that this code is what is causing the problem:
>
>
> CompilerType member_clang_type = member_type->GetLayoutCompilerType ();
> if (!member_clang_type.IsCompleteType())
>member_clang_type.GetCompleteType();
>
> {
>// Older versions of clang emit array[0] and array[1] in the same way
> ().
>// If the current field is at the end of the structure, then there is
> definitely no room for extra
>// elements and we override the type to array[0].
>
>CompilerType member_array_element_type;
>uint64_t member_array_size;
>bool member_array_is_incomplete;
>
>if (member_clang_type.IsArrayType(&member_array_element_type,
> &member_array_size,
> &member_array_is_incomplete) &&
>!member_array_is_incomplete)
>{
>uint64_t parent_byte_size =
> parent_die.GetAttributeValueAsUnsigned(DW_AT_byte_size, UINT64_MAX);
>
>if (member_byte_offset >= parent_byte_size)
>{
>if (member_array_size != 1 && (member_array_size != 0 ||
> member_byte_offset > parent_byte_size))
>{
>module_sp->ReportError ("0x%8.8" PRIx64 ": DW_TAG_member '%s'
> refers to type 0x%8.8" PRIx64 " which extends beyond the bounds of 0x%8.8"
> PRIx64,
>die.GetID(),
>name,
>encoding_form.Reference(),
>parent_die.GetID());
>}
>
>member_clang_type =
> m_ast.CreateArrayType(member_array_element_type, 0, false);
>}
>}
> }
>
>
> So we are parsing a member variable, and the member variable's type is an
> array type, and the offset of the member is beyond the parent's type's size
> and yet the array claims to have a valid size.
>
> This code is trying to correctly create an CompilerType for a struct such as
> this:
>
> struct MyStruct
> {
>size_t num_entries;
>Entry entries[0];
> };
>
> Older versions of clang would emit the same DWARF for:
>
> struct MyStruct
> {
>size_t num_entries;
>Entry entries[0];
> };
>
> or
>
> struct MyStruct
> {
>size_t num_entries;
>Entry entries[1];
> };
>
> This is bad because in the DWARFASTParserClang we are trying to faithfully
> re-create the type as the user initially created it.
>
> This error is trying to say that you have a structure where the byte size of
> "MyStruct" is something like 8 bytes, but "entries" is an array that has a
> valid size (not zero or one) and that the offset of "entries" is greater than
> or equal to 8. If "entries" has a size like:
>
> struct MyStruct
> {
>size_t num_entries;
>Entry entries[1];
> };
>
> You would expect the member offset for "entries" to be less than or equal to
> the sizeof(MyStruct). If "Entry" is 8 bytes in size, you might expect the
> byte size of "MyStruct" to be 16, and the offset of "num_entries" to be 0 and
> "entries" to be 8. Both offsets are less than or equal to the byte size of 16.
>
> If I can see the DWARF file I can tell you more. If I can't, you will need to
> step through this code and see why this is triggering. The error message is
> telling you all you need to know to dump the problem. So for this error
> message:
>
> error: biggrep_master_server_async 0x10b9a91a: DW_TAG_member '_M_pod_data'
> refers to type 0x10bb1e99 which extends beyond the bounds of 0x10b9a901
>
> So if you dump the DWARF and look for the DIE at 0x10b9a91a, you will be able
> to see the DWARF that is causing the problem. On MacOSX, I would do this:
>
> % dwarfdump --debug-info=0x10b9a91a --show-children --show-parents
> biggrep_master_server_async
>
> llvm-dwarfdump will dump your entire file and you will need to look through a
> ton of DWARF in the output. You will need to search for "0x10b9a91a:" (the
> offset followed by a colon).
>
> So LLDB believes it is pointing out an error in the DWARF that needs to be
> fixed in the compiler. It could be an incorrect error, but I would need to
> see the DWARF in question to know more. Debugging can happen just fine if you
> ignore this error, it is actually more of a warning, but we emit an error so
> users know to file a bug and hopefully get the compiler fixed.
>
> Greg
>
>> On Mar 26, 2016, at 5:10 PM, Jeffrey Tan via lldb-dev
>> wrote:
>>
>> Sorry, sent to the wrong alias.
>>
>> -- Forwarded message --
>> From: Jeffrey Tan
>> Date: Sat, Mar 26, 2016 at 3:19 PM
>> Subject: DW_TAG_member extends beyond the bounds error on Linux
>> To: llvm-...@lists.llvm.org
>>
>>
>> Hi,
>>
>> While do
Re: [lldb-dev] UnicodeDecodeError for serialize SBValue description
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 debuggers we often get bogus data because variables are not initialized, but
the compiler tells us that a variable is valid in address range
[0x1000-0x2000), but it actually is [0x1200-0x2000). If we read a variable in
this case, a std::string might contain bogus data and the bytes might not make
sense. So you always have to be prepared for bad data.
If we look at:
store_ = {
= {
small_ = "www"
ml_ = (data_ =
"��UH\x89�H�}�H\x8bE�]ÐUH\x89�H��H\x89}�H\x8bE�H\x89��~\xb4��\x90��UH\x89�SH\x83�H\x89}�H�u�H�E�H���\x9e���H\x8b\x18H\x8bE�H���O\xb4��H\x89ƿ\b",
size_ = 0, capacity_ = 1441151880758558720)
}
}
}
We can see the "size_" is zero, and capacity_ is 1441151880758558720 (which is
0x1400). "data_" seems to be some random pointer.
On MacOSX, we have a special formatting code that displays std::string in
CPlusPlusLanguage.cpp that gets installed in the LoadLibCxxFormatters() or
LoadLibStdcppFormatters() functions with code like:
lldb::TypeSummaryImplSP std_string_summary_sp(new
CXXFunctionSummaryFormat(stl_summary_flags,
lldb_private::formatters::LibcxxStringSummaryProvider, "std::string summary
provider"));
cpp_category_sp->GetTypeSummariesContainer()->Add(ConstString("std::__1::string"),
std_string_summary_sp);
Special flags are set on std::string to say "don't show children of this and
just show a summary" So if a std::string contained "hello". So for the
following code:
std::string h ("hello");
You should just see:
(lldb) fr var h
(std::__1::string) h = "hello"
If you take a look at the normal value in the raw we see:
(lldb) fr var --raw h
(std::__1::string) h = {
__r_ = {
std::__1::__libcpp_compressed_pair_imp, std::__1::allocator >::__rep,
std::__1::allocator, 2> = {
__first_ = {
= {
__l = {
__cap_ = 122511465736202
__size_ = 0
__data_ = 0x
}
__s = {
= {
__size_ = '\n'
__lx = '\n'
}
__data_ = {
[0] = 'h'
[1] = 'e'
[2] = 'l'
[3] = 'l'
[4] = 'o'
[5] = '\0'
[6] = '\0'
[7] = '\0'
[8] = '\0'
[9] = '\0'
[10] = '\0'
[11] = '\0'
[12] = '\0'
[13] = '\0'
[14] = '\0'
[15] = '\0'
[16] = '\0'
[17] = '\0'
[18] = '\0'
[19] = '\0'
[20] = '\0'
[21] = '\0'
[22] = '\0'
}
}
__r = {
__words = {
[0] = 122511465736202
[1] = 0
[2] = 0
}
}
}
}
}
}
}
So the main question is why are our "std::string" formatters not kicking in for
you. That comes down to a typename match, or the format of the string isn't
what the formatter is expecting.
But again, since you std::string can contain anything, you will need to escape
any and all text that is encoded into JSON to ensure it doesn't contain
anything JSON can't deal with.
> On Mar 27, 2016, at 9:20 PM, Jeffrey Tan via lldb-dev
> wrote:
>
> Thanks Siva. All the DW_TAG_member related errors seems to go away after
> patching with your fix. The current problem is handling the decoding.
>
> Here is the correct decoding from gdb whic might be useful:
> (gdb) p corpus
> $3 = (const std::string &) @0x7fd133cfb888: {
> static npos = 18446744073709551615, store_ = {
> static kIsLittleEndian = ,
> static kIsBigEndian = , {
> small_ = "www", '\000' , "\024", ml_ = {
> data_ = 0x77 folly::fibers::Baton::waitFiber::prepareForSelection(facebook::servicerouter::DispatchContext&)::{lambda(folly::fibers::Promise::prepareForSelection(facebook::servicerouter::DispatchContext&)::SelectionResult>)#1},
> void>::type::value_type
> folly::fibers::await::prepareForSelection(facebook::servicerouter::DispatchContext&)::{lambda(folly::fibers::Promise::prepareForSelection(facebook::servicerouter::DispatchContext&)::SelectionResult>)#1}>(folly::fibers::FirstArgOf&&)::{lambda()#1}>(folly::fibers::FiberManager&,
>
> folly::fibers::FirstArgOf::prepareForSelection(facebook::servicerouter::DispatchContext&)::{lambda(folly::fibers::Promise::prepareForSelection(facebook::servicerouter::DispatchContext&)::SelectionResult>)#1},
> void>::type::value_type
> folly::fibers::await::prepareForSelection(facebook::servicerouter::DispatchContext&)::{lambda(folly::fibers::Promise::prepareForSelection(facebook::servicerouter::Di
Re: [lldb-dev] DW_TAG_member extends beyond the bounds error on Linux
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 <
> lldb-dev@lists.llvm.org> 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 that this code is what is causing the problem:
> >
> >
> > CompilerType member_clang_type = member_type->GetLayoutCompilerType ();
> > if (!member_clang_type.IsCompleteType())
> >member_clang_type.GetCompleteType();
> >
> > {
> >// Older versions of clang emit array[0] and array[1] in the same way
> ().
> >// If the current field is at the end of the structure, then there is
> definitely no room for extra
> >// elements and we override the type to array[0].
> >
> >CompilerType member_array_element_type;
> >uint64_t member_array_size;
> >bool member_array_is_incomplete;
> >
> >if (member_clang_type.IsArrayType(&member_array_element_type,
> > &member_array_size,
> > &member_array_is_incomplete) &&
> >!member_array_is_incomplete)
> >{
> >uint64_t parent_byte_size =
> parent_die.GetAttributeValueAsUnsigned(DW_AT_byte_size, UINT64_MAX);
> >
> >if (member_byte_offset >= parent_byte_size)
> >{
> >if (member_array_size != 1 && (member_array_size != 0 ||
> member_byte_offset > parent_byte_size))
> >{
> >module_sp->ReportError ("0x%8.8" PRIx64 ": DW_TAG_member
> '%s' refers to type 0x%8.8" PRIx64 " which extends beyond the bounds of
> 0x%8.8" PRIx64,
> >die.GetID(),
> >name,
> >encoding_form.Reference(),
> >parent_die.GetID());
> >}
> >
> >member_clang_type =
> m_ast.CreateArrayType(member_array_element_type, 0, false);
> >}
> >}
> > }
> >
> >
> > So we are parsing a member variable, and the member variable's type is
> an array type, and the offset of the member is beyond the parent's type's
> size and yet the array claims to have a valid size.
> >
> > This code is trying to correctly create an CompilerType for a struct
> such as this:
> >
> > struct MyStruct
> > {
> >size_t num_entries;
> >Entry entries[0];
> > };
> >
> > Older versions of clang would emit the same DWARF for:
> >
> > struct MyStruct
> > {
> >size_t num_entries;
> >Entry entries[0];
> > };
> >
> > or
> >
> > struct MyStruct
> > {
> >size_t num_entries;
> >Entry entries[1];
> > };
> >
> > This is bad because in the DWARFASTParserClang we are trying to
> faithfully re-create the type as the user initially created it.
> >
> > This error is trying to say that you have a structure where the byte
> size of "MyStruct" is something like 8 bytes, but "entries" is an array
> that has a valid size (not zero or one) and that the offset of "entries" is
> greater than or equal to 8. If "entries" has a size like:
> >
> > struct MyStruct
> > {
> >size_t num_entries;
> >Entry entries[1];
> > };
> >
> > You would expect the member offset for "entries" to be less than or
> equal to the sizeof(MyStruct). If "Entry" is 8 bytes in size, you might
> expect the byte size of "MyStruct" to be 16, and the offset of
> "num_entries" to be 0 and "entries" to be 8. Both offsets are less than or
> equal to the byte size of 16.
> >
> > If I can see the DWARF file I can tell you more. If I can't, you will
> need to step through this code and see why this is triggering. The error
> message is telling you all you need to know to dump the problem. So for
> this error message:
> >
> > error: biggrep_master_server_async 0x10b9a91a: DW_TAG_member
> '_M_pod_data' refers to type 0x10bb1e99 which extends beyond the bounds of
> 0x10b9a901
> >
> > So if you dump the DWARF and look for the DIE at 0x10b9a91a, you will be
> able to see the DWARF that is causing the problem. On MacOSX, I would do
> this:
> >
> > % dwarfdump --debug-info=0x10b9a91a --show-children --show-parents
> biggrep_master_server_async
> >
> > llvm-dwarfdump will dump your entire file and you will need to look
> through a ton of DWARF in the output. You will need to search for
> "0x10b9a91a:" (the offset followed by a colon).
> >
> > So LLDB believes it is pointing out an error in the DWARF that needs to
> be fixed in the compiler. It could be an incorrect error, but I would need
> to see the DWARF in question to know more. Debugging can happen just fine
> if you ignore this error, it is actually more of a warning, but we emit an
> error so users know to file a bug and hopefully get the compiler fixed.
> >
> > Greg
> >
> >> On Mar 26, 2016
Re: [lldb-dev] LLDB /w Windows and MinGW64
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 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 ProcessWindowsLive::CreateInstance and then work backwards to
> see why that isn't getting called (assuming it's not).
>
> On Mon, Mar 28, 2016 at 9:05 AM Eran Ifrah wrote:
>
>> 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
>>
>>
>>
>>> 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 Windows doesn't currently use lldb
>>> server, this piece has never been written for Windows
>>
>> So this raises the question: how come lldb asks for it? (see my first
>> emai inl this conversation)
>> I would have build LLDB in debug mode, but it seems that MinGW as.exe
>> fails to write some of the files "File too big"
>>
>>
>>
>>>
>>> On Mon, Mar 28, 2016 at 8:41 AM Eran Ifrah wrote:
>>>
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 and some other subtle
> differences, so it doesn't surprise me that things don't work quite right.
>
> I got it to compile (I have a big patch that I can send you if you
are interested)
mainly involves blocking code under __MINGW32__ and some updates to the
various CMakeLists.txt and AddLLDB.cmake module files
Some functions are missing in MinGW implementations (like gets_s and
others :/)
> You can try getting lldb-server to build and run under Windows, or you
> can try to get it to use the non lldb server codepath on MinGW, but you
> may
> still run into some
I got lldb-server to compile and run on Windows, however, it crashes
immediately and the backtrace shows this:
0 0x00724615
lldb_private::NativeProcessProtocol::Launch(lldb_private::ProcessLaunchInfo&,
lldb_private::NativeProcessProtocol::NativeDelegate&,
lldb_private::MainLoopBase&,
std::shared_ptr&)
1 0x005f815d
lldb_private::process_gdb_remote::GDBRemoteCommunicationServerLLGS::LaunchProcess()
2 0x004020e5
handle_launch(lldb_private::process_gdb_remote::GDBRemoteCommunicationServerLLGS&,
int, char const* const*)
3 0x0040335e main_gdbserver(int, char**)
4 0x0188329c main
I had to #ifndef __MINGW32__ around lldb-platform.cpp as it contains
too much Linux code that can not be compiled under Windows (fork, exec*)
and basically lldb-server calls the main_gdbserver instead of
main_platform function
Looking at the function that crashes, I see this:
llvm_unreachable("Platform has no NativeProcessProtocol support");
Any ideas?
Thanks!
issues after that as well, since you're the first person afaik to try
> building with MinGW
>
> On Sun, Mar 27, 2016 at 10:29 PM Eran Ifrah via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
>> Hi,
>>
>> I have built LLDB on Windows 7 using MinGW64/4.9.2 (took some effort
>> to get the job done...)
>> When I tried to debug a simple hello world executable, I get this
>> output:
>>
>> D:\software\msys-for-clang\1.0\home\PC\build-release-64-lldb\bin>lldb.exe
>> HelloWorld.exe
>> (lldb) target create "HelloWorld.exe"
>> Current executable set to 'HelloWorld.exe' (x86_64).
>> (lldb) b main.cpp:7
>> Breakpoint 1: where = HelloWorld.exe`main + 26 at main.cpp:7, address
>> = 0x0040154a
>> (lldb) r
>> error: process launch failed: unable to locate lldb-server
>> (lldb)
>>
>> I can't seem to locate lldb-server anywhere, and according
>> to LLDBConfig.cmake, this target should not get built on Windows:
>>
>> # Figure out if lldb could use lldb-server. If so, then we'll
>> # ensure we build lldb-server when an lldb target is being built.
>> if ((CMAK
Re: [lldb-dev] LLDB /w Windows and MinGW64
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 ProcessWindowsLive::CreateInstance and then work backwards to
see why that isn't getting called (assuming it's not).
On Mon, Mar 28, 2016 at 9:05 AM Eran Ifrah wrote:
> 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
>
>
>
>> 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 Windows doesn't currently use lldb
>> server, this piece has never been written for Windows
>
> So this raises the question: how come lldb asks for it? (see my first
> emai inl this conversation)
> I would have build LLDB in debug mode, but it seems that MinGW as.exe
> fails to write some of the files "File too big"
>
>
>
>>
>> On Mon, Mar 28, 2016 at 8:41 AM Eran Ifrah wrote:
>>
>>> 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 and some other subtle
differences, so it doesn't surprise me that things don't work quite right.
I got it to compile (I have a big patch that I can send you if you are
>>> interested)
>>> mainly involves blocking code under __MINGW32__ and some updates to the
>>> various CMakeLists.txt and AddLLDB.cmake module files
>>> Some functions are missing in MinGW implementations (like gets_s and
>>> others :/)
>>>
>>>
>>>
You can try getting lldb-server to build and run under Windows, or you
can try to get it to use the non lldb server codepath on MinGW, but you may
still run into some
>>>
>>> I got lldb-server to compile and run on Windows, however, it crashes
>>> immediately and the backtrace shows this:
>>>
>>> 0 0x00724615
>>>
>>> lldb_private::NativeProcessProtocol::Launch(lldb_private::ProcessLaunchInfo&,
>>> lldb_private::NativeProcessProtocol::NativeDelegate&,
>>> lldb_private::MainLoopBase&,
>>> std::shared_ptr&)
>>> 1 0x005f815d
>>>
>>> lldb_private::process_gdb_remote::GDBRemoteCommunicationServerLLGS::LaunchProcess()
>>>
>>> 2 0x004020e5
>>>
>>> handle_launch(lldb_private::process_gdb_remote::GDBRemoteCommunicationServerLLGS&,
>>> int, char const* const*)
>>> 3 0x0040335e main_gdbserver(int, char**)
>>> 4 0x0188329c main
>>>
>>>
>>> I had to #ifndef __MINGW32__ around lldb-platform.cpp as it contains too
>>> much Linux code that can not be compiled under Windows (fork, exec*)
>>> and basically lldb-server calls the main_gdbserver instead of
>>> main_platform function
>>>
>>> Looking at the function that crashes, I see this:
>>>
>>> llvm_unreachable("Platform has no NativeProcessProtocol support");
>>>
>>> Any ideas?
>>> Thanks!
>>>
>>> issues after that as well, since you're the first person afaik to try
building with MinGW
>>>
>>>
On Sun, Mar 27, 2016 at 10:29 PM Eran Ifrah via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
> Hi,
>
> I have built LLDB on Windows 7 using MinGW64/4.9.2 (took some effort
> to get the job done...)
> When I tried to debug a simple hello world executable, I get this
> output:
>
> D:\software\msys-for-clang\1.0\home\PC\build-release-64-lldb\bin>lldb.exe
> HelloWorld.exe
> (lldb) target create "HelloWorld.exe"
> Current executable set to 'HelloWorld.exe' (x86_64).
> (lldb) b main.cpp:7
> Breakpoint 1: where = HelloWorld.exe`main + 26 at main.cpp:7, address
> = 0x0040154a
> (lldb) r
> error: process launch failed: unable to locate lldb-server
> (lldb)
>
> I can't seem to locate lldb-server anywhere, and according
> to LLDBConfig.cmake, this target should not get built on Windows:
>
> # Figure out if lldb could use lldb-server. If so, then we'll
> # ensure we build lldb-server when an lldb target is being built.
> if ((CMAKE_SYSTEM_NAME MATCHES "Darwin") OR
> (CMAKE_SYSTEM_NAME MATCHES "FreeBSD") OR
> (CMAKE_SYSTEM_NAME MATCHES "Linux") OR
> (CMAKE_SYSTEM_NAME MATCHES "NetBSD"))
> set(LLDB_CAN_USE_LLDB_SERVER 1)
> else()
> set(LLDB_CAN_USE_LLDB_SERVER 0)
> endif()
>
> and in the tools/CMakeLists.txt file we have this:
>
> if (LLDB_CAN_USE_LLDB_SERVER)
>>>
Re: [lldb-dev] LLDB /w Windows and MinGW64
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. 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 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 ProcessWindowsLive::CreateInstance and then work backwards
>> to see why that isn't getting called (assuming it's not).
>>
>> On Mon, Mar 28, 2016 at 9:05 AM Eran Ifrah wrote:
>>
>>> 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
>>>
>>>
>>>
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 Windows doesn't currently use lldb
server, this piece has never been written for Windows
>>>
>>> So this raises the question: how come lldb asks for it? (see my first
>>> emai inl this conversation)
>>> I would have build LLDB in debug mode, but it seems that MinGW as.exe
>>> fails to write some of the files "File too big"
>>>
>>>
>>>
On Mon, Mar 28, 2016 at 8:41 AM Eran Ifrah
wrote:
> 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 and some other subtle
>> differences, so it doesn't surprise me that things don't work quite
>> right.
>>
>> I got it to compile (I have a big patch that I can send you if you
> are interested)
> mainly involves blocking code under __MINGW32__ and some updates to
> the various CMakeLists.txt and AddLLDB.cmake module files
> Some functions are missing in MinGW implementations (like gets_s and
> others :/)
>
>
>
>> You can try getting lldb-server to build and run under Windows, or
>> you can try to get it to use the non lldb server codepath on MinGW, but
>> you
>> may still run into some
>
> I got lldb-server to compile and run on Windows, however, it crashes
> immediately and the backtrace shows this:
>
> 0 0x00724615
>
> lldb_private::NativeProcessProtocol::Launch(lldb_private::ProcessLaunchInfo&,
> lldb_private::NativeProcessProtocol::NativeDelegate&,
> lldb_private::MainLoopBase&,
> std::shared_ptr&)
> 1 0x005f815d
>
> lldb_private::process_gdb_remote::GDBRemoteCommunicationServerLLGS::LaunchProcess()
>
> 2 0x004020e5
>
> handle_launch(lldb_private::process_gdb_remote::GDBRemoteCommunicationServerLLGS&,
> int, char const* const*)
> 3 0x0040335e main_gdbserver(int, char**)
> 4 0x0188329c main
>
>
> I had to #ifndef __MINGW32__ around lldb-platform.cpp as it contains
> too much Linux code that can not be compiled under Windows (fork, exec*)
> and basically lldb-server calls the main_gdbserver instead of
> main_platform function
>
> Looking at the function that crashes, I see this:
>
> llvm_unreachable("Platform has no NativeProcessProtocol support");
>
> Any ideas?
> Thanks!
>
> issues after that as well, since you're the first person afaik to try
>> building with MinGW
>>
>
>
>> On Sun, Mar 27, 2016 at 10:29 PM Eran Ifrah via lldb-dev <
>> lldb-dev@lists.llvm.org> wrote:
>>
>>> Hi,
>>>
>>> I have built LLDB on Windows 7 using MinGW64/4.9.2 (took some effort
>>> to get the job done...)
>>> When I tried to debug a simple hello world executable, I get this
>>> output:
>>>
>>> D:\software\msys-for-clang\1.0\home\PC\build-release-64-lldb\bin>lldb.exe
>>> HelloWorld.exe
>>> (lldb) target create "HelloWorld.exe"
>>> Current executable set to 'HelloWorld.exe' (x86_64).
>>> (lldb) b main.cpp:7
>>> Breakpoint 1: where = HelloWorld.exe`main + 26 at main.cpp:7,
>>> address = 0x0040154a
>>> (lldb) r
>>> error: process launch failed: unable to locate lldb-server
>>> (lldb)
>>>
>>> I can't se
Re: [lldb-dev] SBListener not using a shared_ptr internally? (Update: Segfault after r262863)
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, Paul Peet wrote:
>
> 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()) {
>return 1;
> }
>
> SBTarget target = debugger.CreateTarget("/home/dev/helloWorld/main");
> if(!target.IsValid()) {
>return 1;
> }
>
> const char* args[] = { "/home/dev/helloWorld/main", 0 };
> const char* env[] = { 0 };
>
> SBLaunchInfo launch_info(args);
> launch_info.SetEnvironmentEntries(env, true);
> launch_info.SetWorkingDirectory("/home/dev/helloWorld");
> launch_info.SetLaunchFlags(eLaunchFlagStopAtEntry);
>
> SBError error;
> SBProcess process = target.Launch(launch_info, error);
>
> return 0;
> }
>
> I tried to build lldb with and without the above commit and it turns
> out that the revision is causing the segfault when simply running that
> code (When it's exiting).
>
> This is the backtrace:
>
> #0 0x55b03b00 in ?? ()
> #1 0x771be1aa in
> lldb_private::Broadcaster::BroadcasterImpl::RestoreBroadcaster() ()
> from /usr/lib/liblldb.so.3.8.0
> #2 0x7748b674 in
> lldb_private::process_gdb_remote::GDBRemoteCommunicationClient::SendPacketAndWaitForResponse(char
> const*, unsigned long, StringExtractorGDBRemote&, bool) () from
> /usr/lib/liblldb.so.3.8.0
> #3 0x7748e89d in
> lldb_private::process_gdb_remote::GDBRemoteCommunicationClient::SendGDBStoppointTypePacket(lldb_private::process_gdb_remote::GDBStoppointType,
> bool, unsigned long, unsigned int) () from /usr/lib/liblldb.so.3.8.0
> #4 0x7746fdab in
> lldb_private::process_gdb_remote::ProcessGDBRemote::DisableBreakpointSite(lldb_private::BreakpointSite*)
> () from /usr/lib/liblldb.so.3.8.0
> #5 0x7733938b in std::_Function_handler (lldb_private::BreakpointSite*),
> lldb_private::Process::DisableAllBreakpointSites()::{lambda(lldb_private::BreakpointSite*)#1}>::_M_invoke(std::_Any_data
> const&, lldb_private::BreakpointSite*&&) () from
> /usr/lib/liblldb.so.3.8.0
> #6 0x7716ae4f in
> lldb_private::BreakpointSiteList::ForEach(std::function (lldb_private::BreakpointSite*)> const&) () from
> /usr/lib/liblldb.so.3.8.0
> #7 0x7733ba9f in
> lldb_private::Process::DisableAllBreakpointSites() () from
> /usr/lib/liblldb.so.3.8.0
> #8 0x7734a58c in lldb_private::Process::Destroy(bool) () from
> /usr/lib/liblldb.so.3.8.0
> #9 0x7734aa2d in lldb_private::Process::Finalize() () from
> /usr/lib/liblldb.so.3.8.0
> #10 0x771d3fe0 in lldb_private::Debugger::Clear() () from
> /usr/lib/liblldb.so.3.8.0
> #11 0x771d97cf in lldb_private::Debugger::~Debugger() () from
> /usr/lib/liblldb.so.3.8.0
> #12 0x771da0c8 in
> std::_Sp_counted_ptr (__gnu_cxx::_Lock_policy)2>::_M_dispose() () from
> /usr/lib/liblldb.so.3.8.0
> #13 0x771cdceb in
> std::vector,
> std::allocator > >::~vector()
> () from /usr/lib/liblldb.so.3.8.0
> #14 0x760d9c38 in __run_exit_handlers () from /usr/lib/libc.so.6
> #15 0x760d9c85 in exit () from /usr/lib/libc.so.6
> #16 0x760c4717 in __libc_start_main () from /usr/lib/libc.so.6
> #17 0x4f69 in _start ()
>
> 2016-03-25 22:42 GMT+01:00 Jim Ingham :
>> What version of the lldb sources are you working with? I changed the
>> SBListener over to using only the ListenerSP internally
>> in r262863.
>>
>> Jim
>>
>>> On Mar 25, 2016, at 1:03 PM, Paul Peet via lldb-dev
>>> wrote:
>>>
>>> Hey,
>>>
>>> I am currently working on lldb bindings for javascript (v8) but it
>>> seems that the API is giving me some troubles.
>>>
>>> What I am doing is to basically wrap SB* objects into V8 objects, and
>>> since SB objects contain a shared_ptr into an internal class I think I
>>> can simply copy construct them.
>>>
>>> To return a wrapped SB object by some Javascript function, I am simply
>>> copy constructing the SB object into the wrapper object which is
>>> dynamically allocated and when the Javascript object is garbage
>>> collected it will also destroy the SBObject (And also the shared_ptr,
>>> So it should be save I guess?).
>>>
>>> Okay, so far so good but I detected some inconsistency when trying to
>>> wrap SBListener. The deal was to make SBListener::WaitForEvent
>>> non-blocking, to do that I am creating a new thread which calls
>>> WaitForEvents, when it returns and the event is valid, the callbacks
>>> given from the Javascript code is called.
>>>
>>> There is a catch when doing this. I have to track the threads which
>>> belong to a specifi
Re: [lldb-dev] LLDB /w Windows and MinGW64
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/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. 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 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 ProcessWindowsLive::CreateInstance and then work backwards
>>> to see why that isn't getting called (assuming it's not).
>>>
>>> On Mon, Mar 28, 2016 at 9:05 AM Eran Ifrah wrote:
>>>
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
> 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 Windows doesn't currently use lldb
> server, this piece has never been written for Windows
So this raises the question: how come lldb asks for it? (see my first
emai inl this conversation)
I would have build LLDB in debug mode, but it seems that MinGW as.exe
fails to write some of the files "File too big"
>
> On Mon, Mar 28, 2016 at 8:41 AM Eran Ifrah
> wrote:
>
>> 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 and some other subtle
>>> differences, so it doesn't surprise me that things don't work quite
>>> right.
>>>
>>> I got it to compile (I have a big patch that I can send you if you
>> are interested)
>> mainly involves blocking code under __MINGW32__ and some updates to
>> the various CMakeLists.txt and AddLLDB.cmake module files
>> Some functions are missing in MinGW implementations (like gets_s and
>> others :/)
>>
>>
>>
>>> You can try getting lldb-server to build and run under Windows, or
>>> you can try to get it to use the non lldb server codepath on MinGW, but
>>> you
>>> may still run into some
>>
>> I got lldb-server to compile and run on Windows, however, it crashes
>> immediately and the backtrace shows this:
>>
>> 0 0x00724615
>>
>> lldb_private::NativeProcessProtocol::Launch(lldb_private::ProcessLaunchInfo&,
>> lldb_private::NativeProcessProtocol::NativeDelegate&,
>> lldb_private::MainLoopBase&,
>> std::shared_ptr&)
>> 1 0x005f815d
>>
>> lldb_private::process_gdb_remote::GDBRemoteCommunicationServerLLGS::LaunchProcess()
>>
>> 2 0x004020e5
>>
>> handle_launch(lldb_private::process_gdb_remote::GDBRemoteCommunicationServerLLGS&,
>> int, char const* const*)
>> 3 0x0040335e main_gdbserver(int, char**)
>> 4 0x0188329c main
>>
>>
>> I had to #ifndef __MINGW32__ around lldb-platform.cpp as it contains
>> too much Linux code that can not be compiled under Windows (fork, exec*)
>> and basically lldb-server calls the main_gdbserver instead of
>> main_platform function
>>
>> Looking at the function that crashes, I see this:
>>
>> llvm_unreachable("Platform has no NativeProcessProtocol support");
>>
>> Any ideas?
>> Thanks!
>>
>> issues after that as well, since you're the first person afaik to try
>>> building with MinGW
>>>
>>
>>
>>> On Sun, Mar 27, 2016 at 10:29 PM Eran Ifrah via lldb-dev <
>>> lldb-dev@lists.llvm.org> wrote:
>>>
Hi,
I have built LLDB on Windows 7 using MinGW64/4.9.2 (took some
effort to get the job done...)
When I tried to debug a simple hello world executable, I get this
output:
D:\software\msys-for-clang\1.0\home\PC\build-release-64-lldb\bin>lldb.exe
Hel
Re: [lldb-dev] LLDB /w Windows and MinGW64
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 28, 2016 at 11:20 AM Eran Ifrah wrote:
>
>> 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. 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 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 ProcessWindowsLive::CreateInstance and then work
backwards to see why that isn't getting called (assuming it's not).
On Mon, Mar 28, 2016 at 9:05 AM Eran Ifrah
wrote:
> 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
>
>
>
>> 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 Windows doesn't currently use lldb
>> server, this piece has never been written for Windows
>
> So this raises the question: how come lldb asks for it? (see my first
> emai inl this conversation)
> I would have build LLDB in debug mode, but it seems that MinGW as.exe
> fails to write some of the files "File too big"
>
>
>
>>
>> On Mon, Mar 28, 2016 at 8:41 AM Eran Ifrah
>> wrote:
>>
>>> 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 and some other
subtle
differences, so it doesn't surprise me that things don't work quite
right.
I got it to compile (I have a big patch that I can send you if you
>>> are interested)
>>> mainly involves blocking code under __MINGW32__ and some updates to
>>> the various CMakeLists.txt and AddLLDB.cmake module files
>>> Some functions are missing in MinGW implementations (like gets_s and
>>> others :/)
>>>
>>>
>>>
You can try getting lldb-server to build and run under Windows, or
you can try to get it to use the non lldb server codepath on MinGW,
but you
may still run into some
>>>
>>> I got lldb-server to compile and run on Windows, however, it
>>> crashes immediately and the backtrace shows this:
>>>
>>> 0 0x00724615
>>>
>>> lldb_private::NativeProcessProtocol::Launch(lldb_private::ProcessLaunchInfo&,
>>> lldb_private::NativeProcessProtocol::NativeDelegate&,
>>> lldb_private::MainLoopBase&,
>>> std::shared_ptr&)
>>> 1 0x005f815d
>>>
>>> lldb_private::process_gdb_remote::GDBRemoteCommunicationServerLLGS::LaunchProcess()
>>>
>>> 2 0x004020e5
>>>
>>> handle_launch(lldb_private::process_gdb_remote::GDBRemoteCommunicationServerLLGS&,
>>> int, char const* const*)
>>> 3 0x0040335e main_gdbserver(int, char**)
>>> 4 0x0188329c main
>>>
>>>
>>> I had to #ifndef __MINGW32__ around lldb-platform.cpp as it contains
>>> too much Linux code that can not be compiled under Windows (fork, exec*)
>>> and basically lldb-server calls the main_gdbserver instead of
>>> main_platform function
>>>
>>> Looking at the function that crashes, I see this:
>>>
>>> llvm_unreachable("Platform has no NativeProcessProtocol support");
>>>
>>> Any ideas?
>>> Thanks!
>>>
>>> issues after that as well, since you're the first person afaik to
try building with MinGW
>>>
>>>
On Sun, Mar 27, 2016 at 10:29 PM Eran Ifrah via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
> Hi,
>
> I have built LLDB on Windows 7 using MinGW64/4.9.2
Re: [lldb-dev] UnicodeDecodeError for serialize SBValue description
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 recognize a typename, then they try to inspect the variable in order
to grab a summary
In your example, your std::string exposes a layout that we are not handling -
hence we bail out of the formatter and we fall back to the raw view
If you want pretty printing to work, you’ll need to write a data formatter
There are a few avenues. The obvious easy one is to extend the existing
std::string formatter to recognize your type’s internal layout.
If one were signing up for more infrastructure work, they could decide to try
and detect shared library loads and load formatters that match with whatever
libraries are being loaded.
> On Mar 28, 2016, at 9:47 AM, Greg Clayton via lldb-dev
> wrote:
>
> 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 debuggers we often get bogus data because variables are not initialized,
> but the compiler tells us that a variable is valid in address range
> [0x1000-0x2000), but it actually is [0x1200-0x2000). If we read a variable in
> this case, a std::string might contain bogus data and the bytes might not
> make sense. So you always have to be prepared for bad data.
>
> If we look at:
>
> store_ = {
> = {
> small_ = "www"
> ml_ = (data_ =
> "��UH\x89�H�}�H\x8bE�]ÐUH\x89�H��H\x89}�H\x8bE�H\x89��~\xb4��\x90��UH\x89�SH\x83�H\x89}�H�u�H�E�H���\x9e���H\x8b\x18H\x8bE�H���O\xb4��H\x89ƿ\b",
> size_ = 0, capacity_ = 1441151880758558720)
>}
> }
> }
>
> We can see the "size_" is zero, and capacity_ is 1441151880758558720 (which
> is 0x1400). "data_" seems to be some random pointer.
>
> On MacOSX, we have a special formatting code that displays std::string in
> CPlusPlusLanguage.cpp that gets installed in the LoadLibCxxFormatters() or
> LoadLibStdcppFormatters() functions with code like:
>
>lldb::TypeSummaryImplSP std_string_summary_sp(new
> CXXFunctionSummaryFormat(stl_summary_flags,
> lldb_private::formatters::LibcxxStringSummaryProvider, "std::string summary
> provider"));
>
> cpp_category_sp->GetTypeSummariesContainer()->Add(ConstString("std::__1::string"),
> std_string_summary_sp);
>
> Special flags are set on std::string to say "don't show children of this and
> just show a summary" So if a std::string contained "hello". So for the
> following code:
>
> std::string h ("hello");
>
> You should just see:
>
> (lldb) fr var h
> (std::__1::string) h = "hello"
>
> If you take a look at the normal value in the raw we see:
>
> (lldb) fr var --raw h
> (std::__1::string) h = {
> __r_ = {
>std::__1::__libcpp_compressed_pair_imp std::__1::char_traits, std::__1::allocator >::__rep,
> std::__1::allocator, 2> = {
> __first_ = {
> = {
> __l = {
>__cap_ = 122511465736202
>__size_ = 0
>__data_ = 0x
> }
> __s = {
> = {
> __size_ = '\n'
> __lx = '\n'
>}
>__data_ = {
> [0] = 'h'
> [1] = 'e'
> [2] = 'l'
> [3] = 'l'
> [4] = 'o'
> [5] = '\0'
> [6] = '\0'
> [7] = '\0'
> [8] = '\0'
> [9] = '\0'
> [10] = '\0'
> [11] = '\0'
> [12] = '\0'
> [13] = '\0'
> [14] = '\0'
> [15] = '\0'
> [16] = '\0'
> [17] = '\0'
> [18] = '\0'
> [19] = '\0'
> [20] = '\0'
> [21] = '\0'
> [22] = '\0'
>}
> }
> __r = {
>__words = {
> [0] = 122511465736202
> [1] = 0
> [2] = 0
>}
> }
>}
> }
>}
> }
> }
>
> So the main question is why are our "std::string" formatters not kicking in
> for you. That comes down to a typename match, or the format of the string
> isn't what the formatter is expecting.
>
> But again, since you std::string can contain anything, you will need to
> escape any and all text that is encoded into JSON to ensure it doesn't
> contain anything JSON can't deal with.
>
>> On Mar 27, 2016, at 9:20 PM, Jeffrey Tan via lldb-dev
>> wrote:
>>
>> Thanks Siva. All the DW_TAG_member related errors seems to go away after
>> patching with your fix. The current problem is handling the decoding.
>>
>> Here is the correct decoding from gdb whic mi
Re: [lldb-dev] UnicodeDecodeError for serialize SBValue description
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 content well but gdb does it correct.
2. I guess the std::string formatter did not kick in because our company
may link some special stl implementation. Let me share our binary for you
to confirm.
3. I dumped the content of the object we try to json.dumps() against, here
is the content:
response: {'id': 57, 'result': {'result': [{'name': 'data_', 'value':
{'type': 'object', 'description': '(char *) "\xc9\xc3UH\\x89\xe5H\x8
9}\xf8H\\x8bE\xf8]\xc3\x90UH\\x89\xe5H\x83\xec\x10H\\x89}\xf8H\\x8bE\xf8H\\x89\xc7\xe8~\\xb4\xca\xff\\x90\xc9\xc3UH\\x89\
xe5SH\\x83\xec\x18H\\x89}\xe8H\x89u\xe0H\x8bE\xe0H\x89\xc7\xe8\\x9e\xff\xff\xffH\\x8b\\x18H\\x8bE\xe8H\x89\xc7\xe8O\\xb4\
xca\xffH\\x89\xc6\xbf\\b"', 'objectId': 'RemoteObjectManager.118'}},
{'name': 'size_', 'value': {'type': 'object', 'descr iption':
'(std::size_t) 0'}}, {'name': 'capacity_', 'value': {'type': 'object',
'description': '(std::size_t) 14411518807 58558720'}}]}}
So seems that the problem is json.dumps() is trying to treat the raw byte
array as utf8 which failed.
So we need to figure out how to escape the raw byte array into string so
that we can json.dumps() it. The key question is how do we know the correct
encoding of the byte array. Is my understanding correct that only the
formatter has the knowledge to decode the byte array correctly? If we fail
to find a type formatter(which is this case) and get a raw field with byte
array, we have no knowledge of the encoding so either we have to guess one
default encoding and try it or just display the raw byte array content
instead of decoding it?
Jeffrey
On Mon, Mar 28, 2016 at 9:47 AM, Greg Clayton wrote:
> 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 debuggers we often get bogus data because variables are not
> initialized, but the compiler tells us that a variable is valid in address
> range [0x1000-0x2000), but it actually is [0x1200-0x2000). If we read a
> variable in this case, a std::string might contain bogus data and the bytes
> might not make sense. So you always have to be prepared for bad data.
>
> If we look at:
>
> store_ = {
> = {
> small_ = "www"
> ml_ = (data_ =
>
> "��UH\x89�H�}�H\x8bE�]ÐUH\x89�H��H\x89}�H\x8bE�H\x89��~\xb4��\x90��UH\x89�SH\x83�H\x89}�H�u�H�E�H���\x9e���H\x8b\x18H\x8bE�H���O\xb4��H\x89ƿ\b",
> size_ = 0, capacity_ = 1441151880758558720)
> }
> }
> }
>
> We can see the "size_" is zero, and capacity_ is 1441151880758558720
> (which is 0x1400). "data_" seems to be some random pointer.
>
> On MacOSX, we have a special formatting code that displays std::string in
> CPlusPlusLanguage.cpp that gets installed in the LoadLibCxxFormatters() or
> LoadLibStdcppFormatters() functions with code like:
>
> lldb::TypeSummaryImplSP std_string_summary_sp(new
> CXXFunctionSummaryFormat(stl_summary_flags,
> lldb_private::formatters::LibcxxStringSummaryProvider, "std::string summary
> provider"));
>
> cpp_category_sp->GetTypeSummariesContainer()->Add(ConstString("std::__1::string"),
> std_string_summary_sp);
>
> Special flags are set on std::string to say "don't show children of this
> and just show a summary" So if a std::string contained "hello". So for the
> following code:
>
> std::string h ("hello");
>
> You should just see:
>
> (lldb) fr var h
> (std::__1::string) h = "hello"
>
> If you take a look at the normal value in the raw we see:
>
> (lldb) fr var --raw h
> (std::__1::string) h = {
> __r_ = {
> std::__1::__libcpp_compressed_pair_imp std::__1::char_traits, std::__1::allocator >::__rep,
> std::__1::allocator, 2> = {
> __first_ = {
> = {
> __l = {
> __cap_ = 122511465736202
> __size_ = 0
> __data_ = 0x
> }
> __s = {
> = {
> __size_ = '\n'
> __lx = '\n'
> }
> __data_ = {
> [0] = 'h'
> [1] = 'e'
> [2] = 'l'
> [3] = 'l'
> [4] = 'o'
> [5] = '\0'
> [6] = '\0'
> [7] = '\0'
> [8] = '\0'
> [9] = '\0'
> [10] = '\0'
> [11] = '\0'
> [12] = '\0'
> [13] = '\0'
> [14] = '\0'
> [15] = '\0'
> [16] = '\0'
> [17] = '\0'
> [18] = '\0'
> [19] = '\0'
>
Re: [lldb-dev] SBListener not using a shared_ptr internally? (Update: Segfault after r262863)
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 Ingham :
> 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, Paul Peet wrote:
>>
>> 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()) {
>>return 1;
>> }
>>
>> SBTarget target = debugger.CreateTarget("/home/dev/helloWorld/main");
>> if(!target.IsValid()) {
>>return 1;
>> }
>>
>> const char* args[] = { "/home/dev/helloWorld/main", 0 };
>> const char* env[] = { 0 };
>>
>> SBLaunchInfo launch_info(args);
>> launch_info.SetEnvironmentEntries(env, true);
>> launch_info.SetWorkingDirectory("/home/dev/helloWorld");
>> launch_info.SetLaunchFlags(eLaunchFlagStopAtEntry);
>>
>> SBError error;
>> SBProcess process = target.Launch(launch_info, error);
>>
>> return 0;
>> }
>>
>> I tried to build lldb with and without the above commit and it turns
>> out that the revision is causing the segfault when simply running that
>> code (When it's exiting).
>>
>> This is the backtrace:
>>
>> #0 0x55b03b00 in ?? ()
>> #1 0x771be1aa in
>> lldb_private::Broadcaster::BroadcasterImpl::RestoreBroadcaster() ()
>> from /usr/lib/liblldb.so.3.8.0
>> #2 0x7748b674 in
>> lldb_private::process_gdb_remote::GDBRemoteCommunicationClient::SendPacketAndWaitForResponse(char
>> const*, unsigned long, StringExtractorGDBRemote&, bool) () from
>> /usr/lib/liblldb.so.3.8.0
>> #3 0x7748e89d in
>> lldb_private::process_gdb_remote::GDBRemoteCommunicationClient::SendGDBStoppointTypePacket(lldb_private::process_gdb_remote::GDBStoppointType,
>> bool, unsigned long, unsigned int) () from /usr/lib/liblldb.so.3.8.0
>> #4 0x7746fdab in
>> lldb_private::process_gdb_remote::ProcessGDBRemote::DisableBreakpointSite(lldb_private::BreakpointSite*)
>> () from /usr/lib/liblldb.so.3.8.0
>> #5 0x7733938b in std::_Function_handler> (lldb_private::BreakpointSite*),
>> lldb_private::Process::DisableAllBreakpointSites()::{lambda(lldb_private::BreakpointSite*)#1}>::_M_invoke(std::_Any_data
>> const&, lldb_private::BreakpointSite*&&) () from
>> /usr/lib/liblldb.so.3.8.0
>> #6 0x7716ae4f in
>> lldb_private::BreakpointSiteList::ForEach(std::function> (lldb_private::BreakpointSite*)> const&) () from
>> /usr/lib/liblldb.so.3.8.0
>> #7 0x7733ba9f in
>> lldb_private::Process::DisableAllBreakpointSites() () from
>> /usr/lib/liblldb.so.3.8.0
>> #8 0x7734a58c in lldb_private::Process::Destroy(bool) () from
>> /usr/lib/liblldb.so.3.8.0
>> #9 0x7734aa2d in lldb_private::Process::Finalize() () from
>> /usr/lib/liblldb.so.3.8.0
>> #10 0x771d3fe0 in lldb_private::Debugger::Clear() () from
>> /usr/lib/liblldb.so.3.8.0
>> #11 0x771d97cf in lldb_private::Debugger::~Debugger() () from
>> /usr/lib/liblldb.so.3.8.0
>> #12 0x771da0c8 in
>> std::_Sp_counted_ptr> (__gnu_cxx::_Lock_policy)2>::_M_dispose() () from
>> /usr/lib/liblldb.so.3.8.0
>> #13 0x771cdceb in
>> std::vector,
>> std::allocator > >::~vector()
>> () from /usr/lib/liblldb.so.3.8.0
>> #14 0x760d9c38 in __run_exit_handlers () from /usr/lib/libc.so.6
>> #15 0x760d9c85 in exit () from /usr/lib/libc.so.6
>> #16 0x760c4717 in __libc_start_main () from /usr/lib/libc.so.6
>> #17 0x4f69 in _start ()
>>
>> 2016-03-25 22:42 GMT+01:00 Jim Ingham :
>>> What version of the lldb sources are you working with? I changed the
>>> SBListener over to using only the ListenerSP internally
>>> in r262863.
>>>
>>> Jim
>>>
On Mar 25, 2016, at 1:03 PM, Paul Peet via lldb-dev
wrote:
Hey,
I am currently working on lldb bindings for javascript (v8) but it
seems that the API is giving me some troubles.
What I am doing is to basically wrap SB* objects into V8 objects, and
since SB objects contain a shared_ptr into an internal class I think I
can simply copy construct them.
To return a wrapped SB object by some Javascript function, I am simply
copy constructing the SB object into the wrapper object which is
dynamically allocated and when the Javascript object is garbage
collected it will also destroy the SBObject (And also the shared_ptr,
So it should be save I guess?).
Okay, so far so
Re: [lldb-dev] SBListener not using a shared_ptr internally? (Update: Segfault after r262863)
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 terribly high priority.
Jim
> On Mar 28, 2016, at 11:48 AM, Paul Peet wrote:
>
> 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 Ingham :
>> 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, Paul Peet wrote:
>>>
>>> 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()) {
>>> return 1;
>>> }
>>>
>>> SBTarget target = debugger.CreateTarget("/home/dev/helloWorld/main");
>>> if(!target.IsValid()) {
>>> return 1;
>>> }
>>>
>>> const char* args[] = { "/home/dev/helloWorld/main", 0 };
>>> const char* env[] = { 0 };
>>>
>>> SBLaunchInfo launch_info(args);
>>> launch_info.SetEnvironmentEntries(env, true);
>>> launch_info.SetWorkingDirectory("/home/dev/helloWorld");
>>> launch_info.SetLaunchFlags(eLaunchFlagStopAtEntry);
>>>
>>> SBError error;
>>> SBProcess process = target.Launch(launch_info, error);
>>>
>>> return 0;
>>> }
>>>
>>> I tried to build lldb with and without the above commit and it turns
>>> out that the revision is causing the segfault when simply running that
>>> code (When it's exiting).
>>>
>>> This is the backtrace:
>>>
>>> #0 0x55b03b00 in ?? ()
>>> #1 0x771be1aa in
>>> lldb_private::Broadcaster::BroadcasterImpl::RestoreBroadcaster() ()
>>> from /usr/lib/liblldb.so.3.8.0
>>> #2 0x7748b674 in
>>> lldb_private::process_gdb_remote::GDBRemoteCommunicationClient::SendPacketAndWaitForResponse(char
>>> const*, unsigned long, StringExtractorGDBRemote&, bool) () from
>>> /usr/lib/liblldb.so.3.8.0
>>> #3 0x7748e89d in
>>> lldb_private::process_gdb_remote::GDBRemoteCommunicationClient::SendGDBStoppointTypePacket(lldb_private::process_gdb_remote::GDBStoppointType,
>>> bool, unsigned long, unsigned int) () from /usr/lib/liblldb.so.3.8.0
>>> #4 0x7746fdab in
>>> lldb_private::process_gdb_remote::ProcessGDBRemote::DisableBreakpointSite(lldb_private::BreakpointSite*)
>>> () from /usr/lib/liblldb.so.3.8.0
>>> #5 0x7733938b in std::_Function_handler>> (lldb_private::BreakpointSite*),
>>> lldb_private::Process::DisableAllBreakpointSites()::{lambda(lldb_private::BreakpointSite*)#1}>::_M_invoke(std::_Any_data
>>> const&, lldb_private::BreakpointSite*&&) () from
>>> /usr/lib/liblldb.so.3.8.0
>>> #6 0x7716ae4f in
>>> lldb_private::BreakpointSiteList::ForEach(std::function>> (lldb_private::BreakpointSite*)> const&) () from
>>> /usr/lib/liblldb.so.3.8.0
>>> #7 0x7733ba9f in
>>> lldb_private::Process::DisableAllBreakpointSites() () from
>>> /usr/lib/liblldb.so.3.8.0
>>> #8 0x7734a58c in lldb_private::Process::Destroy(bool) () from
>>> /usr/lib/liblldb.so.3.8.0
>>> #9 0x7734aa2d in lldb_private::Process::Finalize() () from
>>> /usr/lib/liblldb.so.3.8.0
>>> #10 0x771d3fe0 in lldb_private::Debugger::Clear() () from
>>> /usr/lib/liblldb.so.3.8.0
>>> #11 0x771d97cf in lldb_private::Debugger::~Debugger() () from
>>> /usr/lib/liblldb.so.3.8.0
>>> #12 0x771da0c8 in
>>> std::_Sp_counted_ptr>> (__gnu_cxx::_Lock_policy)2>::_M_dispose() () from
>>> /usr/lib/liblldb.so.3.8.0
>>> #13 0x771cdceb in
>>> std::vector,
>>> std::allocator > >::~vector()
>>> () from /usr/lib/liblldb.so.3.8.0
>>> #14 0x760d9c38 in __run_exit_handlers () from /usr/lib/libc.so.6
>>> #15 0x760d9c85 in exit () from /usr/lib/libc.so.6
>>> #16 0x760c4717 in __libc_start_main () from /usr/lib/libc.so.6
>>> #17 0x4f69 in _start ()
>>>
>>> 2016-03-25 22:42 GMT+01:00 Jim Ingham :
What version of the lldb sources are you working with? I changed the
SBListener over to using only the ListenerSP internally
in r262863.
Jim
> On Mar 25, 2016, at 1:03 PM, Paul Peet via lldb-dev
> wrote:
>
> Hey,
>
> I am currently working on lldb bindings for javascript (v8) but it
> seems that the API is giving me some troubles.
>
> What I am doing is to basically
Re: [lldb-dev] LLDB /w Windows and MinGW64
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
> 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 28, 2016 at 11:20 AM Eran Ifrah wrote:
>>
>>> 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. 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 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 ProcessWindowsLive::CreateInstance and then work
> backwards to see why that isn't getting called (assuming it's not).
>
> On Mon, Mar 28, 2016 at 9:05 AM Eran Ifrah
> wrote:
>
>> 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
>>
>>
>>
>>> 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 Windows doesn't currently use lldb
>>> server, this piece has never been written for Windows
>>
>> So this raises the question: how come lldb asks for it? (see my
>> first emai inl this conversation)
>> I would have build LLDB in debug mode, but it seems that MinGW as.exe
>> fails to write some of the files "File too big"
>>
>>
>>
>>>
>>> On Mon, Mar 28, 2016 at 8:41 AM Eran Ifrah
>>> wrote:
>>>
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 and some other
> subtle
> differences, so it doesn't surprise me that things don't work quite
> right.
>
> I got it to compile (I have a big patch that I can send you if
you are interested)
mainly involves blocking code under __MINGW32__ and some updates to
the various CMakeLists.txt and AddLLDB.cmake module files
Some functions are missing in MinGW implementations (like gets_s
and others :/)
> You can try getting lldb-server to build and run under Windows, or
> you can try to get it to use the non lldb server codepath on MinGW,
> but you
> may still run into some
I got lldb-server to compile and run on Windows, however, it
crashes immediately and the backtrace shows this:
0 0x00724615
lldb_private::NativeProcessProtocol::Launch(lldb_private::ProcessLaunchInfo&,
lldb_private::NativeProcessProtocol::NativeDelegate&,
lldb_private::MainLoopBase&,
std::shared_ptr&)
1 0x005f815d
lldb_private::process_gdb_remote::GDBRemoteCommunicationServerLLGS::LaunchProcess()
2 0x004020e5
handle_launch(lldb_private::process_gdb_remote::GDBRemoteCommunicationServerLLGS&,
int, char const* const*)
3 0x0040335e main_gdbserver(int, char**)
4 0x0188329c main
I had to #ifndef __MINGW32__ around lldb-platform.cpp as it
contains too much Linux code that can not be compiled under Windows
(fork,
exec*)
and basically lldb-server calls the main_gdbserver instead of
main_platform function
Looking at the function that crashes, I see this:
llvm_unreachable("Platform has no NativeProcessProtocol support");
Any ideas?
Re: [lldb-dev] LLDB /w Windows and MinGW64
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 will take sometime as the generated files are too large to written to the file system - (clang sources) I will teak the CMakeLists.txt files to fix this and will report back In the meantime, if you have any more hints/tips - I will be happy to try them here Thanks On Mon, Mar 28, 2016 at 10:13 PM, Eran Ifrah wrote: > 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 >> 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 28, 2016 at 11:20 AM Eran Ifrah >>> wrote: >>> 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. 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 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 ProcessWindowsLive::CreateInstance and then work >> backwards to see why that isn't getting called (assuming it's not). >> >> On Mon, Mar 28, 2016 at 9:05 AM Eran Ifrah >> wrote: >> >>> 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 >>> >>> >>> 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 Windows doesn't currently use lldb server, this piece has never been written for Windows >>> >>> So this raises the question: how come lldb asks for it? (see my >>> first emai inl this conversation) >>> I would have build LLDB in debug mode, but it seems that MinGW >>> as.exe fails to write some of the files "File too big" >>> >>> >>> On Mon, Mar 28, 2016 at 8:41 AM Eran Ifrah wrote: > On Mon, Mar 28, 2016 at 6:10 PM, Zachary Turner < > ztur...@google.com> 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 and some other >> subtle >> differences, so it doesn't surprise me that things don't work quite >> right. >> >> I got it to compile (I have a big patch that I can send you if > you are interested) > mainly involves blocking code under __MINGW32__ and some updates > to the various CMakeLists.txt and AddLLDB.cmake module files > Some functions are missing in MinGW implementations (like gets_s > and others :/) > > > >> You can try getting lldb-server to build and run under Windows, >> or you can try to get it to use the non lldb server codepath on >> MinGW, but >> you may still run into some > > I got lldb-server to compile and run on Windows, however, it > crashes immediately and the backtrace shows this: > > 0 0x00724615 > > lldb_private::NativeProcessProtocol::Launch(lldb_private::ProcessLaunchInfo&, > lldb_private::NativeProcessProtocol::NativeDelegate&, > lldb_private::MainLoopBase&, > std::shared_ptr&) > 1 0x005f815d > > lldb_private::process_gdb_remote::GDBRemoteCommunicationServerLLGS::Lau
[lldb-dev] Help debugging OSX build error
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 tried nuking my entire build directory, checking out again from scratch, and building but it still doesn't work. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Help debugging OSX build error
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: '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 tried nuking my entire build directory, checking out again from scratch, > and building but it still doesn't work. > ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] UnicodeDecodeError for serialize SBValue description
> 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
> more meaningful than us? I thought we(lldb) did not display std::string
> content well but gdb does it correct.
So the "size_" variable is zero, so anything that GDB is displaying is shear
luck of what the contents of memory are that "data_" points to. You can't rely
on any contents of "data_" since it is clearly bogus. What you really want to
see is just the string that "std::string" points to:
(std::string) my_string = "Hello"
Or for a std::string that contains 0, 1, and 2 as characters:
(std::string) my_string = "\x00\x01\x02"
> 2. I guess the std::string formatter did not kick in because our company may
> link some special stl implementation. Let me share our binary for you to
> confirm.
You can get some help from Enrico to see why things are not displaying
correctly. My guess is this C++ standard library is different from the ones
that we added support for.
> 3. I dumped the content of the object we try to json.dumps() against, here is
> the content:
> response: {'id': 57, 'result': {'result': [{'name': 'data_', 'value':
> {'type': 'object', 'description': '(char *) "\xc9\xc3UH\\x89\xe5H\x8
> 9}\xf8H\\x8bE\xf8]\xc3\x90UH\\x89\xe5H\x83\xec\x10H\\x89}\xf8H\\x8bE\xf8H\\x89\xc7\xe8~\\xb4\xca\xff\\x90\xc9\xc3UH\\x89\
>
> xe5SH\\x83\xec\x18H\\x89}\xe8H\x89u\xe0H\x8bE\xe0H\x89\xc7\xe8\\x9e\xff\xff\xffH\\x8b\\x18H\\x8bE\xe8H\x89\xc7\xe8O\\xb4\
> xca\xffH\\x89\xc6\xbf\\b"', 'objectId': 'RemoteObjectManager.118'}},
> {'name': 'size_', 'value': {'type': 'object', 'descr iption':
> '(std::size_t) 0'}}, {'name': 'capacity_', 'value': {'type': 'object',
> 'description': '(std::size_t) 14411518807 58558720'}}]}}
> So seems that the problem is json.dumps() is trying to treat the raw byte
> array as utf8 which failed.
> So we need to figure out how to escape the raw byte array into string so that
> we can json.dumps() it. The key question is how do we know the correct
> encoding of the byte array.
It doesn't really matter. Just know that any of the strings from:
const char *SBValue::GetName();
const char *SBValue::GetTypeName ();
const char *SBValue::GetDisplayTypeName();
const char *SBValue::GetValue();
const char *SBValue::GetSummary();
const char *SBValue::GetObjectDescription();
const char *SBValue::GetLocation ();
Will need to be escaped.
> Is my understanding correct that only the formatter has the knowledge to
> decode the byte array correctly?
We dump the values as strings. You won't get bytes out. You might get UTF8
bytes or other things that JSON might interpret as special characters and any C
strings that you get from the above calls will just need to be escaped if
needed.
> If we fail to find a type formatter(which is this case) and get a raw field
> with byte array, we have no knowledge of the encoding so either we have to
> guess one default encoding and try it or just display the raw byte array
> content instead of decoding it?
Again, this is all C strings. I don't think anything else matters.
Our JSON.cpp has the following:
int
JSONParser::GetEscapedChar(bool &was_escaped)
{
was_escaped = false;
const char ch = GetChar();
if (ch == '\\')
{
was_escaped = true;
const char ch2 = GetChar();
switch (ch2)
{
case '"':
case '\\':
case '/':
default:
break;
case 'b': return '\b';
case 'f': return '\f';
case 'n': return '\n';
case 'r': return '\r';
case 't': return '\t';
case 'u':
{
const int hi_byte = DecodeHexU8();
const int lo_byte = DecodeHexU8();
if (hi_byte >=0 && lo_byte >= 0)
return hi_byte << 8 | lo_byte;
return -1;
}
break;
}
return ch2;
}
return ch;
}
You can see how it is used when the JSON parser is parsing in
JSONParser::GetToken() in the '"' case.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Help debugging OSX build error
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 (directories are listed in this list): /usr /usr/local /usr/local/OpenSourceLicenses /usr/local/OpenSourceLicenses/swig.txt /usr/local/OpenSourceVersions /usr/local/OpenSourceVersions/swig.plist /usr/local/bin /usr/local/bin/swig /usr/local/share /usr/local/share/swig /usr/local/share/swig/1.3.40 /usr/local/share/swig/1.3.40/tcl /usr/local/share/swig/1.3.40/tcl/tcluserdir.swg /usr/local/share/swig/1.3.40/tcl/carrays.i /usr/local/share/swig/1.3.40/tcl/tclruntime.swg /usr/local/share/swig/1.3.40/tcl/std_common.i /usr/local/share/swig/1.3.40/tcl/tclrun.swg /usr/local/share/swig/1.3.40/tcl/cstring.i /usr/local/share/swig/1.3.40/tcl/std_wstring.i /usr/local/share/swig/1.3.40/tcl/std_vector.i /usr/local/share/swig/1.3.40/tcl/std_deque.i /usr/local/share/swig/1.3.40/tcl/tcl8.swg /usr/local/share/swig/1.3.40/tcl/tclinit.swg /usr/local/share/swig/1.3.40/tcl/attribute.i /usr/local/share/swig/1.3.40/tcl/tcltypemaps.swg /usr/local/share/swig/1.3.40/tcl/exception.i /usr/local/share/swig/1.3.40/tcl/tclsh.i /usr/local/share/swig/1.3.40/tcl/tclresult.i /usr/local/share/swig/1.3.40/tcl/tclkw.swg /usr/local/share/swig/1.3.40/tcl/cpointer.i /usr/local/share/swig/1.3.40/tcl/std_pair.i /usr/local/share/swig/1.3.40/tcl/std_except.i /usr/local/share/swig/1.3.40/tcl/tclerrors.swg /usr/local/share/swig/1.3.40/tcl/tclapi.swg /usr/local/share/swig/1.3.40/tcl/tclstrings.swg /usr/local/share/swig/1.3.40/tcl/tclprimtypes.swg /usr/local/share/swig/1.3.40/tcl/tclmacros.swg /usr/local/share/swig/1.3.40/tcl/tclopers.swg /usr/local/share/swig/1.3.40/tcl/std_string.i /usr/local/share/swig/1.3.40/tcl/wish.i /usr/local/share/swig/1.3.40/tcl/cni.i /usr/local/share/swig/1.3.40/tcl/tclinterp.i /usr/local/share/swig/1.3.40/tcl/tclfragments.swg /usr/local/share/swig/1.3.40/tcl/std_map.i /usr/local/share/swig/1.3.40/tcl/factory.i /usr/local/share/swig/1.3.40/tcl/stl.i /usr/local/share/swig/1.3.40/tcl/cwstring.i /usr/local/share/swig/1.3.40/tcl/jstring.i /usr/local/share/swig/1.3.40/tcl/cmalloc.i /usr/local/share/swig/1.3.40/tcl/cdata.i /usr/local/share/swig/1.3.40/tcl/tclwstrings.swg /usr/local/share/swig/1.3.40/tcl/typemaps.i /usr/local/share/swig/1.3.40/swiginit.swg /usr/local/share/swig/1.3.40/std /usr/local/share/swig/1.3.40/std/std_container.i /usr/local/share/swig/1.3.40/std/std_set.i /usr/local/share/swig/1.3.40/std/std_basic_string.i /usr/local/share/swig/1.3.40/std/std_char_traits.i /usr/local/share/swig/1.3.40/std/std_queue.i /usr/local/share/swig/1.3.40/std/std_common.i /usr/local/share/swig/1.3.40/std/std_vectora.i /usr/local/share/swig/1.3.40/std/std_stack.i /usr/local/share/swig/1.3.40/std/std_sstream.i /usr/local/share/swig/1.3.40/std/std_wstring.i /usr/local/share/swig/1.3.40/std/std_vector.i /usr/local/share/swig/1.3.40/std/std_deque.i /usr/local/share/swig/1.3.40/std/std_wsstream.i /usr/local/share/swig/1.3.40/std/std_pair.i /usr/local/share/swig/1.3.40/std/std_except.i /usr/local/share/swig/1.3.40/std/std_list.i /usr/local/share/swig/1.3.40/std/std_wios.i /usr/local/share/swig/1.3.40/std/std_multimap.i /usr/local/share/swig/1.3.40/std/std_wiostream.i /usr/local/share/swig/1.3.40/std/std_iostream.i /usr/local/share/swig/1.3.40/std/std_multiset.i /usr/local/share/swig/1.3.40/std/_std_deque.i /usr/local/share/swig/1.3.40/std/std_streambuf.i /usr/local/share/swig/1.3.40/std/std_wstreambuf.i /usr/local/share/swig/1.3.40/std/std_alloc.i /usr/local/share/swig/1.3.40/std/std_string.i /usr/local/share/swig/1.3.40/std/std_ios.i /usr/local/share/swig/1.3.40/std/std_map.i /usr/local/share/swig/1.3.40/std/std_carray.swg /usr/local/share/swig/1.3.40/swigarch.i /usr/local/share/swig/1.3.40/carrays.i /usr/local/share/swig/1.3.40/lua /usr/local/share/swig/1.3.40/lua/carrays.i /usr/local/share/swig/1.3.40/lua/_std_common.i /usr/local/share/swig/1.3.40/lua/std_common.i /usr/local/share/swig/1.3.40/lua/wchar.i /usr/local/share/swig/1.3.40/lua/luarun.swg /usr/local/share/swig/1.3.40/lua/std_vector.i /usr/local/share/swig/1.3.40/lua/std_deque.i /usr/local/share/swig/1.3.40/lua/lua_fnptr.i /usr/local/share/swig/1.3.40/lua/std_pair.i /usr/local/share/swig/1.3.40/lua/std_except.i /usr/local/share/swig/1.3.40/lua/std_string.i /usr/local/share/swig/1.3.40/lua/luaruntime.swg /usr/local/share/swig/1.3.40/lua/luatypemaps.swg /usr/local/share/swig/1.3.40/lua/std_map.i /usr/local/share/swig/1.3.40/lua/stl.i /usr/local/share/swig/1.3.40/lua/lua.swg /usr/local/share/swig/1.3.40/lua/typemaps.i /usr/local/share/swig/1.3.40/chicken /usr/local/share/swig/1.3.40/chicken/multi-generic.scm /usr/local/share/swig/1.3.40/chicken/tinyclos-multi-generic.patch /usr/local/share/swig/1.3.40/chicken/chickenkw.swg /usr/local/share/swig/1.3.40/chicken/chickenrun.swg /usr/local/share/swig/1.3.40/c
Re: [lldb-dev] UnicodeDecodeError for serialize SBValue description
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 because 'data_' points
> to some random memory?
>
> Yes.
>
> > 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 content well but gdb does it correct.
>
> So the "size_" variable is zero, so anything that GDB is displaying is
> shear luck of what the contents of memory are that "data_" points to. You
> can't rely on any contents of "data_" since it is clearly bogus. What you
> really want to see is just the string that "std::string" points to:
>
> (std::string) my_string = "Hello"
>
> Or for a std::string that contains 0, 1, and 2 as characters:
>
> (std::string) my_string = "\x00\x01\x02"
>
>
>
> > 2. I guess the std::string formatter did not kick in because our company
> may link some special stl implementation. Let me share our binary for you
> to confirm.
>
> You can get some help from Enrico to see why things are not displaying
> correctly. My guess is this C++ standard library is different from the ones
> that we added support for.
>
> > 3. I dumped the content of the object we try to json.dumps() against,
> here is the content:
> > response: {'id': 57, 'result': {'result': [{'name': 'data_',
> 'value': {'type': 'object', 'description': '(char *)
> "\xc9\xc3UH\\x89\xe5H\x8
>
> 9}\xf8H\\x8bE\xf8]\xc3\x90UH\\x89\xe5H\x83\xec\x10H\\x89}\xf8H\\x8bE\xf8H\\x89\xc7\xe8~\\xb4\xca\xff\\x90\xc9\xc3UH\\x89\
>
>
> xe5SH\\x83\xec\x18H\\x89}\xe8H\x89u\xe0H\x8bE\xe0H\x89\xc7\xe8\\x9e\xff\xff\xffH\\x8b\\x18H\\x8bE\xe8H\x89\xc7\xe8O\\xb4\
>xca\xffH\\x89\xc6\xbf\\b"', 'objectId': 'RemoteObjectManager.118'}},
> {'name': 'size_', 'value': {'type': 'object', 'descr iption':
> '(std::size_t) 0'}}, {'name': 'capacity_', 'value': {'type': 'object',
> 'description': '(std::size_t) 14411518807 58558720'}}]}}
> > So seems that the problem is json.dumps() is trying to treat the raw
> byte array as utf8 which failed.
> > So we need to figure out how to escape the raw byte array into string so
> that we can json.dumps() it. The key question is how do we know the correct
> encoding of the byte array.
>
> It doesn't really matter. Just know that any of the strings from:
>
> const char *SBValue::GetName();
> const char *SBValue::GetTypeName ();
> const char *SBValue::GetDisplayTypeName();
> const char *SBValue::GetValue();
> const char *SBValue::GetSummary();
> const char *SBValue::GetObjectDescription();
> const char *SBValue::GetLocation ();
>
> Will need to be escaped.
>
> > Is my understanding correct that only the formatter has the knowledge to
> decode the byte array correctly?
>
> We dump the values as strings. You won't get bytes out. You might get UTF8
> bytes or other things that JSON might interpret as special characters and
> any C strings that you get from the above calls will just need to be
> escaped if needed.
>
> > If we fail to find a type formatter(which is this case) and get a raw
> field with byte array, we have no knowledge of the encoding so either we
> have to guess one default encoding and try it or just display the raw byte
> array content instead of decoding it?
>
> Again, this is all C strings. I don't think anything else matters.
>
> Our JSON.cpp has the following:
>
> int
> JSONParser::GetEscapedChar(bool &was_escaped)
> {
> was_escaped = false;
> const char ch = GetChar();
> if (ch == '\\')
> {
> was_escaped = true;
> const char ch2 = GetChar();
> switch (ch2)
> {
> case '"':
> case '\\':
> case '/':
> default:
> break;
>
> case 'b': return '\b';
> case 'f': return '\f';
> case 'n': return '\n';
> case 'r': return '\r';
> case 't': return '\t';
> case 'u':
> {
> const int hi_byte = DecodeHexU8();
> const int lo_byte = DecodeHexU8();
> if (hi_byte >=0 && lo_byte >= 0)
> return hi_byte << 8 | lo_byte;
> return -1;
> }
> break;
> }
> return ch2;
> }
> return ch;
> }
>
> You can see how it is used when the JSON parser is parsing in
> JSONParser::GetToken() in the '"' case.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] How to detach from stop mode without causing signal in inferior on Linux?
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: "*Trace/breakpoint trap*" I tried to call SBTarget.DeleteAllBreakpoints() first before killing debugger. Still the same result. Jeffrey ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] Jobs working on LLVM, Clang, and LLDB at Apple
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 title and a CV. 1. Clang Frontend Engineer In this position, you will work on general frontend development in Clang, with a particular focus on engineering new language and compiler features. Experience with development of C++ frontends is desirable for this position, but all strong candidates with frontend experience are encouraged to apply. Key Qualifications * Strong C++ coding skills and a passion for writing clean, high performing code. * Knowledge of compiler frontends and related tools. * Familiarity with compiler optimizations, code generation, and overall design of compilers. * Expert knowledge of C and C++, with a detailed understanding of the C++ standard and Itanium C++ ABI. * (Optional, but a big plus) Experience with Objective C/C++. * (Optional, but a big plus) Knowledge of LLVM/Clang and open source development. * Excellent communication and interpersonal skills. 2. Compiler Engineer In this position, you will make sure we ship a high quality compiler to our users. This involves working on various components of the LLVM toolchain to support new features, fix bugs, and improve performance. Experience with compiler development is desirable for this position, but strong candidates with other kinds of system software experience are also encouraged to apply. Key Qualifications: * Strong C++ coding skills and a passion for writing great code. * Familiarity with compiler optimizations, code generation and overall design of compilers. * Experience debugging a complex software stack and/or system level issues. * Strong track record of building high quality software. * Strong communication and teamwork skills. 3. LLVM/Clang - QE The Apple compiler team is hiring experienced Quality Engineers to drive quality improvements in LLVM/Clang and associated low level tools. You will be working closely with the compiler team to develop comprehensive test coverage for the suite of compiler tools with a heavy focus on automation and integration testing. Key Qualifications * Experienced in C/C++ development * Knowledge of how compilers work * Experience with Python * Ability to investigate and debug difficult problems * Ability to work in cross functional teams * (Optional, but a big plus) Knowledge of LLVM/Clang and open source development. * Excellent communication and interpersonal skills. * Experience with Jenkins CI systems. 4. LLDB Engineer We are seeking an enthusiastic engineer to improve the development experience across all of our platforms. The LLDB team blends compiler technology and a deep understanding of the runtime representation of running processes to enable a rich debugging experience, as well as enabling the Swift REPL and Playgrounds. You will be working with a talented team to improve on established tools and find new ways to apply technology from LLVM, Clang, and Swift to exploring running code. Key Qualifications * Experienced in C/C++ development * Knowledge of how compilers work * Knowledge of modern operating systems * Ability to investigate and debug difficult problems * Ability to work in cross functional teams * (Optional) Familiar with Swift * (Optional) Experience with Python * (Optional, but a big plus) Knowledge of LLVM/Clang and open source development. * Excellent communication and interpersonal skills. 5. LLDB - QE We are looking for a experienced Quality Engineer who is passionate about improving software quality. You will work closely with the Debugger team to develop and improve our automated testing and design new integration tests for LLDB. You will need to be able to write and debug complex C/C++ code and delve deep into the complexities of debugging on all Apple devices. Key Qualifications * Experienced in C/C++ development * Knowledge of how compilers and debuggers work * Experience with Python * Ability to investigate and debug difficult problems * Ability to work in cross functional teams with varying schedules. * (Optional, but a big plus) Knowledge of LLVM/Clang and open source development. * Excellent communication and interpersonal skills. * Experience with CI systems. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
