public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Pedro Alves <pedro_alves@portugalmail.pt>
To: binutils@sourceware.org
Subject: Re: puzzled - old release works, newer doesn't
Date: Tue, 25 Apr 2006 21:15:00 -0000	[thread overview]
Message-ID: <444E6DA9.1060406@portugalmail.pt> (raw)
In-Reply-To: <444E5ABD.8070209@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 5071 bytes --]

Nick Clifton wrote:
> Hi Danny,
>
>> The old environment is based on gcc 3.4.2, gas 2.13.2, binutils 2.15.
>> (Yes there's a mixup there.) The new environment is using gcc 4.1 and
>> binutils 2.16. In all versions, the target platform is "arm-wince-pe".
>>
>> The person who created this distribution explains the mixup by saying
>> that the GAS from 2.13 works, whereas the one in newer binutils doesn't.
>>
>> My personal experience with the 2.16 release appears to confirm that.
>
> Are you upgrading to the new GCC new GAS and new LD all at the same 
> time ?  If not then that might be the cause.
>
> Are you aware of the --support-old-code linker switch which is 
> specific to the arm-wince-pe target ?  Using this might help you.
>
> Using the latest binutils sources from CVS repository might also help. 
> If not then I would recommend comparing a disassembly of a working 
> binary and broken binary to see where there are changes.  (Do not 
> compare the object files, but linked binaries.  This should allow you 
> to find out how relocs may have been processed differently).
>
> Cheers
>   Nick
>
Here is a patch that "fixes" the differences between  binutils cvs 
20050202 and  cvs head. Probably I got it all wrong, but at least it
shows where the differences are. It fix most of the differences, but 
here is still something in the dll generation that produces quite
some differences. I am still looking into it.

That TE_WINCE addition is there because I didn't take the time yet to 
find the correct place. Any hints where that should be?

Mind you, the both the 20050202 and the head versions I tested with, 
have quite a few more patches applied.
This is just the portion that tries to fix the differences. It should 
also fix them for a pristine cvs version.
Attached is the tar.gz with the tests I used, inspired on Danny's tests.

Particularly, compiling this file (in the tar.gz) shows all the 
differences I could find.

    .global    _ctype_
    .text
    .global    global_sym
    .def    global_sym;    .scl    2;    .type    32;    .endef

_ctype_:
    .word    _ctype_+7

global_sym:
def_sym:
undef_sym:
    nop
    nop
    nop
    b    global_sym
    bl    global_sym
    beq    global_sym
    b    def_sym
    bl    def_sym
    beq    def_sym
    b    undef_sym
    bl    undef_sym
    ldr    r0, global_sym
    ldr    r0, def_sym
    ldr    r0, undef_sym

Cheers,
Pedro Alves

Index: gas/config/tc-arm.c
===================================================================
RCS file: /cvs/src/src/gas/config/tc-arm.c,v
retrieving revision 1.256
diff -u -r1.256 tc-arm.c
--- gas/config/tc-arm.c    7 Apr 2006 15:11:19 -0000    1.256
+++ gas/config/tc-arm.c    25 Apr 2006 15:52:17 -0000
@@ -11182,8 +11182,12 @@
      then we just want to put out any pipeline compensation that the linker
      will need.  Otherwise we want to use the calculated base.  */
   if (fixP->fx_pcrel
-      && ((fixP->fx_addsy && S_GET_SEGMENT (fixP->fx_addsy) != seg)
-      || arm_force_relocation (fixP)))
+    && ((fixP->fx_addsy && S_GET_SEGMENT (fixP->fx_addsy) != seg)
+#ifdef TE_WINCE
+    || (!S_IS_EXTERNAL (fixP->fx_addsy) && arm_force_relocation (fixP))))
+#else
+    || arm_force_relocation (fixP)))
+#endif
     base = 0;
 
   switch (fixP->fx_r_type)
@@ -11220,7 +11224,19 @@
     case BFD_RELOC_ARM_PCREL_BLX:
     case BFD_RELOC_ARM_PLT32:
 #ifdef TE_WINCE
-      return base;
+      /*
+       * When handling fixups immediately, because we have already
+       * discovered the value of a symbol, or the address of the frag 
involved
+       * we must account for the offset by +8, as the OS loader will 
never see the reloc.
+       * see fixup_segment() in write.c
+       * The S_IS_EXTERNAL test handles the case of global symbols.
+       * Those need the calculated base, not just the pipe compensation 
the linker will need.
+      */
+      if (fixP->fx_pcrel && fixP->fx_addsy && (S_GET_SEGMENT 
(fixP->fx_addsy) == seg)
+        && (S_IS_EXTERNAL (fixP->fx_addsy) || !arm_force_relocation 
(fixP)))
+        return base + 8;
+      else
+        return base;
 #else
       return base + 8;
 #endif
@@ -12107,10 +12123,16 @@
     case BFD_RELOC_ARM_ROSEGREL32:
     case BFD_RELOC_ARM_SBREL32:
     case BFD_RELOC_32_PCREL:
+#ifdef TE_WINCE
+      if (seg->use_rela_p && !fixP->fx_done)
+        break;
+      if (fixP->fx_done || fixP->fx_pcrel)
+        md_number_to_chars (buf, value, 4);
+#else
       if (fixP->fx_done || !seg->use_rela_p)
     md_number_to_chars (buf, value, 4);
+#endif
       break;
-
 #ifdef OBJ_ELF
     case BFD_RELOC_ARM_PREL31:
       if (fixP->fx_done || !seg->use_rela_p)
Index: gas/config/te-pe.h
===================================================================
RCS file: /cvs/src/src/gas/config/te-pe.h,v
retrieving revision 1.2
diff -u -r1.2 te-pe.h
--- gas/config/te-pe.h    6 Nov 2002 19:36:19 -0000    1.2
+++ gas/config/te-pe.h    25 Apr 2006 15:52:24 -0000
@@ -1,3 +1,4 @@
+#define TE_WINCE
 #define TE_PE
 #define LEX_AT (LEX_BEGIN_NAME | LEX_NAME) /* Can have @'s inside 
labels.  */
 


[-- Attachment #2: binutils-hunt.tar.gz --]
[-- Type: application/gzip, Size: 18872 bytes --]

  reply	other threads:[~2006-04-25 19:20 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-04-11 23:06 Danny Backx
2006-04-25 17:39 ` Nick Clifton
2006-04-25 21:15   ` Pedro Alves [this message]
2006-04-27  2:23     ` Pedro Alves
2006-04-27  1:32   ` Danny Backx

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=444E6DA9.1060406@portugalmail.pt \
    --to=pedro_alves@portugalmail.pt \
    --cc=binutils@sourceware.org \
    /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).