Re: GDB & FreeBSD

[Mark Kettenis <kettenis@wins.uva.nl>]

   From: "Daniel Berlin" <dan@cgsoftware.com>
   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 <Will_Lentz@Trimble.COM>
To: GDB <gdb@sourceware.cygnus.com>
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 <guy@netapp.com>
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 <guy@netapp.com>
To: Richard Kenner <kenner@vlsi1.ultra.nyu.edu>
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 <ac131313@cygnus.com>
To: Mark Kettenis <kettenis@wins.uva.nl>
Cc: gdb@sourceware.cygnus.com, "David O'Brien" <obrien@FreeBSD.org>
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 <ac131313@cygnus.com>
To: GDB Discussion <gdb@sourceware.cygnus.com>, "Insight (GDB GUI)" <insight@sourceware.cygnus.com>
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" <benoit.millot@cstelecom.com>
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