Date: Wed, 07 May 2003 10:18:53 +0300
From: "Eli Zaretskii" <eliz AT elta DOT co DOT il>
Sender: halo1 AT zahav DOT net DOT il
To: djgpp-workers AT delorie DOT com
Message-Id: <9743-Wed07May2003101853+0300-eliz@elta.co.il>
X-Mailer: emacs 21.3.50 (via feedmail 8 I) and Blat ver 1.8.9
In-reply-to: <200305061759.h46HxXht018427@speedy.ludd.luth.se>
	(ams AT ludd DOT luth DOT se)
Subject: Re: Yet another try on nan in strto{f,d,ld}
References:  <200305061759 DOT h46HxXht018427 AT speedy DOT ludd DOT luth DOT se>
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

> From: <ams AT ludd DOT luth DOT se>
> Date: Tue, 6 May 2003 19:59:33 +0200 (CEST)
> > >  
> > > Call frame traceback EIPs:
> > >   0x00005e21 __modfl+33, file a:/doprnt.c, line 924
> > 
> > Any clues why does it say that __modfl+33 is in doprnt.c?  Is that a
> > bug in symify/bfdsymify?
> 
> Line 924 is the last line of doprnt.c and modfl() wasn't compiled with
> debug information.
> 
> It's like when only t-strtof.c was compile with debug info. Then the
> printf/doprnt stuff was attributed to t-strtof.c.
> 
> That's my guess.
> 
> Or perhaps you mean it should detect that the file is irrelevant and
> shouldn't map to doprnt.c?

Yes, it should have said "__modfl+33, file modfl.S", or maybe omit
the file name (since the library is stripped).

I think this is a known problem with the method used by BFD functions
(which bfdsymify calls) to find a file and source line that
corresponds to a given address: they sometimes err on file boundaries.

What version of bfdsymify do you have on that machine?