From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cagney 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 03:50:00 -0000 Message-id: <38FC3DB4.8841F518@cygnus.com> References: <38FC1F40.FB4B7D45@gmx.net> X-SW-Source: 2000-04/msg00084.html 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 to continue, or q 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 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 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 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