Re: Regressions problem (200 failures)

["Peter.Schauer" <Peter.Schauer@regent.e-technik.tu-muenchen.de>]

> The following might be relevant for this discussion:
> 
> The comment on symtab.c:find_function_start_sal() says:
> 
> /* Given a function symbol SYM, find the symtab and line for the start
>    of the function.
>    If the argument FUNFIRSTLINE is nonzero, we want the first line
>    of real code inside the function.  */
> 
> If you look at the implementation of find_function_start_sal() you'll
> see that it uses SKIP_PROLOGUE to skip over the function prologue if
> FUNFIRSTLINE is nonzero, and then chooses the next line after the
> prologue.  So GDB shouldn't have any problems with line notes for the
> prologue.

SKIP_PROLOGUE is very machine dependent and sometimes you can't get it right
(especially with optimization and instruction reordering). If GDB's
prologue skipping stops to early, then we are at the mercy of GCC to provide
us with the `correct' line note, and additional line notes in the prologue
will confuse GDB under these circumstances.

And if GCC puts a line note at the first instruction after the prologue, and
marks it with the line number of the opening brace, then GDB will
stop at the opening brace, which I would like to avoid at all cost, because
I find it confusing.

So there are actually two questions:
At which instruction should GCC put the first line note and which source line
number should be associated with the note.

-- 
Peter Schauer			pes@regent.e-technik.tu-muenchen.de
From ezannoni@cygnus.com Sat Apr 01 00:00:00 2000
From: Elena Zannoni <ezannoni@cygnus.com>
To: Michael Meissner <meissner@cygnus.com>
Cc: Elena Zannoni <ezannoni@cygnus.com>, gdb@sourceware.cygnus.com
Subject: Re: mdebug?
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <14563.55263.898978.669684@kwikemart.cygnus.com>
References: <14563.50531.341290.804769@kwikemart.cygnus.com> <20000330165810.27223@cse.cygnus.com>
X-SW-Source: 2000-q1/msg00844.html
Content-length: 1301

Michael Meissner writes:
 > On Thu, Mar 30, 2000 at 04:21:39PM -0500, Elena Zannoni wrote:
 > > 
 > > Does anybody know something about mdebug?
 > 
 > In the past, I knew something of the format.  Unfortunately, the only document
 > I ever saw on it (other than the DEC include files) is a hard copy of the DEC
 > Pmax assembler guide, that I may have somewhere.
 > 
 > > I am trying to figure out a problem in gdb which untilmately is due
 > > to some limitation of mdebug.
 > > Is there any documentation at all about how the debug symbols are built?
 > 
 > The program mips-tdump.c in the gcc release, in the distant past dumped the
 > debug tables for MIPS and later Alpha ecoff systems.  Whether it has suffered
 > bit rot in the 9+ years since I wrote it, I don't know.
 > 
 > -- 
 > Michael Meissner, Cygnus Solutions, a Red Hat company.
 > PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
 > Work:	  meissner@redhat.com		phone: +1 978-486-9304
 > Non-work: meissner@spectacle-pond.org	fax:   +1 978-692-4482


Thanks Mike.

I also found that this document at:
http://reality.sgi.com/davea/objectinfo.html

has a pointer to a mdebug.ps file containing some description of the mdebug
format. In this, there is mention of an SGI utility available on IRIX
called stdump. 

Elena
From kettenis@wins.uva.nl Sat Apr 01 00:00:00 2000
From: Mark Kettenis <kettenis@wins.uva.nl>
To: kevinb@cygnus.com
Cc: ac131313@cygnus.com, scottb@netwinder.org, gdb@sourceware.cygnus.com
Subject: Re: store_floating() rewrite (was Re: bug in arm_push_arguments())
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200002281929.UAA03907@landau.wins.uva.nl>
References: <38B6C4A1.7A1461C4@netwinder.org> <38BA642A.6F358273@cygnus.com> <1000228181141.ZM26089@ocotillo.lan>
X-SW-Source: 2000-q1/msg00442.html
Content-length: 1583

   Date: Mon, 28 Feb 2000 11:11:42 -0700
   From: Kevin Buettner <kevinb@cygnus.com>

   On Feb 28, 11:03pm, Andrew Cagney wrote:

   > Kevin Buttner wrote:
   > > It seems to me that you should be able to use store_floating() to do
   > > what you want.  It'll handle both the conversion and the byte swapping.
   > 
   > Yes, that looks correct. I'm just not 100% sure on it working - would
   > one of those if()'s before the TARGET_EXTRACT_FLOATING() get in the way?
				    ^^^^^^^^^^^^^^^^^^^^^^^

   Did you mean TARGET_STORE_FLOATING?

Andrew was probably looking at extract_floating() which suffers from
the same braindamage as you describe.  This needs to be fixed,
and I think your patch is basically right.  Apart from store_floating
and extract_floating, there are probably some other functions where
the same assumptions are made.

However, keep in mind that we must guard for loss of precision.  What
should store_floating do if DOUBLEST (which "lives" on the host) has
less precision than the target type in which it is being stored?  This
is also a problem with a somewhat wider scope.  There is no explicit
policy in GDB on which operations are allowed to lose precision, and
which operations are not supposed to lose precision.  I think that if
we're going to address the issues raised here, we must determine such
a policy, and document it.

Please also keep in mind that TARGET_STORE_FLOATING and
TARGET_EXTRACT_FLOATING really should be eliminated.  They are part of
a workaround for the problem that's being adressed now and are only
used on Linux/i386.

Mark
From ezannoni@cygnus.com Sat Apr 01 00:00:00 2000
From: Elena Zannoni <ezannoni@cygnus.com>
To: davea@dsl-quasar.corp.sgi.com (David B. Anderson)
Cc: gdb@sourceware.cygnus.com
Subject: Re: mdebug
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <14565.12523.449478.621361@kwikemart.cygnus.com>
References: <200003312258.OAA25181@dsl-quasar.corp.sgi.com>
X-SW-Source: 2000-q1/msg00848.html
Content-length: 1410

Thanks David, I did find your paper.

And yes, I have a specific question.  Does mdebug let the user specify
a procedure like 'main()' in a section other than .text? 

Thanks

Elena


David B. Anderson writes:
 > 
 > 
 > 
 > Elena Zannoni <ezannoni@cygnus.com> writes:
 > >Does anybody know something about mdebug?
 > 
 > Yes.
 > 
 > >I am trying to figure out a problem in gdb which untilmately is due
 > >to some limitation of mdebug.
 > >Is there any documentation at all about how the debug symbols are built?
 > 
 > http://reality.sgi.com/davea/objectinfo.html
 > Look early in the page for:
 > 
 >   one part of the old 32bit ABI for MIPS 
 >   is the mdebug debugging information. 
 >   A postscript file with the only currently 
 >   available description of this data is here (119Kbytes) 
 > 
 > It is is an old paper I wrote on mdebug.  
 > Not too well written, but... what else is there?
 > Perhaps it will help. Does not mention limits, though.
 > The limits are implicit in various structs. Perhaps
 >  'explicit' is a better word :-)
 > 
 > If you have any questions let me know.
 > (whether I'll know the answer is something else...)
 > 
 > I don't know too much about DEC or other *extensions*
 > to mdebug. Just sgi's.   But there are certainly some
 > important limitations in mdebug.  Like 64K procedures (at most).
 > SGI did some hack extensions, but ... never mind.
 > 
 > davea@sgi.com
From eliz@delorie.com Sat Apr 01 00:00:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: dan@cgsoftware.com
Cc: gdb@sourceware.cygnus.com, dj@delorie.com, ac131313@cygnus.com
Subject: Re: 000217: status of DJGPP support
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200002202209.RAA13439@indy.delorie.com>
References: <Pine.LNX.4.10.10002201158010.1564-100000@propylaea.anduin.com>
X-SW-Source: 2000-q1/msg00356.html
Content-length: 541

> I have this problem on BeOS.
> I can give you an fd_mask that will work.

Thanks, but it won't be necessary: I already crafted a definition that
works with DJGPP.

I'm not sure where's the appropriate place to put the typedef for
fd_mask.  Can you tell me where did you put yours?

> Unfortunately, i had to disable the event loop based interface because
> our select isn't good enough yet.

Out of curiosity: can you tell what functionality is missing from your
select?  I'd like to double-check that the DJGPP version will work.
Thanks.
From law@cygnus.com Sat Apr 01 00:00:00 2000
From: Jeffrey A Law <law@cygnus.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Daniel Berlin <dan@cgsoftware.com>, gdb-testers@sourceware.cygnus.com, gdb@sourceware.cygnus.com
Subject: Re: Preparing for the GDB 5.0 / GDB 2000 / GDB2k release 
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <4046.949979695@upchuck>
References: <27617.949979286@sss.pgh.pa.us>
X-SW-Source: 2000-q1/msg00153.html
Content-length: 770

 In message < 27617.949979286@sss.pgh.pa.us >you write:
  > Daniel Berlin <dan@cgsoftware.com> writes:
  > >> Debugging shared libraries works most of time with gdb 4.17.0.14.
  > >> If it doesn't work with 5.0, does that count for serious losses of
  > >> functionality?
  > 
  > > You mean for your particular architecture.
  > 
  > I don't know what architecture H.J. is using, but I can tell you that
  > shared lib debugging is completely nonfunctional on HPPA (HPUX 10.20).
  > Can't even get a backtrace when execution is stopped in a shlib...
  > kind of puts a crimp in the usefulness of gdb, at least for me.
Testcases please?  If it's busted, it's news to me.  This stuff was rock
solid when I stopped working on the PA port regularly a few years ago.

jeff