gdb m68k remote debugging - unwanted program stop after 24 lines console output

gdb m68k remote debugging - unwanted program stop after 24 lines console output

[hollerer]

hi,

i have a little question which i hope you can answer.

host: linux, m68k-gdb-aout 4.18
target: motorola 68332, m68k-stub.c
remote debugging via rs232

i have wrapped the output of the target into a 'O' message.
this works fine. but the host gdb stops the program after
24 lines of output with the message:
 ---Type <return> to continue, or q <return> to quit--- 

can i avoid this? it's ok that the output would get lost.
but the program should not be stopped.

thx for any answer
franz hollerer

-- 
Austria
Usually we don't have kangaroos.
From msalter@cygnus.com Tue Apr 18 01:55:00 2000
From: Mark Salter <msalter@cygnus.com>
To: hollerer@gmx.net
Cc: gdb@sourceware.cygnus.com
Subject: Re: gdb m68k remote debugging - unwanted program stop after 24 lines console output
Date: Tue, 18 Apr 2000 01:55:00 -0000
Message-id: <200004180855.BAA06942@rtl.cygnus.com>
References: <38FC1F40.FB4B7D45@gmx.net>
X-SW-Source: 2000-04/msg00083.html
Content-length: 462

>>>>> hollerer  writes:

> hi,
> i have a little question which i hope you can answer.

> i have wrapped the output of the target into a 'O' message.
> this works fine. but the host gdb stops the program after
> 24 lines of output with the message:
>  ---Type <return> to continue, or q <return> to quit--- 

> can i avoid this? it's ok that the output would get lost.
> but the program should not be stopped.

Try "set height 0" in your .gdbinit file.

--Mark

Re: gdb m68k remote debugging - unwanted program stop after 24 lines console output

[Andrew Cagney]

hollerer@gmx.net wrote:
> 
> hi,
> 
> i have a little question which i hope you can answer.
> 
> host: linux, m68k-gdb-aout 4.18
> target: motorola 68332, m68k-stub.c
> remote debugging via rs232
> 
> i have wrapped the output of the target into a 'O' message.
> this works fine. but the host gdb stops the program after
> 24 lines of output with the message:
>  ---Type <return> to continue, or q <return> to quit---
> 
> can i avoid this? it's ok that the output would get lost.
> but the program should not be stopped.
> 
> thx for any answer
> franz hollerer

FYI,  this bug is fixed in the current sources.  I'd suggest downloading
a current snap and trying that.

	Andrew
From ezannoni@cygnus.com Tue Apr 18 07:59:00 2000
From: Elena Zannoni <ezannoni@cygnus.com>
To: gdb@sourceware.cygnus.com
Subject: xcoff anybody?
Date: Tue, 18 Apr 2000 07:59:00 -0000
Message-id: <14588.30807.28666.116807@kwikemart.cygnus.com>
X-SW-Source: 2000-04/msg00085.html
Content-length: 2242

I am trying to fix the section offsets /add-symbol-file thing.
I am quite perplexed by xcoffread.c however.

xcoffread.c is the only reader that uses its own function
(xcoff_symfile_offsets() ) to set up the section offsets in the
objfile, all the other readers (except for another one about which
I'll send e-mail later) use the same function:
default_symfile_offsets().

The function xcoff_symfile_offsets() sets all the offsets to 0
assuming that a later call to objfile_relocate will do the right
thing.
Here is the relevant code from xcoffread.c:

  /* syms_from_objfile kindly subtracts from addr the bfd_section_vma
     of the .text section.  This strikes me as wrong--whether the
     offset to be applied to symbol reading is relative to the start
     address of the section depends on the symbol format.  In any
     event, this whole "addr" concept is pretty broken (it doesn't
     handle any section but .text sensibly), so just ignore the addr
     parameter and use 0.  rs6000-nat.c will set the correct section
     offsets via objfile_relocate.  */
  for (i = 0; i < objfile->num_sections; ++i)
    ANOFFSET (objfile->section_offsets, i) = 0;

vmap_symtab() is the function that calls objfile_relocate. 

One of the arguments to xcoff_symfile_offsets() is 'addrs' which
contains the values supplied by the user to the add-symbol-file
command. This argumetns is ignored by xcoff_symfile_offsets(), and it
gets lost forever, it is not propagated to some other function for
later use. The values used by objfile_relocate are different ones,
probably derived from the objfile itself.

So it seems to me that there is no way to have the user provide
addresses for the various sections vis add-symbol-file in the
xcoff. Is this really the case?

Any suggestion/preference as how to proceed here? Should we just leave
xcoff alone for the moment? 


Another thing:
while grepping for vmap_symtab, I noticed the following:

rs6000-nat.c:68:vmap_symtab PARAMS ((struct vmap *));
rs6000-nat.c:335:vmap_symtab (vp)
rs6000-nat.c:460:      vmap_symtab (vp);
rs6000-nat.c:555:	  vmap_symtab (vp);
rs6000-nat.c:782:      vmap_symtab (vp);
xcoffsolib.c:119:	  vmap_symtab (vp, 0, 0); <<<<<< Wrong # of parameters.

OK to fix this?



Elena
From ezannoni@cygnus.com Tue Apr 18 08:07:00 2000
From: Elena Zannoni <ezannoni@cygnus.com>
To: gdb@sourceware.cygnus.com
Subject: gdb archeology
Date: Tue, 18 Apr 2000 08:07:00 -0000
Message-id: <14588.31296.558318.750143@kwikemart.cygnus.com>
X-SW-Source: 2000-04/msg00086.html
Content-length: 587

Are the dstread.c and dst.h files still in use by anybody out there?

from dstread.c
/* Read apollo DST symbol tables and convert to internal format, for GDB.
   Contributed by Troy Rollo, University of NSW (troy@cbme.unsw.edu.au).
   Copyright 1993 Free Software Foundation, Inc.

from dst.h
/* <apollo/dst.h> */
/* Apollo object module DST (debug symbol table) description */

from config/m68k/apollo*
# Host: Apollo, System V mode (?)
# Target: Apollo m68k in BSD mode
# Host: Apollo m68k, BSD mode.

Seem quite unmaintained and unused. No real changes in the last 2-3 years.

Elena