RE: GDB & FreeBSD

RE: GDB & FreeBSD

[Daniel Berlin]

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.

--Dan
>
> 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?
>
> Mark

Re: GDB & FreeBSD

[Mark Kettenis]

   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

Re: GDB & FreeBSD

[J.T. Conklin]

Mark> I spent some time on reviving GDB on FreeBSD.  Not too difficult
Mark> since it turns out that I can re-use a lot of code from the
Mark> NetBSD port (thanks J.T. :-)).

Your welcome.

Mark> However, in doing so, I've probably killed support for older
Mark> FreeBSD systems (I suspect that the same happened with NetBSD).

If so, it wasn't the intent.  

The earliest machines I have are running 1.3.  If it turns out I broke
an earlier release, I'll fix it.  But I'm not planning on installing
NetBSD 0.9 just to check...  I'd rather spend the time to get i386/ELF
support into the tree.

        --jtc

-- 
J.T. Conklin
RedBack Networks
From jtc@redback.com Tue May 23 12:53:00 2000
From: jtc@redback.com (J.T. Conklin)
To: <riazr@cat.co.za>
Cc: <gdb@sourceware.cygnus.com>
Subject: Re: Breakpoint on Memory Range?
Date: Tue, 23 May 2000 12:53:00 -0000
Message-id: <5mya5182nx.fsf@jtc.redback.com>
References: <000001bfc4d2$7424ac80$1923a8c0@cat.co.za>
X-SW-Source: 2000-05/msg00118.html
Content-length: 829

>>>>> "Riaz" == Riaz  <riazr@cat.co.za> writes:
Riaz> Does GDB 5.0 (i386 NetBSD) offer the ability to stop execution
Riaz> when there has been a "write" to a memory range?

GDB supports watchpoints, that can be used to see if a memory variable
is changed.  The watchpoint command takes an expression, not a memory
range, as its argument; although I suppose that you could construct a
expression that would fit your range.  Even if this works, it will be
slow.

Riaz> I specifically need to know whether my code is being overwritten.

I think this is unlikely, unless you are dynamically generating code
on the stack, in the heap or in the data segment.  The .text (code)
segment is mapped read only.  Any attempt to overwrite your code
should result in a segmentation violation.

        --jtc

-- 
J.T. Conklin
RedBack Networks
From ac131313@cygnus.com Tue May 23 18:58:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Larry Cohen <Larry.J.Cohen@saic.com>
Cc: help-gcc@gnu.org, gdb@sourceware.cygnus.com
Subject: Re: Request for status on fix for limitations with g77 -fdebug_kludge option
Date: Tue, 23 May 2000 18:58:00 -0000
Message-id: <392B36FA.67079BC8@cygnus.com>
References: <002d01bfc4b8$b0343020$1b2731cc@FWB.SAIC.Com>
X-SW-Source: 2000-05/msg00119.html
Content-length: 1036

Larry Cohen wrote:
> 
> To Whom It May Concern;
> 
>  I have recently downloaded and installed gcc-2.95.2 and gdb-5.0 packages
>  for the purposes of compiling and running FORTRAN-77 programs.  The gcc
>  package documentation states that gdb is currently incapable of printing
>  out the values of variables that are part of COMMON BLOCK storage and
>  that rudimentary COMMON BLOCK variable information could be retrieved
>  within gdb by invoking the -fdebug-kludge option during the g77 compile
>  process.  Also, the documentation states that this limitation in
>  printing out the explicit value of a COMMON BLOCK variable will be fixed
>  in some future release of gcc and gdb.  Would you please send me any
>  information about when these future gcc and gdb releases (that print out
>  the value of a COMMON BLOCK variable) will occur.

FYI,

At present there is no active Fortran GDB maintainer and effectivly zero
activity on GDB's support for fortran :-(
Definitly an oportunity in the making for anyone interested.

	Andrew
From guy@netapp.com Tue May 23 21:22:00 2000
From: Guy Harris <guy@netapp.com>
To: gdb@sourceware.cygnus.com
Subject: On Digital UNIX, "continue" doesn't continue correctly if a signal isdelivered
Date: Tue, 23 May 2000 21:22:00 -0000
Message-id: <200005240422.VAA19399@tooting>
X-SW-Source: 2000-05/msg00120.html
Content-length: 4264

On Digital UNIX/Alpha, we have a program that has an interval timer set
up to continuously deliver signals; with GDB 4.18, we find that if you
stop at a breakpoint, and then try to continue from that breakpoint, it
doesn't continue - instead, it stops again at the same breakpoint.

The same thing happens with the GDB that was in the CVS tree as of a
short while ago.

The problem appears to be that various tests in "wait_for_inferior()",
which test whether the current SP is for a frame closer to the top of
the stack than the frame for "step_sp" (or "step_sp - 16") fail, because
"step_sp" hasn't been set.  When continuing from the breakpoint (with
the PRSTEP flag set in the "pr_flags" field of the structure passed to
PIOCRUN, so that it executes only one instruction), it stops in
"__sigtramp", as a SIGALRM was delivered to the process in the interval
since the breakpoint trap; however, GDB doesn't realize that it's in the
signal trampoline, and doesn't properly continue, so that when it next
gets a breakpoint trap after returning from the signal, as it presumably
re-executes the breakpoint instruction, it doesn't realize that it
should drive on, and it just stops.

"step_sp" gets set by "step_1()", "step_once()", and
"until_next_command()", presumably because all those routines call
"proceed()" with "step" set; however, "step_sp" isn't set by
"continue_command()" or any routine between "continue_command()" and
"proceed()", presumably because "proceed()" isn't called with "step" set
in that code path.

However, "proceed()" will be single-stepping, because we're resuming
from a breakpoint, and we need to step over the instruction at which the
breakpoint was placed and then put the breakpoint back, as per:

  if (addr == (CORE_ADDR) -1)
    {
      /* If there is a breakpoint at the address we will resume at,
	 step one instruction before inserting breakpoints
	 so that we do not stop right away (and report a second
	 hit at this breakpoint).  */
 
      if (read_pc () == stop_pc && breakpoint_here_p (read_pc ()))
	oneproc = 1;

in "proceed()".

Making "proceed()" set "step_frame_address" and "step_sp" if "oneproc"
is set but "step" isn't set appears to fix the problem:

Index: gdb/infrun.c
===================================================================
RCS file: /cvs/src/src/gdb/infrun.c,v
retrieving revision 1.14
diff -c -r1.14 gdb/infrun.c
*** gdb/infrun.c	2000/05/22 09:02:23	1.14
--- gdb/infrun.c	2000/05/24 03:44:38
***************
*** 1040,1048 ****
  #endif /* HP_OS_BUG */
  
    if (oneproc)
!     /* We will get a trace trap after one instruction.
!        Continue it automatically and insert breakpoints then.  */
!     trap_expected = 1;
    else
      {
        int temp = insert_breakpoints ();
--- 1040,1058 ----
  #endif /* HP_OS_BUG */
  
    if (oneproc)
!     {
!       /* We will get a trace trap after one instruction.
! 	 Continue it automatically and insert breakpoints then.  */
!       trap_expected = 1;
! 
!       /* Oh, and if we weren't explicitly told to single-step, our
!          caller may not have updated "step_sp", so do it ourselves. */
!       if (!step)
! 	{
! 	  step_frame_address = FRAME_FP (get_current_frame ());
! 	  step_sp = read_sp ();
! 	}
!     }
    else
      {
        int temp = insert_breakpoints ();

Whether this is the right way to fix this is another matter.  (For
example, perhaps "proceed()" should always set "step_frame_address" and
"step_sp" if it will be passing a non-zero value as the first argument
to "resume()", and the routines in "gdb/infcmd.c" that set them should
leave it up to "proceed()" to do so.)

I've attached a small sample program which exhibits the problem; if run
with "clock" as an argument, it sets up a timer to repeatedly deliver
SIGALRM, and if you set a breakpoint on "procedure()", run the program,
and then type "continue", it will stop again in "procedure()" without
printing "Hello", indicating that it hasn't continued from the
breakpoint.

However, if run with "noclock" as an argument, so that it doesn't
repeatedly get SIGALRM, it *will* print "Hello" before stopping again at
"procedure()".

Applying the patch above makes "continue" behave correctly regardless of
whether the program was run with "clock" or "noclock".
From kettenis@wins.uva.nl Wed May 24 01:34:00 2000
From: Mark Kettenis <kettenis@wins.uva.nl>
To: ldm@ilog.fr, chrisd@reservoir.com, wim.delvaux@desc.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: bug in gdb-5.0 & shared libraries on Solaris 7
Date: Wed, 24 May 2000 01:34:00 -0000
Message-id: <200005240834.e4O8Y6c00547@delius.kettenis.local>
References: <00052401214900.31315@buro> <m3d7mch3zq.fsf@namur.ilog.fr>
X-SW-Source: 2000-05/msg00121.html
Content-length: 536

Wow, three bug reports for the same problem in one day!  We should
probably make fixing this a real priority :-).

Anyway, thanks for reporting.

The following patch will fix the problems with setting breakpoints in
dynamically loaded objects:

   http://sourceware.cygnus.com/ml/gdb-patches/2000-05/msg00230.html

This patch isn't checked in yet (ping Michael/JimB), but I hope this
will be in the next GDB release.

There should really be a test in the testsuite for this problem, since
it keeps coming up :-(.  Any volunteers?

Mark
From moene@knmi.nl Wed May 24 02:54:00 2000
From: Toon Moene <moene@knmi.nl>
To: gdb@sourceware.cygnus.com
Subject: Re: Request for status on fix for limitations with g77 -fdebug_kludge option
Date: Wed, 24 May 2000 02:54:00 -0000
Message-id: <392BA6A9.ACE682F@knmi.nl>
X-SW-Source: 2000-05/msg00122.html
Content-length: 969

Andrew Cagney wrote:

>Larry Cohen wrote:

>> The gcc
>>  package documentation states that gdb is currently incapable of printing
>>  out the values of variables that are part of COMMON BLOCK storage and
>>  that rudimentary COMMON BLOCK variable information could be retrieved
>>  within gdb by invoking the -fdebug-kludge option during the g77 compile
>>  process.

> At present there is no active Fortran GDB maintainer and effectivly 
> zero activity on GDB's support for fortran :-(

While this is true, to the best of my knowledge the issue with printing
COMMON BLOCK items in gdb has been solved (it was a limitation of the
way g77 wrote debug information).

The solution is in the CVS mainline of GCC.  Pick any recent snapshot of
GCC if you can't use CVS and see if using just -g solves your problem.

--
Toon Moene, KNMI, PO Box 201, 3730 AE De Bilt, The Netherlands.
Tel. +31302206443, Fax +31302210407,  e-mail moene@knmi.nl
URL: http://www.knmi.nl/hirlam
From kevinb@cygnus.com Wed May 24 09:55:00 2000
From: Kevin Buettner <kevinb@cygnus.com>
To: gdb@sourceware.cygnus.com
Cc: gdb-patches@sourceware.cygnus.com
Subject: PARAMS removal this weekend
Date: Wed, 24 May 2000 09:55:00 -0000
Message-id: <1000524165459.ZM30150@ocotillo.lan>
X-SW-Source: 2000-05/msg00123.html
Content-length: 1030

Earlier this week, I posted a patch for removing most occurrences of
PARAMS from the gdb sources.  See:

    http://sourceware.cygnus.com/ml/gdb-patches/2000-05/msg00330.html

I have seen no objections to this patch and Andrew has suggested that
I specify a date and time for when this patch goes in.

So at 5:00 pm MST of Saturday, May 27 (which is midnight GMT on Sunday),
I'll tag the repository, do the PARAMS removal on the gdb directory,
and tag it again.  I will use gdb-pre-params-removal-2000-05-28 and
gdb-post-params-removal-2000-05-28 for the tags.  (I'm not sure how
long it will take to do all of this, but I wouldn't be surprised if
it were a couple of hours.)

Rather than relying on the patch posted earlier this week, I'll be
using a script to do the actual PARAMS removal.  The script and some
additional commentary may be found at

    http://sourceware.cygnus.com/ml/gdb-patches/2000-05/msg00331.html

If you have any concerns about the PARAMS removal activity, please
let me know as soon as possible.

Kevin
From kettenis@wins.uva.nl Wed May 24 15:55:00 2000
From: Mark Kettenis <kettenis@wins.uva.nl>
To: obrien@FreeBSD.org
Cc: ac131313@cygnus.com, gdb@sourceware.cygnus.com
Subject: Re: GDB & FreeBSD
Date: Wed, 24 May 2000 15:55:00 -0000
Message-id: <200005242255.e4OMtdm00475@delius.kettenis.local>
References: <200005211217.e4LCHPv00623@delius.kettenis.local> <3929EC4C.AD7E0620@cygnus.com> <200005231142.e4NBgjU00165@delius.kettenis.local> <20000523091639.D22706@dragon.nuxi.com>
X-SW-Source: 2000-05/msg00124.html
Content-length: 1546

   Date: Tue, 23 May 2000 09:16:39 -0700
   From: "David O'Brien" <obrien@FreeBSD.org>

   On Tue, May 23, 2000 at 01:42:45PM +0200, Mark Kettenis wrote:
   > I be able to cook something up that should work on all i386 BSD's with

   The thust shouldn't be viewed as working on all i386 BSD's, but all
   4.4BSD derived systems.  FreeBSD/Alpha is very import to me also.

Most of the work I did is specifically related to i386-specific
things, so it doesn't help FreeBSD/Alphe very much :-(.

   >    I'd check it in along with a TODO entry mentioning the need to access
   >    how hard it is to ``fix'' 1.x.  

   I can offer a 1.x install CDROM, but I don't know of any one still
   running a FreeBSD 1.x box.

It's probably not worth it.  People still using FreeBSD 1.x, can use
older versions of GDB instead.

   > OK, I'll do that for the code that I have right now (which should work
   > on FreeBSD 2.2 and up) and then see if I can revive the support for
   > older FreeBSD's after that.

   My concern is for FreeBSD 3.0+ (ie. ELF).  If support for FreeBSD 2.x had
   to be dropped, it would not bother me.  I'd like to have the current
   systems supported; and those of the future (again ELF).

   If I can be of any help providing access to FreeBSD 4-STABLE (which will
   become 4.1 RELEASE) or 5-CURRENT systems, please let me know.

Well, testing on some other FreeBSD releases besides 3.4 wouldn't
hurt.  If no-one volunteers, setting me up with an account on such a
system would probably lead to some test-runs on it :-).

Mark
From ac131313@cygnus.com Wed May 24 19:15:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Kevin Buettner <kevinb@cygnus.com>
Cc: gdb@sourceware.cygnus.com, gdb-patches@sourceware.cygnus.com
Subject: Re: PARAMS removal this weekend
Date: Wed, 24 May 2000 19:15:00 -0000
Message-id: <392C8C8E.DE480348@cygnus.com>
References: <1000524165459.ZM30150@ocotillo.lan>
X-SW-Source: 2000-05/msg00125.html
Content-length: 812

Kevin Buettner wrote:

> So at 5:00 pm MST of Saturday, May 27 (which is midnight GMT on Sunday),
> I'll tag the repository, do the PARAMS removal on the gdb directory,
> and tag it again.  I will use gdb-pre-params-removal-2000-05-28 and
> gdb-post-params-removal-2000-05-28 for the tags.  (I'm not sure how
> long it will take to do all of this, but I wouldn't be surprised if
> it were a couple of hours.)

Sounds like then it is.

> Rather than relying on the patch posted earlier this week, I'll be
> using a script to do the actual PARAMS removal.  The script and some
> additional commentary may be found at

Yes.

BTW, the best way for people to avoid being hurt by this is to mount a
pre-emptive strike - eliminate PARAMS from your code before Kevin comes
through on the script on the weekend.

	Andrew
From donnte@microsoft.com Thu May 25 01:28:00 2000
From: Donn Terry <donnte@microsoft.com>
To: 'Mark Mitchell' <mark@codesourcery.com>
Cc: kettenis@wins.uva.nl, Peter.Schauer@Regent.E-Technik.TU-Muenchen.DE, kingdon@redhat.com, gdb@sourceware.cygnus.com
Subject: RE: Suggested (easier) fix to ... RE: Regressions problem (200 failures)
Date: Thu, 25 May 2000 01:28:00 -0000
Message-id: <309F4FC4705DC844987051A517E9E39B09D1A9@red-pt-02.redmond.corp.microsoft.com>
X-SW-Source: 2000-05/msg00126.html
Content-length: 1556

I can't answer why any better than the author of the change 
that started all this ;-) .

> 2000-02-17  Mark Mitchell  <mark@codesourcery.com>
>
>       * function.c (thread_prologue_and_epilogue_insns): Put a line note
>       after the prologue.

My suspicion is that there were situations where the "first statement"
breakpoint wasn't happening correctly, but I don't know details beyond
this.

Agreed, it only affects a subset of all gcc/gdb implementations, which
clearly
explains why everyone wasn't seeing it.

Donn

> -----Original Message-----
> From: Mark Mitchell [ mailto:mark@codesourcery.com ]
> Sent: Tuesday, May 23, 2000 1:07 AM
> To: Donn Terry
> Cc: kettenis@wins.uva.nl; 
> Peter.Schauer@Regent.E-Technik.TU-Muenchen.DE;
> kingdon@redhat.com; gdb@sourceware.cygnus.com
> Subject: RE: Suggested (easier) fix to ... RE: Regressions 
> problem (200
> fa ilures)
> 
> 
> >>>>> "Donn" == Donn Terry <donnte@microsoft.com> writes:
> 
>     Donn> Remember this one?  I finally found time (or rather
>     Donn> desperation :-) ) to look at it more closely.
> 
> The analysis sounds good.  So, this bug should only affect platforms
> that don't define HAS_INIT_SECTION; platforms that, for example, use
> ELF .init/.fini sections won't run into this issue.
> 
> Why are we emitting a line note at the end of the prologue?  (And
> thus before the call to __main?)  Couldn't we wait until the first
> real statement?
> 
> --
> Mark Mitchell                   mark@codesourcery.com
> CodeSourcery, LLC               http://www.codesourcery.com
> 
From mark@codesourcery.com Thu May 25 08:38:00 2000
From: Mark Mitchell <mark@codesourcery.com>
To: donnte@microsoft.com
Cc: kettenis@wins.uva.nl, Peter.Schauer@Regent.E-Technik.TU-Muenchen.DE, kingdon@redhat.com, gdb@sourceware.cygnus.com
Subject: RE: Suggested (easier) fix to ... RE: Regressions problem(200 fa	ilures)
Date: Thu, 25 May 2000 08:38:00 -0000
Message-id: <20000525084647W.mitchell@codesourcery.com>
References: <309F4FC4705DC844987051A517E9E39B09D1A9@red-pt-02.redmond.corp.microsoft.com>
X-SW-Source: 2000-05/msg00127.html
Content-length: 474

>>>>> "Donn" == Donn Terry <donnte@microsoft.com> writes:

    Donn> I can't answer why any better than the author of the change
    Donn> that started all this ;-) .

Touche.

OK, now I understand the problem -- thanks to you.  I'll look back at
why I did what I did -- and then see if I can figure out how to fix
it.

Thanks for bearing with me on this.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com
From mgalgoci@redhat.com Thu May 25 11:41:00 2000
From: Matt Galgoci <mgalgoci@redhat.com>
To: gdb@sourceware.cygnus.com
Subject: [spolk@cygnus.com: Re: [smooge@redhat.com: helping the debian people]]
Date: Thu, 25 May 2000 11:41:00 -0000
Message-id: <20000525144136.B5227@redhat.com>
X-SW-Source: 2000-05/msg00128.html
Content-length: 2293

Would one of you folks, in your copius spare time ;-), please look 
into this. THanks,

--Matt Galgoci

----- Forwarded message from Syd Polk <spolk@cygnus.com> -----

Date: Thu, 25 May 2000 11:01:57 -0700
From: Syd Polk <spolk@cygnus.com>
To: mgalgoci@redhat.com
CC: spolk@redhat.com
Subject: Re: [smooge@redhat.com: helping the debian people]

I would send mail to gdb@sourceware.cygnus.com or gdb-local@cygnus.com.



Matt Galgoci wrote:
> 
> FYI.
> 
> ----- Forwarded message from Stephen John Smoogen <smooge@redhat.com> -----
> 
> Date: Wed, 24 May 2000 22:14:41 -0400 (EDT)
> From: Stephen John Smoogen <smooge@redhat.com>
> To: Matt Galgoci <mgalgoci@redhat.com>
> Subject: helping the debian people
> 
> http://www.debian.org/Lists-Archives/debian-devel-announce-0005/msg00008.html
> 
> Package: gdb (debian/main)
> Maintainer: Vincent Renardias <vincent@debian.org>
> [HELP] Fix needed. (RB)
>   58450  gdb: Won't compile on PowerPC
>   62081  Looking for gdb-4.18-objc patches....
> 
> Stephen J Smoogen
> Web Support Peon
> Red Hat Inc
> 
> ----- End forwarded message -----
> 
> --
> Matthew J. Galgoci <mgalgoci@redhat.com>
> Key fingerprint = 46C1 B1EB 0BE9 E398 7CC3  E788 007D 4FF9 18C2 42C0
> 
> "Take a shower. I can smell you across the vpn."
 wrote:
> 
> FYI.
> 
> ----- Forwarded message from Stephen John Smoogen <smooge@redhat.com> -----
> 
> Date: Wed, 24 May 2000 22:14:41 -0400 (EDT)
> From: Stephen John Smoogen <smooge@redhat.com>
> To: Matt Galgoci <mgalgoci@redhat.com>
> Subject: helping the debian people
> 
> http://www.debian.org/Lists-Archives/debian-devel-announce-0005/msg00008.html
> 
> Package: gdb (debian/main)
> Maintainer: Vincent Renardias <vincent@debian.org>
> [HELP] Fix needed. (RB)
>   58450  gdb: Won't compile on PowerPC
>   62081  Looking for gdb-4.18-objc patches....
> 
> Stephen J Smoogen
> Web Support Peon
> Red Hat Inc
> 
> ----- End forwarded message -----
> 
> --
> Matthew J. Galgoci <mgalgoci@redhat.com>
> Key fingerprint = 46C1 B1EB 0BE9 E398 7CC3  E788 007D 4FF9 18C2 42C0
> 
> "Take a shower. I can smell you across the vpn."

----- End forwarded message -----

-- 
Matthew J. Galgoci <mgalgoci@redhat.com>
Key fingerprint = 46C1 B1EB 0BE9 E398 7CC3  E788 007D 4FF9 18C2 42C0

"Take a shower. I can smell you across the vpn."
From donnte@microsoft.com Thu May 25 20:44:00 2000
From: Donn Terry <donnte@microsoft.com>
To: Mark Mitchell <mark@codesourcery.com>, rth@cygnus.com
Cc: kettenis@wins.uva.nl, Peter.Schauer@Regent.E-Technik.TU-Muenchen.DE, kingdon@redhat.com, gdb@sourceware.cygnus.com
Subject: RE: Suggested (easier) fix to ... RE: Regressions problem (200 failures)
Date: Thu, 25 May 2000 20:44:00 -0000
Message-id: <309F4FC4705DC844987051A517E9E39B16EEF6@red-pt-02.redmond.corp.microsoft.com>
X-SW-Source: 2000-05/msg00129.html
Content-length: 10047

Mark:
 
I just tried to rebuild with my interim patch in place, and found that RTH
had completely
rewritten the area.  If I don't run into too many ICEs during the rebuild of
the compiler
suite (it comes and goes regularly depending on who has patched what) I'll
know
something tomorrow (Fri) about what effect his changes had on this, but from
 looking at the code, it may have the same problem.  (I'm skipping my patch
for the moment.)
 
Richard: quick synopsis: the code in this area doesn't (didn't?) take into
account the
possibility of there being a call to __main, with the consequence that the
initial
breakpoint for main ends up at the {, rather than at the first statement
*if* the
call to __main is generated.
 
Donn

-----Original Message----- 
From: Mark Mitchell 
Sent: Thu 5/25/2000 8:46 AM 
To: Donn Terry 
Cc: kettenis@wins.uva.nl; Peter.Schauer@Regent.E-Technik.TU-Muenchen.DE;
kingdon@redhat.com; gdb@sourceware.cygnus.com 
Subject: RE: Suggested (easier) fix to ... RE: Regressions problem (200 fa
ilures)



>>>>> "Donn" == Donn Terry <donnte@microsoft.com> writes: 

    Donn> I can't answer why any better than the author of the change 
    Donn> that started all this ;-) . 

Touche. 

OK, now I understand the problem -- thanks to you.  I'll look back at 
why I did what I did -- and then see if I can figure out how to fix 
it. 

Thanks for bearing with me on this. 

-- 
Mark Mitchell                   mark@codesourcery.com 
CodeSourcery, LLC               http://www.codesourcery.com
< http://www.codesourcery.com >  


begin 600 winmail.dat
M>)\^(@8#`0:0"``$```````!``$``0>0!@`(````Y`0```````#H``$%@`,`
M#@```-`'!0`9`!0`%P`:``0`/@$!"8`!`"$````P-#-$.30S0C`Y045!1C0S
M035#-#5&-C(R-T$R-$,R,@`A!P$@@`,`#@```-`'!0`9`!0`*@`%``0`/`$!
M#8`$``(````"``(``0.0!@!D%P``.P```$``.0"*4C_!P<:_`1\`,4`!````
M#@```#0`.0`P`#<`-@`Y```````#`!I``````!\`,$`!````#@```#0`.0`P
M`#<`-@`Y```````#`!E``````!\`20`!````E````%(`10`Z`"``4P!U`&<`
M9P!E`',`=`!E`&0`(``H`&4`80!S`&D`90!R`"D`(`!F`&D`>``@`'0`;P`@
M`"X`+@`N`"``4@!%`#H`(`!2`&4`9P!R`&4`<P!S`&D`;P!N`',`(`!P`'(`
M;P!B`&P`90!M`"``*``R`#``,``@`&8`80`)`&D`;`!U`'(`90!S`"D```!`
M`$X`@$WO;F#&OP$"`5L``0```$$`````````@2L?I+ZC$!F=;@#=`0]4`@``
M``!-87)K($UI=&-H96QL`%--5%``;6%R:T!C;V1E<V]U<F-E<GDN8V]M````
M`!\`9@`!````"@```%,`30!4`%```````!\`9P`!````+````&T`80!R`&L`
M0`!C`&\`9`!E`',`;P!U`'(`8P!E`'(`>0`N`&,`;P!M````'P!:``$````<
M````30!A`'(`:P`@`$T`:0!T`&,`:`!E`&P`;````!\`,D`!````+````&T`
M80!R`&L`0`!C`&\`9`!E`',`;P!U`'(`8P!E`'(`>0`N`&,`;P!M`````@%<
M``$````;````4TU44#I-05)+0$-/1$533U520T5262Y#3TT```,`'4``````
M`@%>``$```!!`````````($K'Z2^HQ`9G6X`W0$/5`(`````36%R:R!-:71C
M:&5L;`!33510`&UA<FM`8V]D97-O=7)C97)Y+F-O;0`````?`&@``0````H`
M``!3`$T`5`!0```````?`&D``0```"P```!M`&$`<@!K`$``8P!O`&0`90!S
M`&\`=0!R`&,`90!R`'D`+@!C`&\`;0```!\`70`!````'````$T`80!R`&L`
M(`!-`&D`=`!C`&@`90!L`&P````?`#-``0```"P```!M`&$`<@!K`$``8P!O
M`&0`90!S`&\`=0!R`&,`90!R`'D`+@!C`&\`;0````(!7P`!````&P```%--
M5%`Z34%22T!#3T1%4T]54D-%4EDN0T]-```#`!Y``````!\`<``!````C```
M`%,`=0!G`&<`90!S`'0`90!D`"``*`!E`&$`<P!I`&4`<@`I`"``9@!I`'@`
M(`!T`&\`(``N`"X`+@`@`%(`10`Z`"``4@!E`&<`<@!E`',`<P!I`&\`;@!S
M`"``<`!R`&\`8@!L`&4`;0`@`"@`,@`P`#``(`!F`&$`"0!I`&P`=0!R`&4`
M<P`I`````@%Q``$````;`````;_&7X8^4#+W%AL42P*QW/TNPFGG?@`83#?#
M`!\`<P`!````Y@```&L`90!T`'0`90!N`&D`<P!``'<`:0!N`',`+@!U`'8`
M80`N`&X`;``[`"``4`!E`'0`90!R`"X`4P!C`&@`80!U`&4`<@!``%(`90!G
M`&4`;@!T`"X`10`M`%0`90!C`&@`;@!I`&L`+@!4`%4`+0!-`'4`90!N`&,`
M:`!E`&X`+@!$`$4`.P`@`&L`:0!N`&<`9`!O`&X`0`!R`&4`9`!H`&$`=``N
M`&,`;P!M`#L`(`!G`&0`8@!``',`;P!U`'(`8P!E`'<`80!R`&4`+@!C`'D`
M9P!N`'4`<P`N`&,`;P!M```````?`'0``0```!8```!$`&\`;@!N`"``5`!E
M`'(`<@!Y```````"`0D0`0```$@,``!$#```C"X``$Q:1G6-5J)$`P`*`')C
M<&<Q,C6",@-#:'1M;#$#,#\!`P'W"H`"I`/C`@!C:,$*P'-E=#`@!Q,"@/\0
M`P!0!%8(50>R$=4.40,!W1#7,@8`!L,1U3,$1A#9;Q+K$>,([PGW.QC/#C`U
M.Q'2#&!C`%`+"0%D,S:3$6`+I30@$`(J7`ZRO0&09Q3P"J,1XQWH-!3P`#PA
M1$]#5%E0`$4@2%1-3"!0`%5"3$E#("(M("\O5S-#(8!$5")$()0S+C(A@$5.
MG"(^'NT>CR/!,3@?\&\@HB,/)!\FD#,=@"5P17Q!1"7-#O$F[REO)/0V00[P
M/$U%5$$'L$$Q+&`](D<)\`20871%!;`B$M!/3E0BT%03+/`%X45X$/%N9V4]
M!E)V$S$O00"0`B`@-M`N,"XT'-`X,#`B_A,JSR4#-S<?\%1)5!1,127.-`[P
M4D4Z208`=6<NX'-T"8`@&"AE80"0!)`I(&;(:7@@+7`@+C:@-+.\4F4)P000
M+\$$('`#8#D"8&5M-9`!T!%@9F%=#((@`Q`(<`>0*21N-?T?\"\S3S%_)D4T
MD3JP*$\+)I\^A#418#Q"3T1`62!D:7(]/J!RGSWP/F,`(0,P00%D;P#@\T$!
M"K%<<1BP00$0\`,P'T%E$6`^&QSQ/Q]G.3;Q'_!$259!.0``0W<^.2PV-$:O
M0\)-"L!K.G\^.0'`04<*HD%'"G$D?##_*!$AX$9[3`A#_T4/1A]'+Q=(/U*K
M/ALX'8`F;F+,<W`"@$%8)V$!0%+O_TKO2_]-#TX?53]0/U%/5'^#4V]@;R!)
M(&IU-5"?-F`(@36`-G$8T&)U`Q#+-8`#\'1#0&UY.1`",/<&<3A`"K!T0S$+
M@#?0"V!P8V4L(`!P-8`"$'7/9S%E0"U@!_!42!V<'8!O7H01`#6`!:!M"U`1
M0&7\;'E8?UF/6I];KUR_7<^_7M]?[V#_8@]O%QC0=P40OP)`"?!GL2[P"L`U
ML"Y5GS]6KU>Z8Y!!P&.@0B!N)_T%0')G@&62-H`M<#:``X'K98`A,$4$(&0(
M<2[0=D/W:%]PLF2F;T'`=E)IX@,0_PBB:J]KOVS/;=]N[V__<0_O<A]S+W0_
MA!5S9-`U8#60SV4P:=('D6<B9V\'D1C0-&=U"V!R:F!`L&5PSPGP0,!\,2_1
M=V@V@!$`/S?!9C(U<8V0+6`V$$DG#FP#('ROA9)K;F]W_W]O@'^!CX*?@Z^$
MOX7/AM__A^^(_XH(BT%E0'PC`W`%L/,#8`?@*$8%$#80`:`(8/L%0(Z2(`$1
M!9`%0)Q0!"#?+J0$(&FB+]&<07-G`&3`_P5`CT^7`@-2D-^1[Y+_E`__E1^6
M+Y<_F$^97YIOIJ]W;^=X?ZT"&&!O:WPB9^%^I/\!`&<`BP$`P&6`$0`O0'9#
M?'-A!X`WUG;?KD]X_"BOCO`X0*"/J$)SL%!P?Q#_?#%E<68D`A`%P'92!&`'
M@/D","XIHA^C+Z0_I4^F7_^G;ZA_J8^JGZNOOH^SS[3?_U@_NL^[W[SOO?^_
M#\`?P2^WPC_#3]!+4@W@$0%D-.!2<6308VN*@'F0H'#]`)!S-."PUF9RG^)V
M@WH1JP>0>D(H0,!D>D$_-A#]`9!KU3(V<;:/SC(`T`6@_V>`L+/(#\D?RB_+
M/\Q/S5^?SF_/?]"/T9_>=W!O-W%^8@,093!E@'YT&-"@,&6?L&-IT`=``R`V
M<5]?`,#?"X!G`&4C?J0`@&73P`GP_V;@9[1\;VDF"X!E,`<QV>__VO_<#]T?
MWB_?/^!/X5_B;^OC?_`78G:A:^409:&XXT_G@IXP9S`$('5PL)9<_GMG`"U1
MYA%GL@.@L*4V,/\1(`5`-5`M8#@PN:'IO_&C^BH&D"K9K^Q?[6_N?^^/__"?
M\:_RO_//]-\%:^;L.1#OBW`NX"TS&.`N_2_^/_]/_P!?`6\"?P./!)\%KP:_
M#J__Q:_&O\?/"N\+_PT/#A\/+U\0/Q%/$E\3;R!K1"_0;O\8+QD_&D\;7QQO
M'7\>CT!@@$Q/0TM154\M\!M`MOJA>3@@+C%!4D<`24XM4DE'2%3Q-.`P<'@P
MH1:X*;$HLO]"94,#0L%#7RD?,]MYH2GO'Q^/()\AKS`(0O!I,S81,(TQ-#@F
M\$9/3E)4BH!I>BR`,C1[9JQS,C%Q,!<M._)/=>#^9_?`YO!*`(M@LG`)<#OS
MM3A=,2KB4D$[]\!E,*#O,`\5MRL`-'MB+_F=0+F`^CHS/#(F\4&Z*`E*`TH`
M_XL`CD&/'S&/%>0S#CY_/X_W0)]!KTP(4_L10Y]$KWE'@%1H=2`U+S)2@4(P
M4N`@.#HT-!!!?DT]GTJO2[],STW?5C54?F]/GU"O>4<C4E(P?T!R_WN`1R](
M/TE/5%]5;U9_5X_Y0II#8UE_6H]Y1]=@=@*-GL!`Y^#HD"YU=G;`N&YL.US/
M7=]>Y5"<,!E_0"Y3GO'HT')`4G.,,+FB12U<<(Y`ZR!K8"Y452U-Z-)V8&ZX
M+D1%:1"P4GHA0(P@^F2.H2Z+,6D?:B]>UF[0W&)`G`!\`.D`=]71;X#P>6=N
M=6B0BS%3GV!?CV%O8G]CCT[F=6)JGG%G92]F/T6W4D73H'FP9_^?,0G1BN#5
M\.5`?T#7(/I0WG@(DF_O</]>]"Z!,'S#_VR1C"#E,>B!LK:*X%+1]U#OU@#E
M<'+`BV`I=`]U'W8OKX0?A2^&/R96-301+SF"_WMO%]\D7R5O)G^+CS"/?Z_W
M,J\V-9`04"W?-UDVSS??3SCO.?\[#15/9W06F3[_F]^<[YW_GP^@'Z$OHC^C
M3Q>D7Z5O1?,B(U(B(#W>/5P??P^`'ZOO)I.P%IF./*88;N'[(&5`;=-`>[+0
M<J!F;W.M+Z?/1<9W_SQ0"=#4D(GOBO]%BHV?CJ7_E:^F/XTDD!&5<9'?J[^3
M__^5#Y>OF+^9SYK?N6\5SQ;?_\0?Q2_&/\=/R%\7>2-#RA\[L@]%QDD(0=9B
M^;!S=_GY87=HY;#YL.6PYF!G\?_Y=:JOO%^LQ.@R;$#I,/=Q_^74Z&#YH0EP
MM`^U'T6*AN__A_^)#\#_P@_#'\GORO_)+__?K^"_X<_BW^/OS*_-O\[/_](/
MTQ_4)_AQ^K&W,'V!"&/2:`E!.RU^("[6']<O_[8OMS^X3^2ONF^[?[R/O9^_
MOJ^_O]O_W0_>'UCV=4;!_^\_\$_Q7_)O\W_TC_6?]J__][_XS_G?^N_[__T/
M_A\%A8!/2RP@;F]WS]'X=6YDJE#MX1$`U6."=ML]<='":X)0?H%Y<K#__'/F
M'^<O22=&_P@OK)=LQ&]O1G!B86-&<&]@_P`/`1_8/]E/VE\%;PU/#E__WIW0
MTL_@*\!]D-#0[;$CI*<]<1%EJB!S9=2P::[@O\_@%K\7SZS$T`%^,6>#D?O5
M,-3@(-4`$+!^@7Y!&?__&P\<'QTO'C\?3R!?(6_>G?]&H/__*Q\"'P,O!#\O
M3P9?_P=O"'\)CPJ?"Z\O[S#_,@_[6.82I&;5$=%0/`!NL;.`\4:@:"!M*1&J
M(.ZB,Z__-+\USS;?-^\X_SH/.Q\\+_\]/SY//U]`;T%_0H]+M22P_T8_1T\L
M/RU/+E]+GU-_5(]]WIU-3H`9L"8/3H^LQ$W_L[!N$1:`$W\4C^2/8[]DS_]E
MWV;O9_]I#VH?:R]L/VU/_VY?;V]P?W&/<I]SKW2_=<__=M]W[WC_>@]['WPO
M?3]^3_]_7X!O@7^"CX.?A*^%OX;/_X??B.^)_XL/C!^-+XX_CT]_D%^1;Y)_
MYVM@;V%_K,1MO6`A0+#`$1"P<"CP8ZI0_GFPOU=_6(]9GUJO6[]<S]==WU[O
MH,!#FA%3FE40<,>7/YA/K,1,3$.43Y5?_Y./J%^I;ZI_JX^LGZVOKK__K\^P
MW['OLO^T#[4?MB^W/_^X3[E?NF^[?[R/O9^^K[^__\#/P=_"[\/_Q0_&'\<O
MR#__R4_*7\MOEC^E;Z9_*#/-;HP\02E@*0!F/2+.X,!T<#HO+W?4T)K!59HL
M(J*\:6,P9$[B9@?7()_P$4![2%E01<!23$E.2R#47]5J/'U]HV'7(!$P3U!<
M8_!F,5QU%I#,R-B_FFBOG)]24MX/H,TY30)!35W_F]^<[]!OT7\H,TD?2B]+
M/PM,3^&N,%#A+T),3X!#2U%53U1%XS]OZ>]./^\_3P<UH='LH$^\1%E-7>L0
M\/]/<3?BP5!(5$U,HK!]];`#`"8```````,`-@``````'P!'$`$````>````
M;0!E`',`<P!A`&<`90`O`'(`9@!C`#@`,@`R```````#`-X_Z?T```,`\3\)
M!````P#]/^0$```+`/(0`0````L`]!``````"P#U$``````+`/80`````!\`
M\Q`!````H@```%(`10`E`#,`00`@`%,`=0!G`&<`90!S`'0`90!D`"``*`!E
M`&$`<P!I`&4`<@`I`"``9@!I`'@`(`!T`&\`(``N`"X`+@`@`%(`10`E`#,`
M00`@`%(`90!G`'(`90!S`',`:0!O`&X`<P`@`'``<@!O`&(`;`!E`&T`(``H
M`#(`,``P`"``9@!A`&D`;`!U`'(`90!S`"D`+@!%`$T`3````````@%'``$`
M```Q````8SU54SMA/4U#23MP/6US9G0[;#U2140M4%0M,#(M,#`P-3(V,#,R
M,S(V6BTR.3<R``````(!^3\!````40````````#<IT#(P$(0&K2Y"``K+^&"
M`0`````````O3SU-24-23U-/1E0O3U4]3D]25$A!345224-!+T-./5)%0TE0
M245.5%,O0TX]-#DP-S8Y`````!\`^#\!````%@```$0`;P!N`&X`(`!4`&4`
M<@!R`'D``````!\`.$`!````#@```#0`.0`P`#<`-@`Y```````"`?L_`0``
M`%$`````````W*=`R,!"$!JTN0@`*R_A@@$`````````+T\]34E#4D]33T94
M+T]5/4Y/4E1(04U%4DE#02]#3CU214-)4$E%3E13+T-./30Y,#<V.0`````?
M`/H_`0```!8```!$`&\`;@!N`"``5`!E`'(`<@!Y```````?`#E``0````X`
M```T`#D`,``W`#8`.0``````0``',+8/';?`QK\!0``(,`:6$%S$QK\!'P`:
M``$````2````20!0`$T`+@!.`$\`5`!%```````?`#<``0```)(```!2`$4`
M.@`@`%,`=0!G`&<`90!S`'0`90!D`"``*`!E`&$`<P!I`&4`<@`I`"``9@!I
M`'@`(`!T`&\`(``N`"X`+@`@`%(`10`Z`"``4@!E`&<`<@!E`',`<P!I`&\`
M;@!S`"``<`!R`&\`8@!L`&4`;0`@`"@`,@`P`#``(`!F`&$`:0!L`'4`<@!E
M`',`*0``````'P`]``$````*````4@!%`#H`(```````'P`=#@$```"*````
M4P!U`&<`9P!E`',`=`!E`&0`(``H`&4`80!S`&D`90!R`"D`(`!F`&D`>``@
M`'0`;P`@`"X`+@`N`"``4@!%`#H`(`!2`&4`9P!R`&4`<P!S`&D`;P!N`',`
M(`!P`'(`;P!B`&P`90!M`"``*``R`#``,``@`&8`80!I`&P`=0!R`&4`<P`I
M```````?`#40`0```)P````\`#,`,``Y`$8`-`!&`$,`-``W`#``-0!$`$,`
M.``T`#0`.0`X`#<`,``U`#$`00`U`#$`-P!%`#D`10`S`#D`0@`Q`#8`10!%
M`$8`-@!``'(`90!D`"T`<`!T`"T`,``R`"X`<@!E`&0`;0!O`&X`9``N`&,`
M;P!R`'``+@!M`&D`8P!R`&\`<P!O`&8`=``N`&,`;P!M`#X````+`"D`````
M``L`(P```````P`&$#3W0:`#``<0H00```,`$!```````P`1$`$````>``@0
M`0```&4```!-05)+.DE*55-45%))14143U)%0E5)3$17251(35E)3E1%4DE-
M4$%40TA)3E!,04-%+$%.1$9/54Y$5$A!5%)42$A!1$-/35!,151%3%E215=2
M251414Y42$5!4D5!249)1$].``````(!?P`!````3@```#PS,#E&-$9#-#<P
M-41#.#0T.3@W,#4Q034Q-T4Y13,Y0C$V145&-D!R960M<'0M,#(N<F5D;6]N
:9"YC;W)P+FUI8W)O<V]F="YC;VT^````_4P=
`
end
From dyp@perchine.com Thu May 25 21:06:00 2000
From: Denis Perchine <dyp@perchine.com>
To: gdb@sourceware.cygnus.com
Subject: GDB shows extra SIGTRAP and then SIGSEGV if continue on linux/glibc 2.1.3
Date: Thu, 25 May 2000 21:06:00 -0000
Message-id: <00052611073508.24471@dyp>
X-SW-Source: 2000-05/msg00130.html
Content-length: 283

Hello all,

Is there any solution for this problem available or planned to be available?

-- 
Sincerely Yours,
Denis Perchine

----------------------------------
E-Mail: dyp@perchine.com
HomePage: http://www.perchine.com/dyp/
FidoNet: 2:5000/120.5
----------------------------------
From ac131313@cygnus.com Thu May 25 22:23:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: mgalgoci@redhat.com, Vincent Renardias <vincent@debian.org>
Cc: gdb@sourceware.cygnus.com
Subject: Re: [spolk@cygnus.com: Re: [smooge@redhat.com: helping the debian people]]
Date: Thu, 25 May 2000 22:23:00 -0000
Message-id: <392E09B7.674006C@cygnus.com>
References: <20000525144136.B5227@redhat.com>
X-SW-Source: 2000-05/msg00131.html
Content-length: 792

Matt Galgoci wrote:

> > ----- Forwarded message from Stephen John Smoogen <smooge@redhat.com> -----
> >
> > Date: Wed, 24 May 2000 22:14:41 -0400 (EDT)
> > From: Stephen John Smoogen <smooge@redhat.com>
> > To: Matt Galgoci <mgalgoci@redhat.com>
> > Subject: helping the debian people
> >
> > http://www.debian.org/Lists-Archives/debian-devel-announce-0005/msg00008.html
> >
> > Package: gdb (debian/main)
> > Maintainer: Vincent Renardias <vincent@debian.org>
> > [HELP] Fix needed. (RB)
> >   58450  gdb: Won't compile on PowerPC
> >   62081  Looking for gdb-4.18-objc patches....

Is that GDB 4.18?  If it is then the problem isn't suprising. Patches to
support Linux/PPC were only merged into GDB after gdb 4.18 was created. 
I would suggest restarting with GDB - 5.0.

	enjoy,
		Andrew
From vincent@redhat.com Fri May 26 06:04:00 2000
From: Vincent Renardias <vincent@redhat.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: mgalgoci@redhat.com, gdb@sourceware.cygnus.com
Subject: Re: [spolk@cygnus.com: Re: [smooge@redhat.com: helping the debian people]]
Date: Fri, 26 May 2000 06:04:00 -0000
Message-id: <Pine.LNX.4.20.0005261301520.16057-100000@v2.ldsol.com>
References: <392E09B7.674006C@cygnus.com>
X-SW-Source: 2000-05/msg00132.html
Content-length: 700

On Fri, 26 May 2000, Andrew Cagney wrote:

> > > http://www.debian.org/Lists-Archives/debian-devel-announce-0005/msg00008.html
> > >
> > > Package: gdb (debian/main)
> > > Maintainer: Vincent Renardias <vincent@debian.org>
> > > [HELP] Fix needed. (RB)
> > >   58450  gdb: Won't compile on PowerPC
> > >   62081  Looking for gdb-4.18-objc patches....
> 
> Is that GDB 4.18?  If it is then the problem isn't suprising. Patches to
> support Linux/PPC were only merged into GDB after gdb 4.18 was created. 
> I would suggest restarting with GDB - 5.0.

Indeed, it was 4.18. I'm going to package 5.0 soon.

	Cordialement,

-- 
Vincent Renardias <vincent@redhat.com>                  Red Hat France BOFH