This is the mail archive of the cygwin@sourceware.cygnus.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

forwarded message from MDaemon@pruimpit


What's going on here? Did my message get to the list?
------- start of forwarded message (RFC 934 encapsulation) -------
Content-Length: 8611
Received: from holly.cam.harlequin.co.uk (holly.cam.harlequin.co.uk [193.128.4.58]) by propos.long.harlequin.co.uk (8.8.4/8.6.12) with ESMTP id LAA01212 for <jont@mailhost>; Sat, 13 Sep 1997 11:51:11 +0100 (BST)
Received: from smtp1.xs4all.nl (smtp1.xs4all.nl [194.109.6.51])
          by holly.cam.harlequin.co.uk (8.8.4/8.8.4) with ESMTP
	  id LAA00215 for <jont@harlequin.co.uk>; Sat, 13 Sep 1997 11:51:11 +0100 (BST)
Received: from PRUIMPIT (asd-isdn03-02.dial.xs4all.nl [194.109.46.67]) by smtp1.xs4all.nl (8.8.6/XS4ALL) with SMTP id MAA04366 for <jont@harlequin.co.uk>; Sat, 13 Sep 1997 12:50:10 +0200 (MET DST)
Received: from PRUIMPIT [192.9.200.51] by PRUIMPIT [192.9.200.51] with RAW (MDaemon.v2.0.rW.b2.32-R) for <jont@harlequin.co.uk>; Sat, 13 Sep 97 12:42:58 +0100
X-MDSend-Notifications-To: [trash]
Reply-To: MDaemon@PRUIMPIT
Message-ID: <MDAEMON9709131242.AA4258@PRUIMPIT>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Actual-To: jont@harlequin.co.uk
X-Actual-From: MDaemon@PRUIMPIT
X-MDMail-Server: MDaemon v2.0 rW b2 32-R
From: MDaemon@PRUIMPIT
To: jont
Subject: Warning: No Such User!
Date: Sat, 13 Sep 97 12:42:58 +0100

gnu-win32-outgoing@PRUIMPIT - no such user here.

- --ORIGINAL MESSAGE BEGINS--
Received: from pop.xs4all.nl [194.109.6.25] by PRUIMPIT [192.9.200.51] with POP (MDaemon.v2.0.rW.b2.32-R) for <gnu-win32-outgoing@PRUIMPIT>; Sat, 13 Sep 97 12:15:55 +0100
Received: from smtp1.xs4all.nl (smtp1.xs4all.nl [194.109.6.51]) by magigimmix.xs4all.nl (8.8.6/XS4ALL) with ESMTP id VAA00264 for <jelleb@xs4all.nl>; Sun, 7 Sep 1997 21:33:20 +0200 (MET DST)
Received: from nf2.netforward.com (nf2.netforward.com [204.57.67.146]) by smtp1.xs4all.nl (8.8.6/XS4ALL) with ESMTP id VAA21803 for <jelleb@xs4all.nl>; Sun, 7 Sep 1997 21:33:12 +0200 (MET DST)
X-Forwarder: NetForward.com
Received: (from daemon@localhost)
	by cygnus.com (8.8.5/8.8.5) id GAA09698
	for gnu-win32-outgoing; Wed, 3 Sep 1997 06:38:41 -0700 (PDT)
Received: from holly.cam.harlequin.co.uk (holly.cam.harlequin.co.uk [193.128.4.58])
	by cygnus.com (8.8.5/8.8.5) with ESMTP id GAA09693
	for <gnu-win32@cygnus.com>; Wed, 3 Sep 1997 06:38:09 -0700 (PDT)
Received: from propos.long.harlequin.co.uk (propos.long.harlequin.co.uk [193.128.93.50])
          by holly.cam.harlequin.co.uk (8.8.4/8.8.4) with ESMTP
	  id OAA07412 for <gnu-win32@cygnus.com>; Wed, 3 Sep 1997 14:37:59 +0100 (BST)
Received: from zaphod.long.harlequin.co.uk (zaphod.long.harlequin.co.uk [193.128.93.30]) by propos.long.harlequin.co.uk (8.8.4/8.6.12) with SMTP id OAA29564; Wed, 3 Sep 1997 14:37:27 +0100 (BST)
Received: by zaphod.long.harlequin.co.uk (SMI-8.6) id OAA03966; Wed, 3 Sep 1997 14:33:08 +0100
Date: Wed, 3 Sep 1997 14:33:08 +0100
Message-Id: <199709031333.OAA03966@zaphod.long.harlequin.co.uk>
From: Jon Thackray <jont@harlequin.co.uk>
To: gnu-win32@cygnus.com
Subject: b18 linker problems
Sender: owner-gnu-win32@cygnus.com
Precedence: bulk
X-UIDL: 4f71c84cf185f73f3e65ebb1d0a3a30b
Status: N 
X-MDMail-Server: MDaemon v2.0 rW b2 32-R
X-MDaemon-Deliver-To: gnu-win32-outgoing@PRUIMPIT

It seems that the b18 linker does incorrect things with pc relative
relocation to symbols not in the .text section (or more specifically
not in section 0, as will be revealed later). The following email
contains a number of exhibits demonstrating the problem, and where I
think it lies. First is a small assembler program demonstrating the
problem. The problem can be shown under as if there is a pc relative
relocation to a symbol not in the .text section, as in the example
below. If one rearranges the sections by replaacing .text with .text$i
and vice versa then all is ok. A language translator which does not
place its text in section 0 may also encounter the problem. I include
three outputs from objdump of the link of this program. The first link
was done with a raw b18 and demonstrates the problem. The second link
was done using b17 ld, and shows that the problem is a regression. The
third link is done with a version of ld that I have modified to
produce a fix for the problem.

The problem seems to lie in a combination of
_bfd_coff_generic_relocate_section within cofflink.c and
coff_i386_rtype_to_howto in coff-i386.c I include annotated code from
cofflink.c and coff-i386.c demonstrating where I think the problem
lies.

	.section	.text$i
	.global	foo1
	.global	foo2
foo1:	mov	$0, %eax
	ret
foo2:	mov	$1, %eax
	ret
	.text
	.global	main
	.global	foo1
	.global	foo2
main:	call	foo1
	call	foo2
	mov	$0, %eax
	ret

with b18 ld

bash$ objdump --disassemble foo.exe

foo.exe:     file format pei-i386

Disassembly of section .text:

00401000 <main>:
     0:	e8 1b 00 00 00 	call   00401020 <etext+4>
     5:	e8 1c 00 00 00 	call   00401026 <etext+a>
     a:	b8 00 00 00 00 	movl   $0x0,%eax
     f:	c3             	ret    

00401010 <foo1>:
     0:	b8 00 00 00 00 	movl   $0x0,%eax
     5:	c3             	ret    

00401016 <foo2>:
     0:	b8 01 00 00 00 	movl   $0x1,%eax
     5:	c3             	ret    

0040101c <etext>:
	...

with b17 ld

objdump --disassemble foo.exe

foo.exe:     file format pei-i386

Disassembly of section .text:

00401000 <main>:
     0:	e8 0b 00 00 00 	call   00401010 <foo1>
     5:	e8 0c 00 00 00 	call   00401016 <foo2>
     a:	b8 00 00 00 00 	movl   $0x0,%eax
     f:	c3             	ret    

00401010 <foo1>:
     0:	b8 00 00 00 00 	movl   $0x0,%eax
     5:	c3             	ret    

00401016 <foo2>:
     0:	b8 01 00 00 00 	movl   $0x1,%eax
     5:	c3             	ret    

0040101c <etext>:
	...

After modifying b18

objdump --disassemble foo.exe

foo.exe:     file format pei-i386

Disassembly of section .text:

00401000 <main>:
     0:	e8 0b 00 00 00 	call   00401010 <foo1>
     5:	e8 0c 00 00 00 	call   00401016 <foo2>
     a:	b8 00 00 00 00 	movl   $0x0,%eax
     f:	c3             	ret    

00401010 <foo1>:
     0:	b8 00 00 00 00 	movl   $0x0,%eax
     5:	c3             	ret    

00401016 <foo2>:
     0:	b8 01 00 00 00 	movl   $0x1,%eax
     5:	c3             	ret    

0040101c <etext>:
	...

Annotated excerpt from bfd/coff-i386.c (annotations within C style
comments)

static reloc_howto_type *
coff_i386_rtype_to_howto (abfd, sec, rel, h, sym, addendp)
     bfd *abfd;
     asection *sec;
     struct internal_reloc *rel;
     struct coff_link_hash_entry *h;
     struct internal_syment *sym;
     bfd_vma *addendp;
{

  reloc_howto_type *howto;

  howto = howto_table + rel->r_type;

#ifdef COFF_WITH_PE
  *addendp = 0;  /* For gun-win32 on the PC, this will happen */
#endif

  if (howto->pc_relative)
    *addendp += sec->vma;

  if (sym != NULL && sym->n_scnum == 0 && sym->n_value != 0)
    {
      /* This is a common symbol.  The section contents include the
	 size (sym->n_value) as an addend.  The relocate_section
	 function will be adding in the final value of the symbol.  We
	 need to subtract out the current size in order to get the
	 correct result.  */
 
      BFD_ASSERT (h != NULL);


#ifndef COFF_WITH_PE
      /* I think we *do* want to bypass this.  If we don't, I have seen some data
	 parameters get the wrong relcation address.  If I link two versions
	 with and without this section bypassed and then do a binary comparison,
	 the addresses which are different can be looked up in the map.  The 
	 case in which this section has been bypassed has addresses which correspond
	 to values I can find in the map */
      *addendp -= sym->n_value;
#endif
    }

  /* If the output symbol is common (in which case this must be a
     relocateable link), we need to add in the final size of the
     common symbol.  */
  if (h != NULL && h->root.type == bfd_link_hash_common) 
    *addendp += h->root.u.c.size;


#ifdef COFF_WITH_PE
  if (howto->pc_relative)
    *addendp -= 4; /* This will also happen */

  if (rel->r_type == R_IMAGEBASE)
    {
      *addendp -= pe_data(sec->output_section->owner)->pe_opthdr.ImageBase;
    }
#endif

  return howto;
}

Annotated excerpt from bfd/cofflink.c (annotations within C style
comments)

      if (sym != NULL && sym->n_scnum != 0)
	addend = - sym->n_value;
      else
	addend = 0;

/* In the example case, addend is assigned the value -sym->n_value.
 * However, this is irrelevant because howto overwites the value of
 * addend to be -4 (to deal with the fact that the 386 computes
 * pc-relative addresses from the start of the next instruction,
 * whereas the address we'll subtract out later will be the address at
 * which the relocation takes place, ie 4 less). In the modified
 * example, where the section names are switched, addend is simply set
 * to zero.
 */
      howto = bfd_coff_rtype_to_howto (input_bfd, input_section, rel, h,
				       sym, &addend);
      if (howto == NULL)
	return false;

      /* If we are doing a relocateable link, then we can just ignore
         a PC relative reloc that is pcrel_offset.  It will already
         have the correct value.  If this is not a relocateable link,
         then we should ignore the symbol value.  */
      if (howto->pc_relative && howto->pcrel_offset)
	{
	  if (info->relocateable)
	    continue;
	  if (sym != NULL && sym->n_scnum != 0)
	    addend += sym->n_value;

/* This would undo the earlier subtraction, except that howto has
 * junked the result. The overall effect is that we end up pointing
 * to an address which is too large by an amount equal to the symbol
 * value.
 */
	}

A simple fix for the above is to leave out the two modifications of
addend by sym->n_value. This produces the corect result for the
example code above, and also for the code I was originally trying to
link. However, I suspect there is more to this than meets my eye.
- -
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".


------- end -------
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]