From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18721 invoked by alias); 28 Feb 2004 20:26:02 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 18708 invoked from network); 28 Feb 2004 20:26:00 -0000 Received: from unknown (HELO walton.kettenis.dyndns.org) (213.93.115.144) by sources.redhat.com with SMTP; 28 Feb 2004 20:26:00 -0000 Received: from elgar.kettenis.dyndns.org (elgar.kettenis.dyndns.org [192.168.0.2]) by walton.kettenis.dyndns.org (8.12.6p3/8.12.6) with ESMTP id i1SKPe6C000288; Sat, 28 Feb 2004 21:25:40 +0100 (CET) (envelope-from kettenis@elgar.kettenis.dyndns.org) Received: from elgar.kettenis.dyndns.org (localhost [127.0.0.1]) by elgar.kettenis.dyndns.org (8.12.6p3/8.12.6) with ESMTP id i1SKPebk000433; Sat, 28 Feb 2004 21:25:40 +0100 (CET) (envelope-from kettenis@elgar.kettenis.dyndns.org) Received: (from kettenis@localhost) by elgar.kettenis.dyndns.org (8.12.6p3/8.12.6/Submit) id i1SKPdRr000430; Sat, 28 Feb 2004 21:25:39 +0100 (CET) Date: Sat, 28 Feb 2004 20:26:00 -0000 Message-Id: <200402282025.i1SKPdRr000430@elgar.kettenis.dyndns.org> From: Mark Kettenis To: cagney@gnu.org CC: ac131313@redhat.com, gdb-patches@sources.redhat.com In-reply-to: <4040E96F.4010809@gnu.org> (message from Andrew Cagney on Sat, 28 Feb 2004 14:18:07 -0500) Subject: Re: [rfa/amd64] Zero fill 32-bit registers References: <403E9BC3.2030807@redhat.com> <200402281046.i1SAkhhe000441@elgar.kettenis.dyndns.org> <4040B0F8.2050803@gnu.org> <200402281734.i1SHYvol017921@elgar.kettenis.dyndns.org> <4040E96F.4010809@gnu.org> X-SW-Source: 2004-02/txt/msg00858.txt.bz2 Date: Sat, 28 Feb 2004 14:18:07 -0500 From: Andrew Cagney > I don't know enough about MIPS to be sure, but I really think AMD64 is > different; the ISA doesn't magically extend 32-bit values to 64-bit > values. (That's why I zero extended). The problem with MIPS is that the code, instead of always being locally consistent, assume that problems like this were handled elsewhere - they never were or were not handled consistently. Only when MIPS started being locally consistent (and the mantra that addresses shall always be sign extended) did the code become robust, and the bugs disappear. It became possible to mix 'n' match 32-bit and 64-bit code. The problem with MIPS is that it has far too many ABI's ;-). Here amd64 has the same problem - all 32x64-bit code needs to ensure that it is locally consistent. If asked to supply a 64-bit register, supply the full 64-bits, and not hope something else is filling in the upper 32-bits. Hmm, actually the AMD64 Architecture Programmer's Manual explicitly says that the 16 general purpose registers are "zero-extended for 32-bit operands", so I guess zero-extending makes sense here. It doesn't say anthing about %rip, but that makes sense since you can't change it directly. Zero-extending makes sense though. I'm not sure about %eflags. Hmm, it should probably be named %rflags. Its upper 32-bits are reserved, and read as zero. The manual says that anything you write to the upper 32 bits is ignored. I get the feeling that we should leave the upper bits alone, just in case they ever get used for new processors. The segment registers are wierd anyway, since they're 16-bit regsisters in reality. Zero extending shouldn't be a problem here, but these registers could pose a problem. See below. > Short-term fix is probably to let fill_gregset() clear the register > buffer before calling amd64_native_collect_gregset(). > store_inferior_registers() should call amd64_native_collect_gregset() > then. It doesn't address the underlying problem where fetching an individual register leaves half the register field undefined. The code shouldn't assume that other code has magically initialized the rest of that register field. OK, but you realize its the problem of the threads code, and *not* the code amd64-nat.c? > > Another problem with your patch is that I'd rather like avoid assuming > > that the register buffer is an array of 8-byte registers. > > That code already assumems that, and that the values are little-endian. > > Yes it assumes little-endianness, but the assumptions on the size of > the slots in the register buffer are weaker. The register buffer here > corresponds to `struct reg' on the BSD's. It would be prefectly well > possible for some of its members to be 4 bytes in size. The current > code works for that case, whereas with your patch, it could thrash > another member of the structure. Do you know of any such an system? Actually GNU/Linux x86-64 has a gregset_t where %cs, %fs and %gs are stored in a short. Could you live with just zero-extending the 16 general-purpose registers and the instruction pointer? I'll implement it for you. Mark