From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1690 invoked by alias); 23 Apr 2005 17:47:11 -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 1543 invoked from network); 23 Apr 2005 17:47:01 -0000 Received: from unknown (HELO cheetah.davemloft.net) (216.27.180.174) by sourceware.org with SMTP; 23 Apr 2005 17:47:01 -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 1DPObI-0002Yc-00; Sat, 23 Apr 2005 10:39:28 -0700 Date: Sat, 23 Apr 2005 17:47: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: <20050423103928.52d3c5e2.davem@davemloft.net> In-Reply-To: <200504231232.j3NCWuZT029533@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> <20050422153835.12aaf3c1.davem@davemloft.net> <200504231232.j3NCWuZT029533@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/msg00298.txt.bz2 On Sat, 23 Apr 2005 14:32:56 +0200 (CEST) Mark Kettenis wrote: > Hmm, the SCD 2.4.1 document that I'm looking at now says there are 32K > entries of 32 bytes followed by sections of 160 24-byte entries > followed by 160 pointers. The first part is correct, there are 32K pure code entries. The latter section is "160 24-byte entries followed by 160 pointers" for every full group of 160 entries, for the final group that has less than 160 entries (say N entries) it is N 24-byte entries followed by N pointers. The formulas to compute this stuff are pretty well described in the sparc64 BFD backend support code. Search for "h->plt.offset" and "build_plt_entry" in the current bfd/elfxx-sparc.c code. > I'm not sure it really matters though. > IIRC the most important thing is to avoid thinking that the PLT is a > proper function that starts with setting up a stack frame. Did you > notice any problems with the current code. Yes, there is a test case that fails on sparc32 for at least the past 8 years that's been bugging me like crazy. Basically it's trying to step over an integer multiply in a piece of C code, via a watchpoint. It's 32-bit Sparc compiled code with no hw multiply support, so to implement the multiply it calls ".umul" in the C library via a PLT entry. GDB outside of my own trees has never handled this test correctly and it's because of the PLT frame handling. The PLT trampoline _does_ have a frame, the issue is only to teach the Sparc target dependant code where to find the restore which releases the frame. Anyways, let me dig through my old patches and notes I took on this matter. I'll use that to come up with a solution proposal. > Looks to me as if the sparc PLT entries are deliberately constructed a > way to avoid the PLT breakpoint issue the ppc-linux-tdep.c code tries > to solve. That said, moving that code into a common file is probably > a good idea. It has the same problem. If you set a breakpoint in the second instruction of a PLT entry while we're in the dynamic linker resolve code, the dynamic linker will write the new instructions in the PLT entry, then GDB will restore the old out-of-date instruction when it removes the breakpoint it had there, thus corrupting the PLT entry and causing a crash the next time the child calls that function via that PLT entry. Like the above, I'll come up some specific test cases and fix proposals over the next few days for this stuff.