RE: question about objdump output format ?
> Regardless, basic patch management would dictate that you provide > patches against plain CVS. You shouldn't expect maintainers to apply > unrelated patches in order to check your changes in. > ... but the segfault patch is pending and the removing duplicate line patch makes no sense (in true it does not work) without th segfault patches. So what should I do ? The is a possibility, I can merge both patches and submit it as one, but this infringe a rule, that patches should cover only single issues because of easier testing, isn't it ? So should I merge the patches or what should I do ? Regards Ralf
Re: question about objdump output format ?
On Tue, May 28, 2002 at 01:24:24PM +0200, Ralf Habacker wrote: >> 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 <[EMAIL PROTECTED]> >> > >> > * 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 >> <[EMAIL PROTECTED]> 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. I was waiting for success reports from someone besides you. Regardless, basic patch management would dictate that you provide patches against plain CVS. You shouldn't expect maintainers to apply unrelated patches in order to check your changes in. cgf
RE: question about objdump output format ?
> 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 <[EMAIL PROTECTED]>
> >
> > * 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
> <[EMAIL PROTECTED]> 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 & 0x8000)
> fprintf (file, "\t%04lx\t %4lu", member,
>member & 0x7fff);
>
> 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 & 0x8000)
> fprintf (file, "\t%04lx\t %4lu ", member,
>member & 0x7fff);
>
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.
>
RE: question about objdump output format ?
Ralf Habacker > -Original Message- > From: [EMAIL PROTECTED] > Hi Ralf, Hi Robert, > > > > Oops. I missed that. If you made (1) look like the following, I have no > > > obbjection to (2) going: >> > > > > vma: Hint/Ord Member-Name Bound-To > > > 181798844 _7QString$null 5ff556b8 (1) > > > > > I will change this, but let us see what Nick Clifton say about this > > Please go ahead and generate and submit a patch. > > Cheers > Nick Here is the patch. It is based on the "objdump_ai_segfault_2.patch", which I have send in before. Changelog entry for bfd dir -- 2002-05-22 Ralf Habacker <[EMAIL PROTECTED]> * 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 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 thant on bounded adresses and this is printed explicit. Any comments ? Regards Ralf objdump_no_double_import_table_printing.patch Description: Binary data
RE: question about objdump output format ?
> > -Original Message- > > From: Ralf Habacker [mailto:[EMAIL PROTECTED]] > > Sent: Friday, May 24, 2002 8:02 PM > > To: Robert Collins; Cygwin-Apps; Binutils > > Subject: RE: question about objdump output format ? > > > > > > > > A side effect of this is, that objdump > > > > prints each line twice (the second line contains no additional > > > > infos), which blows up listing on bigger libs (for example about > > > > 35000 lines of 100860 for the kdecore dll from kde 2.2.2), so my > > > > question is, are there any objections for removing this ? > > > > > > > > 001540f0 0017f218 00189390 3934 > > > > > > > > DLL Name: qt-2-3.dll > > > > vma: Hint/Ord Member-Name > > > > 181798844 _7QString$null 5ff556b8 (1) > > > ... > > > > 5ff556b8 844 _7QString$null (2) > > > > > > Yes, it is providing differnet information. The extra info is the > > > bound address, and thus should not be removed. > > > > > But this is printed already in line (1), so line (2) gives no > > more informations > > Oops. I missed that. If you made (1) look like the following, I have no > obbjection to (2) going: > > vma: Hint/Ord Member-Name Bound-To > 181798844 _7QString$null 5ff556b8 (1) > I will change this, but let us see what Nick Clifton say about this Ralf
RE: question about objdump output format ?
> -Original Message- > From: Ralf Habacker [mailto:[EMAIL PROTECTED]] > Sent: Friday, May 24, 2002 8:02 PM > To: Robert Collins; Cygwin-Apps; Binutils > Subject: RE: question about objdump output format ? > > > > > A side effect of this is, that objdump > > > prints each line twice (the second line contains no additional > > > infos), which blows up listing on bigger libs (for example about > > > 35000 lines of 100860 for the kdecore dll from kde 2.2.2), so my > > > question is, are there any objections for removing this ? > > > > > > 001540f0 0017f218 00189390 3934 > > > > > > DLL Name: qt-2-3.dll > > > vma: Hint/Ord Member-Name > > > 181798844 _7QString$null 5ff556b8 (1) > > ... > > > 5ff556b8 844 _7QString$null (2) > > > > Yes, it is providing differnet information. The extra info is the > > bound address, and thus should not be removed. > > > But this is printed already in line (1), so line (2) gives no > more informations Oops. I missed that. If you made (1) look like the following, I have no obbjection to (2) going: vma: Hint/Ord Member-Name Bound-To 181798844 _7QString$null 5ff556b8 (1) Rob
RE: question about objdump output format ?
> Hi Ralf, > > > Hi all, > > > > the windows runtime linker allows rebinding of dll's and exe for > which I have > > written a tool currently located on the kde-cygwin project on > > http://sourceforge.net/project/showfiles.php?group_id=27249. > > > > A side effect of this is, that objdump prints each line twice (the > second line > > contains no additional infos), which blows up listing on bigger libs (for > > example about 35000 lines of 100860 for the kdecore dll from kde > 2.2.2), so my > > question is, are there any objections for removing this ? > > Err, sorry, I do not quite understand your question. What is it that > you are asking to remove ? > DLL Name: qt-2-3.dll vma: Hint/Ord Member-Name 181798844 _7QString$null 5ff556b8 (1) The Import Address Table (difference found) vma: Hint/Ord Member-Name 5ff556b8 844 _7QString$null (2) line (1) contains all information which is printed in (2), so line (2) seems to be obsolate for me. Regards Ralf
RE: question about objdump output format ?
> > A side effect of this is, that objdump > > prints each line twice (the second line contains no > > additional infos), which blows up listing on bigger libs (for > > example about 35000 lines of 100860 for the kdecore dll from > > kde 2.2.2), so my question is, are there any objections for > > removing this ? > > > > 001540f0 0017f218 00189390 3934 > > > > DLL Name: qt-2-3.dll > > vma: Hint/Ord Member-Name > > 181798844 _7QString$null 5ff556b8 (1) > ... > > 5ff556b8 844 _7QString$null (2) > > Yes, it is providing differnet information. The extra info is the bound > address, and thus should not be removed. > But this is printed already in line (1), so line (2) gives no more informations Ralf
RE: question about objdump output format ?
> -Original Message- > From: Ralf Habacker [mailto:[EMAIL PROTECTED]] > Sent: Friday, May 24, 2002 7:19 AM > To: Cygwin-Apps; Binutils > Subject: question about objdump output format ? > > > Hi all, > > the windows runtime linker allows rebinding of dll's and exe > for which I have written a tool currently located on the > kde-cygwin project on > http://sourceforge.net/project/showfiles.php?> group_id=27249. > > > A side effect of this is, that objdump > prints each line twice (the second line contains no > additional infos), which blows up listing on bigger libs (for > example about 35000 lines of 100860 for the kdecore dll from > kde 2.2.2), so my question is, are there any objections for > removing this ? > > 001540f0 0017f218 00189390 3934 > > DLL Name: qt-2-3.dll > vma: Hint/Ord Member-Name > 181798844 _7QString$null 5ff556b8 ... > 5ff556b8 844 _7QString$null Yes, it is providing differnet information. The extra info is the bound address, and thus should not be removed. ROb
