This is the mail archive of the gdb-patches@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: tracepoints implementation: bug in byte code generating.



----- Original Message -----
From: "J.T. Conklin" <jtc@redback.com>
To: "Josef Ezra" <jezra@emc.com>
Cc: "Michael Snyder" <msnyder@redhat.com>; <gdb-patches@sources.redhat.com>;
"ezra, josef" <ezra_josef@emc.com>; <shagam@emc.com>; <sgordon@emc.com>
Sent: Thursday, October 19, 2000 7:14 PM
Subject: Re: tracepoints implementation: bug in byte code generating.


> >>>>> "Josef" == Josef Ezra <jezra@emc.com> writes:
> >> Any changes to the remote protocol can be discussed
> >> on this mailing list.
>
> Josef> Actually I had in mind a 'show protocol version' command (for
> Josef> backward compatibility) and a special read memory command (like
> Josef> "mxxxx,lll") which can be used at target side for special reads
> Josef> (in my case, it will show values in different memory scope).
>
> For better or for worse, the remote protocol is been designed such
> that support for individual features can be probed for at run time
> instead of having protocol versions.
>
> While I believe that this has allowed new command packets to be added
> to the protocol expediently, I also believe that a more formal design
> and review may have produced a better overall result.  Even so, if at
> all possible, I think your new command should be probed at run time.
>
> Can you offer more details about your command packet?  Is it a varient
> of the 'm' command, or a new command?  What exactly do you mean by
> different memory scope?  Is there a cooresponding 'M' command to write
> memory?
>
> Josef> If it will turn out to be very useful, I will suggest it in
> Josef> this forum.
>
> In my remote II protocol spec (which regulars on the list know that
> I've been working on-and-off for about a year, but has never been
> ready enough to publish :-( ), the read and write memory commands
> take a memory space argument.  I was thinking about it being used
> (on a target specific basis) for things like the x86 i/o ports or
> PCI config space, etc.  I haven't thought about how such things
> would get through GDB to the CLI, but I thought it was important
> enough that the protocol support such things.
>
>         --jtc
>
> --
> J.T. Conklin
> RedBack Networks
>

Hi

I thought about 'nAAAA,LLLL' and 'NAAAA,LLLL:XXXX' commands as an
alternative for 'm' and 'M' commands. In my case (EMC SYMMETRIX) it could be
useful for indicating the target to get those addresses from a different
memory space. Your idea of having a memory space argument is more general
and flexible; I will be very happy to use it.

(May I have a copy of your remote II protocol spec? Even half-baked, it
would be of great help.)

About the "qver" (show-version) command, I need it for the
set-tracepoint-with-a-byte-code command. I am adding some byte-code-items
(like trace/ref-from-other-memory-space and stop-tracing-if) to my target
and I want gdb to determine the target abilities before it creates this
code.

 Regards -  Josef Ezra




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