From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30038 invoked by alias); 14 Dec 2007 10:29:02 -0000 Received: (qmail 30026 invoked by uid 22791); 14 Dec 2007 10:29:01 -0000 X-Spam-Check-By: sourceware.org Received: from ocean.emcraft.com (HELO ocean.emcraft.com) (213.221.7.182) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 14 Dec 2007 10:28:50 +0000 Received: from [172.17.0.10] (helo=[172.17.0.10]) by ocean.emcraft.com with esmtp (Exim 4.43) id 1J37Vv-0008I8-TF; Fri, 14 Dec 2007 13:11:30 +0300 Message-ID: <47625A95.7080203@emcraft.com> Date: Fri, 14 Dec 2007 10:29:00 -0000 From: Sergei Poselenov User-Agent: Thunderbird 1.5.0.7 (X11/20061008) MIME-Version: 1.0 To: gdb@sourceware.org Subject: Re: [rfc / remote protocol] ELF segment based qOffsets Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -104.2 (---------------------------------------------------) Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2007-12/txt/msg00092.txt.bz2 Hello all, We've ran into the following problem while running the ppc cross-gdb with the U-Boot firmware image: bash# ./gdb u-boot GNU gdb Red Hat Linux (6.7-1rh) Copyright (C) 2007 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "--host=i686-pc-linux-gnu --target=ppc-linux". The target architecture is set automatically (currently powerpc:403) .. warning: Loadable segment ".resetvec" outside of ELF segments warning: Loadable segment ".bootpg" outside of ELF segments (gdb) bash# readelf -lS u-boot There are 27 section headers, starting at offset 0xc3dc0: Section Headers: [Nr] Name Type Addr Off Size ES Flg Lk Inf Al [ 0] NULL 00000000 000000 000000 00 0 0 0 [ 1] .resetvec PROGBITS fffffffc 02e208 000004 00 AX 0 0 1 [ 2] .bootpg PROGBITS fffff000 02d20c 00033c 00 AX 0 0 1 [ 3] .text PROGBITS fffc0000 0000a0 022f9c 00 AX 0 0 16 [ 4] .rodata PROGBITS fffe2f9c 02303c 007250 00 A 0 0 4 [ 5] .reloc PROGBITS fffea200 02a2a0 001204 00 WA 0 0 1 ... Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x0000a0 0xfffc0000 0xfffc0000 0x2d16c 0x35cd0 RWE 0x10 LOAD 0x02d20c 0xfffff000 0xfffff000 0x01000 0x01000 R E 0x1 GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RWE 0x4 Section to Segment mapping: Segment Sections... 00 .text .rodata .reloc .data .data.rel.local .data.rel.ro.local .data.rel data .u_boot_cmd 01 .resetvec .bootpg 02 You see, the warnings are caused by the fact that the segment 01 has address/size values which wraps to 0 in the following 'if' condition introduced by the $subj in elfread.c, elf_symfile_segments(): ... && vma < segments[j]->p_vaddr + segments[j]->p_memsz) The place above is trivial to fix, but I wonder will be any other consequences to the remote debugging of such kind of images? (I can't try this at the moment) Regards, Sergei