From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-patches-return-18350-listarch-gdb-patches=sourceware.cygnus.com@sources.redhat.com>
Received: (qmail 31721 invoked by alias); 2 Sep 2002 21:39:08 -0000
Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm
Precedence: bulk
List-Subscribe: <mailto:gdb-patches-subscribe@sources.redhat.com>
List-Archive: <http://sources.redhat.com/ml/gdb-patches/>
List-Post: <mailto:gdb-patches@sources.redhat.com>
List-Help: <mailto:gdb-patches-help@sources.redhat.com>, <http://sources.redhat.com/ml/#faqs>
Sender: gdb-patches-owner@sources.redhat.com
Received: (qmail 31711 invoked from network); 2 Sep 2002 21:39:06 -0000
Received: from unknown (HELO walton.kettenis.dyndns.org) (62.163.169.250)
  by sources.redhat.com with SMTP; 2 Sep 2002 21:39:06 -0000
Received: from elgar.kettenis.dyndns.org (elgar.kettenis.dyndns.org [192.168.0.2])
	by walton.kettenis.dyndns.org (8.12.5/8.12.5) with ESMTP id g82Ld5BG000273;
	Mon, 2 Sep 2002 23:39:05 +0200 (CEST)
	(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.5/8.12.5) with ESMTP id g82Ld5aA000585;
	Mon, 2 Sep 2002 23:39:05 +0200 (CEST)
	(envelope-from kettenis@elgar.kettenis.dyndns.org)
Received: (from kettenis@localhost)
	by elgar.kettenis.dyndns.org (8.12.5/8.12.5/Submit) id g82Ld5jx000582;
	Mon, 2 Sep 2002 23:39:05 +0200 (CEST)
To: Jason R Thorpe <thorpej@wasabisystems.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [PATCH] i386nbsd_pc_in_sigtramp robustness
References: <20020902093426.G4034@dr-evil.shagadelic.org>
From: Mark Kettenis <kettenis@chello.nl>
Date: Mon, 02 Sep 2002 14:39:00 -0000
In-Reply-To: Jason R Thorpe's message of "Mon, 2 Sep 2002 09:34:26 -0700"
Message-ID: <86bs7gt6km.fsf@elgar.kettenis.dyndns.org>
X-SW-Source: 2002-09/txt/msg00024.txt.bz2

Jason R Thorpe <thorpej@wasabisystems.com> writes:

> --3xoW37o/FfUZJwQG
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> 
> The strategy of comparing against hard-coded addresses to find the
> signal trampoline is a bad one; it is possible for the user to change
> the VM layout, and thus the location of the signal trampoline, with a
> kernel option.
> 
> The following patch changes the i386-netbsd* targets to disassemble to
> find the trampoline, as is done for other NetBSD targets.

Just a few thoughts:

 * Doesn't this break things for NetBSD before 1.4?  Did you consider
   falling back on the old method?

 * Did you notice any effect on performance?  Reading from a target's
   memory can be time-consuming for remote targets.

Mark