This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: binutils, bfd library, debug.h/c files and so on...


Tarmo Pikaro <tapika@yahoo.com> writes:

> Attaching a zip with debug.h/c, initial version with
> my modifications, I haven't fully implemented the
> feature which I need, but these are initial changes to
> debug.h/c.

It is most helpful if you generate a diff, using
    diff -pu OLDFILE NEWFILE
and then attach the diff using MIME type text/plain or text/x-patch.
Thanks!

In order to be accepted, your patches must follow the GNU formatting
conventions, described here:
    http://gnu.org/prep/standards/
or just look at the formatting used in the rest of the file.

The approach looks reasonable to me.

> 1. Do I need to inspect all the changes with you ?
> Probably yes, and it's fine by me, but I need to know
> your requirements for source code quality.

If you want to get the patches accepted, then they need to be approved
by one of the binutils maintainers (I am one, but I am not very
active).  The code has to be bug-free, has to compile with -Wall
-Werror, and has to be formatted correctly.

> 2. Thinking in more details, I've realized why do we
> need a separate typedump.exe, when we could integrate
> my function into objdump ?  And that would be my next
> proposal - add into objdump additional flag:
> --print_type_tree_for_perl ?
> I will implement a separate .c file and you will add
> into objdump additional function call to that .c file.

That approach is only going to be OK if you can very clearly specify
what the output should look like.  It's not going to be OK if the
output is only for your program.

Ian


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]