bug-binutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [incomplete patch] Get objdump to report exception tables for ARM/SH


From: Danny Backx
Subject: Re: [incomplete patch] Get objdump to report exception tables for ARM/SH4 correctly
Date: Sat, 29 Mar 2008 11:37:30 +0100

This has been on my todo-list for far too long, apologies.

I've tried to tackle the conditional compilation part, and would like
your renewed input on it, I may have missed some points. Naming for
instance.

Diffs in the attachment are relative to the cegcc svn, I've checked and
they patch cleanly in a binutils 2.18 tree.

So, please tell me what I'm missing and I'll change my patch.

        Danny

On Mon, 2007-08-06 at 16:22 +0100, Nick Clifton wrote:
> Hi Danny,
> 
> 
> > 2. Cleanup in my_symbol_for_address. There's none now. Should there be?
> 
> Yes. :-)
> 
> Also it looks like my_symbol_for_address is going to quite slow for large 
> symbol tables.  You might want to consider ensuring that the symbol time is 
> sorted by address and then performing some kind of binary search on it.  (Or 
> do 
> you know that my_symbol_for_address will always be called with incrementally 
> increasing addresses, in which case you could just cache the last returned 
> value and start your search there).
> 
> > 3. Which macros should be used for the conditional compilation ? I've
> > used
> > #if defined(ARM_WINCE) || defined(SH4)
> > in my code. This happens to work for me because our build chain defines
> > ARM_WINCE, but I don't suppose this is right.
> 
> The correct way to handle this is to add a new function pointer field to the 
> bfd_coff_backend_data structure.  Arrange for this field to be initialized by 
> the various backends that need it (IA64, ARM, MIPS, SH) pointing at static 
> functions defined in the appropriate target specific source file (pe-arm.c 
> etc), and otherwise for it to be empty(*).  Then in 
> _bfd_XX_print_private_bfd_data_common test the field and call it if it is not 
> empty.
> 
> Cheers
>    Nick
> 
> (*) Or maybe to point at a default pdata display function which does not try 
> to 
> provide any target specific interpretation.

Attachment: x
Description: Text Data

Attachment: signature.asc
Description: This is a digitally signed message part


reply via email to

[Prev in Thread] Current Thread [Next in Thread]