This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: RFA: Skip ARM ELF Mapping symbols when showing disassembly
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: Richard dot Earnshaw at arm dot com
- Cc: Nick Clifton <nickc at redhat dot com>, gdb-patches at sources dot redhat dot com,binutils at sources dot redhat dot com
- Date: Thu, 13 Nov 2003 10:20:35 -0500
- Subject: Re: RFA: Skip ARM ELF Mapping symbols when showing disassembly
- References: <m3he181gxc.fsf@redhat.com> <200311131445.hADEj7C19503@pc960.cambridge.arm.com>
On Thu, Nov 13, 2003 at 02:45:07PM +0000, Richard Earnshaw wrote:
> > Hi Guys,
> >
> > I have recently committed a patch to the arm-elf port of GAS which
> > causes it to generate special mapping symbols as required by the ARM
> > ELF spec. Unfortunately this now means that when GDB shows a
> > disassembly it can select one of the mapping symbols instead of the
> > proper function name symbol.
> >
> > The patch below is a fix for this problem. It is not elegant, but
> > it does have the advantage of being entirely arm specific. A
> > cleaner patch would require changes to generic code, which I did not
> > feel comfortable doing.
> >
> > May I apply this patch ?
> >
> > Cheers
> > Nick
> >
>
> I wonder whether a better way to handle all this is to override
> slurp_symbol_table for arm-elf to a routine that just skips the mapping
> symbols entirely (or at least, doesn't put them into the list that it
> passes back to its caller), then to add a separate function to slurp the
> mapping symbols independently. Then gdb and the disassembler (and the
> linker error reports) would all just work normally.
>
> It would be necessary to add support for copying and fixing up the mapping
> symbols when linking, but that's probably not too hard.
FWIW, I think this is a good idea.
I don't want to end up with them in the symbol table for GDB; there
could be a substantial number of them (especially if the linker emits
them for interworking veneers), and they could have nasty adverse
effects on the hash table. Plus a symbol table isn't a useful data
structure for this information, I think, just a convenient way to store
it in the object file.
I have always envisioned this sort of information being carried by
.debug_line instead, but of course that doesn't meet the same needs as
the mapping symbols.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer