From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24472 invoked by alias); 7 Jun 2003 11:40:38 -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 24450 invoked from network); 7 Jun 2003 11:40:37 -0000 Received: from unknown (HELO stardust.solidas.com) (217.13.28.68) by sources.redhat.com with SMTP; 7 Jun 2003 11:40:37 -0000 Received: from solidas.com (217-13-28-83.dd.nextgentel.com [217.13.28.83]) (authenticated) by stardust.solidas.com (8.11.6/8.11.6) with ESMTP id h57BeSl31247; Sat, 7 Jun 2003 13:40:29 +0200 Message-ID: <3EE1CF23.6000100@solidas.com> Date: Sat, 07 Jun 2003 11:40:00 -0000 From: "Svein E. Seldal" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) Gecko/20030527 Debian/1.3.1-2 X-Accept-Language: en MIME-Version: 1.0 To: Andrew Cagney CC: gdb@sources.redhat.com Subject: Re: [RFC] TARGET_CHAR_BIT != HOST_CHAR_BIT References: <3ED6964E.2080509@solidas.com> <3EDA425B.6070209@redhat.com> <3EDAB4D5.1040509@solidas.com> <3EDCBA69.7040306@redhat.com> In-Reply-To: <3EDCBA69.7040306@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-06/txt/msg00089.txt.bz2 Andrew Cagney wrote: > There are two things at play here: > > - the compilers decision on how to implement char > > The original alpha, for instance, had 8 bit addressable pointers yet the > hardware could only read/write 64 bit words. Access to anything > smaller than 64 bits was handled in software. Having the tic4x do > something similar (presumably with long pointers) is just a ``small > matter of programming''. The difference between the alpha and the tic4x, is the fact that a pointer can only read 32-bits nothing more, nothing less. An address points to a 32-bit location, never bytes. > - physical limitations of the hardware > > This is the important one. The data space pointers for this hardware > identify 32 bit words, not 8 bit bytes. Not just data pointers. All kind of pointers behaves this way. > To expand my point. TARGET_CHAR_BIT is used to identify: > > - bitsizeof (char) > - the implied address alignment > - anything else such as debug info? If you are to apply all these conditions to the tic4x target, you'll wind up with a TARGET_CHAR_BIT of 32. > Those two are, as I noted above, orthogonal. The problem, I think, is > that GDB has used them interchangably > > To address this I can see two models. > > - assume an 8 bit host byte size (aka bfd_byte) > > This is effectively what GDB does now. It, via pointer_to_address, maps > a target pointer onto a cannonical CORE_ADDR. For your architecture, a > read of the word pointed at by 0x1000 would be converted into a read of > four 8 bit bytes bytes at 0x4000. > > - use the target byte size > > And have any memory manipulations try to remember which (host or target) > is used for any length computations. > > I have a feeling that the first will be much easier. All, in theory, > that is needed is for this target to implement a pointer_to_address that > does the above manipulation (and then stop GDB trying to use > TARGET_CHAR_BIT when moving memory around). I agree that the first method could be a way of solving this issue. But I have the impression that this will be a hack. To implement the tic4x target with byte-addresses in gdb, is something that is solely made for satisfying gdb! The target _never_ operates with any of these numbers. Please remember that the pointers coming from the BFD still are in the target format. > I've also got reservations over making the semantics of memory transfer > operations architecture dependant. I think memory transfers should be > defined in an architecture independant way. Even if this is made though a gdbarch function that defaultly works like it does today? > The problem with this approach is that GDB's CORE_ADDRs become visible > to the user vis: This will certainly confuse the user. Because these numbers are never present on the target. > >> (gdb) print/x $pc >> $7 = 0x10140b8 > > > That's the PC as a GDB CORE_ADDR. > >> (gdb) print/x (int)$pc >> $8 = 0x502e > > > Where as that's the actual pointer value. > >> (gdb) x/i $pc >> 0x10140b8 : ld r0, @r11 || nop >> (gdb) x/4b $pc >> 0x10140b8 : 0x30 0x0b 0x5e 0x00 > > > In both cases an examine works as expected. Note that x/b examines an 8 > bit byte and not a 16 bit instruction word. > >> (gdb) x/4b (@code *)0x502e >> A syntax error in expression, near `*)0x502e'. > > > Hmm, it would be better if that worked. Would save the need to do: > >> (gdb) x/4b (@code void *)0x502e >> 0x10140b8 : 0x30 0x0b 0x5e 0x00 > > > But note that this code pointer is very different to: > >> (gdb) x/4b (char *)0x502e >> 0x200502e: 0x00 0x00 0x00 0x00 > > > which created a pointer into the data space. To me it seems like the internal gdb address is too visible to the user. Since this internal gdb address thing only present for satisfying the gdb implmentation, the user should _never_ be confronted with these hacky host-gdb-addresses. 1) (gdb) x/4b (@code void *)0x502e 0x10140b8 : 0x30 0x0b 0x5e 0x00 IMHO the only correct answer for this target is 0x502e : 0x300b5300 2) How does gdb handle this: struct buffer { char part1; char part2; }; Both of these members will be allocated a one-address location, but with the length of 32-bits. For the target: sizeof(struct buffer) == 2. 3) What happens if a user requests a datadump of a length of 4? In our definition of a char, a dump of "x/4b", should dump 4x 32-bits of information. The user will also expect this, as when he compiles "char buffer[10];" it will be implemented at 10x 32-bits memory locations. And when he issues "x/10b" (10 because he wants 10 number, and b because he knows that the buffer is char) we will expecat a dump of the entire buffer. > I should note that having CORE_ADDR visible is a blessing in disguise. > It makes operations such as x/b meaningful. What do you mean? Regards, Svein