From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11347 invoked by alias); 12 Dec 2003 00:16:31 -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 11338 invoked from network); 12 Dec 2003 00:16:29 -0000 Received: from unknown (HELO mail2.cray.com) (136.162.64.100) by sources.redhat.com with SMTP; 12 Dec 2003 00:16:29 -0000 Received: from relayc.wc.cray.com (relayc.us.cray.com [192.168.226.146]) by mail2.cray.com (8.12.10/8.12.10/gw-1.2) with ESMTP id hBC0GOjh005184 for ; Thu, 11 Dec 2003 16:16:25 -0800 (PST) Received: from gershwin.cray.com (gershwin.wc.cray.com [207.224.230.28]) by relayc.wc.cray.com (8.12.10/8.12.10/hub-1.3) with ESMTP id hBC0GMDZ000754 for ; Thu, 11 Dec 2003 16:16:22 -0800 (PST) Received: from boom.wc.cray.com (boom.wc.cray.com [172.28.16.241]) by gershwin.cray.com (8.12.10/8.12.10/gershwin-1.1) with ESMTP id hBC0GJso013574 for ; Thu, 11 Dec 2003 16:16:21 -0800 (PST) Subject: x86_64 register cache layout From: Anthony Booker To: gdb@sources.redhat.com Content-Type: text/plain Organization: Message-Id: <1071188179.30671.61.camel@boom.wc.cray.com> Mime-Version: 1.0 Date: Fri, 12 Dec 2003 00:16:00 -0000 Content-Transfer-Encoding: 7bit X-Cray-VirusStatus: clean X-SW-Source: 2003-12/txt/msg00177.txt.bz2 Hello gdb, I am trying to implement a simple remote protocol server for an AMD Opteron based system. I am happily getting exchanges back and forth, I'm ignoring a whole bunch of comands but eventually gdb settles down and says it's attached to the remote process. I can modify memory on the target and see the effects on the process. What I'd like to do is have the 'g' command actually provide register contents, preferably all the registers and preferably the real data. :) To do this I'll need to find the right packing order for the reply frame. From my reading so far I believe this is, with a couple of minor exceptions, the hex string representation of the register cache. So I follow the bouncing ball and get down to supply_register which calls register data which uses reg_defs to define the order and length of entries in the cache. Now reg_defs seems to be set set_register_cache but I can't find where that is called. I did attach to a gdbserver and found that the caller seems to give regs_x86_64 as the initialiser. But I can find neither hide nor hair of that variable in the gdb source I have and the gdbserver is sans symbols. So I'm stuffed. Can anyone help me join the final dot and locate the table? Thanks for your time. Anthony Booker