From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32203 invoked by alias); 2 Jun 2006 15:46:15 -0000 Received: (qmail 31551 invoked by uid 22791); 2 Jun 2006 15:46:14 -0000 X-Spam-Check-By: sourceware.org Received: from smtp4.wanadoo.fr (HELO smtp4.wanadoo.fr) (193.252.22.27) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 02 Jun 2006 15:46:12 +0000 Received: from [192.168.1.10] (AAubervilliers-153-1-42-243.w83-200.abo.wanadoo.fr [83.200.14.243]) by mwinf0408.orange.fr (SMTP Server) with ESMTP id 9F6341C00175 for ; Fri, 2 Jun 2006 17:46:09 +0200 (CEST) X-ME-UUID: 20060602154609652.9F6341C00175@mwinf0408.orange.fr Message-ID: <44805D41.7030608@jacob.remcomp.fr> Date: Fri, 02 Jun 2006 15:46:00 -0000 From: jacob navia User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) MIME-Version: 1.0 To: GCC Mailing List Subject: Bug in gnu assembler? Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2006-06/txt/msg00069.txt.bz2 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: (file dwarf.framedump) 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