Date:	Tue, 10 Jul 2001 11:07:46 +0300 (IDT)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de>
cc:	djgpp-workers AT delorie DOT com
Subject:	Re: bfdsymify
In-Reply-To:	<Pine.LNX.4.10.10107091927470.27567-100000@acp3bf>
Message-ID:	<Pine.SUN.3.91.1010710110717.18978D-100000@is>
MIME-Version:	1.0
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

On Mon, 9 Jul 2001, Hans-Bernhard Broeker wrote:

> But what about submitting it to GDB? It is a kind of debugger, after all.
> And GDB comes with bfd, too, so there'd always be one available for
> building bfdsymify.

This approach still requires to come up with a portable program.
Otherwise, I find it hard to believe that GDB maintainers will accept
it.  I once tried to put into the distribution a bunch of
DJGPP-specific files to make the test suite usable for the DJGPP port,
but couldn't convince the maintainers to agree to that.

> > Plus, other systems may dump such a traceback in a redirectable way, so
> > extending bfdsymify to be able to read the traceback from a text file would
> > be a more useful feature than trying to implement generic screen-reading.
> 
> Doesn't bfdsymify do that, already?

Yes, it does.  It does everything symify does, as far as the user
interface goes.

What's more, our traceback is also redirectable: we output it by
writing to file handle 2, so redirecting stderr is all you need.  The
screen capture feature of symify is there because in most cases, you
won't think your program has a bug, and thus won't redirect stderr
until it's too late ;-)

- Raw text -