From mboxrd@z Thu Jan 1 00:00:00 1970 From: Fernando Nasser To: Mark Salter Cc: Fabrice_Gautier@sdesigns.com, gdb@sources.redhat.com, ecos-discuss@sourceware.cygnus.com Subject: Re: Ctrl-C interrupt problem. Date: Thu, 16 Nov 2000 05:48:00 -0000 Message-id: <3A13E574.5BF265BB@cygnus.com> References: <200011161325.eAGDP8P09301@deneb.localdomain> X-SW-Source: 2000-11/msg00185.html 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 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 To: Fernando Nasser 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 To: Andrew Cagney 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 To: Fernando Nasser 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 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 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 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 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> 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 To: 'Mark Salter' 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: 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