[lldb-dev] [Bug 27073] New: TestReturnValue.test_with_python fails with hard float abi on android device
https://llvm.org/bugs/show_bug.cgi?id=27073 Bug ID: 27073 Summary: TestReturnValue.test_with_python fails with hard float abi on android device Product: lldb Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-dev@lists.llvm.org Reporter: chy...@google.com CC: llvm-b...@lists.llvm.org Classification: Unclassified Xfail the test. -- You are receiving this mail because: You are the assignee for the bug. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [Bug 27074] New: TestCallUserAnonTypedef.py fails with hard float abi on android arm
https://llvm.org/bugs/show_bug.cgi?id=27074 Bug ID: 27074 Summary: TestCallUserAnonTypedef.py fails with hard float abi on android arm Product: lldb Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-dev@lists.llvm.org Reporter: chy...@google.com CC: llvm-b...@lists.llvm.org Classification: Unclassified xfail the test for hard float abi. -- You are receiving this mail because: You are the assignee for the bug. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [Bug 27075] New: TestLldbGdbServer.software_breakpoint_set_and_remove_work fails on android arm with -mthumb
https://llvm.org/bugs/show_bug.cgi?id=27075 Bug ID: 27075 Summary: TestLldbGdbServer.software_breakpoint_set_and_remove_w ork fails on android arm with -mthumb Product: lldb Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-dev@lists.llvm.org Reporter: chy...@google.com CC: llvm-b...@lists.llvm.org Classification: Unclassified xfail TestLldbGdbServer.software_breakpoint_set_and_remove_work for "-mthumb". -- You are receiving this mail because: You are the assignee for the bug. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] SBListener not using a shared_ptr internally?
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::SBListener{listener} {
}
~SBListener_Internal() = default;
void* GetInternalPtr() {
return reinterpret_cast(GetSP().get());
}
};
I had some worried about if the SBListener object could be destroyed
at some point and the internal pointer would still be in the
"ListenerWorkers" map so
to avoid that I copied the the SBListener object into the class which
manages the thread and stuff (SBListenerWorker), that means that the
reference counter should be still > 0 when all other shared_ptrs are
destroyed.
Now to the actual problem, it turns out that GetInternalPtr() actually
returns nullptr and instead uses m_opaque_ptr for calling internal
functions.
This means that the SBListener object isn't actually using a
shared_ptr internally, which brings another question up if it is save
to use the SBListener across thread? What happens if the SBListener
gets destroyed.
___
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?
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::SBListener{listener} {
> }
> ~SBListener_Internal() = default;
>
> void* GetInternalPtr() {
>return reinterpret_cast(GetSP().get());
> }
> };
>
> I had some worried about if the SBListener object could be destroyed
> at some point and the internal pointer would still be in the
> "ListenerWorkers" map so
> to avoid that I copied the the SBListener object into the class which
> manages the thread and stuff (SBListenerWorker), that means that the
> reference counter should be still > 0 when all other shared_ptrs are
> destroyed.
>
> Now to the actual problem, it turns out that GetInternalPtr() actually
> returns nullptr and instead uses m_opaque_ptr for calling internal
> functions.
> This means that the SBListener object isn't actually using a
> shared_ptr internally, which brings another question up if it is save
> to use the SBListener across thread? What happens if the SBListener
> gets destroyed.
> ___
> 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] SBListener not using a shared_ptr internally?
One question is why are you trying to make SBListener::WaitForEvent
non-blocking? Seems like an implementation that changes the behavior of the API
is going to make the port less useful. Can you go into some detail as to why
you are trying to do this?
Are you using swig to do the javascript port?
Greg
> 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::SBListener{listener} {
> }
> ~SBListener_Internal() = default;
>
> void* GetInternalPtr() {
>return reinterpret_cast(GetSP().get());
> }
> };
>
> I had some worried about if the SBListener object could be destroyed
> at some point and the internal pointer would still be in the
> "ListenerWorkers" map so
> to avoid that I copied the the SBListener object into the class which
> manages the thread and stuff (SBListenerWorker), that means that the
> reference counter should be still > 0 when all other shared_ptrs are
> destroyed.
>
> Now to the actual problem, it turns out that GetInternalPtr() actually
> returns nullptr and instead uses m_opaque_ptr for calling internal
> functions.
> This means that the SBListener object isn't actually using a
> shared_ptr internally, which brings another question up if it is save
> to use the SBListener across thread? What happens if the SBListener
> gets destroyed.
> ___
> 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] SBListener not using a shared_ptr internally?
I am currently using the package from Arch Linux's repository, it's 3.7.1.
So I guess this "patch" will be in llvm/lldb 3.8.1?
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::SBListener{listener} {
>> }
>> ~SBListener_Internal() = default;
>>
>> void* GetInternalPtr() {
>>return reinterpret_cast(GetSP().get());
>> }
>> };
>>
>> I had some worried about if the SBListener object could be destroyed
>> at some point and the internal pointer would still be in the
>> "ListenerWorkers" map so
>> to avoid that I copied the the SBListener object into the class which
>> manages the thread and stuff (SBListenerWorker), that means that the
>> reference counter should be still > 0 when all other shared_ptrs are
>> destroyed.
>>
>> Now to the actual problem, it turns out that GetInternalPtr() actually
>> returns nullptr and instead uses m_opaque_ptr for calling internal
>> functions.
>> This means that the SBListener object isn't actually using a
>> shared_ptr internally, which brings another question up if it is save
>> to use the SBListener across thread? What happens if the SBListener
>> gets destroyed.
>> ___
>> 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] SBListener not using a shared_ptr internally?
I am coding bindings for node.js which is basically V8 with an event
loop (libuv). So by the nature of nodejs, having "blocking" could stop
the whole event-loop, that's why I am trying to make WaitForEvent
non-blocking.
I am not using swig to do the port. It's more like directly using the
V8 api which surprisingly isn't that complicated.
2016-03-25 22:48 GMT+01:00 Greg Clayton :
> One question is why are you trying to make SBListener::WaitForEvent
> non-blocking? Seems like an implementation that changes the behavior of the
> API is going to make the port less useful. Can you go into some detail as to
> why you are trying to do this?
>
> Are you using swig to do the javascript port?
>
> Greg
>
>> 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::SBListener{listener} {
>> }
>> ~SBListener_Internal() = default;
>>
>> void* GetInternalPtr() {
>>return reinterpret_cast(GetSP().get());
>> }
>> };
>>
>> I had some worried about if the SBListener object could be destroyed
>> at some point and the internal pointer would still be in the
>> "ListenerWorkers" map so
>> to avoid that I copied the the SBListener object into the class which
>> manages the thread and stuff (SBListenerWorker), that means that the
>> reference counter should be still > 0 when all other shared_ptrs are
>> destroyed.
>>
>> Now to the actual problem, it turns out that GetInternalPtr() actually
>> returns nullptr and instead uses m_opaque_ptr for calling internal
>> functions.
>> This means that the SBListener object isn't actually using a
>> shared_ptr internally, which brings another question up if it is save
>> to use the SBListener across thread? What happens if the SBListener
>> gets destroyed.
>> ___
>> 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
[lldb-dev] SBProcess::Detach kills target
Hi, Is this expected behavior or am I doing something wrong? I am running my C++ program that uses LLDB API on Linux Ubuntu 15.10. If I attach to already running process then SBProcess::Detach() behaves as expected - my debugger quits and the target keeps running. But if the target was launched by my debugger, then detach just kills it. Is there any way to leave the target running? Thanks,Eugene ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] SBProcess::Detach kills target
Calling SBProcess::Detach() on a process that is currently running should always detach and this seems like a bug. This might be this way because if you launch a process in LLDB and then quit: % lldb /bin/ls (lldb) b malloc (lldb) run (lldb) quit This should kill the process if it was launched and detach if we attached. But only when we quit without telling it to do something. If we did: % lldb /bin/ls (lldb) b malloc (lldb) run (lldb) detach Then this should always detach if the user explicitly requests it no matter how it was launched. > On Mar 25, 2016, at 3:35 PM, Eugene Birukov via lldb-dev > wrote: > > Hi, > > Is this expected behavior or am I doing something wrong? > > I am running my C++ program that uses LLDB API on Linux Ubuntu 15.10. > > If I attach to already running process then SBProcess::Detach() behaves as > expected - my debugger quits and the target keeps running. But if the target > was launched by my debugger, then detach just kills it. Is there any way to > leave the target running? > > Thanks, > Eugene > ___ > 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] SBProcess::Detach kills target
I vaguely remember that not all Unixen support detaching from a process that is a child of the debugger that is attached to it. If you run the process under gdb & detach, does the process survive? This may not be an exact test, since gdb may use procfs rather than ptrace, I don't know any more... But if it doesn't work for gdb, it's probably a system limitation. Anyway, launch then detach works as Greg described on OS X, so all the bits down to the call into the Process plugin's Detach is working correctly. So either there's a bug in llgs or in the Process plugin for Linux's detach. Jim > On Mar 25, 2016, at 3:57 PM, Greg Clayton via lldb-dev > wrote: > > Calling SBProcess::Detach() on a process that is currently running should > always detach and this seems like a bug. This might be this way because if > you launch a process in LLDB and then quit: > > % lldb /bin/ls > (lldb) b malloc > (lldb) run > (lldb) quit > > This should kill the process if it was launched and detach if we attached. > But only when we quit without telling it to do something. If we did: > > % lldb /bin/ls > (lldb) b malloc > (lldb) run > (lldb) detach > > Then this should always detach if the user explicitly requests it no matter > how it was launched. > >> On Mar 25, 2016, at 3:35 PM, Eugene Birukov via lldb-dev >> wrote: >> >> Hi, >> >> Is this expected behavior or am I doing something wrong? >> >> I am running my C++ program that uses LLDB API on Linux Ubuntu 15.10. >> >> If I attach to already running process then SBProcess::Detach() behaves as >> expected - my debugger quits and the target keeps running. But if the target >> was launched by my debugger, then detach just kills it. Is there any way to >> leave the target running? >> >> Thanks, >> Eugene >> ___ >> 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 ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [Bug 27079] New: Add an MSVC Language Runtime ABI
https://llvm.org/bugs/show_bug.cgi?id=27079 Bug ID: 27079 Summary: Add an MSVC Language Runtime ABI Product: lldb Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-dev@lists.llvm.org Reporter: ztur...@google.com CC: llvm-b...@lists.llvm.org, ztur...@google.com Classification: Unclassified Right now the only C++ language runtime assumes Itanium ABI. This is probably the reason for a number of test failures, especially those involving virtual bases, functions, and dynamic types. We will need to add one for MSVC ABI. Less importantly, it is possible for MSVC and Itanium ABI modules to be loaded into the same process. The system doesn't seem well designed to handle this, so it will probably be some effort to get that working. -- You are receiving this mail because: You are the assignee for the bug. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
