From: Fernando Nasser <fnasser@cygnus.com>
To: Fabrice Gautier <Fabrice_Gautier@sdesigns.com>
Cc: gdb@sources.redhat.com,
"Ecos-List (E-mail)" <ecos-discuss@sourceware.cygnus.com>,
dmoseley@cygnus.com
Subject: Re: Ctrl-C interrupt problem.
Date: Wed, 15 Nov 2000 23:10:00 -0000 [thread overview]
Message-ID: <3A13884B.8409CEC8@cygnus.com> (raw)
In-Reply-To: <B1F6452C89AFD411AE0800A0CC734C23015020@EMAIL1>
Fabrice Gautier wrote:
>
> [eCos and RedBoot guys, I think this may concern you
> its about a ctrl-C problem which only happen when debugging via ethernet.
> full story in the gdb list archives ]
>
> I Got it!
> Well, i hope....
>
> And it make sens why it only happens with TCP...
>
> The problem is that when gdb send the continue packet to the target, it wait
> for the target to send the '+' Ack. During this time the SIGINT handler is
> not set.
>
> My guess is that RedBoot intedn to send it BUT (tata) the ethernet driver
> just wait to have a full packet before really sending! So this happen when a
> O packet is sent.
>
> So i guess the only thing needed in RedBoot is to add a "flush" somewhere.
> I'm not sure at what level, but i'll look at it tomorrow if nobody does it
> before.
>
Fabrice, if this is true (and it is a very plausible explanation), you have
caught a very nasty bug that was going to bother many people.
For instance, the GUI presently (with the new sources you got from cvs) is
kept active while the target is running, but not while waiting for an ACK!
--
Fernando Nasser
Red Hat Canada Ltd. E-Mail: fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario M4P 2C9
From eliz@delorie.com Thu Nov 16 01:51:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: fnasser@cygnus.com
Cc: lache@tu-harburg.de, insight@cygnus.com, gdb@sources.redhat.com
Subject: Re: Debugging with ANGEL
Date: Thu, 16 Nov 2000 01:51:00 -0000
Message-id: <200011160950.EAA04460@indy.delorie.com>
References: <Pine.HPX.4.21.0011151426430.8611-100000@erasmus.rz.tu-harburg.de> <00111514532502.01686@lab04> <3A12B912.3864E7BA@cygnus.com> <00111519092700.13870@lab04> <3A12EFC7.D4CB22@cygnus.com>
X-SW-Source: 2000-11/msg00183.html
Content-length: 796
> Date: Wed, 15 Nov 2000 15:19:19 -0500
> From: Fernando Nasser <fnasser@cygnus.com>
>
> > * An other stupid question: What time difference is between Hamburg
> > and Toronto (plus or minus?) And what difference between Toronto
> > and Silicon Valley?
> >
>
> Toronto is 3 hours ahead of Silicon Valley. And I keep asking our engineers
> in Germany what is the time difference for them and I keep forgetting!
> And there is all these changes to save daylight...
These issues should be easy to figure out by looking at the mail
headers of the person in question: you have there the local time and
the offset from GMT. (Assuming people send mail from where they live,
which might not be true, as you can see from the headers of *this*
message, due to the ORBS nuisance with this list.)
From msalter@redhat.com Thu Nov 16 05:24:00 2000
From: Mark Salter <msalter@redhat.com>
To: Fabrice_Gautier@sdesigns.com
Cc: gdb@sources.redhat.com, ecos-discuss@sourceware.cygnus.com
Subject: Re: Ctrl-C interrupt problem.
Date: Thu, 16 Nov 2000 05:24:00 -0000
Message-id: <200011161325.eAGDP8P09301@deneb.localdomain>
References: <B1F6452C89AFD411AE0800A0CC734C23015020@EMAIL1>
X-SW-Source: 2000-11/msg00184.html
Content-length: 1391
>>>>> Fabrice Gautier writes:
> [eCos and RedBoot guys, I think this may concern you
> its about a ctrl-C problem which only happen when debugging via ethernet.
> full story in the gdb list archives ]
> I Got it!
> Well, i hope....
> And it make sens why it only happens with TCP...
> The problem is that when gdb send the continue packet to the target, it wait
> for the target to send the '+' Ack. During this time the SIGINT handler is
> not set.
> My guess is that RedBoot intedn to send it BUT (tata) the ethernet driver
> just wait to have a full packet before really sending! So this happen when a
> O packet is sent.
> So i guess the only thing needed in RedBoot is to add a "flush" somewhere.
> I'm not sure at what level, but i'll look at it tomorrow if nobody does it
> before.
> Thanks
> --
> Fabrice Gautier
> fabrice_gautier@sdesigns.com
Yes, it appears that redboot only flushes the output stream when
it sees the end of a packet. This causes the problem you see.
Look at .../redboot/current/src/net/net_io.c:net_io_putc().
A quick workaround would be to also flush if a '+' is seen. This
has a downside as it may severely impact download speeds, but at
least it is functionally correct. YMMV.
This needs to be fixed with a flush of the output stream prior
to continuing or stepping the target. Its not clear to me right
now how this can be done.
--Mark
next parent reply other threads:[~2000-11-15 23:10 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <B1F6452C89AFD411AE0800A0CC734C23015020@EMAIL1>
2000-11-15 23:10 ` Fernando Nasser [this message]
[not found] ` <200011161325.eAGDP8P09301@deneb.localdomain>
2000-11-16 5:48 ` Fernando Nasser
2000-11-15 17:48 Fabrice Gautier
-- strict thread matches above, loose matches on Subject: below --
2000-11-10 16:13 Fabrice Gautier
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=3A13884B.8409CEC8@cygnus.com \
--to=fnasser@cygnus.com \
--cc=Fabrice_Gautier@sdesigns.com \
--cc=dmoseley@cygnus.com \
--cc=ecos-discuss@sourceware.cygnus.com \
--cc=gdb@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