[lldb-dev] Allocation memory is failing in PPC64le

2017-12-05 Thread Alexandre Yukio Yamashita via lldb-dev
Hi,

I am trying to implement the expression evaluation for PPC64le using JIT.
But the LLDB is failling to allocate memory when it tries to evaluate an 
expression.
A Thread Plan is being interrupted before LLDB tries to allocate memory.
How could I check why this plan is not finishing?
What functions should I implement to enable JIT?
I am sending the logs of the issue below.

Thanks.
Alexandre.

lldb 0x10013069c10: tid = 0x976: stop info = breakpoint 1.1 
(stop_id = 4)
lldb Process::RunThreadPlan(): execution interrupted: 
0x3fff70006ac0 Event: broadcaster = 0x100130167b8 (lldb.process), type = 
0x0001 (state-changed), data = { process = 0x10013016780 (pid = 2422), 
state = stopped} <1 threads> <0x0976 [ip 0x158c] breakpoint 1.1>
lldb Process::RunThreadPlan: ExecutionInterrupted - discarding 
thread plans up to 0x10013076210.
lldb Discarding thread plans for thread tid = 0x0976, up to 
0x10013076210
lldb 0x10013025c10 Broadcaster("lldb.process")::RestoreBroadcaster 
(about to pop listener("lldb.process.listener.run-thread-plan")=0x10012f85810)
lldb 0x10012f85810 
Listener::Clear('lldb.process.listener.run-thread-plan')
lldb 0x10012f85810 
Listener::~Listener('lldb.process.listener.run-thread-plan')
lldb ThreadPlanCallFunction(0x10013076210): DoTakedown called as 
no-op for thread 0x0976, m_valid: 1 complete: 1.

lldb Target::RemoveBreakpointByID (break_id = -3, internal = yes)

lldb Target::DisableBreakpointByID (break_id = -3, internal = yes)

lldb GDBRemoteCommunicationClient::SendGDBStoppointTypePacket() 
remove at addr = 0x13d0
lldb 0x10013017168 Communication::Write (src = 0x10012e7d318, 
src_len = 17) connection = 0x1001302e610
lldb 0x1001302e610 ConnectionFileDescriptor::Write (src = 
0x10012e7d318, src_len = 17)
lldb 0x1001302e610 ConnectionFileDescriptor::Write(fd = 7, src = 
0x10012e7d318, src_len = 17) => 17 (error = (null))
lldb this = 0x010013017168, dst = 0x3FFFED125FC8, dst_len = 
8192, timeout = 00 us, connection = 0x01001302E610
lldb this = 0x01001302E610, timeout = 00 us
lldb 0x1001302e610 ConnectionFileDescriptor::Read()  fd = 7, dst = 
0x3fffed125fc8, dst_len = 8192) => 6, error = (null)
lldb ProcessGDBRemote::DoAllocateMemory no direct stub support for 
memory allocation, and InferiorCallMmap also failed - is stub missing register 
context save/restore capability?
lldb Process::DoAllocateMemory (byte_size = 0x1000, permissions 
= rwx) => 0x
lldb AllocatedMemoryCache::AllocateMemory (byte_size = 0x0008, 
permissions = rwx) => 0x
lldb Process::CanJIT pid 2422 allocation test failed, CanJIT () is 
false: unable to allocate 4096 bytes of memory with permissions rwx
lldb AllocatedMemoryCache::DeallocateMemory (addr = 
0x) => 0



--
Alexandre Yukio Yamashita (DSB)
Instituto de Pesquisas Eldorado
www.eldorado.org.br
+55 19 3757 3201 / +55 19 9 8336 5553
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev


Re: [lldb-dev] Allocation memory is failing in PPC64le

2017-12-05 Thread Pavel Labath via lldb-dev
On linux, we allocate memory by setting up the inferior registers to appear
as if the inferior called mmap(2) upon resume. This is done in
InferiorCallMmap. You should check whether this function sets up the
context correctly. Things to look at are:
- did it find the mmap address correctly?
- are the mmap flags correct
- is ABI correct (did it put the flags in the right registers)
- after mmap returns, it should jump to the process entry point (where we
have placed a breakpoint). Does this happen?
- do you correctly restore the original registers afterwards

Looking at the gdb-remote packet log should give you some insight there. If
you can send the relevant parts over, I can give you a rough answer as to
how far along did it progress before things broke down.


On 5 December 2017 at 11:54, Alexandre Yukio Yamashita via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> Hi,
>
> I am trying to implement the expression evaluation for PPC64le using JIT.
> But the LLDB is failling to allocate memory when it tries to evaluate an
> expression.
> A Thread Plan is being interrupted before LLDB tries to allocate memory.
> How could I check why this plan is not finishing?
> What functions should I implement to enable JIT?
> I am sending the logs of the issue below.
>
> Thanks.
> Alexandre.
> lldb 0x10013069c10: tid = 0x976: stop info = breakpoint 1.1
> (stop_id = 4)
> lldb Process::RunThreadPlan(): execution interrupted:
> 0x3fff70006ac0 Event: broadcaster = 0x100130167b8 (lldb.process), type =
> 0x0001 (state-changed), data = { process = 0x10013016780 (pid = 2422),
> state = stopped} <1 threads> <0x0976 [ip 0x158c] breakpoint 1.1>
> lldb Process::RunThreadPlan: ExecutionInterrupted - discarding
> thread plans up to 0x10013076210.
> lldb Discarding thread plans for thread tid = 0x0976, up to
> 0x10013076210
> lldb 0x10013025c10 Broadcaster("lldb.process")::RestoreBroadcaster
> (about to pop listener("lldb.process.listener.run-thread-plan")=
> 0x10012f85810)
> lldb 0x10012f85810 Listener::Clear('lldb.process.
> listener.run-thread-plan')
> lldb 0x10012f85810 Listener::~Listener('lldb.
> process.listener.run-thread-plan')
> lldb ThreadPlanCallFunction(0x10013076210): DoTakedown called
> as no-op for thread 0x0976, m_valid: 1 complete: 1.
>
> lldb Target::RemoveBreakpointByID (break_id = -3, internal =
> yes)
>
> lldb Target::DisableBreakpointByID (break_id = -3, internal =
> yes)
>
> lldb GDBRemoteCommunicationClient::SendGDBStoppointTypePacket()
> remove at addr = 0x13d0
> lldb 0x10013017168 Communication::Write (src = 0x10012e7d318,
> src_len = 17) connection = 0x1001302e610
> lldb 0x1001302e610 ConnectionFileDescriptor::Write (src =
> 0x10012e7d318, src_len = 17)
> lldb 0x1001302e610 ConnectionFileDescriptor::Write(fd = 7,
> src = 0x10012e7d318, src_len = 17) => 17 (error = (null))
> lldb this = 0x010013017168, dst = 0x3FFFED125FC8,
> dst_len = 8192, timeout = 00 us, connection = 0x01001302E610
> lldb this = 0x01001302E610, timeout = 00 us
> lldb 0x1001302e610 ConnectionFileDescriptor::Read()  fd = 7,
> dst = 0x3fffed125fc8, dst_len = 8192) => 6, error = (null)
> lldb ProcessGDBRemote::DoAllocateMemory no direct stub
> support for memory allocation, and InferiorCallMmap also failed - is stub
> missing register context save/restore capability?
> lldb Process::DoAllocateMemory (byte_size = 0x1000,
> permissions = rwx) => 0x
> lldb AllocatedMemoryCache::AllocateMemory (byte_size =
> 0x0008, permissions = rwx) => 0x
> lldb Process::CanJIT pid 2422 allocation test failed, CanJIT
> () is false: unable to allocate 4096 bytes of memory with permissions rwx
> lldb AllocatedMemoryCache::DeallocateMemory (addr =
> 0x) => 0
>
>
> --
> Alexandre Yukio Yamashita (DSB)
> Instituto de Pesquisas Eldorado
> www.eldorado.org.br
> +55 19 3757 3201 <+55%2019%203757-3201> / +55 19 9 8336 5553
>
> ___
> 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] gdb-remote incompatibility with gdbserver?

2017-12-05 Thread Greg Clayton via lldb-dev
LLDB should be changed to error out if we don't get any register information 
from the remote GDB server and have the error message tell us that we need to 
add register definition file. Then this would be clear. Maybe a message like:

error: GDB server doesn't vend register information. You must specify a 
register definition file with "settings set 
plugin.process.gdb-remote.target-definition-file /path/to/def-file.py"

Though it does seem to be a bug that the "gdbserver" you were using doesn't 
support the Target XML packets that the GDB remote protocol defines? Is this 
some old version of GDB remote from many many years ago? Seems any recent 
gdbserver should have this feature?

Greg


> On Dec 4, 2017, at 6:30 PM, David Manouchehri via lldb-dev 
>  wrote:
> 
> Thanks, that did the trick! Should I add this information to
> https://llvm.org/viewvc/llvm-project/lldb/trunk/www/ and submit a
> review on Phabricator?
> 
> root@13bfa9bdf1e7:/# lldb-5.0 /bin/date
> (lldb) target create "/bin/date"
> Current executable set to '/bin/date' (x86_64).
> (lldb) settings set plugin.process.gdb-remote.target-definition-file
> ./x86_64_linux_target_definition.py
> (lldb) gdb-remote localhost:
> (lldb) Process 5221 stopped
> * thread #1, stop reason = signal SIGTRAP
>frame #0: 0x2aaabc30
> ->  0x2aaabc30: movq   %rsp, %rdi
>0x2aaabc33: callq  0x2aaac9b0
>0x2aaabc38: movq   %rax, %r12
>0x2aaabc3b: movl   0x225037(%rip), %eax
> 
> For those who run into this message in the future, here's the exact
> commands I ran to get gdbserver working:
> 
> wget -O - http://apt.llvm.org/llvm-snapshot.gpg.key | sudo apt-key add -
> sudo apt-add-repository "deb http://apt.llvm.org/xenial/
> llvm-toolchain-xenial-5.0 main"
> sudo apt-get update
> sudo apt-get -y install lldb-5.0 gdbserver
> wget 
> https://llvm.org/svn/llvm-project/lldb/trunk/examples/python/x86_64_linux_target_definition.py
> # In another terminal run: gdbserver localhost: /bin/date
> lldb-5.0 /bin/date
> settings set plugin.process.gdb-remote.target-definition-file
> ./x86_64_linux_target_definition.py
> gdb-remote localhost:
> ___
> 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] gdb-remote incompatibility with gdbserver?

2017-12-05 Thread David Manouchehri via lldb-dev
I was/am running gdbserver 7.11.1 (Ubuntu 7.11.1-0ubuntu1~16.5).
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev


Re: [lldb-dev] gdb-remote incompatibility with gdbserver?

2017-12-05 Thread Greg Clayton via lldb-dev

> On Dec 5, 2017, at 12:45 PM, Pedro Alves  wrote:
> 
> On 12/05/2017 06:49 PM, Greg Clayton via lldb-dev wrote:
> 
>> Though it does seem to be a bug that the "gdbserver" you were using doesn't 
>> support the Target XML packets that the GDB remote protocol defines? Is this 
>> some old version of GDB remote from many many years ago? Seems any recent 
>> gdbserver should have this feature?
> 
> The x86 port of gdbserver won't send back a XML target description
> unless the client includes "xmlRegisters=i386" in the initial
> qSupported negotiation.  (This was done at the same time support
> for x86 XML descriptions was added in order to keep new-gdbserver
> working against old-gdb, because the XML register layout doesn't match
> the no-XML layout.)

Interesting! So would we add xmlRegisters=i386 to qSupported for i386 and 
xmlRegisters=x86_64 for x86_64? We should have LLDB send this down to the 
server then and everything would just work?

Greg

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev


Re: [lldb-dev] gdb-remote incompatibility with gdbserver?

2017-12-05 Thread David Manouchehri via lldb-dev
Is there a user accessible setting to force on XML target descriptions
in new-gdbsever?
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev


[lldb-dev] December LLVM bay-area social is this Thursday!

2017-12-05 Thread George Burgess IV via lldb-dev
We'll be at Tied House as usual, starting on Thursday the 7th at 7pm!

If you can, help us plan and RSVP here:
https://www.meetup.com/LLVM-Bay-Area-Social/events/kncsjlywqbkb/

See everyone there!
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev