Hi Greg,
It's enumerating the debug registers, which is different than what
debugserver does.
< 60> read packet:
$name:dr0;bitsize:64;offset:848;encoding:uint;format:hex;#54 < 19> send
packet: $qRegisterInfo87#b1 < 60> read packet:
$name:dr1;bitsize:64;offset:856;encoding:uint;format:hex;#54 < 19> send
packet: $qRegisterInfo88#b2 < 60> read packet:
$name:dr2;bitsize:64;offset:864;encoding:uint;format:hex;#54 < 19> send
packet: $qRegisterInfo89#b3 < 60> read packet:
$name:dr3;bitsize:64;offset:872;encoding:uint;format:hex;#54 < 19> send
packet: $qRegisterInfo8a#db < 60> read packet:
$name:dr4;bitsize:64;offset:880;encoding:uint;format:hex;#54 < 19> send
packet: $qRegisterInfo8b#dc < 60> read packet:
$name:dr5;bitsize:64;offset:888;encoding:uint;format:hex;#5d < 19> send
packet: $qRegisterInfo8c#dd < 60> read packet:
$name:dr6;bitsize:64;offset:896;encoding:uint;format:hex;#5d < 19> send
packet: $qRegisterInfo8d#de < 60> read packet:
$name:dr7;bitsize:64;offset:904;encoding:uint;format:hex;#54 < 19> send
packet: $qRegisterInfo8e#df < 7> read packet: $E45#ae
Later on, trying to read these registers returns an error
< 20> send packet: $p85;thread:71ec;#35
< 68> read packet:
$0000000000000000000000000000000000000000000000000000000000000000#00
< 20> send packet: $p86;thread:71ec;#36
< 7> read packet: $E15#ab
< 20> send packet: $p87;thread:71ec;#37
< 7> read packet: $E15#ab
< 20> send packet: $p88;thread:71ec;#38
< 7> read packet: $E15#ab
< 20> send packet: $p89;thread:71ec;#39
< 7> read packet: $E15#ab
< 20> send packet: $p8a;thread:71ec;#61
< 7> read packet: $E15#ab
< 20> send packet: $p8b;thread:71ec;#62
< 7> read packet: $E15#ab
< 20> send packet: $p8c;thread:71ec;#63
< 7> read packet: $E15#ab
< 20> send packet: $p8d;thread:71ec;#64
< 7> read packet: $E15#ab
I can probably fix the register read (not sure) but should I? These will be
used internally by LLDB for watchpoints, right?
> There should be no need to do anything special in
GDBRemoteCommunicationServer::Handle_qRegisterInfo()
Then the solution is to remove the debug registers from
RegisterInfos_x86_64.h
On Tue, Nov 18, 2014 at 11:27 AM, Greg Clayton <gclay...@apple.com> wrote:
> When running qRegisterInfo, there can be no gaps in the register
> numbering. There should be no need to do anything special in
> GDBRemoteCommunicationServer::Handle_qRegisterInfo(). The remote llgs
> should be correctly responding to the qRegisterInfo packet and if it is
> truthful then there should be no problem. It sounds like the bug is in llgs
> and it is sending back the wrong responses for qRegisterInfo. Can you
> elaborate on what is not correct in the qRegisterInfo packets? Maybe attach
> a log from "log enable -f /tmp/packets.txt gdb-remote packets" and I can
> tell you more.
>
> Greg
>
> > On Nov 17, 2014, at 7:31 PM, Vince Harron <vhar...@google.com> wrote:
> >
> > Hi Ed/all,
> >
> > I'm working on Linux remote debugging. I'm getting a failure in one of
> the TestRegisters.py tests.
> >
> > It stems from the fact that the register context's register list is
> longer than the number of registers covered by the union of all register
> sets (CPU/FPU/AVX).
> (lldb/source/Plugins/Process/Utility/RegisterInfos_x86_64.h has the x86
> debug registers listed)
> >
> > For local debugging, registers are enumerated by set rather than index
> so we don't see any of those registers.
> >
> > For remote debugging, registers are enumerated by register index so
> those registers are sent over to the host. This behavior differs from
> debugserver.
> >
> > I have a couple of options here
> >
> > 1) I can remove the debug registers from RegisterInfos_x86_64.h. I'm
> inclined to do this but they seem be used by FreeBSD but I'm not sure why.
> >
> > 2) I can add a check that the register index being queried is part of a
> valid register set. (See patch below)
> >
> > 3) I might be able to make these registers readable/writeable on Linux
> but I think we'll want to use them internally in LLDB (to implement
> watchpoints?) and not display them to users at all.
> >
> > Thoughts?
> >
> > Thanks,
> >
> > Vince
> >
> > GDBRemoteCommunicationServer::Handle_qRegisterInfo
> (StringExtractorGDBRemote &pa
> > // Ensure we have a thread.
> > NativeThreadProtocolSP thread_sp
> (m_debugged_process_sp->GetThreadAtIndex (0));
> > if (!thread_sp)
> > return SendErrorResponse (69);
> >
> > // Get the register context for the first thread.
> > NativeRegisterContextSP reg_context_sp
> (thread_sp->GetRegisterContext ());
> > if (!reg_context_sp)
> > return SendErrorResponse (69);
> >
> > // Parse out the register number from the request.
> > packet.SetFilePos (strlen("qRegisterInfo"));
> > const uint32_t reg_index = packet.GetHexMaxU32 (false,
> std::numeric_limits<uint32_t>::max ());
> > if (reg_index == std::numeric_limits<uint32_t>::max ())
> > return SendErrorResponse (69);
> >
> > // Return the end of registers response if we've iterated one past
> the end of the register set.
> > if (reg_index >= reg_context_sp->GetRegisterCount ())
> > return SendErrorResponse (69);
> >
> > + // Verify that the register index is part of a valid register set
> > + const char* reg_set_name =
> reg_context_sp->GetRegisterSetNameForRegisterAtIndex(reg_index);
> > + if (!reg_set_name)
> > + {
> > + return SendErrorResponse (69);
> > + }
> > +
> > + bool reg_set_available = false;
> > + for (uint32_t reg_set_idx = 0; reg_set_idx <
> reg_context_sp->GetRegisterSetCount(); reg_set_idx++)
> > + {
> > + const RegisterSet* reg_set =
> reg_context_sp->GetRegisterSet(reg_set_idx);
> > + if (0 == strcmp(reg_set->name,reg_set_name))
> > + {
> > + reg_set_available = true;
> > + break;
> > + }
> > + }
> > + if (!reg_set_available)
> > + {
> > + return SendErrorResponse (69);
> > + }
> > +
> > const RegisterInfo *reg_info =
> reg_context_sp->GetRegisterInfoAtIndex(reg_index);
> > if (!reg_info)
> > return SendErrorResponse (69);
> >
> > // Build the reginfos response.
> > StreamGDBRemote response;
> >
> >
> > --
> >
> > Vince Harron | Technical Lead Manager |
> vhar...@google.com | 858-442-0868
> >
> > _______________________________________________
> > lldb-dev mailing list
> > lldb-dev@cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>
>
--
Vince Harron | Technical Lead Manager | vhar...@google.com | 858-442-0868
_______________________________________________
lldb-dev mailing list
lldb-dev@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
