Mailing-List: contact cygwin-apps-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-apps-owner AT cygwin DOT com
List-Subscribe: <mailto:cygwin-apps-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-apps/>
List-Post: <mailto:cygwin-apps AT cygwin DOT com>
List-Help: <mailto:cygwin-apps-help AT cygwin DOT com>, <http://sources.redhat.com/lists.html#faqs>
Mail-Followup-To: cygwin-apps AT cygwin DOT com
Delivered-To: mailing list cygwin-apps AT cygwin DOT com
From: "Ralf Habacker" <Ralf DOT Habacker AT freenet DOT de>
To: "Nick Clifton" <nickc AT cambridge DOT redhat DOT com>
Cc: <robert DOT collins AT itdomain DOT com DOT au>, <cygwin-apps AT cygwin DOT com>,
   <binutils AT sources DOT redhat DOT com>
Subject: RE: question about objdump output format ?
Date: Tue, 28 May 2002 13:24:24 +0200
Message-ID: <003e01c2063a$384808f0$651c440a@BRAMSCHE>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
Importance: Normal
In-Reply-To: <m3u1osbn1c.fsf@north-pole.nickc.cambridge.redhat.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400

> Hi Ralf,
>
> > Here is the patch. It is based on the "objdump_ai_segfault_2.patch",
> > which I have send in before.

See note below

> >
> > Changelog entry for bfd dir ----------------------
> >
> > 2002-05-22 Ralf Habacker <ralf DOT habacker AT freenet DOT de>
> >
> >   * peXXigen.c (pe_print_idata()): removed double printed
> >   import table lines, added Bound-To comment.
> >
> > I hope, the changelog entry is clear. It may be, that the indents
> > ate 100% pure, please correct if necessary
>
> Unfortunately I have some problems with this patch:
>
>   * It does not apply against the current sources in the CVS
>     repository.  In fact it is not even close.  There has been some
>     recent work on this code by Laurent Pinchart
>     <laurent DOT pinchart AT skynet DOT be> which chnages the layout for the
>     code.

This patch is based on Laurants work (peXXigen.c cvs version 1.7) and(1) on the
patch in
http://www.cygwin.com/ml/cygwin-apps/2002-05/msg00346.html, which fixes some
additional seg fault fixes relating to auto-import.
It is called "objdump_ai_segfault_2.patch" on the top of this mail and is also
based on Laurants work.

So this is the way:

1. apply objdump_ai_segfault_2 patch

2. apply objdump_no_double_import_table_printing patch.

I have send patch (1) to binutils and cygwin-apps, but unfortunally noone has
checked this in.



>   * It appears that although the statement:
>
>       fprintf (file, _("\tvma:  Hint/Ord Member-Name\n"));
>
>     implies that a member name will be printed, if the top bit of the
>     VMA is set, no name is output:
>
>       if (member & 0x80000000)
> 	fprintf (file, "\t%04lx\t %4lu", member,
> 		 member & 0x7fffffff);
>
>     This is a problem because your patch changes the fprintf to:
>
>       fprintf (file, _("\tvma:  Hint/Ord Member-Name Bound-To\n"));
>
>     So that readers might confuse the Bound-To address that is printed
>     later on with the (non-existent) Member-Name.  May I suggest that
>     you change the fprintf for when the top bit is set to something
>     like:
>
>       if (member & 0x80000000)
> 	fprintf (file, "\t%04lx\t %4lu  <none>", member,
> 		 member & 0x7fffffff);
>
This make sense
>
>   * Your patch completely eliminates the loop starting:
>
> 	  for (j = 0; j < datasize; j += 4)
>
>     I understand that this is the duplicate information that you are
>     trying to avoid, but what if datasize is greater than 4 ?  Would
>     this not mean that extra information that should be displayed is
>     no longer printed ?
>

This loop does only the check for detecting differences beetwen the hint array
and the import allocation table,

> > One issue may be, printing the line "The Import Address Table is
> > identical" or The Import Address Table (difference are found)",
> > which I have removed, because I currently see no other reasons than
> > on bounded addresses and this is printed explicit. Any comments ?
>
> Given that the Bound-To addresses are being explicitly displayed, I do
> not have a problem with your patch removing this line.
>