From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Kettenis To: mellon@pobox.com Cc: obrien@FreeBSD.ORG, gdb@sourceware.cygnus.com Subject: Re: GDB on FreeBSD/Alpha Date: Tue, 30 May 2000 03:17:00 -0000 Message-id: <200005301017.e4UAH3p06032@delius.kettenis.local> References: <200005292310.e4TNAoY05799@delius.kettenis.local> <20000529192510.A72082@sasami.jurai.net> X-SW-Source: 2000-05/msg00160.html Date: Mon, 29 May 2000 19:25:10 -0400 From: Anatoly Vorobey Cc: obrien@FreeBSD.ORG, gdb@sourceware.cygnus.com Content-Type: text/plain; charset=us-ascii You, Mark Kettenis, were spotted writing this on Tue, May 30, 2000 at 01:09:45AM +0200: > > -g This generates stabs-in-ecoff debugging information (which is > embedded in an .mdebug section in ELF). GDB's support for > this particular format has suffered from some bit rot, but it > isn't too difficult fix. The code is also used on MIPS, so I > guess this would be appreciate by a some other people too. > Looking through the code, there are several places where > stabs-in-ecoff is commented on as being a (temporary) hack. Unless I'm mistaken, gcc doesn't know anything about ecoff -- it just outputs stabs. gas is the program which makes the decision to use stabs-in-ecoff. Please correct me if I'm wrong. Well, GCC knows some ecoff; it outputs .ent, .frame and .mask pseudo-ops. Basically enough to record the ecoff frame info, something that stabs doesn't support very well. But nothing beyond that AFAICT. It's indeed the job of the assembler to convert everthing into the right format. I'm not at all an expert on Alpha, hence the following question might be silly, but -- is it possible for gcc/gas on FreeBSD/Alpha to generate true stabs (i.e. .stab and .stabstr sections) instead of stabs-in-ecoff? What would be wrong with this? You'll lose the frame info, which is quite essential for debugging, and might also be used for exception handling. > A bigger problem is that GCC 2.95.2 doesn't output the right > stabs for function arguments (and perhaps for local variables > under some special circumstances). This makes debugging > really painful, since function arguments will most likely have > the wrong values in GDB. The GCC bug is fixed in the > development tree. I understand that David is going to give us gcc 2.96 on FreeBSD soon. Is the bug fixed there? Well, 2.96 is just the version number used in the current tree. There is no official release yet, and AFAIK the next release will be GCC 3.0. I guess the answer will be, yes it will be fixed. > In the long run I'd advice FreeBSD/Alpha to standardize in DWARF 2, > since it is used on more platforms. I would argue against this. Wouldn't it be better for FreeBSD/Alpha to stay with stabs, in particular to maintain uniformity with FreeBSD/i386? I admit I have a private interest in staying with stabs too -- I have my own pet project which is kernel debugger support for stabs in FreeBSD, in a working shape on i386 now. I'm not too thrilled about adding DWARF2 support there as well and bloating it out of bounds; till now I thought I'd only need to recover stabs from stabs-in-ecoff on Alpha. What I'm suggesting, is making DWARF 2 the default format on FreeBSD. You could still have stabs by passing -gstabs to GCC, and GDB would in principle still support it (although it might suffer from bit-rot if it isn't widely used anymore). What are the advantages of DWARF2 versus stabs? Dan already answered that :-). Mark >From fnasser@cygnus.com Tue May 30 06:47:00 2000 From: Fernando Nasser To: rearnsha@arm.com Cc: Nicolas.Thery@Symbian.com, gdb@sourceware.cygnus.com Subject: Re: ARM/linux gdb stops and gives no info Date: Tue, 30 May 2000 06:47:00 -0000 Message-id: <3933C65A.CB1626B1@cygnus.com> References: <200005300948.KAA21133@cam-mail2.cambridge.arm.com> X-SW-Source: 2000-05/msg00161.html Content-length: 3160 Richard Earnshaw wrote: > > > > > Richard Earnshaw wrote: > > > > > I can understand not being able to unpick the stack frame if I've jumped > > > to never-never land, but to not even be able to display the registers > > > makes the debugger useless. > > > > Have you tried "print $pc", "print $r1", ... to get the register contents? > > > > Thanks for the tip: yes, that works. However, I still think that "info > reg" should display the raw registers if there is no valid stack frame. > Peter Schauer added the test for NULL frames in there back in 1995. I believe it was causing core dumps, but I am not sure as the ChangeLog entry does not give the motive (we nowadays make sure it does, but that was not always true at the time): * infcmd.c (registers_info): Error out if selected_frame is NULL. I believe the default gdb routine (if the target does not define DO_REGISTERS_INFO) does not depend on selected_frame but I can't be sure about all targets. I quickly created the patch below. I have no time to test it these days. If you care applying it to your sources and trying I would appreciate. Otherwise it goes in my 25 pages long TODO list.. ;-) Regards, Fernando -- Fernando Nasser Red Hat - Toronto E-Mail: fnasser@cygnus.com 2323 Yonge Street, Suite #300 Tel: 416-482-2661 ext. 311 Toronto, Ontario M4P 2C9 Fax: 416-482-6299 Index: infcmd.c =================================================================== RCS file: /cvs/src/src/gdb/infcmd.c,v retrieving revision 1.1.1.17 diff -c -p -r1.1.1.17 infcmd.c *** infcmd.c 2000/02/03 04:14:31 1.1.1.17 --- infcmd.c 2000/05/30 13:42:23 *************** char *gdb_register_names[] = REGISTER_NA *** 1494,1501 **** is required, (eg, for MIPS or Pyramid 90x, which both have lots of regs), or there is an existing convention for showing all the registers, define the macro DO_REGISTERS_INFO(regnum, fp) ! to provide that format. */ #if !defined (DO_REGISTERS_INFO) #define DO_REGISTERS_INFO(regnum, fp) do_registers_info(regnum, fp) --- 1494,1504 ---- is required, (eg, for MIPS or Pyramid 90x, which both have lots of regs), or there is an existing convention for showing all the registers, define the macro DO_REGISTERS_INFO(regnum, fp) ! to provide that format. + This default routine must work even if there is no selected_frame (== NULL). + Please don't add any dependencies on that being defined. */ + #if !defined (DO_REGISTERS_INFO) #define DO_REGISTERS_INFO(regnum, fp) do_registers_info(regnum, fp) *************** registers_info (addr_exp, fpregs) *** 1617,1624 **** --- 1620,1633 ---- if (!target_has_registers) error ("The program has no registers now."); + + #if !defined (DO_REGISTERS_INFO) + /* The default do_registers_info() does not need the selected_frame + so we don't test for it not being NULL. Tagets that define + DO_REGISTERS_INFO may rely on that, so we make sure it is valid. */ if (selected_frame == NULL) error ("No selected frame."); + #endif if (!addr_exp) { >From fnasser@cygnus.com Tue May 30 07:00:00 2000 From: Fernando Nasser To: shebs@apple.com Cc: Michael Snyder , gdb@sourceware.cygnus.com Subject: Re: [RFD]: deprecate the "fg" command Date: Tue, 30 May 2000 07:00:00 -0000 Message-id: <3933C98C.43C402B6@cygnus.com> References: <8gn1pc$as9$1@cronkite.cygnus.com> <392F0D07.8116804F@apple.com> X-SW-Source: 2000-05/msg00162.html Content-length: 1064 Stan Shebs wrote: > > Michael Snyder wrote: > > > > Does anybody use the "fg" command (a synonym for continue)? > > It's been in there since 1991, but never documented. I'd like to > > deprecate it to reduce clutter and the hazard of dangerous typos. > > If you tried to say "f" (the frame command) and your finger hit > > two keys by accident, the result would be an unintentional continue, > > which is generally a bad thing. > > I'm agreeable. In fact, I think we discussed using "fg" and "bg" as > commands to control multiple processes for when we implemented > multiple-process-debugging, in which case having fg mean something > else already would be bad. > Me too. Can someone submit a patch for this using David Whedon's deprecate facility? It seems from the text above that someone has already volunteered... ;-) Thanks, Fernando -- Fernando Nasser Red Hat - Toronto E-Mail: fnasser@cygnus.com 2323 Yonge Street, Suite #300 Tel: 416-482-2661 ext. 311 Toronto, Ontario M4P 2C9 Fax: 416-482-6299 >From stewart@netwinder.org Tue May 30 07:40:00 2000 From: Rod Stewart To: libc-alpha@sourceware.cygnus.com, gcc@gcc.gnu.org, linux-arm@vger.rutgers.edu, binutils@sourceware.cygnus.com, gdb@sourceware.cygnus.com Subject: [Comments?] Nightly build of GNU tool chains. (fwd) Date: Tue, 30 May 2000 07:40:00 -0000 Message-id: X-SW-Source: 2000-05/msg00163.html Content-length: 2112 We, at Rebel.com, are now running nightly builds of some of the GNU tool chains from CVS. Currently we are building the following tool chains: GNU Binary Utilities (binutils) GNU C Library (glibc) GNU Compiler Collection (egcs/gcc) GNU Debugger (gdb) At present we are building RPMs and SRPMs, as well as running the testsuites for each project. To begin with we are targeting armv3l-unknown-linux-gnu, and armv4l-unknown-linux-gnu architectures for versioned glibc hosts. Although the source rpms should rebuild on most Linux systems. The files from each build are available from the web page for each project. These include the rpms and srpms, log files of the builds, along with the testsuite output and summaries. http://www.netwinder.org/build (main project page) http://www.netwinder.org/build/binutils.html http://www.netwinder.org/build/gcc.html http://www.netwinder.org/build/gdb.html http://www.netwinder.org/build/glibc.html ftp://ftp.netwinder.org/pub/build/autobuild/ (scripts used, poorly documented) http://www.netwinder.org/cvsweb/cvsweb.cgi/pub/autobuild/ (scripts in CVS, usually current :)) These pages are based off similar work done by CodeSourcery, http://www.codesourcery.com/gcc-snapshots.html for GCC targeting i386-pc-linux-gnu. Send any comment/suggestions to: build@netwinder.org. The web pages were written by Ralph Siemsen and Scott Bambrough. Blame me for the build scripts, Rod m. Stewart. Sponsored by Rebel.com, http:/www.rebel.com For those who care: Warranty The NetWinder.Org AutoBuild system is an automated process which runs on a daily basis. There is absolutely no quality control on these RPMs. Use these RPMs at your own risk. Rebel.com and NetWinder.Org provide absolutely no warranty, including the implied warranties of merchantability or fitness for a particular purpose, for any code generated by the AutoBuild system. Additionally Rebel.com and NetWinder.Org provide no support for these RPMs. All questions regarding these RPMs, or suggestions for their improvement should be directed to build@netwinder.org. Enjoy, -Rms