This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: Borland TDS reading + BFD Interface Change
- To: Troy Rollo <troy at rollo dot com>
- Subject: Re: Borland TDS reading + BFD Interface Change
- From: Daniel Berlin <dan at cgsoftware dot com>
- Date: Sat, 19 Aug 2000 21:14:09 -0700 (PDT)
- cc: gdb-patches at sourceware dot cygnus dot com
> Specific things to be aware of:
>
> 1. I have included the Borland demangling as a module of GDB rather than
> trying to get it into the common demangling code - that code appears to be
> designed to deal with demangling formats that are fundamentally similar,
> but Borland's bears no resemblence to any of those formats.
Huh?
libiberty's demangler module provides a generic interface to demangling
any c++ symbol.
You should be able to add any type of demangler into it, no matter how
dissimilar.
Compaq C++, GNU, ARM, HP, EDG, java, GNAT, GNU new-abi all fit with it's
framework.
I've also fit a demangler for MS's mangling scheme in there before.
I don't see how borland's is so amazingly different that it can't be
included.
It makes it amazingly difficult to do useful C++ debugging if your
demangler must be called seperately. We need to simply be able to use
cplus_demangle, and get the right stuff back, no matter what the mangling
scheme used is.
Otherwise, you'll break so much it's not even funny.
Unless you never use a mangled name anywhere in your debug info.
And in the future, you'll break even more, as i add a lot more C++
functionality.
> > 2. TDS stores partially mangled symbols - they often don't have the
> arguments mangled in them. To get past this, I have made a call to
> c_type_print_args when necessary to put the arguments into the C++
> demangled name. This of course entailed making c_type_print_args non-static.
This i don't really have much problem with.
>
> 3. There was a bug in main.c that meant that the --symbols command line
> argument was effectively ignored in any practical case. I had to fix that
> because we need the --symbols argument for TDS, because the debug
> information may be in a sepearate file to the executable.
>
> 4. Binutils interface change - In the BFD structure I have added a data
> element "opened_for_symbols" - because TDS data may or may not be in the
> same file as an executable, and we need to recognise the executable in one
> case and the debug information in another, I added this member that the
> Borland TDS recognition code checks before deciding if it matches.
Not my call.
>
> 5. Almost everything else should be reasonably kosher as far as
> modifications to existing files go.
>
> I use the following shell script to launch GDB for Borland files - it may
> be useful to people who are going to do this, but I'm not sure if it
> belongs anywhere in the GDB source tree itself.
>
> #!/bin/sh
>
> GNUTARGET=borland-tds
> export GNUTARGET
>
> GDB=/usr/local/bin/gdb
>
> case "x$1" in
> x)
> ;;
>
> *)
> [ -f "$1.tds" ] && {
> exec ${GDB} --symbols="$1.tds" "$@"
> }
> ;;
> esac
> exec ${GDB} "$@"