From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10582 invoked by alias); 23 Jan 2006 20:51:55 -0000 Received: (qmail 10574 invoked by uid 22791); 23 Jan 2006 20:51:54 -0000 X-Spam-Check-By: sourceware.org Received: from zproxy.gmail.com (HELO zproxy.gmail.com) (64.233.162.204) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 23 Jan 2006 20:51:52 +0000 Received: by zproxy.gmail.com with SMTP id x3so987660nzd for ; Mon, 23 Jan 2006 12:51:50 -0800 (PST) Received: by 10.37.2.80 with SMTP id e80mr4235132nzi; Mon, 23 Jan 2006 12:51:49 -0800 (PST) Received: by 10.37.2.42 with HTTP; Mon, 23 Jan 2006 12:51:49 -0800 (PST) Message-ID: <8f2776cb0601231251v253ad0dft98eb2b558531d99@mail.gmail.com> Date: Mon, 23 Jan 2006 20:51:00 -0000 From: Jim Blandy To: NZG Subject: Re: gdb code review, pointer madness Cc: gdb-patches@sourceware.org, uClinux development list In-Reply-To: <200601231438.26040.ngustavson@emacinc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <200601231438.26040.ngustavson@emacinc.com> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-01/txt/msg00340.txt.bz2 On 1/23/06, NZG wrote: > Specifically this loop doesn't seem to be executing correctly > > for (p =3D startaddr; p < endaddr; ++p) > retval =3D (retval << 8) | *p; > > In the function call I'm watching, > endaddr =3D startaddr+4, > yet, when I step through the function the loop executes 8 times and overs= hoots > the array. > > I don't see anything wrong with the code. > Can anyone else see anything weird in the pointer math below? I don't think there's anything wrong with the C code. That's a completely fundamental function in GDB, used everywhere, all the time. And it's hard for me to believe that both endiannesses aren't being exercised. If it were broken, we surely would have found out by now. If the function is behaving as you say, then I'd say your compiler has miscompiled GDB. Why don't you look through the assembly code for the function, and see if it's right?