about Reloc Type: BFD_RELOC_8/16/32

[daniel tian]

hi, everyone:
     I have question about the relocation types BFD_RELOC_8/16/32. I
don't understand those type yet.
     After adding the parameter "-g" into gcc, there are lots of data
generated from gcc, and I guess this is for debug.
     Here are pieces of those code, like the following:
$Lframe0:
        .4byte $LECIE0-$LSCIE0
$LSCIE0:
        .4byte 0xffffffff
        .byte 0x1
        .ascii "\000"
        .uleb128 0x1
        .sleb128 -4
        .byte 0x1f
        .byte 0xc
        .uleb128 0x1d
        .uleb128 0x0
        .align 2
$LECIE0:
$LSFDE0:
        .4byte $LEFDE0-$LASFDE0
$LASFDE0:
        .4byte $Lframe0
        .4byte $LFB2
        .4byte $LFE2-$LFB2
        .byte 0x4
        .4byte $LCFI0-$LFB2
        .byte 0xe
        .uleb128 0x20
        .byte 0x4
        .4byte $LCFI2-$LCFI0
        .byte 0x9e
        .uleb128 0x2
        .byte 0x9f
        .uleb128 0x1
        .byte 0x4
        .4byte $LCFI3-$LCFI2
        .byte 0xc
        .uleb128 0x1e
        .uleb128 0x20
        .align 2
$LEFDE0:
        .align 0
        .text
$Letext0:
        .section .debug_loc,"",@progbits
$Ldebug_loc0:
$
......

And the " .4byte $LECIE0-$LSCIE0" code will cause the function
"emit_expr_fix" in read.c.
This is where generate the relocation type "BFD_RELOC_8/16/32", I just
don't know what those relocation is.
I don't think those things have something to do with the program. I
guess this is for gdb(or any other debug tool).
BY THE WAY, I have already finished the relocation part in BFD which
will deal with the relocation in JMP/CALL instructions.
But those relocation type I mentioned have nothinng to do with FLOW
CONTROL instructions, so I was eally confused by those things.



Can your guys give me some advice how I could deal with those things.
Or where I could find references for further study.

Thanks very much.

[Nick Clifton]

Hi Daniel,

>      After adding the parameter "-g" into gcc, there are lots of data
> generated from gcc, and I guess this is for debug.

Correct.

> And the " .4byte $LECIE0-$LSCIE0" code will cause the function
> "emit_expr_fix" in read.c.
> This is where generate the relocation type "BFD_RELOC_8/16/32", I just
> don't know what those relocation is.

OK, what these relocations say is that a 8-bit, 16-bit or 32-bit value
needs to be inserted at the location pointed to by the reloc.  The value
to be inserted is the value/address of the symbol associated with the
reloc, plus whatever addend the reloc may have.  The value is an
absolute value, not a PC relative one.

It is not clear however why gas should be generating one of these relocs
for the ".4byte $LECIE0 - $LSCIE0" expression.  Normally they are only
generated when one symbol is involved, not two.  Usually the difference
of two symbols in the same section can be computed at assembly time, so
there is no need to generate a reloc to resolve the expression at link
time.  The exception to this is ports which perform link-time relaxation
where the addresses of symbols in the same section could change because
of changes in code size.

Cheers
   Nick

[daniel tian]

2009/10/28 Nick Clifton <nickc@...>:

> Hi Daniel,
>
>>     After adding the parameter "-g" into gcc, there are lots of data
>> generated from gcc, and I guess this is for debug.
>
> Correct.
>
>> And the " .4byte        $LECIE0-$LSCIE0" code will cause the function
>> "emit_expr_fix" in read.c.
>> This is where generate the relocation type "BFD_RELOC_8/16/32", I just
>> don't know what those relocation is.
>
> OK, what these relocations say is that a 8-bit, 16-bit or 32-bit value needs
> to be inserted at the location pointed to by the reloc.  The value to be
> inserted is the value/address of the symbol associated with the reloc, plus
> whatever addend the reloc may have.  The value is an absolute value, not a
> PC relative one.
>
> It is not clear however why gas should be generating one of these relocs for
> the ".4byte $LECIE0 - $LSCIE0" expression.  Normally they are only generated
> when one symbol is involved, not two.  Usually the difference of two symbols
> in the same section can be computed at assembly time, so there is no need to
> generate a reloc to resolve the expression at link time.  The exception to
> this is ports which perform link-time relaxation where the addresses of
> symbols in the same section could change because of changes in code size.
>
> Cheers
>  Nick
>

Thanks.
Is there any reference (like howto manual) tells me how to deal with
those kind of symbol?
like this:
        .file "test_lib.c"
        .section .mdebug.abi32
        .section .debug_abbrev,"",@progbits
.Ldebug_abbrev0:
        .section .debug_info,"",@progbits
.Ldebug_info0:
        .section .debug_line,"",@progbits
.Ldebug_line0:

There is relocation symbol ".debug_abbrev", how do I resolve this type
of relocation?

Or just leave them. Because now I haven't ported gdb yet.

Any suggestion is appreciation.
Thanks very much.
                                                                    daniel.tian

[Nick Clifton]

Hi Daniel,

> Is there any reference (like howto manual) tells me how to deal with
> those kind of symbol?

Not really. :-(  There are manuals that you can buy which cover how
linkers work, but if you have already implemented relocations for
function calls then you probably know most of that stuff already.  I can
recommend Ian Lance Taylor's blogs on how linkers work, especially these
two:

   http://www.airs.com/blog/archives/39
   http://www.airs.com/blog/archives/43

> like this:
> .file "test_lib.c"
> .section .mdebug.abi32
> .section .debug_abbrev,"",@progbits
> .Ldebug_abbrev0:
> .section .debug_info,"",@progbits
> .Ldebug_info0:
> .section .debug_line,"",@progbits
> .Ldebug_line0:
>
> There is relocation symbol ".debug_abbrev", how do I resolve this type
> of relocation?

Can you provide a full example of the problem that you are trying to
resolve ?  Ie please include details of the target you are working with,
the command lines that you use to assemble and disassemble the test
case, and the output showing the relocs.

It sounds to me like you have a bug in your backend code for gas
somewhere that is making it generate relocations when there is no need.
  Perhaps you can compare your backend code with the code for another
(similar) target to see where they differ.

Cheers
   Nick

[Ian Lance Taylor-3]

daniel tian <daniel.xntian@...> writes:

> Is there any reference (like howto manual) tells me how to deal with
> those kind of symbol?
> like this:
> .file "test_lib.c"
> .section .mdebug.abi32
> .section .debug_abbrev,"",@progbits
> .Ldebug_abbrev0:
> .section .debug_info,"",@progbits
> .Ldebug_info0:
> .section .debug_line,"",@progbits
> .Ldebug_line0:
>
> There is relocation symbol ".debug_abbrev", how do I resolve this type
> of relocation?

The question as written doesn't make much sense to me.  .debug_abbrev
is the name of a section, not a relocation.

You may well see relocations involving a subtraction between some
symbol and .Ldebug_abbrev0.  That will only happen if the other symbol
is in the .debug_abbrev section.  That kind of calculation can be made
by the assembler at assembly time, and does not involve a relocation.

Ian

[DJ Delorie-2]

Ian Lance Taylor <iant@...> writes:
> You may well see relocations involving a subtraction between some
> symbol and .Ldebug_abbrev0.  That will only happen if the other symbol
> is in the .debug_abbrev section.  That kind of calculation can be made
> by the assembler at assembly time, and does not involve a relocation.

One exception is targets that support linker relaxation - they may have
a "difference of symbols" reloc so that the difference can be adjusted
after linker relaxation is done.

[daniel tian]

2009/10/29 Nick Clifton <nickc@...>:

> Hi Daniel,
>
>> Is there any reference (like howto manual) tells me how to deal with
>> those kind of symbol?
>
> Not really. :-(  There are manuals that you can buy which cover how linkers
> work, but if you have already implemented relocations for function calls
> then you probably know most of that stuff already.  I can recommend Ian
> Lance Taylor's blogs on how linkers work, especially these two:
>
>  http://www.airs.com/blog/archives/39
>  http://www.airs.com/blog/archives/43
>

Yeah. I finished the JMP/CALL relocation.  Because there is really a
small Instruction Mem and Data Mem in my chip. So 16bit relocation is
enough. and I didn't resolve the 32bit relocation, and even don't let
generate this kind of relocation symbol.
Here is a integeral  assemble:

        .file "test_lib.c"
        .section .mdebug.abi32
        .section .debug_abbrev,"",@progbits
.Ldebug_abbrev0:
        .section .debug_info,"",@progbits
.Ldebug_info0:
        .section .debug_line,"",@progbits
.Ldebug_line0:
        .text
.Ltext0:
        .globl __extendsfdf2
        .globl __truncdfsf2
        .align 4
        .globl main
        .type main, @function
main:
.LFB2:
.LM1:
        STOREW R14 (R15) #4  -PRD
        MOV R0 LINK
        STOREW R0 (R14) #8  -PRD
        ADD R15 R15 #-32
        MOV R14 R15
.LM2:
        MOVI #0 -L
        MOVI #16320 -U
        STOREW R0 (R14) #20  -PRI
.LM3:
        LOADW R4   (R14) #20  -PRI
        CALL @__extendsfdf2 -D0
        MOV R4 R2
        MOV R5 R3
        STOREW R4 (R15)  #0  -PRI
        STOREW R5 (R15) #4  -PRI
        CALL @asin -D0
        MOV R4 R2
        MOV R5 R3
        STOREW R4 (R15) #8  -PRI
        STOREW R5 (R15) #12  -PRI
        CALL @__truncdfsf2 -D0
        MOV R4 R2
        STOREW R4 (R14) #16  -PRI
.LM4:
        MOV R4 #0
        MOV R2 R4
.LM5:
        ADD R15 R14 #32
        LOADW R14   (R15) #4  -PRD
        LOADW R0   (R15) #8  -PRD
        MOV LINK R0
        RETURN -D0
.LFE2:
        .size main, .-main
        .section .debug_frame,"",@progbits
.Lframe0:
        .4byte .LECIE0-.LSCIE0
.LSCIE0:
        .4byte 0xffffffff
        .byte 0x1
        .string ""
        .uleb128 0x1
        .sleb128 -4
        .byte 0x1f
        .byte 0xc
        .uleb128 0xf
        .uleb128 0x0
        .align 4
.LECIE0:
.LSFDE0:
        .4byte .LEFDE0-.LASFDE0
.LASFDE0:
        .4byte .Lframe0
        .4byte .LFB2
        .4byte .LFE2-.LFB2
        .align 4
.LEFDE0:
        .text
.Letext0:
        .section .debug_info
        .4byte 0xb7
        .2byte 0x2
        .4byte .Ldebug_abbrev0
        .byte 0x4
        .uleb128 0x1
        .4byte .LASF13
        .byte 0x1
        .4byte .LASF14
        .4byte .LASF15
        .4byte .Ltext0
        .4byte .Letext0
        .4byte .Ldebug_line0
        .uleb128 0x2
        .byte 0x1
        .byte 0x6
        .4byte .LASF0
        .uleb128 0x2
        .byte 0x1
        .byte 0x8
        .4byte .LASF1
        .uleb128 0x2
        .byte 0x2
        .byte 0x5
        .4byte .LASF2
        .uleb128 0x2
        .byte 0x2
        .byte 0x7
        .4byte .LASF3
        .uleb128 0x3
        .byte 0x4
        .byte 0x5
        .string "int"
        .uleb128 0x2
        .byte 0x4
        .byte 0x7
        .4byte .LASF4
        .uleb128 0x2
        .byte 0x8
        .byte 0x5
        .4byte .LASF5
        .uleb128 0x2
        .byte 0x8
        .byte 0x7
        .4byte .LASF6
        .uleb128 0x2
        .byte 0x4
        .byte 0x5
        .4byte .LASF7
        .uleb128 0x4
        .byte 0x4
        .byte 0x7
        .uleb128 0x2
        .byte 0x4
        .byte 0x7
        .4byte .LASF8
        .uleb128 0x2
        .byte 0x1
        .byte 0x6
        .4byte .LASF9
        .uleb128 0x2
        .byte 0x8
        .byte 0x4
        .4byte .LASF10
        .uleb128 0x2
        .byte 0x4
        .byte 0x4
        .4byte .LASF11
        .uleb128 0x2
        .byte 0x8
        .byte 0x4
        .4byte .LASF12
        .uleb128 0x5
        .byte 0x1
        .4byte .LASF16
        .byte 0x1
        .byte 0x3
        .byte 0x1
        .4byte 0x41
        .4byte .LFB2
        .4byte .LFE2
        .byte 0x1
        .byte 0x5f
        .uleb128 0x6
        .string "x"
        .byte 0x1
        .byte 0x4
        .4byte 0x7c
        .byte 0x2
        .byte 0x7e
        .sleb128 20
        .uleb128 0x6
        .string "y"
        .byte 0x1
        .byte 0x4
        .4byte 0x7c
        .byte 0x2
        .byte 0x7e
        .sleb128 16
        .byte 0x0
        .byte 0x0
        .section .debug_abbrev
        .uleb128 0x1
        .uleb128 0x11
        .byte 0x1
        .uleb128 0x25
        .uleb128 0xe
        .uleb128 0x13
        .uleb128 0xb
        .uleb128 0x3
        .uleb128 0xe
        .uleb128 0x1b
        .uleb128 0xe
        .uleb128 0x11
        .uleb128 0x1
        .uleb128 0x12
        .uleb128 0x1
        .uleb128 0x10
        .uleb128 0x6
        .byte 0x0
        .byte 0x0
        .uleb128 0x2
        .uleb128 0x24
        .byte 0x0
        .uleb128 0xb
        .uleb128 0xb
        .uleb128 0x3e
        .uleb128 0xb
        .uleb128 0x3
        .uleb128 0xe
        .byte 0x0
        .byte 0x0
        .uleb128 0x3
        .uleb128 0x24
        .byte 0x0
        .uleb128 0xb
        .uleb128 0xb
        .uleb128 0x3e
        .uleb128 0xb
        .uleb128 0x3
        .uleb128 0x8
        .byte 0x0
        .byte 0x0
        .uleb128 0x4
        .uleb128 0x24
        .byte 0x0
        .uleb128 0xb
        .uleb128 0xb
        .uleb128 0x3e
        .uleb128 0xb
        .byte 0x0
        .byte 0x0
        .uleb128 0x5
        .uleb128 0x2e
        .byte 0x1
        .uleb128 0x3f
        .uleb128 0xc
        .uleb128 0x3
        .uleb128 0xe
        .uleb128 0x3a
        .uleb128 0xb
        .uleb128 0x3b
        .uleb128 0xb
        .uleb128 0x27
        .uleb128 0xc
        .uleb128 0x49
        .uleb128 0x13
        .uleb128 0x11
        .uleb128 0x1
        .uleb128 0x12
        .uleb128 0x1
        .uleb128 0x40
        .uleb128 0xa
        .byte 0x0
        .byte 0x0
        .uleb128 0x6
        .uleb128 0x34
        .byte 0x0
        .uleb128 0x3
        .uleb128 0x8
        .uleb128 0x3a
        .uleb128 0xb
        .uleb128 0x3b
        .uleb128 0xb
        .uleb128 0x49
        .uleb128 0x13
        .uleb128 0x2
        .uleb128 0xa
        .byte 0x0
        .byte 0x0
        .byte 0x0
        .section .debug_pubnames,"",@progbits
        .4byte 0x17
        .2byte 0x2
        .4byte .Ldebug_info0
        .4byte 0xbb
        .4byte 0x8a
        .string "main"
        .4byte 0x0
        .section .debug_aranges,"",@progbits
        .4byte 0x1c
        .2byte 0x2
        .4byte .Ldebug_info0
        .byte 0x4
        .byte 0x0
        .2byte 0x0
        .2byte 0x0
        .4byte .Ltext0
        .4byte .Letext0-.Ltext0
        .4byte 0x0
        .4byte 0x0
        .section .debug_line
        .4byte .LELT0-.LSLT0
.LSLT0:
        .2byte 0x2
        .4byte .LELTP0-.LASLTP0
.LASLTP0:
        .byte 0x1
        .byte 0x1
        .byte 0xf6
        .byte 0xf5
        .byte 0xa
        .byte 0x0
        .byte 0x1
        .byte 0x1
        .byte 0x1
        .byte 0x1
        .byte 0x0
        .byte 0x0
        .byte 0x0
        .byte 0x1
        .byte 0x0
        .string "test_lib.c"
        .uleb128 0x0
        .uleb128 0x0
        .uleb128 0x0
        .byte 0x0
.LELTP0:
        .byte 0x0
        .uleb128 0x5
        .byte 0x2
        .4byte .LM1
        .byte 0x16
        .byte 0x0
        .uleb128 0x5
        .byte 0x2
        .4byte .LM2
        .byte 0x16
        .byte 0x0
        .uleb128 0x5
        .byte 0x2
        .4byte .LM3
        .byte 0x15
        .byte 0x0
        .uleb128 0x5
        .byte 0x2
        .4byte .LM4
        .byte 0x15
        .byte 0x0
        .uleb128 0x5
        .byte 0x2
        .4byte .LM5
        .byte 0x15
        .byte 0x0
        .uleb128 0x5
        .byte 0x2
        .4byte .Letext0
        .byte 0x0
        .uleb128 0x1
        .byte 0x1
.LELT0:
        .section .debug_str,"MS",@progbits,1
.LASF5:
        .string "long long int"
.LASF4:
        .string "unsigned int"
.LASF15:
        .string "/home/daniel.tian/gcc_rice_dev/rice-binutils/rice-gcc-test"
.LASF8:
        .string "long unsigned int"
.LASF6:
        .string "long long unsigned int"
.LASF11:
        .string "float"
.LASF9:
        .string "char"
.LASF1:
        .string "unsigned char"
.LASF16:
        .string "main"
.LASF7:
        .string "long int"
.LASF10:
        .string "double"
.LASF3:
        .string "short unsigned int"
.LASF0:
        .string "signed char"
.LASF12:
        .string "long double"
.LASF13:
        .string "GNU C 4.3.0"
.LASF2:
        .string "short int"
.LASF14:
        .string "test_lib.c"
        .ident "GCC: (GNU) 4.3.0"

> Can you provide a full example of the problem that you are trying to resolve
> ?  Ie please include details of the target you are working with, the command
> lines that you use to assemble and disassemble the test case, and the output
> showing the relocs.
>
> It sounds to me like you have a bug in your backend code for gas somewhere
> that is making it generate relocations when there is no need.  Perhaps you
> can compare your backend code with the code for another (similar) target to
> see where they differ.
>

Yes, you are right. Now I am cracking the CRX BFD.

Here is the detail of what I target did.
gas only generates the relocation type:
1.BFD_RELOC_RICE_REL_14_JMP:
   Most of this relocation type is local resolved. like for/while
statement in c language will generate JMP instruction.
2.BFD_RELOC_RICE_REL_14_CALL:
  This relocation type is global, and only will be resolved in link
time(in BFD backend, function "elf_backend_relocate_section" will take
care of this part at link time).
3.BFD_RELOC_RICE_REL_16:
  This relocation type I defined is also global. Like: move the
function address (Or data symbol_ref) into a register, then CALL
instruction will call the function with the register (or access the
data memory with this register). So this type also will be resolved at
link time in function "elf_backend_relocate_section"

But when I debug the as and ld with insight, there were some
relocation types which I have mentioned in former email
(BFD_RELOC_8/16/32, mostly BFD_RELOC_32), I didn't take care in
function "elf_backend_relocate_section". Yeah. I check the gas(the
code I wrote) missed those relocation type, they just generated
without any of my processing(I don't know how to handle it due to this
part of relocation confusing me.).

there are mainly two functions I used to deal with relocation
type:md_apply_fix, and tc_gen_reloc.
No relaxation did right now.

I run the as simply: rice-elf-as test-lib.s -o test-lib.o

Here is the data dump with command rice-elf-readelf -a:

ELF Header:
  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
  Class:                             ELF32
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              REL (Relocatable file)
  Machine:                           MavrixTech.Inc RICE microprocessor
  Version:                           0x1
  Entry point address:               0x0
  Start of program headers:          0 (bytes into file)
  Start of section headers:          1112 (bytes into file)
  Flags:                             0x0
  Size of this header:               52 (bytes)
  Size of program headers:           0 (bytes)
  Number of program headers:         0
  Size of section headers:           40 (bytes)
  Number of section headers:         22
  Section header string table index: 19

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] .text             PROGBITS        00000000 000034 000074 00  AX  0   0  4
  [ 2] .rela.text        RELA            00000000 00091c 000024 0c     20   1  4
  [ 3] .data             PROGBITS        00000000 0000a8 000000 00  WA  0   0  1
  [ 4] .bss              NOBITS          00000000 0000a8 000000 00  WA  0   0  1
  [ 5] .mdebug.abi32     PROGBITS        00000000 0000a8 000000 00      0   0  1
  [ 6] .debug_abbrev     PROGBITS        00000000 0000a8 000059 00      0   0  1
  [ 7] .debug_info       PROGBITS        00000000 000101 0000bb 00      0   0  1
  [ 8] .rela.debug_info  RELA            00000000 000940 000114 0c     20   7  4
  [ 9] .debug_line       PROGBITS        00000000 0001bc 000077 00      0   0  1
  [10] .rela.debug_line  RELA            00000000 000a54 000048 0c     20   9  4
  [11] .debug_frame      PROGBITS        00000000 000234 000020 00      0   0  4
  [12] .rela.debug_frame RELA            00000000 000a9c 000018 0c     20  11  4
  [13] .debug_pubnames   PROGBITS        00000000 000254 00001b 00      0   0  1
  [14] .rela.debug_pubna RELA            00000000 000ab4 00000c 0c     20  13  4
  [15] .debug_aranges    PROGBITS        00000000 00026f 000020 00      0   0  1
  [16] .rela.debug_arang RELA            00000000 000ac0 000018 0c     20  15  4
  [17] .debug_str        PROGBITS        00000000 00028f 0000f9 01  MS  0   0  1
  [18] .comment          PROGBITS        00000000 000388 000012 00      0   0  1
  [19] .shstrtab         STRTAB          00000000 00039a 0000be 00      0   0  1
  [20] .symtab           SYMTAB          00000000 0007c8 000120 10     21  14  4
  [21] .strtab           STRTAB          00000000 0008e8 000031 00      0   0  1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings)
  I (info), L (link order), G (group), x (unknown)
  O (extra OS processing required) o (OS specific), p (processor specific)

There are no section groups in this file.

There are no program headers in this file.

Relocation section '.rela.text' at offset 0x91c contains 3 entries:
 Offset     Info    Type            Sym.Value  Sym. Name + Addend
00000024  00000e07 R_RICE_REL14_CALL 00000000   __extendsfdf2 + 0
00000038  00001107 R_RICE_REL14_CALL 00000000   asin + 0
0000004c  00000f07 R_RICE_REL14_CALL 00000000   __truncdfsf2 + 0

Relocation section '.rela.debug_info' at offset 0x940 contains 23 entries:
 Offset     Info    Type            Sym.Value  Sym. Name + Addend
00000006  00000603 R_RICE_32         00000000   .debug_abbrev + 0
0000000c  00000c03 R_RICE_32         00000000   .debug_str + d8
00000011  00000c03 R_RICE_32         00000000   .debug_str + ee
00000015  00000c03 R_RICE_32         00000000   .debug_str + 1b
00000019  00000203 R_RICE_32         00000000   .text + 0
0000001d  00000203 R_RICE_32         00000000   .text + 74
00000021  00000803 R_RICE_32         00000000   .debug_line + 0
00000028  00000c03 R_RICE_32         00000000   .debug_str + c0
0000002f  00000c03 R_RICE_32         00000000   .debug_str + 8a
00000036  00000c03 R_RICE_32         00000000   .debug_str + e4
0000003d  00000c03 R_RICE_32         00000000   .debug_str + ad
0000004b  00000c03 R_RICE_32         00000000   .debug_str + e
00000052  00000c03 R_RICE_32         00000000   .debug_str + 0
00000059  00000c03 R_RICE_32         00000000   .debug_str + 68
00000060  00000c03 R_RICE_32         00000000   .debug_str + 9d
0000006a  00000c03 R_RICE_32         00000000   .debug_str + 56
00000071  00000c03 R_RICE_32         00000000   .debug_str + 85
00000078  00000c03 R_RICE_32         00000000   .debug_str + a6
0000007f  00000c03 R_RICE_32         00000000   .debug_str + 7f
00000086  00000c03 R_RICE_32         00000000   .debug_str + cc
0000008c  00000c03 R_RICE_32         00000000   .debug_str + 98
00000097  00000203 R_RICE_32         00000000   .text + 0
0000009b  00000203 R_RICE_32         00000000   .text + 74

Relocation section '.rela.debug_line' at offset 0xa54 contains 6 entries:
 Offset     Info    Type            Sym.Value  Sym. Name + Addend
0000002b  00000203 R_RICE_32         00000000   .text + 0
00000033  00000203 R_RICE_32         00000000   .text + 14
0000003b  00000203 R_RICE_32         00000000   .text + 20
00000043  00000203 R_RICE_32         00000000   .text + 58
0000004b  00000203 R_RICE_32         00000000   .text + 60
00000053  00000203 R_RICE_32         00000000   .text + 74

Relocation section '.rela.debug_frame' at offset 0xa9c contains 2 entries:
 Offset     Info    Type            Sym.Value  Sym. Name + Addend
00000014  00000903 R_RICE_32         00000000   .debug_frame + 0
00000018  00000203 R_RICE_32         00000000   .text + 0

Relocation section '.rela.debug_pubnames' at offset 0xab4 contains 1 entries:
 Offset     Info    Type            Sym.Value  Sym. Name + Addend
00000006  00000703 R_RICE_32         00000000   .debug_info + 0

Relocation section '.rela.debug_aranges' at offset 0xac0 contains 2 entries:
 Offset     Info    Type            Sym.Value  Sym. Name + Addend
00000006  00000703 R_RICE_32         00000000   .debug_info + 0
00000010  00000203 R_RICE_32         00000000   .text + 0

There are no unwind sections in this file.

Symbol table '.symtab' contains 18 entries:
   Num:    Value  Size Type    Bind   Vis      Ndx Name
     0: 00000000     0 NOTYPE  LOCAL  DEFAULT  UND
     1: 00000000     0 FILE    LOCAL  DEFAULT  ABS test_lib.c
     2: 00000000     0 SECTION LOCAL  DEFAULT    1
     3: 00000000     0 SECTION LOCAL  DEFAULT    3
     4: 00000000     0 SECTION LOCAL  DEFAULT    4
     5: 00000000     0 SECTION LOCAL  DEFAULT    5
     6: 00000000     0 SECTION LOCAL  DEFAULT    6
     7: 00000000     0 SECTION LOCAL  DEFAULT    7
     8: 00000000     0 SECTION LOCAL  DEFAULT    9
     9: 00000000     0 SECTION LOCAL  DEFAULT   11
    10: 00000000     0 SECTION LOCAL  DEFAULT   13
    11: 00000000     0 SECTION LOCAL  DEFAULT   15
    12: 00000000     0 SECTION LOCAL  DEFAULT   17
    13: 00000000     0 SECTION LOCAL  DEFAULT   18
    14: 00000000     0 NOTYPE  GLOBAL DEFAULT  UND __extendsfdf2
    15: 00000000     0 NOTYPE  GLOBAL DEFAULT  UND __truncdfsf2
    16: 00000000   116 FUNC    GLOBAL DEFAULT    1 main
    17: 00000000     0 NOTYPE  GLOBAL DEFAULT  UND asin

No version information found in this file.

I wonder the relocation entries (BFD_RELOC_32 mapped to R_RICE_32) in
those section '.rela.debugXXX'  only works in debug tools(e.g: gdb).

The BFD_RELOC_8/16/32 is mapped to R_RICE_8/16/32 in BFD backend.  In
my BFD backend, I also did not process those
relocation types. Like this:
              if ((r_type == R_RICE_REL14_CALL) || (r_type == R_RICE_REL14_JMP))
        {
            Rvalue = Rvalue >> 2;
            Rvalue = (Rvalue & 0x3FF) | ((Rvalue & 0x3C00) << 2);
            Rvalue |=  (bfd_get_32 (input_bfd, hit_data));
                        bfd_put_32 (input_bfd, Rvalue, hit_data);
          //Rvalue |= (((bfd_get_32 (input_bfd, hit_data)) |
                    //  bfd_get_16 (input_bfd, hit_data + 2)) & ~howto->dst_mask);
        }

       else if (r_type == R_RICE_REL16)
        {
        //if contents is code, address will be align 32bit.
        //pc register will ignore the 2bit in lsb.
        if((sec->flags & SEC_CODE))
                                Rvalue = Rvalue >> 2;
                       
        Rvalue = (Rvalue & 0x3FF) | ((Rvalue & 0x1FC00) << 2);
                        Rvalue |=  (bfd_get_32 (input_bfd, hit_data));
          bfd_put_32 (input_bfd, Rvalue, hit_data);
        }
      break;

if never return bfd_reloc_notsupported.

This object file doesn't invoke ld. I just wanna show the relocation
types which I can't understand and how to fix them.
 I built the it with command: rice-elf-gcc test-lib.c -o test-lib -lm
and the following is the readelf dump:
ELF Header:
  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
  Class:                             ELF32
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           MavrixTech.Inc RICE microprocessor
  Version:                           0x1
  Entry point address:               0x0
  Start of program headers:          52 (bytes into file)
  Start of section headers:          61788 (bytes into file)
  Flags:                             0x0
  Size of this header:               52 (bytes)
  Size of program headers:           32 (bytes)
  Number of program headers:         4
  Size of section headers:           40 (bytes)
  Number of section headers:         20
  Section header string table index: 17

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] .text             PROGBITS        00000000 0000b4 002e40 00  AX  0   0  4
  [ 2] .rodata           PROGBITS        80000000 0032fc 000024 00   A  0   0  4
  [ 3] .data             PROGBITS        80000024 002ef4 000408 00  WA  0   0  4
  [ 4] .heap             NOBITS          8000042c 003320 002000 00  WA  0   0  1
  [ 5] .stack            NOBITS          8000242c 003320 006000 00  WA  0   0  1
  [ 6] .istack           NOBITS          8000842c 003320 000100 00  WA  0   0  1
  [ 7] .comment          PROGBITS        00000000 003320 0001e6 00      0   0  1
  [ 8] .debug_aranges    PROGBITS        00000000 003506 0002f0 00      0   0  1
  [ 9] .debug_pubnames   PROGBITS        00000000 0037f6 00036a 00      0   0  1
  [10] .debug_info       PROGBITS        00000000 003b60 004448 00      0   0  1
  [11] .debug_abbrev     PROGBITS        00000000 007fa8 001d17 00      0   0  1
  [12] .debug_line       PROGBITS        00000000 009cbf 002eab 00      0   0  1
  [13] .debug_frame      PROGBITS        00000000 00cb6c 000300 00      0   0  4
  [14] .debug_str        PROGBITS        00000000 00ce6c 000c23 01  MS  0   0  1
  [15] .debug_loc        PROGBITS        00000000 00da8f 001178 00      0   0  1
  [16] .debug_ranges     PROGBITS        00000000 00ec07 000490 00      0   0  1
  [17] .shstrtab         STRTAB          00000000 00f097 0000c3 00      0   0  1
  [18] .symtab           SYMTAB          00000000 00f47c 000610 10     19  46  4
  [19] .strtab           STRTAB          00000000 00fa8c 0002db 00      0   0  1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings)
  I (info), L (link order), G (group), x (unknown)
  O (extra OS processing required) o (OS specific), p (processor specific)

There are no section groups in this file.

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x0000b4 0x00000000 0x00000000 0x02e40 0x02e40 R E 0x4
  LOAD           0x002ef4 0x80000024 0x00002e40 0x00408 0x00408 RW  0x4
  LOAD           0x0032fc 0x80000000 0x80000000 0x00024 0x00024 R   0x4
  LOAD           0x003320 0x8000042c 0x8000042c 0x00000 0x08100 RW  0x1

 Section to Segment mapping:
  Segment Sections...
   00     .text
   01     .data
   02     .rodata
   03     .heap .stack .istack

There is no dynamic section in this file.

There are no relocations in this file.

There are no unwind sections in this file.

Symbol table '.symtab' contains 97 entries:
   Num:    Value  Size Type    Bind   Vis      Ndx Name
     0: 00000000     0 NOTYPE  LOCAL  DEFAULT  UND
     1: 00000000     0 SECTION LOCAL  DEFAULT    1
     2: 80000000     0 SECTION LOCAL  DEFAULT    2
     3: 80000024     0 SECTION LOCAL  DEFAULT    3
     4: 8000042c     0 SECTION LOCAL  DEFAULT    4
     5: 8000242c     0 SECTION LOCAL  DEFAULT    5
     6: 8000842c     0 SECTION LOCAL  DEFAULT    6
     7: 00000000     0 SECTION LOCAL  DEFAULT    7
     8: 00000000     0 SECTION LOCAL  DEFAULT    8
     9: 00000000     0 SECTION LOCAL  DEFAULT    9
    10: 00000000     0 SECTION LOCAL  DEFAULT   10
    11: 00000000     0 SECTION LOCAL  DEFAULT   11
    12: 00000000     0 SECTION LOCAL  DEFAULT   12
    13: 00000000     0 SECTION LOCAL  DEFAULT   13
    14: 00000000     0 SECTION LOCAL  DEFAULT   14
    15: 00000000     0 SECTION LOCAL  DEFAULT   15
    16: 00000000     0 SECTION LOCAL  DEFAULT   16
    17: 00000000     0 FILE    LOCAL  DEFAULT  ABS test_lib.c
    18: 00000000     0 FILE    LOCAL  DEFAULT  ABS w_asin.c
    19: 00000000     0 FILE    LOCAL  DEFAULT  ABS e_asin.c
    20: 00000000     0 FILE    LOCAL  DEFAULT  ABS e_sqrt.c
    21: 00000000     0 FILE    LOCAL  DEFAULT  ABS s_fabs.c
    22: 00000000     0 FILE    LOCAL  DEFAULT  ABS s_isnand.c
    23: 00000000     0 FILE    LOCAL  DEFAULT  ABS s_lib_ver.c
    24: 00000000     0 FILE    LOCAL  DEFAULT  ABS s_matherr.c
    25: 00000000     0 FILE    LOCAL  DEFAULT  ABS s_nan.c
    26: 00000000     0 FILE    LOCAL  DEFAULT  ABS fp-bit.c
    27: 00000000     0 FILE    LOCAL  DEFAULT  ABS dp-bit.c
    28: 000014bc  1448 FUNC    LOCAL  DEFAULT    1 _fpadd_parts
    29: 00000000     0 FILE    LOCAL  DEFAULT  ABS dp-bit.c
    30: 00000000     0 FILE    LOCAL  DEFAULT  ABS dp-bit.c
    31: 00000000     0 FILE    LOCAL  DEFAULT  ABS dp-bit.c
    32: 00000000     0 FILE    LOCAL  DEFAULT  ABS dp-bit.c
    33: 00000000     0 FILE    LOCAL  DEFAULT  ABS dp-bit.c
    34: 00000000     0 FILE    LOCAL  DEFAULT  ABS dp-bit.c
    35: 00000000     0 FILE    LOCAL  DEFAULT  ABS libgcc2.c
    36: 00000000     0 FILE    LOCAL  DEFAULT  ABS libgcc2.c
    37: 00000000     0 FILE    LOCAL  DEFAULT  ABS fp-bit.c
    38: 00000000     0 FILE    LOCAL  DEFAULT  ABS fp-bit.c
    39: 00000000     0 FILE    LOCAL  DEFAULT  ABS dp-bit.c
    40: 00000000     0 FILE    LOCAL  DEFAULT  ABS dp-bit.c
    41: 00000000     0 FILE    LOCAL  DEFAULT  ABS dp-bit.c
    42: 00000000     0 FILE    LOCAL  DEFAULT  ABS fp-bit.c
    43: 00000000     0 FILE    LOCAL  DEFAULT  ABS errno.c
    44: 00000000     0 FILE    LOCAL  DEFAULT  ABS impure.c
    45: 8000002c  1024 OBJECT  LOCAL  DEFAULT    3 impure_data
    46: 000013ac    44 FUNC    GLOBAL DEFAULT    1 fabs
    47: 00002e40     0 NOTYPE  GLOBAL DEFAULT  ABS __DATA_IMAGE_START
    48: 00002278   168 FUNC    GLOBAL DEFAULT    1 __gtdf2
    49: 00002e34    12 FUNC    GLOBAL DEFAULT    1 __errno
    50: 00002320    84 FUNC    GLOBAL DEFAULT    1 __make_dp
    51: 80000024     0 NOTYPE  GLOBAL DEFAULT    3 __DATA_START
    52: 0000260c    76 FUNC    GLOBAL DEFAULT    1 __make_fp
    53: 00002e40     0 NOTYPE  GLOBAL DEFAULT    2 __DTOR_END
    54: 00002e40     0 NOTYPE  GLOBAL DEFAULT    2 __DTOR_START
    55: 80000024     0 NOTYPE  GLOBAL DEFAULT    2 __RDATA_END
    56: 00000000     0 NOTYPE  GLOBAL DEFAULT    1 __INIT_END
    57: 00000000     0 NOTYPE  GLOBAL DEFAULT    1 __TEXT_START
    58: 000029e4   344 FUNC    GLOBAL DEFAULT    1 __unpack_d
    59: 00000000     0 NOTYPE  GLOBAL DEFAULT    1 __FINI_START
    60: 00001454   104 FUNC    GLOBAL DEFAULT    1 __extendsfdf2
    61: 00001af8   136 FUNC    GLOBAL DEFAULT    1 __adddf3
    62: 80000024     4 OBJECT  GLOBAL DEFAULT    3 __fdlib_version
    63: 80000014     4 OBJECT  GLOBAL DEFAULT    2 _global_impure_ptr
    64: 8000042c     0 NOTYPE  GLOBAL DEFAULT    4 __BSS_START
    65: 8000042c     0 NOTYPE  GLOBAL DEFAULT    4 __BSS_END
    66: 00002514   248 FUNC    GLOBAL DEFAULT    1 __unpack_f
    67: 00002c60   468 FUNC    GLOBAL DEFAULT    1 __pack_f
    68: 0000021c  3556 FUNC    GLOBAL DEFAULT    1 __ieee754_asin
    69: 00000000    20 NOTYPE  GLOBAL DEFAULT    1 _start
    70: 000024a8   108 FUNC    GLOBAL DEFAULT    1 __ucmpdi2
    71: 00002b3c   292 FUNC    GLOBAL DEFAULT    1 __fpcmp_parts_d
    72: 00000000     0 NOTYPE  GLOBAL DEFAULT    1 __FINI_END
    73: 00001f90   744 FUNC    GLOBAL DEFAULT    1 __divdf3
    74: 00001b80  1040 FUNC    GLOBAL DEFAULT    1 __muldf3
    75: 00000014   116 FUNC    GLOBAL DEFAULT    1 main
    76: 8000842c     0 NOTYPE  GLOBAL DEFAULT    5 __STACK_START
    77: 00001424     8 FUNC    GLOBAL DEFAULT    1 matherr
    78: 00002374   144 FUNC    GLOBAL DEFAULT    1 __truncdfsf2
    79: 00000000     0 NOTYPE  GLOBAL DEFAULT    1 __INIT_START
    80: 00002e40     0 NOTYPE  GLOBAL DEFAULT    2 __CTOR_END
    81: 8000242c     0 NOTYPE  GLOBAL DEFAULT    4 __HEAP_MAX
    82: 80000000    20 OBJECT  GLOBAL DEFAULT    2 __thenan_df
    83: 00000088   404 FUNC    GLOBAL DEFAULT    1 asin
    84: 80000028     4 OBJECT  GLOBAL DEFAULT    3 _impure_ptr
    85: 8000042c     0 NOTYPE  GLOBAL DEFAULT    3 __DATA_END
    86: 0000142c    40 FUNC    GLOBAL DEFAULT    1 nan
    87: 00001000   940 FUNC    GLOBAL DEFAULT    1 __ieee754_sqrt
    88: 00002e40     0 NOTYPE  GLOBAL DEFAULT    1 __TEXT_END
    89: 8000042c     0 NOTYPE  GLOBAL DEFAULT    4 __HEAP_START
    90: 000013d8    76 FUNC    GLOBAL DEFAULT    1 __isnand
    91: 00002404   164 FUNC    GLOBAL DEFAULT    1 __muldi3
    92: 8000852c     0 NOTYPE  GLOBAL DEFAULT    6 __ISTACK_START
    93: 00001a64   148 FUNC    GLOBAL DEFAULT    1 __subdf3
    94: 00002658   908 FUNC    GLOBAL DEFAULT    1 __pack_d
    95: 80000000     0 NOTYPE  GLOBAL DEFAULT    2 __RDATA_START
    96: 00002e40     0 NOTYPE  GLOBAL DEFAULT    2 __CTOR_START

No version information found in this file.

I checked the disassembler, it 's ok.

So I wonder how to deal with the BFD_RELOC_32.

Any suggestion is appreciated.
Thanks very much.

                            daniel.tian

[Nick Clifton]

Hi Daniel,

> So I wonder how to deal with the BFD_RELOC_32.

Treat it in the same way as a BFD_RELOC_16, except that the top 16 bits
are zero.

So for example in your assembler source you have:

   [...]
   .section .debug_abbrev,"",@progbits
   .Ldebug_abbrev0:
   [...]
   .section .debug_info
   .4byte 0xb7
   .2byte 0x2
   .4byte .Ldebug_abbrev0
   [...]

Which is generating a 32-bit reloc for the reference to Ldebug_abbrev0:

   Relocation section '.rela.debug_info' at offset 0x940 contains 23
entries:
    Offset     Info    Type            Sym.Value  Sym. Name + Addend
   00000006  00000603 R_RICE_32         00000000   .debug_abbrev + 0

This relocation is here because the assembler does not know where the
.Ldebug_abbrev0 symbol will be located at run time.  The relocation has
to be a R_RICE_32 because the DWARF2 standard specifies that this field
in the .debug_info header is a 4-byte value.

So in your code in bfd/elf16-rice.c (or whatever filename you have given
to the RICE specific code in the BFD library) you need to handle
R_RICE_32 relocations and insert a 32-bit value into the indicated place
in the output binary.

For this particular example all that the code will have to do is to
lookup the address of the Ldebug_abbrev0 symbol, (it is probably 0x0),
zero-extend this from 16-bits to 32-bits, (you are using a 16-bit
address space aren't you ?) and then store this 32-bit value into bytes
6,7,8 and 9 of the .debug_info section.

Cheers
   Nick