From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13313 invoked by alias); 22 Apr 2005 22:45:56 -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 13258 invoked from network); 22 Apr 2005 22:45:50 -0000 Received: from unknown (HELO cheetah.davemloft.net) (216.27.180.174) by sourceware.org with SMTP; 22 Apr 2005 22:45:50 -0000 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DP6nD-00045a-00; Fri, 22 Apr 2005 15:38:35 -0700 Date: Fri, 22 Apr 2005 22:45:00 -0000 From: "David S. Miller" To: Mark Kettenis Cc: gdb-patches@sources.redhat.com Subject: Re: [PATCH] Add sparc64-linux sigtramp support Message-Id: <20050422153835.12aaf3c1.davem@davemloft.net> In-Reply-To: <200504212209.j3LM9Z2a010525@elgar.sibelius.xs4all.nl> References: <20050420204427.20d670e6.davem@davemloft.net> <200504211923.j3LJNHo6010891@elgar.sibelius.xs4all.nl> <20050421122250.6108168c.davem@davemloft.net> <200504212120.j3LLKB42010991@elgar.sibelius.xs4all.nl> <20050421144901.6fa89749.davem@davemloft.net> <200504212209.j3LM9Z2a010525@elgar.sibelius.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-SW-Source: 2005-04/txt/msg00294.txt.bz2 Mark do you actually have a sparc-linux machine that you test your changes on? Your solaris2 tdep removal breaks even the most simplest debugging test case, there is no way you tested sparc64-linux debugging. You're not calling sparc64_init_abi() anymore. Once you remove the call to sparc64_sol2_init_abi() it's not occuring at all. If you don't have a sparc*-linux machine to test your changes on, please at least run them by me quickly so I can run the testsuite on both 32-bit and 64-bit native Linux/Sparc. BTW, the plt entry size stuff is wrong. It was wrong for the solaris2 sparc64 target and it's wrong for the Linux target as well. They are variable in size, the first 64K of them are 16 bytes in size, then they become variable length sections of split instructions+data. I think we should instead either teach gdb how to really get the correct frame even in the funny PLT entry save/restore sequence (I had this working flawlessly a few years ago, I could resurrect that code) or we could do something similar to what the ppc-linux-tdep.c code does. I also think we should integrate the "PLT breakpoint avoidance" stuff they do there as well (and move that into a common file as the comment above it suggests). Thanks.