public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Christopher Faylor <cgf@redhat.com>
To: Binutils <binutils@sources.redhat.com>
Subject: Re: objdump/cygwin crashes on auto-imported libs
Date: Mon, 15 Apr 2002 10:32:00 -0000	[thread overview]
Message-ID: <20020415173229.GA12664@redhat.com> (raw)
In-Reply-To: <00e901c19756$476668c0$865c07d5@BRAMSCHE>

Out of curiousity, was this problem ever resolved?

cgf

On Mon, Jan 07, 2002 at 09:35:36AM +0100, Ralf Habacker wrote:
>I have encountered a bug in objdump relating to the new auto-import stuff.
>Objdumping a dll containing symbols, which could be auto-imported works, but objdumping a dll
>which uses auto-imported vars from another lib let objdump crashes.
>
>For detailed information see the appended thread from the cygwiwn mailing list. Appended is a
>testcase, which uses the cygncurses6.dll from cygwin to show how this will fail. It seems
>that in peigen.c:pe_print_idata() while printing the imported symbols the code to access the
>dll internal data structure doesn't work.
>
>Is there anybody on this list, who can fix this bug ?
>
>Regards
>Ralf
>
>> > On Fri, Dec 28, 2001 at 12:50:07PM +0100, Ralf Habacker wrote:
>> > >> -----Original Message-----
>> > >> From: Jason Tishler [mailto:jason@tishler.net]
>> > >> On Wed, Dec 26, 2001 at 09:08:49PM +0100, Ralf Habacker wrote:
>> > >> > On analysing this problem I added an option "-l" to the rebase tool to
>> > >> > list dll's imagebase and -size without rebasing. It's very interesting
>> > >> > to see how MS chooses there Imagebase.
>> > >>
>> > >> What about the following alternative solution:
>> > >>
>> > >>     $ objdump -p foo.dll | egrep '(ImageBase|SizeOfImage)'
>> > >>     ImageBase               68000000
>> > >>     SizeOfImage             0003f000
>> > >
>> > >Try it with a recent objdump and a dll with auto-import variables and you will see that
>> > >objdump crashes. :-(
>> >
>> > Seems to work fine with the distributed version of binutils.  I tried
>> > this with cygncurses6.dll.
>
>Yes this work, because this lib provides an auto-importable var. But try a lib which depends
>on this lib, than objdump will fail with a segment violation.
>This is an example from cygkdecore-3.dll (the kdecore dll of kde 2.2.1) which uses
>qt-2.3.dll, which exports such auto-importable vars
>....
> 001530b4       0017dfd4 00000000 00000000 0018814c 00002b13
>
>        DLL Name: qt-2-3.dll
>        vma:  Hint/Ord Member-Name
>        180554    842  _7QString$null
>
>Program received signal SIGSEGV, Segmentation fault.
>bfd_getl32 (addr=0xa011928 "??\"") at libbfd.c:1059
>1059    libbfd.c: No such file or directory.
>        in libbfd.c
>(gdb) bt
>#0  bfd_getl32 (addr=0xa011928 "??\"") at libbfd.c:1059
>#1  0x0045bccf in _bfd_pe_print_private_bfd_data_common (abfd=0xa011928,
>    vfile=0x6109f25c) at peigen.c:1846
>#2  0x0043cc94 in pe_print_private_bfd_data (abfd=0xa011928, vfile=0x6109f25c)
>    at peicode.h:365
>#3  0x0040557d in dump_bfd_private_header (abfd=0xa011928) at ./objdump.c:2029
>#4  0x00405693 in dump_bfd (abfd=0xa011928) at ./objdump.c:2059
>#5  0x0040591c in display_bfd (abfd=0xa011928) at ./objdump.c:2140
>#6  0x00405a75 in display_file (
>    filename=0x22feae "/opt/kde2/bin/cygkdecore-3.dll", target=0x0)
>    at ./objdump.c:2195
>#7  0x004074a6 in main (argc=3, argv=0xa0118c8) at ./objdump.c:2942
>#8  0x61003f6e in dll_crt0_1 () at ../../../src/winsup/cygwin/dcrt0.cc:769
>#9  0x61004262 in _dll_crt0 () at ../../../src/winsup/cygwin/dcrt0.cc:863
>#10 0x610042a1 in dll_crt0 (uptr=0x0)
>    at ../../../src/winsup/cygwin/dcrt0.cc:876
>#11 0x00487bcf in cygwin_crt0 ()
>#12 0x0040103d in mainCRTStartup ()
>#13 0x77e892a6 in _system_dlls__ ()
>
>0xa011928:      0x0022feae
>0xa01192c:      0x00440fd4
>0xa011930:      0x0a011764
>0xa011934:      0x00000001
>0xa011938:      0x00000001
>0xa01193c:      0x0a011928
>0xa011940:      0x0a011928
>0xa011944:      0x00184600
>0xa011948:      0x00000000
>0xa01194c:      0x00000000
>0xa011950:      0x00000000
>0xa011954:      0x00000000
>0xa011958:      0x00000001
>0xa01195c:      0x00000001
>0xa011960:      0x00000133
>0xa011964:      0x00000000
>
>The following is an extract of a debugging session.
>
>(gdb) c
>Continuing.
>        The Import Address Table is identical
>
> 001530b4       0017dfd4 00000000 00000000 0018814c 00002b13
>
>        DLL Name: qt-2-3.dll
>        vma:  Hint/Ord Member-Name
>        180554    842  _7QString$null
>Breakpoint 6, pe_print_idata (abfd=0xa011928, vfile=0x6109f25c)
>    at peigen.c:1222
>1222          if (hint_addr != first_thunk && time_stamp == 0)
>(gdb) n
>1227              idx2 = first_thunk - adj;
>(gdb)
>1224              int differ = 0;
>(gdb)
>1227              idx2 = first_thunk - adj;
>(gdb)
>1229              for (j = 0; j < datasize; j += 4)
>(gdb)
>1233                  bfd_vma hint_member = 0;
>(gdb)
>1236                  if (hint_addr != 0)
>(gdb)
>1237                    hint_member = bfd_get_32 (abfd, data + idx + j);
>(gdb)
>1238                  iat_member = bfd_get_32 (abfd, data + idx2 + j);
>(gdb)
>Program received signal SIGSEGV, Segmentation fault.
>bfd_getl32 (addr=0xa011928 "??\"") at libbfd.c:1059
>1059      v |= (unsigned long) addr[1] << 8;

      reply	other threads:[~2002-04-15 17:32 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <002801c19047$5fa26300$0e6307d5@BRAMSCHE>
2002-01-07  1:02 ` Ralf Habacker
2002-04-15 10:32   ` Christopher Faylor [this message]

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=20020415173229.GA12664@redhat.com \
    --to=cgf@redhat.com \
    --cc=binutils@sources.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).