public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: "Gina Verlekar" <GinaV@KPITCummins.com>
To: "Nick Clifton" <nickc@redhat.com>
Cc: <binutils@sourceware.org>
Subject: RE: [PATCH] Addition of new option '--rlib' in linker for Renesas SH targets
Date: Thu, 13 Jul 2006 05:11:00 -0000	[thread overview]
Message-ID: <1F211FE03383644EAA6BB7A52FCD9B9B09280E@sohm.kpit.com> (raw)
In-Reply-To: <m3bqrud7by.fsf@redhat.com>


Hi Nick,

Thank you very much for the detailed review. 
I will implement all the mentioned changes and re-post the patch.

Regards,
Gina Verlekar
KPIT Cummins InfoSystems Ltd.
Pune, India
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~	
Free download of GNU based tool-chains for Renesas SH, H8, R8C, M16C and
M32C Series.
The following site also offers free technical support to its users.	
Visit http://www.kpitgnutools.com for details.
Latest versions of KPIT GNU tools were released on June 1, 2006.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~	


-----Original Message-----
From: Nick Clifton [mailto:nickc@redhat.com] 
Sent: Wednesday, July 12, 2006 11:39 PM
To: Gina Verlekar
Cc: binutils@sourceware.org
Subject: Re: [PATCH] Addition of new option '--rlib' in linker for
Renesas SH targets

Hi Gina,

> Please refer to the link below for the patch I had submitted:
> http://sources.redhat.com/ml/binutils/2006-07/msg00068.html

Sorry for the delay in reviewing this patch.

Unfortunately I do not think that it is ready for inclusion into the
sources yet.  The problems that I have with it are:

  * The changes to Makefile.am mean that recreating Makefile.in
    results a warning message about the convrenesaslib_SOURCES being
    defined but not used.  You need to add it to the EXTRA_PROGRAMS
    definition.

  * The copyright comment at the start of convrenesaslib.c has the
    wrong address for the FSF and it says that the tool is part of GLD
    whereas in fact it is part of the GNU Binutils.

  * REPORT_BUGS_TO is defined in the bin-bugs.h header.

  * Having the "magic_num" field of the rlib_header structure be of
    the "unsigned char" type results in compile time warning messages
    when it is used as an argument to strcpy().

  * None of the textual output of the program has been
    internationalized.

  * The --remove-underscore switch is a bad idea.  It would be much
    cleaner and safer if you just invoke "objcopy
    --remove-leading-char" for yourself as a separate step after
    completing the conversion to the GNU ar format.

  * The indentation and formatting do not quite match up to the GNU
    Coding Standard.

  * The use of the program_name array looks very strange to me.  I
    think that it would be much cleaner if you left program_name as
    being the value of argv[0] and you used a different variable when
    you are constructing the ar command line.

  * There are various "magic" constants in some of the malloc() calls
    (eg + 50, or + 100) without any explanation of where they come
    from.  There are also several fixed length arrays that should not
    be fixed (eg filepath, module_name).

  * The fatal() function should be used in place of the
    printf();exit(1); combination currently used.

  * [optional] Adding a --verbose switch would be useful.  It could
    tell the user the command line it is using to invoke "ar", and
    also mention when files are being created and deleted.

  * [optional] A test case to check that the tool works would be very
    helpful.

Cheers
  Nick
  

  reply	other threads:[~2006-07-13  5:11 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-07-12 18:08 Nick Clifton
2006-07-13  5:11 ` Gina Verlekar [this message]
2006-07-24  7:10 ` Gina Verlekar
2006-08-06 14:34   ` Nick Clifton
  -- strict thread matches above, loose matches on Subject: below --
2006-07-04  8:21 Gina Verlekar
2006-07-04 11:24 ` Dave Korn
2006-07-07  8:51   ` Gina Verlekar
2006-06-26 13:47 Gina Verlekar
2006-06-26 15:54 ` Andrew STUBBS
2006-06-28 12:33   ` Gina Verlekar
2006-06-26 17:28 ` Pedro Alves
2006-06-28 15:51   ` Pedro Alves
2006-06-29 18:37     ` Dave Korn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1F211FE03383644EAA6BB7A52FCD9B9B09280E@sohm.kpit.com \
    --to=ginav@kpitcummins.com \
    --cc=binutils@sourceware.org \
    --cc=nickc@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).