bug-gnu-utils
[Top][All Lists]
Advanced

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

problem with fill on IA64 linker


From: Lowney, Geoff
Subject: problem with fill on IA64 linker
Date: Wed, 13 Feb 2002 13:57:19 -0800

                                                2/13/02

I am using GNU ld version 2.11.2 (with BFD 2.11.2) on a IA64 (Itanium)
Linux system.  I am writing a binary optimizer for IA64 and have a
small problem with linker.

The fill is -1 (0xffffffff), which does not not decode to valid
instructions.  I would like the fill to be 0, which decodes to a
series of break instructions.

There appear to be several problems in processing the fill on IA64.

  - There is a bug in the parsing of the default linker script.  The
    fill is set to 0x00300000010070000002000001000400.  However, the
    lexer uses bfd_scan_vma to read the fill value, and it cannot read
    a value that is greater than ULONG_MAX.  In a native linker,
    bfd_scan_vms calls strtoul to lex the string, and it returns -1.

  - The back end processing (default_fill_link_order) is only prepared
    to handle a 2-byte fill value.

  - The string 0x00300000010070000002000001000400 appears to decode to
    three nops (unless I have made an endian mistake, see example below).
    I would prefer to use a break, rather than a nop, because the fill
    code should be unreachable. 

I would recommend that we change the fill to 0, which is the default.
This can happen by dropping the NOP definition from elf64_ia64.sh.  
Can we agree to do this?  A patch to comment out the NOP defintion
is at the end of this message.

Here are some possible fill values. 

shli0001-62> cat pad.s
        .section .text
        .align 32

                // NOP=0x00300000010070000002000001000400  

        data8 0x0002000001000400
        data8 0x0030000001007000
        
                // try reversing bytes to see if this makes it better
        data8 0x0070000100003000
        data8 0x0004000100000200

                // -1           
        data8 -1
        data8 -1

                // 0
        data8 0
        data8 0

                // endian check 0x00112233445566778899aabbccddeeff
        
        data8 0x8899aabbccddeeff
        data8 0x0011223344556677


        data8 0x7766554433221100
        data8 0xffeeddccbbaa9988

shli0001-63> gcc -c pad.s

shli0001-64> objdump -d -z pad.o

pad.o:     file format elf64-ia64-little

objdump: pad.o: no symbols
Disassembly of section .text:

0000000000000000 <.text>:
   0:   00 04 00 01 00 00       [MII] (p32) break.m 0x2000
   6:   02 00 00 70 00 01                   data8 0x1c0000008
   c:   00 00 30 00                         data8 0x060000002
  10:   00 30 00 00 01 00       [MII]       nop.m 0x6
  16:   70 00 00 02 00 00                   nop.i 0x7
  1c:   01 00 04 00                         nop.i 0x8
  20:   ff ff ff ff ff ff       [-f-]       data8 0x1ffffffffff
  26:   ff ff ff ff ff ff                   data8 0x1ffffffffff
  2c:   ff ff ff ff                         data8 0x1ffffffffff
  30:   00 00 00 00 00 00       [MII]       break.m 0x0
  36:   00 00 00 00 00 00                   break.i 0x0
  3c:   00 00 00 00                         break.i 0x0
  40:   ff ee dd cc bb aa       [-f-]       data8 0x155de66ef77
  46:   99 88 77 66 55 44                   data8 0x15599de2266
  4c:   33 22 11 00                         data8 0x022446688
  50:   00 11 22 33 44 55       [MII]       data8 0xaa21991088
  56:   66 77 88 99 aa bb                   data8 0xaa6621dd99
  5c:   cc dd ee ff                         data8 0x1ffddbb9977


shli0001-65> objdump -s --section=.text pad.o

pad.o:     file format elf64-ia64-little

Contents of section .text:
 0000 00040001 00000200 00700001 00003000  .........p....0.
 0010 00300000 01007000 00020000 01000400  .0....p.........
 0020 ffffffff ffffffff ffffffff ffffffff  ................
 0030 00000000 00000000 00000000 00000000  ................
 0040 ffeeddcc bbaa9988 77665544 33221100  ........wfUD3"..
 0050 00112233 44556677 8899aabb ccddeeff  .."3DUfw........
shli0001-66> 

--------------
patch to comment out NOP definition in linker script

*** old/elf64_ia64.sh   Tue Feb 13 18:10:22 2001
--- new/elf64_ia64.sh   Wed Feb 13 09:17:00 2002
***************
*** 9,15 ****
  TEXT_START_ADDR="0x4000000000000000"
  DATA_ADDR="0x6000000000000000 + (. & (${MAXPAGESIZE} - 1))"
  GENERATE_SHLIB_SCRIPT=yes
! NOP=0x00300000010070000002000001000400  # a bundle full of nops
  OTHER_GOT_SECTIONS='.IA_64.pltoff : { *(.IA_64.pltoff) }'
  OTHER_PLT_RELOC_SECTIONS='.rela.IA_64.pltoff : { *(.rela.IA_64.pltoff) }'
  OTHER_READONLY_SECTIONS='.opd : { *(.opd) }  .IA_64.unwind_info : {
*(.IA_64.unwind_info*) }  .IA_64.unwind : { *(.IA_64.unwind*) }'
--- 9,15 ----
  TEXT_START_ADDR="0x4000000000000000"
  DATA_ADDR="0x6000000000000000 + (. & (${MAXPAGESIZE} - 1))"
  GENERATE_SHLIB_SCRIPT=yes
! # NOP=0x00300000010070000002000001000400  # a bundle full of nops
  OTHER_GOT_SECTIONS='.IA_64.pltoff : { *(.IA_64.pltoff) }'
  OTHER_PLT_RELOC_SECTIONS='.rela.IA_64.pltoff : { *(.rela.IA_64.pltoff) }'
  OTHER_READONLY_SECTIONS='.opd : { *(.opd) }  .IA_64.unwind_info : {
*(.IA_64.unwind_info*) }  .IA_64.unwind : { *(.IA_64.unwind*) }'





reply via email to

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