bug-binutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Bug in linker for Win32.


From: Eric Youngdale
Subject: RE: Bug in linker for Win32.
Date: Mon, 15 Dec 2003 16:09:48 -0500


        It has been many years since I have submitted anything for binutils (1997 is the last ChangeLog entry that I see with my name on it), so my recollection of the preferred format is a bit hazy.  For now I am operating on the assumption that the default formatting that Emacs uses is the preferred format (most of the time I have to override the damned thing, as in my day job I have a completely different formatting convention that I prefer to use).

        Anyways, as best I can tell it was the comment formatting that was out of spec.  I have fixed that plus the problem of obj files getting renamed.  If there is something else I am missing, feel free to let me know, or point me at the current coding standard.

        Does anyone know who handles gdb bug reports?  I sent something to bug-gdb, but that mailing list is choked with spam and I have no idea whether anyone monitors it or not.

-Eric

*** pe.em.~1~ Sun Dec  7 11:23:31 2003
--- pe.em Mon Dec 15 15:43:23 2003
***************
*** 1113,1118 ****
--- 1113,1119 ----
      int is_ms_arch = 0;
      bfd *cur_arch = 0;
      lang_input_statement_type *is2;
+     lang_input_statement_type *is3;
 
      /* Careful - this is a shell script.  Watch those dollar signs! */
      /* Microsoft import libraries have every member named the same,
***************
*** 1127,1147 ****
        {
        if (is->the_bfd->my_archive)
          {
            bfd *arch = is->the_bfd->my_archive;
            if (cur_arch != arch)
              {
                cur_arch = arch;
                is_ms_arch = 1;
!               for (is2 = is;
!                    is2 && is2->the_bfd->my_archive == arch;
!                    is2 = (lang_input_statement_type *)is2->next)
                  {
!                   if (strcmp (is->the_bfd->filename, is2->the_bfd->filename))
!                     is_ms_arch = 0;
                  }
              }
 
!           if (is_ms_arch)
              {
                int idata2 = 0, reloc_count=0;
                asection *sec;
--- 1128,1185 ----
        {
        if (is->the_bfd->my_archive)
          {
+           char * pnt;
            bfd *arch = is->the_bfd->my_archive;
            if (cur_arch != arch)
              {
                cur_arch = arch;
                is_ms_arch = 1;
!               for (is3 = is;
!                    is3 && is3->the_bfd->my_archive == arch;
!                    is3 = (lang_input_statement_type *)is3->next)
                  {
!                       pnt = strrchr(is3->the_bfd->filename, '.');
!                       /* A MS dynamic import library can also contain static members,
!                          so look for the first element with a .dll extension, and use
!                          that for the remainder of the comparisons. */
!                       if( pnt != NULL && strcmp(pnt, ".dll") != 0 )
!                         {
!                           continue;
!                         }
!                       /* OK, found one.  Now make sure the remainder are consistent. */
!                       for (is2 = is;
!                            is2 && is2->the_bfd->my_archive == arch;
!                            is2 = (lang_input_statement_type *)is2->next)
!                         {
!                           /* A MS dynamic import library can also contain static members,
!                              so looking for archive members that have names other than the
!                              one we are processing is bound to fail.  As a heuristic
!                              to help with this, we ignore elements with a .obj extension. */
!                           pnt = strrchr(is2->the_bfd->filename, '.');
!                           if( pnt != NULL && strcmp(pnt, ".obj") == 0 )
!                             {
!                               continue;
!                             }
!                          
!                           if (strcmp (is3->the_bfd->filename, is2->the_bfd->filename))
!                             {
!                               is_ms_arch = 0;
!                             }
!                         }
!                       break;
                  }
+               if( is3 == NULL )
+                 {
+                   is_ms_arch = 0;
+                 }
              }
 
!           /* This fragment might have come from an .obj file in a Microsoft import,
!              and not an actual import record. If this is the case, then leave
!              the filename alone. */
!           pnt = strrchr(is->the_bfd->filename, '.');
!
!           if (is_ms_arch && (strcmp(pnt, ".dll") == 0))
              {
                int idata2 = 0, reloc_count=0;
                asection *sec;


-----Original Message-----
From: Nick Clifton [mailto:address@hidden]
Sent: Monday, December 15, 2003 2:16 PM
To: address@hidden
Cc: address@hidden
Subject: Re: Bug in linker for Win32.


Hi Eric,

>        I have been poking at the ld/bfd sources to try and figure
>    out what the fault is, and have traced it to the function
>    gld_i386pe_after_open(), in ei386pe.c (which is a generated
>    source file).  Essentially there is extra magic that takes place
>    for Microsoft import libraries to make sure that the .idata$[2,3,4]
>    sections are properly sorted, and the presence of the .obj
>    files causes this section of code to decide that the library
>    isn't a Microsoft import library, and hence the hack isn't
>    required.
>
>        For my testcase, the enclosed patch does work, but I haven't
>    tested much beyond this however.  The patch is a bit on the ugly
>    side - it is on the conservative side I suppose in that I am not
>    sure what harm there would be in mistakenly concluding that we
>    have a Microsoft import library.

The patch does not look too bad.  if you can tidy up the formatting
and resubmit it I will approve it.


>       In fact, there is a harmless nit whereby the object files
>    that are included appear as foo.obj.b in the linker map.  Doesn't
>    hurt anything, but I suppose I ought to fix it before any patch
>    is official.

That would be good, although I would not consider it to be a priority.

Cheers
        Nick
       


reply via email to

[Prev in Thread] Current Thread [Next in Thread]