From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29689 invoked by alias); 12 Dec 2003 17:06:53 -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 29681 invoked from network); 12 Dec 2003 17:06:49 -0000 Received: from unknown (HELO walton.kettenis.dyndns.org) (213.93.115.144) by sources.redhat.com with SMTP; 12 Dec 2003 17:06:49 -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 hBCH6m9h001226 for ; Fri, 12 Dec 2003 18:06:49 +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 hBCH6mrL011422 for ; Fri, 12 Dec 2003 18:06:48 +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 hBCH6mIh011419; Fri, 12 Dec 2003 18:06:48 +0100 (CET) Date: Fri, 12 Dec 2003 17:06:00 -0000 Message-Id: <200312121706.hBCH6mIh011419@elgar.kettenis.dyndns.org> From: Mark Kettenis To: gdb@sources.redhat.com Subject: [RFC] i386 SSE registers X-SW-Source: 2003-12/txt/msg00184.txt.bz2 Some time ago, I unconditionally enabled the SSE registers in the i386 target. On (sub-)targets that don't provide these registers[1] we now have a slight discrepancy. A native GNU/Linux GDB will set these registers to some non-zero dummy values. In all other cases the registers are left alone, which means that they're initialized to zero when GDB creates its register cache, and stay that way, unless the user explicitly sets them to some other value. I'd like to get rid of this discrepancy. However, since this will result in a user-visible change, and since I'm not very familliar with SIMD programming, I'd like to hear some opinions first. Here are the three options I'm considering: 1. Set the SSE registers to the dummy values that the native GNU/Linux GDB provides. 2. Leave the SSE registers alone like we do for the other cases right now. 3. Set the SSE registers explicitly to zero everytime we read the FPU registers. Personally I'm leaning towards option 2, since it allows us to detect that the SSE registers aren't there by using regcache_valid_p(). Thoughts? If nobody objects, I'll change the native GNU/Linux GDB around Christmas. Cheers, Mark [1] Either because the underlying OS doesn't (fully) support them, the remote protocol doesn't support them or the code is executing on a CPU that doesn't support them.