From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31390 invoked by alias); 19 Dec 2007 16:20:58 -0000 Received: (qmail 31378 invoked by uid 22791); 19 Dec 2007 16:20:57 -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; Wed, 19 Dec 2007 16:20:53 +0000 Received: from [172.17.0.10] (helo=[172.17.0.10]) by ocean.emcraft.com with esmtp (Exim 4.43) id 1J51Jn-0004Xl-VP; Wed, 19 Dec 2007 18:58:49 +0300 Message-ID: <476944A0.8060104@emcraft.com> Date: Wed, 19 Dec 2007 16:20: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 References: <47625A95.7080203@emcraft.com> <20071217225456.GA24192@caradoc.them.org> <47693C3F.40108@emcraft.com> In-Reply-To: <47693C3F.40108@emcraft.com> Content-Type: multipart/mixed; boundary="------------030908010802000004020800" 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/msg00146.txt.bz2 This is a multi-part message in MIME format. --------------030908010802000004020800 Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Content-length: 1660 Hello again, Sorry, previous patch is wrong, please ignore. Attached is the correct one. Regards, Sergei Sergei Poselenov wrote: > Hello Daniel, > > Daniel Jacobowitz wrote: >> On Fri, Dec 14, 2007 at 01:27:33PM +0300, Sergei Poselenov wrote: >>> 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) >> >> Drat. Yes, this just seems like a bug. I'll try to fix it later. >> > > Please review attached. > >>> 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) >> >> I don't think there should be any problems. There would be a little >> trouble debugging code from those sections if the image was relocated >> (qOffsets response), but yours shouldn't be; it goes at the address in >> the ELF file. >> > OK, thanks. > > Regards, > Sergei > > > ------------------------------------------------------------------------ > > --- gdb-6.7/gdb/elfread.c.orig 2007-12-19 16:27:32.000000000 +0100 > +++ gdb-6.7/gdb/elfread.c 2007-12-19 16:32:21.000000000 +0100 > @@ -107,7 +107,7 @@ elf_symfile_segments (bfd *abfd) > for (j = 0; j < num_segments; j++) > if (segments[j]->p_memsz > 0 > && vma >= segments[j]->p_vaddr > - && vma < segments[j]->p_vaddr + segments[j]->p_memsz) > + && (vma - segments[j]->p_vaddr) > segments[j]->p_memsz) > { > data->segment_info[i] = j + 1; > break; --------------030908010802000004020800 Content-Type: text/x-patch; name="gdb-6.7-uboot-sections.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="gdb-6.7-uboot-sections.patch" Content-length: 470 --- gdb-6.7/gdb/elfread.c.orig 2007-12-19 16:27:32.000000000 +0100 +++ gdb-6.7/gdb/elfread.c 2007-12-19 16:32:21.000000000 +0100 @@ -107,7 +107,7 @@ elf_symfile_segments (bfd *abfd) for (j = 0; j < num_segments; j++) if (segments[j]->p_memsz > 0 && vma >= segments[j]->p_vaddr - && vma < segments[j]->p_vaddr + segments[j]->p_memsz) + && (vma - segments[j]->p_vaddr) < segments[j]->p_memsz) { data->segment_info[i] = j + 1; break; --------------030908010802000004020800--