From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19238 invoked by alias); 23 Jan 2008 19:22:16 -0000 Received: (qmail 19223 invoked by uid 22791); 23 Jan 2008 19:22:15 -0000 X-Spam-Check-By: sourceware.org Received: from py-out-1112.google.com (HELO py-out-1112.google.com) (64.233.166.181) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 23 Jan 2008 19:21:53 +0000 Received: by py-out-1112.google.com with SMTP id v53so3552327pyh.33 for ; Wed, 23 Jan 2008 11:21:51 -0800 (PST) Received: by 10.35.67.18 with SMTP id u18mr11286746pyk.64.1201116110397; Wed, 23 Jan 2008 11:21:50 -0800 (PST) Received: by 10.35.36.15 with HTTP; Wed, 23 Jan 2008 11:21:50 -0800 (PST) Message-ID: <8f2776cb0801231121r3fe9aea0q6f3c3d6887fcb251@mail.gmail.com> Date: Wed, 23 Jan 2008 19:22:00 -0000 From: "Jim Blandy" To: "Pedro Alves" Subject: Re: arm_addr_bits_remove Cc: gdb-patches In-Reply-To: <479752C8.8030201@portugalmail.pt> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <47965D31.3040602@codesourcery.com> <8f2776cb0801221525w1d26661dgf6452f876197a591@mail.gmail.com> <479752C8.8030201@portugalmail.pt> X-Google-Sender-Auth: 84139ce26c0dc9c1 X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-01/txt/msg00560.txt.bz2 On Jan 23, 2008 6:44 AM, Pedro Alves wrote: > With that you'll be certain that there is a symbol *before* the > address you want to check, and you'll be sure about it's mode, > and I'm sure that most of the times that mode will be the same as > the mode of memaddr, but you can't be sure, can you? I guess the thought was that if there is no symbol covering an address, but there is a symbol whose range ends at that address, it's a safe bet the address is some sort of endpoint (as it is in the case at hand), and should be treated like the other addresses within the range. But you're right, it's a heuristic. > The case I stumbled on the bug is a bit different from that > case you mentioned, because the line info doesn't refer to a possible > function which includes memaddr or ends before memaddr. There was no > real code at the address the lookup was being performed, because > it refers to the end of the object file, where padding is being > performed, but real code in a different mode could be there. If > there was code there, then the correct mode for it could be > inferred, and it could be different from memaddr-1 -- at > least that's my understanding. I could be wrong though. :-) So the heuristic I suggested will often be wrong. :( I guess you're right that one should be subtracting one from the address somewhere earlier in the call stack. Looking into this a bit more, I got even more confused. (I don't want to get in the way of getting a bug fixed, so take this if it's helpful and ignore it if it's not.) Why are we calling gdbarch_addr_bits_remove in record_line at all? Who sets the thumb bit in line number info? The thumb bit is only meaningful in ELF symbols, and values derived from those. It seems like the use of gdbarch_addr_bits_remove originated in 2001: 2001-04-06 Fernando Nasser * buildsym.c (record_line): Turn off unused addr bits. Could we try simply removing this?