From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Peter.Schauer" To: kettenis@wins.uva.nl (Mark Kettenis) Cc: gdb@sourceware.cygnus.com Subject: Re: Regressions problem (200 failures) Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200003021322.OAA14220@reisser.regent.e-technik.tu-muenchen.de> References: <200003021246.e22CkWL00549@delius.kettenis.local> X-SW-Source: 2000-q1/msg00499.html > 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 To: Michael Meissner Cc: Elena Zannoni , 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 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 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 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 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 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: 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 To: Tom Lane Cc: Daniel Berlin , 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 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