Patch for avr port of binutils [adiw, sbiw, ldd with more functionality]

[Klaus Rudolph]

Hi Nick,


Nick Clifton wrote:

> Hi Klaus,
>
>   * The file bfd-in2.h is an automatically generated file.  If you 
> need to patch it, you should also patch the source file(s) that are 
> used to create it.  In this particular case the new relocs that you 
> created needed to be added to the bfd/reloc.c file.
>
OK, thanks for this info. I downloaded the version (041119) via a single 
file not from cvs. And bfd-in2.h was contained there :-(??
I have removed it from my sources and bring the change into bfd/relocs.c.
But after that I was not longer able to build? What I have to typ for a 
rebuild of the internal generated header files?


>   * You used C++ style comments in a few places in the code.  Although 
> GCC allows this, other compiler might not, and besides we are trying 
> to get to the state where we can compile all of binutils with the 
> -Wall -Werror flags set.

OK, changed.

>
>   * We are now using ISO-C90 style C formatting in binutils, and 
> although there are quite a lot of files that have not yet been 
> converted over, we still ike to encourage any new patches to make use 
> of this standard.  Thus for example the PARAMS() macro is now no 
> longer needed when declaring function prototypes, and function 
> declarations can include their arguments inside the parentheses.
>
Done, but only for my single new function. If you are interested in 
changing the complete avr-related files I can do this also but please
after this patch. So that I am able to keep track and not through all 
the things together :-)

>   * The patch needlessly inserted whitespace in various places and did 
> not always follow the GNU Coding convention.
>
Ups, yes. I need a bit assistent from you. Is there a tool for 
checking/auto formatting available? Or have you a .vimrc file where I
can do this with traditional "gg=G" command? I´m a bit confused above 
the old style in the changed files. I found there tabs also as
normal spaces to shift the raws. Please give me a hint what to do, I 
will apply this soon as possible.

>   * It is helpful if you can generate patches using the -c switch to 
> diff.  The extra context makes the patch much easier to read.
>
Done.

>   * When adding a new feature it is always a good idea to include a 
> new entry in the relevent testsuite to make sure that the feature 
> works, and continues to work in the future.
>
There is actually no testsuite for avr. Sorry!

>   * You should always include a set of entries for the relevent 
> ChangeLog files annotating which files you have changed and why.  Note 
> - for convenince we ask that these entries just be submitted as plain 
> text, not a diff, as they usually have to be applied by hand.
>
I add an additional file as attatchment so you have the ability to use 
the given text. If you need it in an other way please let me know.

Because of the open items: could not build the bfd-in2.h file, and the 
formatting rules we need another version. So please give
me a detailed information on this to topics so that the next patch is 
maybe the last one :-)

Regards
   Klaus

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: binutils-041119_patch004
URL: <https://sourceware.org/pipermail/binutils/attachments/20041220/65c3bacf/attachment.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ChangeLog004
URL: <https://sourceware.org/pipermail/binutils/attachments/20041220/65c3bacf/attachment-0001.ksh>