Bug in assembler????

[jacob navia <jacob at jacob dot remcomp dot fr>]

How to reproduce this problem
-----------------------------


1) Take some C file. I used for instance dwarf.c from
  the new binutils distribution.
2) Generate an assembler listing of this file
3) Using objdump -s dwarf.o I dump all the
  sections of the executable in hexadecimal format.
  Put the result of this dump in some file, I used
  "vv" as name.
4) Dump the contents of the eh_frame section in
  symbolic form. You should use readelf -W. Put
  the result in some file, say, "dwarf.framedump"

-------------------------------------------------------

OK Now let's start. I go to the assembly listing
(dwarf.s) and search for "eh_frame" in the editor.
I arrive at:
       .section        .debug_frame,"",@progbits

This section consists of a CIE (Common Information Entry
in GNU terminology) that is generated as follows
in the assembly listing

.Lframe0:
       .long   .LECIE0-.LSCIE0
.LSCIE0:
       .long   0xffffffff
       .byte   0x1
       .string ""
       .uleb128 0x1
       .sleb128 -8
       .byte   0x10
       .byte   0xc
       .uleb128 0x7
       .uleb128 0x8
       .byte   0x90
       .uleb128 0x1
       .align 8
.LECIE0:
-------------------------------------------------------
This corresponds to a symbolic listing like this:
The section .debug_frame contains:

00000000 00000014 ffffffff CIE
 Version:               1
 Augmentation:          ""
 Code alignment factor: 1
 Data alignment factor: -8
 Return address column: 16

 DW_CFA_def_cfa: r7 ofs 8
 DW_CFA_offset: r16 at cfa-8
 DW_CFA_nop
 DW_CFA_nop
 DW_CFA_nop
 DW_CFA_nop
 DW_CFA_nop
 DW_CFA_nop
------------------------------------------------------------
This means that this entry starts at offset 0 and goes
for 20+4 bytes (the length field is 4 bytes).
Our binary dump of the contents of the first 96 bytes
(0x60) looks like this:
Contents of section .eh_frame:
0000 14000000 00000000 01000178 100c0708  ...........x....
0010 90010000 00000000 1c000000 1c000000  ................
0020 00000000 00000000 59000000 00000000  ........Y.......
0030 410e1083 02000000 1c000000 3c000000  A...........<...
0040 00000000 00000000 68000000 00000000  ........h.......
0050 410e1083 02000000 14000000 5c000000  A...........\...
0060 00000000 00000000 4e000000 00000000  ........N.......
We eliminate the first 24 (0x18) bytes and we obtain:
0018 1c000000 1c000000  ................
0020 00000000 00000000 59000000 00000000  ........Y.......
0030 410e1083 02000000 1c000000 3c000000  A...........<...
The is a FDE or Frame description entry in GNU terminology.
We have first a 32 bit length field represented
by the difference LEFDZ0 - LASDFE0. This is 1c000000 above

Then we have another .long instruction, (32 bits)
that corresponds to the second 1c000000 above.

Then we have two .quad instructions that correspond to
the line
0020 00000000 00000000 59000000 00000000  ........Y.......
above

AND NOW IT BECOMES VERY INTERESTING:
We have the instructions
   .byte    0x4
   .long    .LCFI0 - .LFB50
       .byte   0xe
       .uleb128 0x10
       .byte   0x83
       .uleb128 0x2
       .align 8

And we find in the hexademical dump the line
0030 410e1083 02000000 1c000000 3c000000  A...........<...

The 4 and the 1 are in the same byte, followed by the correct
0xe byte the correct 0x10 byte (uleb128 is 0x10) followed
by the correct 0x83 and followed by the correctd 0x02 byte.

WHERE AM I WRONG ?????????????????

I am getting CRAZY with this!!!!

Here is the full assembly listing of the FDE:

.LSFDE0:
       .long   .LEFDE0-.LASFDE0 /* first field 1c000000 */
.LASFDE0:
       .long   .Lframe0         
       .quad   .LFB50
       .quad   .LFE50-.LFB50
       .byte   0x4
       .long   .LCFI0-.LFB50
       .byte   0xe
       .uleb128 0x10
       .byte   0x83
       .uleb128 0x2
       .align 8