From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32551 invoked by alias); 25 Mar 2004 10:26:43 -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 32532 invoked from network); 25 Mar 2004 10:26:40 -0000 Received: from unknown (HELO walton.kettenis.dyndns.org) (213.93.115.144) by sources.redhat.com with SMTP; 25 Mar 2004 10:26:40 -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 i2PAQYw2000255; Thu, 25 Mar 2004 11:26:34 +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 i2PAQYvw000638; Thu, 25 Mar 2004 11:26:34 +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 i2PAQXRr000635; Thu, 25 Mar 2004 11:26:33 +0100 (CET) Date: Thu, 25 Mar 2004 10:26:00 -0000 Message-Id: <200403251026.i2PAQXRr000635@elgar.kettenis.dyndns.org> From: Mark Kettenis To: cagney@gnu.org CC: gdb-patches@sources.redhat.com In-reply-to: <40622721.6010603@gnu.org> (message from Andrew Cagney on Wed, 24 Mar 2004 19:26:09 -0500) Subject: Re: Signal Trampoline Frames References: <200403242303.i2ON33uL005973@elgar.kettenis.dyndns.org> <40622721.6010603@gnu.org> X-SW-Source: 2004-03/txt/msg00603.txt.bz2 Date: Wed, 24 Mar 2004 19:26:09 -0500 From: Andrew Cagney > Andrew, > > It's probably too late now, but I have the feeling this new > tramp-frame.c is not generic enough. It assumes fixed-length > instructions (which makes it unsuitable for IA-32 and AMD64) I didn't forget IA-32, I figured that it is always little endian so a sequence of one byte "insns" would work. Ah, that would probably work :-). > and uses > the arbitrary number 8 for the number of instructions (which makes it > not quite suitable for SPARC). I'm assuming people will increase it (It's like the arbitrary number 16 for the largest possible size of an instruction). OK. Although you must realize that for SPARC we might need to increase it to 80 or so. Then it makes more sense to check only for a small number of key instructions I think. > The whole thing seems a bit > over-engineered to me :-(. In what way? I wrote it after churn out 4 almost identical signal trampolines - so it works for one type but not for others. You also haven't seen my test cases :-) My experience is that there is too much variation for a one-size-fits-all trampoline recognition function. I was under the impression that there were only two cases where this could be used. Turns out I'm wrong. I still think we run the risk of over-engineering this by adding to much knobs if we try to make it work for too many slightly different signal tramps. Mark