From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Kettenis To: dan@cgsoftware.com Cc: gdb@sourceware.cygnus.com Subject: Re: GDB & FreeBSD Date: Mon, 22 May 2000 10:35:00 -0000 Message-id: <200005221735.TAA25065@landau.wins.uva.nl> References: X-SW-Source: 2000-05/msg00101.html From: "Daniel Berlin" Date: Mon, 22 May 2000 13:17:16 -0400 IMHO, yes. BTW, all you needed to do was take the patches from the FreeBSD cvs tree, and make a few small changes, and you'd be golden. I lost them when my HD crashed a few weeks ago, unfortunately. Also realize FreeBSD 4.0 is ELF, while 3.4 is a.out. 3.4 is defenitely ELF too (although support for a.out is still included). I based my work on the NetBSD port since I understand the copyright status of the stuff in the FreeBSD tree isn't clear. I also added support for ELF core dumps, which I couldn't find in the FreeBSD CVS tree (at least 3.4 didn't support it). I'll check things in if I don't hear any objections in the next week. Mark >From Will_Lentz@Trimble.COM Mon May 22 18:06:00 2000 From: Will Lentz To: GDB Subject: Introspect Date: Mon, 22 May 2000 18:06:00 -0000 Message-id: <8B0BE50D6F9AD01185A300A0C92BF455085E66AC@US01XCH01.Trimble.COM> X-SW-Source: 2000-05/msg00102.html Content-length: 252 Hi, I recently discovered the "The Heisenberg Debugging Technology/ Introspect" link on the GDB page. What targets is the remote trace feature available on? Is this a free part of the GDB distribution, or is it available for purchase? Thanks, Will >From guy@netapp.com Mon May 22 18:19:00 2000 From: Guy Harris To: gcc-patches@gcc.gnu.org, gdb@sourceware.cygnus.com Subject: GCC on Alpha/Digital UNIX putting ".stabn" in the middle of functionprologue Date: Mon, 22 May 2000 18:19:00 -0000 Message-id: <200005230119.SAA05383@tooting> X-SW-Source: 2000-05/msg00103.html Content-length: 4452 This problem was originally reported to "gdb-bug@gnu.org" and "egcs-bugs@cygnus.com" in http://gcc.gnu.org/ml/gcc-bugs/1999-04/msg00898.html which says that, on Alpha/Digital UNIX, the "next" command stepped into, rather than over, a function call. A similar problem is discussed in: http://sourceware.cygnus.com/ml/bug-gdb/2000-03/msg00060.html http://sourceware.cygnus.com/ml/bug-gdb/2000-04/msg00012.html http://sourceware.cygnus.com/ml/bug-gdb/2000-04/msg00038.html with GCC 2.95.2 on Digital UNIX 4.0D and 4.0E, with various versions of GDB. I see the same problem here, with GCC 2.95.1; it appears to be due to GCC putting a ".stabn" in the middle of the function prologue - for example, the following: /* compile/link with debugging. */ /*when trying to step over the get_fname call, gdb will step into it instead.*/ void get_fname () { const char* dir = "foo"; } int main (int argc, char* argv[]) { get_fname (); } compiles to: ... .align 5 .globl get_fname .ent get_fname get_fname: .frame $15,32,$26,0 .mask 0x4008000,-32 ldgp $29,0($27) $get_fname..ng: $LM1: #.stabn 68,0,5,$LM1 lda $30,-32($30) stq $26,0($30) stq $15,8($30) mov $30,$15 .prologue 1 $LM2: #.stabn 68,0,6,$LM2 $LBB2: lda $1,$LC0 stq $1,16($15) ... with the "#.stabn" after "$LM1". The assembler and/or linker apparently arrange to put a line number entry out for the start of the function, so there end up being two line number entries, one for the beginning of the function, and one for the code after the "ldgp". This causes the GDB function "in_prologue()" to think that the "lda" at "$LM1" is not part of the prologue, causing "next" to fail if the call goes to "$get_fname..ng" (because the calling function and called function can share a GP value). (See the "gcc-bugs" message cited above for more details.) A change to GCC that eliminates the "#.stabn" in the middle of the prologue appears to fix this problem. However: 1) I don't know whether, on *all* platforms for which GCC can generate code for Alpha, the line number table entry for the beginning of the function will be generated - if not, perhaps a line number entry needs to be emitted by GCC (although I think I have heard claims of problems with "next" on Linux/Alpha; I may be misremembering, however, or those may have been unrelated problems); 2) I don't know whether my change, which adds a "NO_LINE_NUMBER_AFTER_PROLOGUE" #define that, if defined, keeps "final_start_function()" from calling "output_source_line()" to emit a line table entry, is the right fix; 3) I don't know whether this might be needed for other targets, e.g. MIPS. Here's the patch I made to GCC: Index: gcc/final.c =================================================================== RCS file: /cvs/gcc/egcs/gcc/final.c,v retrieving revision 1.131 diff -c -3 -p -r1.131 final.c *** final.c 2000/05/22 17:05:15 1.131 --- final.c 2000/05/23 00:59:08 *************** final_start_function (first, file, optim *** 1628,1635 **** --- 1628,1637 ---- #endif /* But only output line number for other debug info types if -g2 or better. */ + #ifndef NO_LINE_NUMBER_AFTER_PROLOGUE if (NOTE_LINE_NUMBER (first) != NOTE_INSN_DELETED) output_source_line (file, first); + #endif #ifdef LEAF_REG_REMAP if (current_function_uses_only_leaf_regs) Index: gcc/config/alpha/alpha.h =================================================================== RCS file: /cvs/gcc/egcs/gcc/config/alpha/alpha.h,v retrieving revision 1.97 diff -c -3 -p -r1.97 alpha.h *** alpha.h 2000/03/31 04:48:39 1.97 --- alpha.h 2000/05/23 00:59:09 *************** struct machine_function *** 1228,1233 **** --- 1228,1242 ---- #define FUNCTION_END_PROLOGUE(FILE) output_end_prologue (FILE) + /* Don't put out a line number entry for the prologue of a function; + one appears to be generated automatically, at least on Digital + UNIX, and if we put one out in "output_source_line()" when called + from "final_start_function()", it gets put out after the + GP-loading portion of the prologue but before the rest of the + prologue, which confuses GDB and often causes the "next" + command to step into, rather than over, function calls. */ + #define NO_LINE_NUMBER_AFTER_PROLOGUE 1 + /* Output any profiling code before the prologue. */ #define PROFILE_BEFORE_PROLOGUE 1 >From guy@netapp.com Mon May 22 18:49:00 2000 From: Guy Harris To: Richard Kenner Cc: gdb@sourceware.cygnus.com Subject: Re: GCC on Alpha/Digital UNIX putting ".stabn" in the middle of functionprologue Date: Mon, 22 May 2000 18:49:00 -0000 Message-id: <200005230149.SAA09486@tooting> References: <10005230141.AA26696@vlsi1.ultra.nyu.edu> X-SW-Source: 2000-05/msg00104.html Content-length: 290 (CCed to "gdb@sourceware.cygnus.com", as an FYI.) > I have a better fix for this, which I'll check in shortly. > > Basically, the problem is that the whole prologue isn't emitted as > RTL: the ldgp comes out as assembler text. Making it done via RTL > fixes the problem. Cool. Thanks. >From ac131313@cygnus.com Mon May 22 19:27:00 2000 From: Andrew Cagney To: Mark Kettenis Cc: gdb@sourceware.cygnus.com, "David O'Brien" Subject: Re: GDB & FreeBSD Date: Mon, 22 May 2000 19:27:00 -0000 Message-id: <3929EC4C.AD7E0620@cygnus.com> References: <200005211217.e4LCHPv00623@delius.kettenis.local> X-SW-Source: 2000-05/msg00105.html Content-length: 1039 Mark Kettenis wrote: > > Hi All, > > I spent some time on reviving GDB on FreeBSD. Not too difficult since > it turns out that I can re-use a lot of code from the NetBSD port > (thanks J.T. :-)). > > However, in doing so, I've probably killed support for older FreeBSD > systems (I suspect that the same happened with NetBSD). From looking > at the FreeBSD CVS tree, FreeBSD 2.2 (which was released in March > 1997) and up should be fine (I did my work on FreeBSD 3.4). On older > systems GDB will not compile. > > Is this acceptable? By ``killed'' support did you completly delete it or just do changes that require obvious tweeks? Having it working on 2.x, 3.x and 4.x with bit rot on 1.x is better than only working on 1.x/2.x. I've also CC'd David O'Brien who, I suspect, is responsible for getting the FreeBSD and GNU toolchanins unified. He may have access to a 1.x system and can access the damage. I'd check it in along with a TODO entry mentioning the need to access how hard it is to ``fix'' 1.x. Thanks! Andrew >From ac131313@cygnus.com Mon May 22 20:01:00 2000 From: Andrew Cagney To: GDB Discussion , "Insight (GDB GUI)" Subject: Snapshots back on trunk Date: Mon, 22 May 2000 20:01:00 -0000 Message-id: <3929F468.908931CB@cygnus.com> X-SW-Source: 2000-05/msg00106.html Content-length: 304 Just FYI, I'm switching the nightly snapshots back to the trunk. It will take affect tomorrow, the snapshot currently being created came from the gdb-5.0 branch (figuring out exactly what tomorrow means is left as an exercise to the reader :-) I'll roll out the occasional 5.0.0.nnn by hand. Andrew >From benoit.millot@cstelecom.com Mon May 22 23:46:00 2000 From: "Benoit MILLOT" To: gdb@sourceware.cygnus.com Subject: Gdb is IEEE 695 compatible? Date: Mon, 22 May 2000 23:46:00 -0000 Message-id: <392A2AEF.4018D7C0@cstelecom.com> X-SW-Source: 2000-05/msg00107.html Content-length: 1372 Hello, On sparc-sun-solaris2.6, I want to use gdb with a m68k target (remote target mode). MRI tools (microtech: mcc68k v4.4, asm68k v7.0, lnk68k v7.0) throught platine utilities(v4.30) are used to produce an object file in ieee 695. At the begginning GDB doesn't recognize this file because i configured it for m68k-monitor-none. As yoo say,I build gdb again as a m68k-monitor-ieee. So BFD and Gdb support IEEE. So when running gdb with a small soft with debug information: millot@palpatine : m68k-monitor-ieee-gdb GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "--host=sparc-sun-solaris2.6 --target=m68k-monitor-ieee". (gdb) file etoto.xray warning: little endian file does not match big endian target. Reading symbols from etoto.xray...I'm sorry, Dave, I can't do that. Symbol format `ieee' unknown. (gdb) The m68k Target is really big endian style. And according the specification of IEEE format, the file is little endian style. Do I make something wrong? (perhap my targe?) Any idea are greatly appreciated. Thanks