This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Spec; Was: tracepoints implementation: bug in byte code generating.


>>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:
>> 4.1 REGISTER FETCH
>> 
>> input:
>> context_t       id;
>> int             offset;         offset within register data
>> int             length;         length of transfer
>> 
>> output:
>> int             status;
>> char            data[];
>> 
>> This command may yeild unpredicable results if context <id> has not
>> been suspended.
>> 
>> issues:
>> This assumes a single flat address space for all registers.
>> It might be convienent to have separate (but potentially
>> overlapping) register files for integer registers, floating
>> point registers, system registers, miscellaneous registers,
>> etc.
>> 
>> For example, one register file could contain the PC, FP, SP,
>> and whatever other registers are needed on a particular
>> architecture for GDB after a signal/exception/breakpoint
>> event.  This would solve the problem of what to return in
>> those events.

Andrew> One problem with this on targets that like to switch their
Andrew> byte order (yes not very many :-).  The register data is, by
Andrew> definition, target byte order dependant.  Consequently, when
Andrew> GDB connects to the target it needs to know that targets byte
Andrew> order for it to correctly interpret register values.

I mentioned in the introduction that I hadn't settled on how any field
should be encoded. 

At this point, I have been thinking of the low levels being binary, so
that virtual I/O, etc. is relatively efficent.  This essentially pre-
cludes being able to understand what's going on by looking at the raw
packets (which has been mentioned in the past as being one of the
assets of the current remote debug protocol).  I think some code that
can be bound into GDB and the debug agent that would produce annotated
output for each packet (sort of like tcpdump) might accomplish the same
thing.

If the low layers end up like this, (IMO) there is little to gained by
having the debug protocol ASCII based.  So the byte order issue is not
only relevant for register and memory data, but also for simple things
like addresses, breakpoint ids, etc.

Wind River's WDB is based on Sun XDR/RPC.  XDR could be used to
provide a host- and target-independent representation for the fields
in each command and response.  Since rpcgen can generate the code to
encode and decode the structures, It's proabably what I'll be using
for a proof of concept implementation.

        --jtc

-- 
J.T. Conklin
RedBack Networks

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]