public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: hjl@lucon.org (H.J. Lu)
To: drepper@ipd.info.uni-karlsruhe.de
Cc: egcs@cygnus.com, gcc2@cygnus.com
Subject: Re: the dynamic linker bug
Date: Fri, 12 Dec 1997 01:52:00 -0000	[thread overview]
Message-ID: <m0xgPyA-0004ecC@ocean.lucon.org> (raw)
In-Reply-To: <x73ejz120d.fsf@myware.rz.uni-karlsruhe.de>

> 
> Hi,
> 
> I describe here what I found out.  I cannot produce a small test case
> but I can compare two assembler outputs and explain the context with
> the sources.  All this is on ix86.  At then end of the mail is the
> preprocessed source.  You have to run
> 
> 	gcc /tmp/dl-reloc.i -Wall -c -O3 -g -momit-leaf-frame-pointer -mpentium  -fPIC -fno-common -o dl-reloc.o
> 
> 
> I tried to remove the -Wall but this changes the result!!!!!
> 
> 
> The critical part of the code is compiled using the current CVS egcs
> version (ok, the CVS version as of yesterday):
> 
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>  2d7:   89 45 b0        movl   %eax,0xffffffb0(%ebp)
>  2da:   83 bd 50 ff ff  cmpl   $0x0,0xffffff50(%ebp)
>  2df:   ff 00 
>  2e1:   74 35           je     318 <_dl_relocate_object+0x318>
>  2e3:   8b 8d 50 ff ff  movl   0xffffff50(%ebp),%ecx
>  2e8:   ff 
>  2e9:   83 79 04 00     cmpl   $0x0,0x4(%ecx)
>  2ed:   74 29           je     318 <_dl_relocate_object+0x318>
>  2ef:   52              pushl  %edx
>  2f0:   51              pushl  %ecx
>  2f1:   8b 7d c8        movl   0xffffffc8(%ebp),%edi
>  2f4:   8b 57 fc        movl   0xfffffffc(%edi),%edx
>  2f7:   8b 02           movl   (%edx),%eax
>  2f9:   8b 40 04        movl   0x4(%eax),%eax
>  2fc:   50              pushl  %eax
>  2fd:   8b 42 04        movl   0x4(%edx),%eax
>  300:   50              pushl  %eax
>  301:   8d 45 e8        leal   0xffffffe8(%ebp),%eax
>  304:   50              pushl  %eax
>  305:   8b 45 e8        movl   0xffffffe8(%ebp),%eax
>  308:   8b 00           movl   (%eax),%eax
>  30a:   03 47 f8        addl   0xfffffff8(%edi),%eax
>  30d:   50              pushl  %eax
>  30e:   e8 fc ff ff ff  call   30f <_dl_relocate_object+0x30f>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> Using an older version 2.90.15 I get:
> 
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>  2d7:   89 45 b0        movl   %eax,0xffffffb0(%ebp)
>  2da:   83 bd 50 ff ff  cmpl   $0x0,0xffffff50(%ebp)
>  2df:   ff 00 
>  2e1:   74 35           je     318 <_dl_relocate_object+0x318>
>  2e3:   8b 8d 50 ff ff  movl   0xffffff50(%ebp),%ecx
>  2e8:   ff 
>  2e9:   83 79 04 00     cmpl   $0x0,0x4(%ecx)
>  2ed:   74 29           je     318 <_dl_relocate_object+0x318>
>  2ef:   52              pushl  %edx
>  2f0:   51              pushl  %ecx
>  2f1:   8b 7d c8        movl   0xffffffc8(%ebp),%edi
>  2f4:   8b 57 fc        movl   0xfffffffc(%edi),%edx
>  2f7:   8b 02           movl   (%edx),%eax
>  2f9:   8b 40 04        movl   0x4(%eax),%eax
>  2fc:   50              pushl  %eax
>  2fd:   8b 42 04        movl   0x4(%edx),%eax
>  300:   50              pushl  %eax
>  301:   8d 45 e8        leal   0xffffffe8(%ebp),%eax
>  304:   50              pushl  %eax
>  305:   8b 4d b0        movl   0xffffffb0(%ebp),%ecx
>  308:   8b 01           movl   (%ecx),%eax
>  30a:   03 47 f8        addl   0xfffffff8(%edi),%eax
>  30d:   50              pushl  %eax
>  30e:   e8 fc ff ff ff  call   30f <_dl_relocate_object+0x30f>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> The critical instruction is at address 305.  You see the difference
> 
> wrong:		 305:   8b 45 e8        movl   0xffffffe8(%ebp),%eax
> 
> correct:	 305:   8b 4d b0        movl   0xffffffb0(%ebp),%ecx
> 
> 
> The other key location is 2d7 where is both pieces of code 0xffffffb0(%ebp)
> is initialized.
> 
> 
> Looking at the source code you'll see this implements the following
> (function elf_machine_rel, a bit reformatted):
> 
> 
>       const Elf32_Sym *const refsym = sym;
>       Elf32_Addr value = ((  version ) != ((void *)0)
> 			  && (  version )->hash != 0
>     ? _dl_lookup_versioned_symbol (strtab + (* &sym )->st_name,
> 			           ( &sym ), scope, l->l_name,
>                                    (  version ), (  (( reloc->r_info ) & 0xff)  ))
>     : _dl_lookup_symbol (strtab + (* &sym )->st_name, ( &sym ), scope,
>                          l->l_name, (  (( reloc->r_info ) & 0xff)  ))) ;
> 
> 
> The call is too `_dl_lookup_versioned_symbol' ad the parameter we are
> dealing with is the first which is computed as
> 
> 	strtab + (* &sym )->st_name
> 
> Please note that the second parameter is `&sym'.
> 
> Back to the assembler code: Obviously at address 30a the value of
> `strtab' is added.  The `st_name' element of `Elf32_Sym' is the first,
> i.e., the
> 
> 	movl   (%ecx),%eax
> 
> if the dereference of the pointer.  But this means the %ecx (or %eax
> in the wrong code, both solutions are equivalent here) has to be the
> pointer `sym'.  This value is loaded at address 305.
> 
> In the correct case it is loaded from 0xffffffb0(%ebp) which was
> initialized at address 2d7.
> 
> 
> But in the wrong case %eax is loaded from 0xffffffe8(%ebp).  Please
> note that this is the address which was pushed for the second
> parameter before.  The error is that at address 2d7 the value at
> address 0xffffffb0(%ebp) is initialized, as for the correct version.
> But this does not mean anything but that at address 305 uninitialized
> memory is read.
> 
> 
> So the problem is: why is at address 305 0xffffffe8(%ebp) read and not
> 0xffffffb0(%ebp)?
> 

That is one of 2 bugs. 16(%ebp), which is the third argument of
_dl_relocate_object (), is mixed up with -24(%ebp).


H.J.

  reply	other threads:[~1997-12-12  1:52 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1997-12-12  3:55 Ulrich Drepper
1997-12-12  1:52 ` H.J. Lu [this message]
     [not found] <9712121305.AA19929@vlsi1.ultra.nyu.edu>
1997-12-12 14:32 ` Ulrich Drepper
1997-12-12 15:46   ` H.J. Lu
     [not found] <19308.881955381@hurl.cygnus.com>
1997-12-12 15:46 ` H.J. Lu

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=m0xgPyA-0004ecC@ocean.lucon.org \
    --to=hjl@lucon.org \
    --cc=drepper@ipd.info.uni-karlsruhe.de \
    --cc=egcs@cygnus.com \
    --cc=gcc2@cygnus.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).