Sender:	rich AT phekda DOT freeserve DOT co DOT uk
Message-ID:	<3E070DD2.6420C1E4@phekda.freeserve.co.uk>
Date:	Mon, 23 Dec 2002 13:21:22 +0000
From:	Richard Dawe <rich AT phekda DOT freeserve DOT co DOT uk>
X-Mailer:	Mozilla 4.77 [en] (X11; U; Linux 2.2.23 i586)
X-Accept-Language:	de,fr
MIME-Version:	1.0
To:	djgpp-workers AT delorie DOT com
Subject:	Re: RESEND: gdb 5.2.1 segfaults while debugging fileutils 4.1
References:	<3E05A070 DOT 20810EB8 AT phekda DOT freeserve DOT co DOT uk>
Reply-To:	djgpp-workers AT delorie DOT com

Hello.

Richard Dawe wrote:
[snip]
> I seem to be having some trouble debugging fileutils 4.1 with gdb 5.2.1.
> Here's the situation:
> 
> * fileutils 4.1 and DJGPP CVS both built with -gstabs+3.
> * gdb 5.2.1 from binaries on Simtel.NET or gdb 5.2.1 built against DJGPP CVS.
> 
> If I load up gdb on cp from fileutils 4.1 ("cd gnu/filutil4.1/src; gdb
> cp.exe"), then type "b copy" then TAB, gdb segfaults. The symify message is
> below. I press tab to complete for the copy_internal function. If I type "b
> copy_internal", the breakpoint is set OK.
[snip]

I've found the problem or, at least, a cause. I had compiled lib/*.c with a
different version of gcc, so it had different debugging info to compiled
src/*.c - stabs ("dbx") vs. DWARF-2. Does gdb support this? (I don't see why
not, but perhaps it has not been tested much.)

In the gdb-5.3 sources the for loop at gdb/symtab.c:3306 eventually lead to a
protection fault. This seemed to occur when an object file built with
non-DWARF-2 debugging info was reached.

Now I've rebuilt everything with DWARF-2, I can debug.

Bye, Rich =]

-- 
Richard Dawe [ http://www.phekda.freeserve.co.uk/richdawe/ ]

- Raw text -