public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: Gary Thomas <gthomas@redhat.com>
To: Fabrice Gautier <Fabrice_Gautier@sdesigns.com>
Cc: "Ecos-List (E-mail)" <ecos-discuss@sourceware.cygnus.com>
Subject: RE: [ECOS] diag_printf to debug Ctrl-C behaviour.
Date: Sat, 04 Nov 2000 05:23:00 -0000	[thread overview]
Message-ID: <XFMail.20001104065422.gthomas@redhat.com> (raw)
In-Reply-To: <5AF611D83988D4118ACF00E0B1040054055807@mr-intranet.sdesigns.net>

On 04-Nov-2000 Fabrice Gautier wrote:
> Hi,
> 
> Where is it safe to place diag_printf, to debug ctrl-C handling?
> 
> I believe it is safe to put diag_printf in redboot but i've encountered some
> strange behaviour when using diag_printf in the code which is part of the
> program,like in ctrlc_isr for example.
> 

I would definitely avoid any calls to diag_printf() in the ^C path
in your application.  This could get very messy and also not be terribly
productive.

Adding printf() calls within RedBoot should be pretty safe, however.

> My guess is this has something to do with
> CYGACC_CALL_IF_CONSOLE_INTERRUPT_FLAG()

More than likely.  They key with this flag is that it gets set when
the target (application) has detected that a ^C has occurred on the
console.  This causes the debugger (GDB via RedBoot) to insert a
breakpoint in such a way that the application will stop at the next
reasonable opportunity.

This flag is tested, primarily, at the exit to the console print
code which runs the "GDB mangler" (the piece of code that actually
knows how to talk GDB protocol).  This is why using "diag_printf()"
in your application to debug the use of the flag would be so tricky
and/or dangerous.

      reply	other threads:[~2000-11-04  5:23 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-11-04  1:09 Fabrice Gautier
2000-11-04  5:23 ` Gary Thomas [this message]

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=XFMail.20001104065422.gthomas@redhat.com \
    --to=gthomas@redhat.com \
    --cc=Fabrice_Gautier@sdesigns.com \
    --cc=ecos-discuss@sourceware.cygnus.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).