From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15117 invoked by alias); 2 Sep 2002 22:13:15 -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 15110 invoked from network); 2 Sep 2002 22:13:15 -0000 Received: from unknown (HELO dr-evil.shagadelic.org) (208.176.2.174) by sources.redhat.com with SMTP; 2 Sep 2002 22:13:15 -0000 Received: by dr-evil.shagadelic.org (Postfix, from userid 7518) id F1E6D9869; Mon, 2 Sep 2002 15:13:14 -0700 (PDT) Date: Mon, 02 Sep 2002 15:13:00 -0000 From: Jason R Thorpe To: Mark Kettenis Cc: gdb-patches@sources.redhat.com Subject: Re: [PATCH] i386nbsd_pc_in_sigtramp robustness Message-ID: <20020902151314.D6992@dr-evil.shagadelic.org> Mail-Followup-To: Jason R Thorpe , Mark Kettenis , gdb-patches@sources.redhat.com References: <20020902093426.G4034@dr-evil.shagadelic.org> <86bs7gt6km.fsf@elgar.kettenis.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <86bs7gt6km.fsf@elgar.kettenis.dyndns.org>; from kettenis@chello.nl on Mon, Sep 02, 2002 at 11:39:05PM +0200 Organization: Wasabi Systems, Inc. X-SW-Source: 2002-09/txt/msg00026.txt.bz2 On Mon, Sep 02, 2002 at 11:39:05PM +0200, Mark Kettenis wrote: > Just a few thoughts: > > * Doesn't this break things for NetBSD before 1.4? Did you consider > falling back on the old method? The old method didn't work on 1.3 anyway, because the VM layout was different then, i.e the sigtramp start/end were different. I could add a disassemble-using version for 1.3, but it hardly seems worth it at this point. Heh, just checked, and FWIW, the old method didn't work for 1.4, either; it used the same VM layout as 1.3. The VM layout was changed between 1.4 and 1.5; the new VM layout also was in 1.4.2 and 1.4.3. 1.4 did, however, have a slightly different signal trampoline (which changed based on a kernel option). I'm going to file a PR to remind me to audit all of the signal trampoline stuff back to NetBSD 1.4. > * Did you notice any effect on performance? Reading from a target's > memory can be time-consuming for remote targets. It certainly didn't seem any slower on my Athlon :-) Yes, I know reading memory is time-consuming for remote targets, however, there isn't really any other sane way to do it, since the VM layout is totally arbitrary and can be changed by the user. I'll note that i386-linux also uses the disassemble method. Also note that the use of the disassemble-method is going to fade over time, since post-1.6 NetBSD now uses symbol names to find the trampoline. -- -- Jason R. Thorpe