* Re: Ctrl-C interrupt problem.
[not found] ` <200011161325.eAGDP8P09301@deneb.localdomain>
@ 2000-11-16 5:48 ` Fernando Nasser
0 siblings, 0 replies; 4+ messages in thread
From: Fernando Nasser @ 2000-11-16 5:48 UTC (permalink / raw)
To: Mark Salter; +Cc: Fabrice_Gautier, gdb, ecos-discuss
Nice catch Fabrice.
Congratulations on your persistence.
Fernando
Mark Salter wrote:
>
> >>>>> 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
--
Fernando Nasser
Red Hat Canada Ltd. E-Mail: fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario M4P 2C9
From fnasser@cygnus.com Thu Nov 16 06:37:00 2000
From: Fernando Nasser <fnasser@cygnus.com>
To: gdb@sources.redhat.com
Subject: RFC: UI_OUT activation time
Date: Thu, 16 Nov 2000 06:37:00 -0000
Message-id: <3A13F122.A51AAF42@cygnus.com>
X-SW-Source: 2000-11/msg00186.html
Content-length: 1300
I am aware of several projects on the net that rely on the output
produced through the new ui_out output functions.
The separation between the CLI and libgdb also relies on that.
Currently, the old version of the code (using the ?printf_* family of
functions) is still there, on a "ifdef", but it is still the default.
One has to explicitly build with UI_OUT defined to use the new code.
The people who are working on the projects above (that includes me) are
concerned that the default has not yet been changed. This is probably
also delaying the availability of script languages in GDB.
Having both codes make the sources hard to read because of the ifdefs.
Furthermore, we cannot write code that assumes that ui_out is present
because GDB can still be configured without it. I have recently received
a patch which would change only the old code (as it is the active one)
without changing the new ui_out based version. And the ui_out code is
not been tested at large.
I propose (and I will submit a patch) to make the ui_out code the default
effective immediately, and the complete elimination of the old style code
from the sources before 5.1.
--
Fernando Nasser
Red Hat Canada Ltd. E-Mail: fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario M4P 2C9
From ac131313@cygnus.com Thu Nov 16 07:10:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Fernando Nasser <fnasser@cygnus.com>
Cc: gdb@sources.redhat.com
Subject: Re: RFC: UI_OUT activation time
Date: Thu, 16 Nov 2000 07:10:00 -0000
Message-id: <3A13F70D.11DB6D6B@cygnus.com>
References: <3A13F122.A51AAF42@cygnus.com>
X-SW-Source: 2000-11/msg00187.html
Content-length: 414
Fernando Nasser wrote:
> I propose (and I will submit a patch) to make the ui_out code the default
> effective immediately, and the complete elimination of the old style code
> from the sources before 5.1.
Switching over is part of 5.1. Eliminating the code would can after 5.1
goes out. This is significant change so I think having a fallback
position all through the 5.1 release cycle is important.
Andrew
From fnasser@cygnus.com Thu Nov 16 07:27:00 2000
From: Fernando Nasser <fnasser@cygnus.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: gdb@sources.redhat.com
Subject: Re: RFC: UI_OUT activation time
Date: Thu, 16 Nov 2000 07:27:00 -0000
Message-id: <3A13FCB3.9973A175@cygnus.com>
References: <3A13F122.A51AAF42@cygnus.com> <3A13F70D.11DB6D6B@cygnus.com>
X-SW-Source: 2000-11/msg00188.html
Content-length: 827
Andrew Cagney wrote:
>
> Fernando Nasser wrote:
>
> > I propose (and I will submit a patch) to make the ui_out code the default
> > effective immediately, and the complete elimination of the old style code
> > from the sources before 5.1.
>
> Switching over is part of 5.1. Eliminating the code would can after 5.1
> goes out. This is significant change so I think having a fallback
> position all through the 5.1 release cycle is important.
>
If switching over is part of 5.1, we should start to test the code
on a wider basis asap. Only the people that are working on scripts/GUIs
is not enough, we need everybody to use it for a while.
What about starting right now?
--
Fernando Nasser
Red Hat Canada Ltd. E-Mail: fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario M4P 2C9
From jingham@apple.com Thu Nov 16 09:55:00 2000
From: Jim Ingham <jingham@apple.com>
To: Fernando Nasser <fnasser@cygnus.com>
Cc: gdb@sources.redhat.com
Subject: Re: RFC: UI_OUT activation time
Date: Thu, 16 Nov 2000 09:55:00 -0000
Message-id: <200011161755.JAA05828@scv1.apple.com>
References: <3A13F122.A51AAF42@cygnus.com>
X-SW-Source: 2000-11/msg00189.html
Content-length: 2173
Fernando,
As one of the groups using the UI_OUT feature, I naturally think this is a great idea! But even without the self interest, I think that this is a good idea. The UI_OUT printers are much better than relying on the printf_* routines, since the UI_OUT mode preserves the knowledge of the significance of each bit in the output, whereas the printf_* routines force anyone who wants to use gdb output to reparse the results - basically throwing away information, then trying to reconstruct it later on.
It is silly to support two output printing methods, gdb is complicated enough already, we don't need to add complexity...
Jim
On Thursday, November 16, 2000, at 06:37 AM, Fernando Nasser wrote:
> I am aware of several projects on the net that rely on the output
> produced through the new ui_out output functions.
> The separation between the CLI and libgdb also relies on that.
>
> Currently, the old version of the code (using the ?printf_* family of
> functions) is still there, on a "ifdef", but it is still the default.
> One has to explicitly build with UI_OUT defined to use the new code.
>
> The people who are working on the projects above (that includes me) are
> concerned that the default has not yet been changed. This is probably
> also delaying the availability of script languages in GDB.
>
> Having both codes make the sources hard to read because of the ifdefs.
> Furthermore, we cannot write code that assumes that ui_out is present
> because GDB can still be configured without it. I have recently received
> a patch which would change only the old code (as it is the active one)
> without changing the new ui_out based version. And the ui_out code is
> not been tested at large.
>
> I propose (and I will submit a patch) to make the ui_out code the default
> effective immediately, and the complete elimination of the old style code
> from the sources before 5.1.
>
>
> --
> Fernando Nasser
> Red Hat Canada Ltd. E-Mail: fnasser@redhat.com
> 2323 Yonge Street, Suite #300
> Toronto, Ontario M4P 2C9
--
Jim Ingham jingham@apple.com
Developer Tools - gdb
Apple Computer
From jtc@redback.com Thu Nov 16 11:05:00 2000
From: jtc@redback.com (J.T. Conklin)
To: Eli Zaretskii <eliz@is.elta.co.il>
Cc: gdb@sourceware.cygnus.com
Subject: Re: memory region documentation
Date: Thu, 16 Nov 2000 11:05:00 -0000
Message-id: <5mpujvhh52.fsf@jtc.redback.com>
References: <5mg0ku2r9l.fsf@jtc.redback.com> <200011151126.GAA03721@indy.delorie.com>
X-SW-Source: 2000-11/msg00190.html
Content-length: 1527
>>>>> "Eli" == Eli Zaretskii <eliz@delorie.com> writes:
>> I spent some time writing this.
Eli> Thanks!
No problem.
However, this exercise has reminded me why I'm a programmer and not a
tech writer.
>> @node Memory Region Attributes
>> @chapter Memory Region Attributes
Eli> It is usually a good idea to have a @cindex entry identical to
Eli> the chapter/section names; in this case, "@cindex memory region
Eli> attributes" (note the all-lower case: it's intentional).
Done.
>> Memory region attributes allow you to describe special handling required
>> by regions of your target's memory. @value{GDBN} uses attributes to
Eli> When introducing a new term, it is usually best to have it in the
Eli> @dfn{} markup, when you first use the term:
Done.
>> @subsection Memory Access Mode
>> [...]
>> @subsection Memory Access Size
>> [...]
>> @subsection Data Cache
Eli> Here, too, I'd suggest @cindex entries.
This seems a bit odd to me. These are pretty generic concepts. If I
was browsing the index I'm not sure I'd expect that they'd be related
to memory regions. On the other hand, if I wanted to set the memory
access width, it would take me to the right page.
Let me know what you think, I'll do whatever you feel is correct.
Can you tell me where you'd like me to put this chapter? I assume
it's a chapter, since it doesn't seem to be a good fit into any of
the existing chapters --- especially if we start adding more varied
attributes.
Many thanks,
--jtc
--
J.T. Conklin
RedBack Networks
From eliz@delorie.com Thu Nov 16 12:01:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: jtc@redback.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: memory region documentation
Date: Thu, 16 Nov 2000 12:01:00 -0000
Message-id: <200011162001.PAA04807@indy.delorie.com>
References: <5mg0ku2r9l.fsf@jtc.redback.com> <200011151126.GAA03721@indy.delorie.com> <5mpujvhh52.fsf@jtc.redback.com>
X-SW-Source: 2000-11/msg00191.html
Content-length: 2373
> From: jtc@redback.com (J.T. Conklin)
> Date: 16 Nov 2000 11:05:29 -0800
>
> However, this exercise has reminded me why I'm a programmer and not a
> tech writer.
Actually, what you wrote was very good; the comments I had were pretty
much minor.
> >> @subsection Memory Access Mode
> >> [...]
> >> @subsection Memory Access Size
> >> [...]
> >> @subsection Data Cache
>
> Eli> Here, too, I'd suggest @cindex entries.
>
> This seems a bit odd to me. These are pretty generic concepts. If I
> was browsing the index I'm not sure I'd expect that they'd be related
> to memory regions.
Indices are for quickly finding something that you know or suspect
to be somewhere in the manual. That is, you don't look in the index
to find what's in the book---that's what the TOC or the top-level menu
is for---but when you use the manual as a reference.
When that happens, it is perfectly okay to have an index entry which,
under other circumstances, would sound as a generic concept, provided
that the index entry points to the place where those concepts are
discussed in depth in the manual.
> On the other hand, if I wanted to set the memory access width, it
> would take me to the right page.
That is exactly the purpose of an index. Imagine someone looking for
this specific piece of information, and ask yourself whether it would
be reasonable for that person to try to type "memory access mode".
I usually find the info-search command (bound to the `i' key) to be
the most efficient means of finding specific information in a manual.
When you use index-search, the situation when someone browses the
index is not the most important one.
> Can you tell me where you'd like me to put this chapter? I assume
> it's a chapter, since it doesn't seem to be a good fit into any of
> the existing chapters --- especially if we start adding more varied
> attributes.
It looks like making this a chapter is the right thing.
As to its place, it is not very important. You need to add an entry
to the top-level menu (in the @top node) that leads to this new node
you've written, and you need to insert the text somewhere in the
file. It is customary to put the node between the same nodes as the
menu entry in the top-level menu (but IIRC this is not required,
strictly speaking).
It looks like between "Native Debugging" and "Support Libraries" would
be a good place.
From kevinb@cygnus.com Thu Nov 16 12:02:00 2000
From: Kevin Buettner <kevinb@cygnus.com>
To: gdb@sources.redhat.com
Subject: Re: RFC: UI_OUT activation time
Date: Thu, 16 Nov 2000 12:02:00 -0000
Message-id: <1001116200209.ZM22877@ocotillo.lan>
References: <3A13F122.A51AAF42@cygnus.com> <fnasser@cygnus.com>
X-SW-Source: 2000-11/msg00192.html
Content-length: 887
On Nov 16, 2:37pm, Fernando Nasser wrote:
> Currently, the old version of the code (using the ?printf_* family of
> functions) is still there, on a "ifdef", but it is still the default.
> One has to explicitly build with UI_OUT defined to use the new code.
Yes, these ifdefs are evil. They make the code hard to maintain and
double the amount of testing required in order to be sure that a
change is correct. (This is one of the reasons that I haven't
finished making the suggested/required changes to the
TARGET_ADJUST_BREAKPOINT_ADDRESS patch that I submitted a while back.)
[...]
> I propose (and I will submit a patch) to make the ui_out code the default
> effective immediately, and the complete elimination of the old style code
> from the sources before 5.1.
I won't comment on your proposed schedule, but I think the quicker we
can remove the old code, the better.
Kevin
From Fabrice_Gautier@sdesigns.com Thu Nov 16 12:17:00 2000
From: Fabrice Gautier <Fabrice_Gautier@sdesigns.com>
To: 'Mark Salter' <msalter@redhat.com>
Cc: gdb@sources.redhat.com, ecos-discuss@sourceware.cygnus.com
Subject: RE: [ECOS] Re: Ctrl-C interrupt problem.
Date: Thu, 16 Nov 2000 12:17:00 -0000
Message-id: <B1F6452C89AFD411AE0800A0CC734C23015025@EMAIL1>
X-SW-Source: 2000-11/msg00193.html
Content-length: 1124
> -----Original Message-----
> From: Mark Salter [ mailto:msalter@redhat.com ]
> Subject: [ECOS] Re: Ctrl-C interrupt problem.
>
> 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.
You're right, this is slow as hell....
> 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.
I think the logical way should be to remove the ACK thing from the GDB
protocol when the transport protocol is reliable and already have an ACK
thing as TCP.
However that would not be a minor change.
Another way would be to add a flush function in the interface functions. As
a new function entry like read or write, or as an command entry for the ctrl
function.
--
Fabrice Gautier
fabrice_gautier@sdesigns.com
^ permalink raw reply [flat|nested] 4+ messages in thread