From: Jim Blandy <jimb@redhat.com>
To: rda@sources.redhat.com
Subject: PATCH: fix some typos in rda/HOWTO
Date: Tue, 14 Sep 2004 18:57:00 -0000 [thread overview]
Message-ID: <vt2brg865mp.fsf@zenia.home> (raw)
Committed as obvious.
2004-09-14 Jim Blandy <jimb@theseus.home>
* HOWTO: Fix typos.
Index: rda/HOWTO
===================================================================
RCS file: /cvs/cvsfiles/devo/rda/HOWTO,v
retrieving revision 1.5
diff -c -p -r1.5 HOWTO
*** rda/HOWTO 21 Aug 2002 22:43:13 -0000 1.5
--- rda/HOWTO 14 Sep 2004 18:51:38 -0000
*************** either reject the connection (returning
*** 119,125 ****
(returning a target object). That is where you come in.
You must provide a routine like (please see the precise API in the header file
! lib/gdbserv-client.h):
typedef struct gdbserv_target *(gdbserv_target_attach) (struct gdbserv *gdbserv, void *attatch_data);
--- 119,125 ----
(returning a target object). That is where you come in.
You must provide a routine like (please see the precise API in the header file
! include/gdbserv-client.h):
typedef struct gdbserv_target *(gdbserv_target_attach) (struct gdbserv *gdbserv, void *attatch_data);
*************** This will be called by the server to not
*** 127,133 ****
connection. You must return a GDBSERV_TARGET struct for the session or null
if your target has rejected the connection.
! The recommended way to create your gdbsert_target object is:
struct gdbserv_target *gdbtarget = malloc (sizeof (struct gdbserv_target));
memset (gdbtarget, 0, sizeof (*gdbtarget));
--- 127,133 ----
connection. You must return a GDBSERV_TARGET struct for the session or null
if your target has rejected the connection.
! The recommended way to create your gdbserv_target object is:
struct gdbserv_target *gdbtarget = malloc (sizeof (struct gdbserv_target));
memset (gdbtarget, 0, sizeof (*gdbtarget));
*************** new entries are added to this struct.
*** 140,158 ****
Handling target events:
! The fromtarget_* routines may be called by your target. Before you despair, let
! me tell you that they are only three: reset, break and exit. They indicate that
! some interesting condition happened in your target that requires debugger
! attention. Reset and exit are quite obvious and break is for everything else.
! These routines must *not* be called from within a gdbserv_target callback
! function, so it may be necessary for your target to set some flags to signal
! state change calls later.
If your target is a simulator, call those when the corresponding
! condition arises in your simulated target. If it is a board, it will probably
! be called from your ISRs. A special case occurs if your target is a device that
! has to be polled in order to detect state changes. If this is the case, you
! will call these routines from the polling code.
The main loop:
--- 140,160 ----
Handling target events:
! The fromtarget_* routines may be called by your target. Before you
! despair, let me tell you that they are only three: reset, break and
! exit. They indicate that some interesting condition happened in your
! target that requires debugger attention. Reset and exit are quite
! obvious and break is for everything else. These routines must *not*
! be called from within a gdbserv_target callback function, so it may be
! necessary for your target to set some flags to signal state change
! calls later.
If your target is a simulator, call those when the corresponding
! condition arises in your simulated target. If it is a board, it will
! probably be called from your ISRs. A special case occurs if your
! target is a device that has to be polled in order to detect state
! changes. If this is the case, you will call these routines from the
! polling code.
The main loop:
*************** At some point you must get things going
*** 163,172 ****
2) causing remote protocol commands to be read from the input port (socket).
You must (repeatedly) call a function called gdbloop_poll(). This
! will be in your main loop. If it is a server it will be in you main()
! function. If it is a simulator that also accepts input from other
! sources, it will have to be added to the existing main loop. If it is
! a board, it will probably be called from the timer ISR.
Before doing that you must initialize your socket interface. Look in
the main() routine of the sample program to see what to call. When
--- 165,174 ----
2) causing remote protocol commands to be read from the input port (socket).
You must (repeatedly) call a function called gdbloop_poll(). This
! will be in your main loop. If it is a server it will be in your
! main() function. If it is a simulator that also accepts input from
! other sources, it will have to be added to the existing main loop. If
! it is a board, it will probably be called from the timer ISR.
Before doing that you must initialize your socket interface. Look in
the main() routine of the sample program to see what to call. When
reply other threads:[~2004-09-14 18:57 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=vt2brg865mp.fsf@zenia.home \
--to=jimb@redhat.com \
--cc=rda@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).