[valgrind] [Bug 356174] Enhance the embedded gdbserver to allow LLDB to use it

[Sam James]

https://bugs.kde.org/show_bug.cgi?id=356174

Sam James  changed:

   What|Removed |Added

 CC||s...@gentoo.org

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 356174] Enhance the embedded gdbserver to allow LLDB to use it

[Paul Floyd]

https://bugs.kde.org/show_bug.cgi?id=356174

Paul Floyd  changed:

   What|Removed |Added

 CC||pjfl...@wanadoo.fr

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 356174] Enhance the embedded gdbserver to allow LLDB to use it

[Ivo Raisr via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=356174

Ivo Raisr  changed:

   What|Removed |Added

 CC||iv...@ivosh.net

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 356174] Enhance the embedded gdbserver to allow LLDB to use it

[Philippe Waroquiers via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=356174

--- Comment #16 from Philippe Waroquiers  ---
(In reply to Daniel Trebbien from comment #15)
> Looking through the sources of the release_35 and release_36 branches, I see
> that LLDB 3.5 and 3.6 do not support the target.xml or target definition
> file ways of specifying register information.  See
> ProcessGDBRemote::BuildDynamicRegisterInfo():
> http://llvm.org/svn/llvm-project/lldb/branches/release_35/source/Plugins/
> Process/gdb-remote/ProcessGDBRemote.cpp
> http://llvm.org/svn/llvm-project/lldb/branches/release_36/source/Plugins/
> Process/gdb-remote/ProcessGDBRemote.cpp
> 
> LLDB 3.7 is the first to add this support:
> http://llvm.org/svn/llvm-project/lldb/branches/release_37/source/Plugins/
> Process/gdb-remote/ProcessGDBRemote.cpp
> 
> I think that to get this working with LLDB 3.5 and 3.6, the embedded
> gdbserver would need to respond to 'qRegisterInfo XX' packets. 
> 'qRegisterInfo' is specific to LLDB.  It is documented here:
> http://llvm.org/svn/llvm-project/lldb/trunk/docs/lldb-gdb-remote.txt
> 
> Adding support for 'qRegisterInfo' would entail using an XML parser in the
> embedded server which can build up the XML target description (resolving the
> s if any), and then process the  elements.
> 
> Would adding a dependency on an XML parser be out of the question? 
> Preferably libxml2.
Valgrind core cannot be linked with a library (to avoid problems of
interactions
with guest processes that are using the same library).
So, linking with libxml2 is out of the question.

Also, if lldb 3.7 properly supports target.xml, then it looks to me good enough
to make the changes needed to have lldb 3.7 working properly:
As I understood, it is needed to do some modifications to the xml files, to add
some lldb specific xml elements, such as altname or generic.
What we have to ensure is that these elements unknown to gdb are not causing a
problem
(the idea is that valgrind gdbserver supports various gdb versions).
 Otherwise, either lldb has to be modified to work with the current xml files,
or alternatively, we maintain 2 sets of xml files : the 'gdb' version and the
'lldb' version
(we can maybe build the first one by automatically editing the 2nd one during
build phase).

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 356174] Enhance the embedded gdbserver to allow LLDB to use it

[Daniel Trebbien via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=356174

Daniel Trebbien  changed:

   What|Removed |Added

  Attachment #95906|0   |1
is obsolete||

--- Comment #11 from Daniel Trebbien  ---
Created attachment 95931
  --> https://bugs.kde.org/attachment.cgi?id=95931=edit
Add generic register info (2)

This patch adds LLDB generic register info to 32bit-core.xml, 64bit-core.xml,
arm-core.xml, mips-cpu.xml, mips64-cpu.xml, power-core.xml, and
power64-core.xml based on LLDB sources:
http://llvm.org/svn/llvm-project/lldb/trunk/source/Plugins/ABI/

s390x-core64.xml is not touched because it appears that LLDB does not support
s390.

This patch also includes a small change in server.c so that
qXfer:features:read+ is always included in the response to a 'qSupported'
packet.

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 356174] Enhance the embedded gdbserver to allow LLDB to use it

[Daniel Trebbien via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=356174

--- Comment #14 from Daniel Trebbien  ---
(In reply to Philippe Waroquiers from comment #13)
> On debina8/x86, when using --vgdb-shadow-registers=yes, valgrind gdbserver
> reports
> qXfer:features:read+;
> but lldb 3.5.0 does not read target.xml
> 
> When I use gdb with the same setup, it requests to read target.xml

Hmmm, yes, I can confirm that I see this issue (using lldb 3.5 on debian8/x86).
 I am taking a look at this.

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 356174] Enhance the embedded gdbserver to allow LLDB to use it

[Daniel Trebbien via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=356174

--- Comment #15 from Daniel Trebbien  ---
Looking through the sources of the release_35 and release_36 branches, I see
that LLDB 3.5 and 3.6 do not support the target.xml or target definition file
ways of specifying register information.  See
ProcessGDBRemote::BuildDynamicRegisterInfo():
http://llvm.org/svn/llvm-project/lldb/branches/release_35/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
http://llvm.org/svn/llvm-project/lldb/branches/release_36/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp

LLDB 3.7 is the first to add this support:
http://llvm.org/svn/llvm-project/lldb/branches/release_37/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp

I think that to get this working with LLDB 3.5 and 3.6, the embedded gdbserver
would need to respond to 'qRegisterInfo XX' packets.  'qRegisterInfo' is
specific to LLDB.  It is documented here:
http://llvm.org/svn/llvm-project/lldb/trunk/docs/lldb-gdb-remote.txt

Adding support for 'qRegisterInfo' would entail using an XML parser in the
embedded server which can build up the XML target description (resolving the
s if any), and then process the  elements.

Would adding a dependency on an XML parser be out of the question?  Preferably
libxml2.

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 356174] Enhance the embedded gdbserver to allow LLDB to use it

[Daniel Trebbien via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=356174

--- Comment #10 from Daniel Trebbien  ---
(In reply to Philippe Waroquiers from comment #9)
> Otherwise, valgrind gdbserver expects that the debugger knows the register
> layout of x86 or amd64.

I think that this is what is causing the problem; i.e. that unlike gdb, lldb
does not have built-in knowledge of the x86 and amd64 architectures.

On my system (OS X 10.11.1 and Core i7 with AVX support), the embedded
gdbserver responds with qXfer:features:read+ and lldb retrieves the target.xml.
 In my case, the embedded gdbserver sends back amd64-avx-coresse.xml.  When I
comment out the s leaving just the
i386:x86-64 element, then I also see "frame #0:
0x" and `register read' says "error: invalid frame".

I think that the solution is to always respond with qXfer:features:read+ and
for the XML target descriptions to have the generic register information.

I am looking at the LLDB sources, within source/Plugins/ABI, to see what the
appropriate generic registers are for the different architectures.

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 356174] Enhance the embedded gdbserver to allow LLDB to use it

[Daniel Trebbien via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=356174

Daniel Trebbien  changed:

   What|Removed |Added

  Attachment #95898|0   |1
is obsolete||

--- Comment #7 from Daniel Trebbien  ---
Created attachment 95906
  --> https://bugs.kde.org/attachment.cgi?id=95906=edit
Add generic register info

Swapping the 'rip' and 'r15' register declarations is not the right fix.

In this case, as explained by Greg Clayton
(http://lists.llvm.org/pipermail/lldb-dev/2015-December/009021.html ), LLDB is
looking for the 'arg1' through 'arg6' generic registers.  This information can
be supplied by adding appropriate `generic' attributes to the  elements.

This new patch adds `generic' attributes to the declarations of 'rcx', 'rdx',
'rsi', 'rdi', 'rbp', 'rsp', 'r8', 'r9', 'rip', and 'eflags'.

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 356174] Enhance the embedded gdbserver to allow LLDB to use it

[Philippe Waroquiers via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=356174

--- Comment #9 from Philippe Waroquiers  ---
An additional note: on x86 linux, valgrind gdbserver only reports  the
Xfer:features:read+ 
supported if --vgdb-shadow-registers=yes is given.
On amd64 linux, Xfer:features:read+ is reported as supported if either shadow
registers are
requested or if the host has avx register.
Otherwise, valgrind gdbserver expects that the debugger knows the register
layout
of x86 or amd64.

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 356174] Enhance the embedded gdbserver to allow LLDB to use it

[Daniel Trebbien via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=356174

--- Comment #5 from Daniel Trebbien  ---
I contacted Apple Developer Relations about the crash and they informed me that
unlike gdb, lldb does not have an initial target definition set, and relies on
the gdbserver to tell it which registers the gdbserver supports.  This can be
done either by responding to 'qRegisterInfo XX' packets or to
'qXfer:features:read:target.xml'.

They also informed me about the
plugin.process.gdb-remote.target-definition-file LLDB setting and the example
target definitions at
http://llvm.org/svn/llvm-project/lldb/trunk/examples/python/
I can confirm that using either x86_64_linux_target_definition.py or
x86_64_target_definition.py fixes the segfault issue.

I have posted a message to lldb-dev to ask if anyone can see why the XML target
definition sent back by the embedded gdbserver might be causing the crash:
http://lists.llvm.org/pipermail/lldb-dev/2015-December/009011.html

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 356174] Enhance the embedded gdbserver to allow LLDB to use it

[Philippe Waroquiers via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=356174

Philippe Waroquiers  changed:

   What|Removed |Added

 CC||philippe.waroquiers@skynet.
   ||be

--- Comment #4 from Philippe Waroquiers  ---
Thanks for the analysis and patches. I can reproduce on debian8/x86 the problem
that
implies to have support for qC.
I have quickly looked at the patches, which look ok.
I should be able to handle and commit the patches in a few days.

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 356174] Enhance the embedded gdbserver to allow LLDB to use it

[Daniel Trebbien via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=356174

--- Comment #3 from Daniel Trebbien  ---
The two patches allow LLDB 3.4, 3.5, and 3.6 to debug using the embedded
gdbserver on an Ubuntu 14.04.3 'Trusty Tahr' system.

The crash on Mac has the following backtrace:
```
Thread 5 Crashed:
0   com.apple.LLDB.framework  0x000108b637ad
ABISysV_x86_64::GetArgumentValues(lldb_private::Thread&,
lldb_private::ValueList&) const + 147
1   com.apple.LLDB.framework  0x0001089aba51
DynamicLoaderMacOSXDYLD::NotifyBreakpointHit(void*,
lldb_private::StoppointCallbackContext*, unsigned long long, unsigned long
long) + 399
2   com.apple.LLDB.framework  0x00010882ce04
lldb_private::BreakpointOptions::InvokeCallback(lldb_private::StoppointCallbackContext*,
unsigned long long, unsigned long long) + 48
3   com.apple.LLDB.framework  0x000108829f7e
lldb_private::BreakpointLocation::InvokeCallback(lldb_private::StoppointCallbackContext*)
+ 82
4   com.apple.LLDB.framework  0x00010882a6de
lldb_private::BreakpointLocation::ShouldStop(lldb_private::StoppointCallbackContext*)
+ 116
5   com.apple.LLDB.framework  0x00010882b418
lldb_private::BreakpointLocationCollection::ShouldStop(lldb_private::StoppointCallbackContext*)
+ 76
6   com.apple.LLDB.framework  0x000108833884
lldb_private::BreakpointSite::ShouldStop(lldb_private::StoppointCallbackContext*)
+ 48
7   com.apple.LLDB.framework  0x000108ac0db5
lldb_private::StopInfoBreakpoint::ShouldStopSynchronous(lldb_private::Event*) +
241
8   com.apple.LLDB.framework  0x000108adabdf
lldb_private::Thread::ShouldStop(lldb_private::Event*) + 715
9   com.apple.LLDB.framework  0x000108ae0562
lldb_private::ThreadList::ShouldStop(lldb_private::Event*) + 502
10  com.apple.LLDB.framework  0x000108aae550
lldb_private::Process::ShouldBroadcastEvent(lldb_private::Event*) + 396
11  com.apple.LLDB.framework  0x000108aab685
lldb_private::Process::HandlePrivateEvent(std::__1::shared_ptr&)
+ 471
12  com.apple.LLDB.framework  0x000108aaed3a
lldb_private::Process::RunPrivateStateThread() + 568
13  com.apple.LLDB.framework  0x000108aae771
lldb_private::Process::PrivateStateThread(void*) + 9
14  libsystem_pthread.dylib   0x7fff8e3b59b1 _pthread_body + 131
15  libsystem_pthread.dylib   0x7fff8e3b592e _pthread_start + 168
16  libsystem_pthread.dylib   0x7fff8e3b3385 thread_start + 13
```

This appears to be Apple-specific.

If these two patches are committed, then I think that this bug can be closed as
"fixed".

-- 
You are receiving this mail because:
You are watching all bug changes.