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>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
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/ ]