From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3179 invoked by alias); 11 Jun 2003 18:07:20 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 2751 invoked from network); 11 Jun 2003 18:07:06 -0000 Received: from unknown (HELO planck.amplepower.com) (216.39.162.139) by sources.redhat.com with SMTP; 11 Jun 2003 18:07:06 -0000 Received: from [192.168.8.30] (helo=knuth.amplepower.com ident=roth) by planck.amplepower.com with esmtp (Exim 3.36 #1 (Debian)) id 19Q9pX-0007zp-00; Wed, 11 Jun 2003 10:56:15 -0700 Date: Wed, 11 Jun 2003 18:07:00 -0000 From: "Theodore A. Roth" X-X-Sender: roth@knuth.amplepower.com To: Jim Blandy cc: gdb@sources.redhat.com Subject: Re: Function addresses on the AVR In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2003-06/txt/msg00187.txt.bz2 On Wed, 11 Jun 2003, Jim Blandy wrote: :) :) Hey there. I've been looking at uses of CONVERT_FROM_FUNC_PTR_ADDR :) with an eye towards fixing up some related stuff, and I noticed two :) things about avr-tdep.c: :) :) - It provides a function for CONVERT_FROM_FUNC_PTR_ADDR that :) multiplies the address by two, and :) :) - There's a comment saying: :) :) ... :) The problem manifests itself when trying to set a breakpoint in a :) function which resides in the upper half of the instruction space and :) thus requires a 17-bit address. :) ... :) :) Both of these things caught my eye, and made me wonder if there :) weren't a way to help the AVR port work better, and incidentally :) remove your use of CONVERT_FROM_FUNC_PTR_ADDR altogether. :) :) >From looking at the AVR manual, I gather that code addresses are 16 :) bits wide, and refer to 16-bit words in the program memory. So the :) architecture can address 64k words (128k bytes), of code. :) Instructions are always 16 or 32 bits long, so the processor never :) addresses them by byte at all. So as far as the processor is :) concerned, code addresses are 16 bit long. Is that right? Yes, that is correct. There is a device coming end of year (rumored) with 128k words (256k bytes) of code space, but there isn't a datasheet available yet. Not sure yet how that will affect the GNU toolchain though. :) :) But GDB and the rest of the GNU toolchain all want to use byte :) addresses for everything, so in the unified address space you use for :) linking, your program memory appears as 128k bytes at addresses 0x0 :) through 0x1ffff. Whatever SRAM the system has appears at 0x800000 in :) this unified address space; a pointer value of 0x0 refers to the byte :) at 0x800000 in the unified space. Is that right? Yes. :) :) I'll bet C programs represent data pointers as byte addresses, but :) pointers to a functions as word addresses --- 16-bit values you could :) load directly into the PC. And I'll bet return addresses on the stack :) are also just 16-bit values. True for now. The rumored 256k device will put a 24-bit return address on the stack (pushes 3 bytes). One gotcha with the return addresses on the stack is that they are in big-endian byte order in memory, but the avr's are considered little-endian devices. A call instruction does the pushes in hardware, so gcc has no control or knowledge of this as far as I can tell. :) :) So this means that the toolchain is using 17-bit byte addresses, while :) the running program is using 16-bit word addresses. Right? For the current devices, yes. :) :) If so, I think this is exactly the program that POINTER_TO_ADDRESS and :) ADDRESS_TO_POINTER are supposed to solve. They're described in more :) detail in gdb/doc/gdbint.texinfo, in the section called "Pointers Are :) Not Always Addresses"; that even uses a Harvard architecture as an :) example. :) :) You're using them to add and remove the upper "prefix" bits, which is :) partly what they're for, but they're also supposed to handle :) converting between the word addresses that appear in the running :) program, and the byte addresses that GDB uses to actually read and :) write instruction memory. :) :) The general idea is that CORE_ADDR values should always be byte :) addresses, and if the processor's natural form for function pointers :) and return addresses on the stack is not a byte address, then :) POINTER_TO_ADDRESS converts the natural form to byte addresses, and :) ADDRESS_TO_POINTER converts byte addresses to the natural form. :) :) In other words, POINTER_TO_ADDRESS should shift the value left one bit :) when the type is a pointer to function or method --- turning the word :) address into a byte address --- and ADDRESS_TO_POINTER should shift :) the value right one bit when the type is right --- turning the byte :) address back into a word address. :) :) If you change your methods to do this, and dedicate the full range 0x0 :) -- 0x1ffff for byte-addressed program memory (which I'll bet is what :) gas, ld, and the binutils are doing already), and then get rid of the :) definition of CONVERT_FROM_FUNC_PTR_ADDR, then I think a bunch of :) stuff should start to work better. :) I've changed the ADDRESS_TO_POINTER and POINTER_TO_ADDRESS methods to do the bit shift for code addrs and removed the CONVERT_FROM_FUNC_PTR_ADDR method. I can't see that it negatively affects either what is in cvs or the new code I'm working on (frame-ifying the avr), so it looks like your analysis is correct. I'll commit the changes after I've done a bit more testing (I still don't have the testsuite running for avr yet :-\ ). That will remove one more instance of CONVERT_FROM_FUNC_PTR_ADDR for you. Thanks for digging through the avr stuff. Ted Roth