From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14236 invoked by alias); 1 Nov 2004 00:48:18 -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 12745 invoked from network); 1 Nov 2004 00:48:02 -0000 Received: from unknown (HELO localhost.redhat.com) (24.42.65.225) by sourceware.org with SMTP; 1 Nov 2004 00:48:02 -0000 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 7D146129D8C; Sun, 31 Oct 2004 19:47:33 -0500 (EST) Message-ID: <418587A1.5060008@gnu.org> Date: Mon, 01 Nov 2004 00:48:00 -0000 From: Andrew Cagney User-Agent: Mozilla Thunderbird 0.8 (X11/20041020) MIME-Version: 1.0 To: Mark Kettenis Cc: gdb-patches@sources.redhat.com Subject: Re: [COMMIT] OpenBSD/mips64 target and native support References: <200410231216.i9NCG6YK023827@elgar.sibelius.xs4all.nl> <417D1A69.2070904@gnu.org> <20041025152912.GA28110@nevyn.them.org> <417D4D56.80003@gnu.org> <4185314C.7020307@gnu.org> <200410311945.i9VJjMoG002666@elgar.sibelius.xs4all.nl> <418545F4.8060401@gnu.org> <200410312228.i9VMSfcQ003129@elgar.sibelius.xs4all.nl> In-Reply-To: <200410312228.i9VMSfcQ003129@elgar.sibelius.xs4all.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-11/txt/msg00001.txt.bz2 Mark Kettenis wrote: > Date: Sun, 31 Oct 2004 15:07:16 -0500 > From: Andrew Cagney > > > Scaring away contributors by making unreasonable demands isn't a > > sensible thing to do. > > Our situtation here is identical to what we encountered with basic > multi-arch, the frame code, the regcace code, the function call code. > There, with our help and co-operation, people not just stepped up to, > but also exceeded the challenge. > > I strongly disagree. The shared library code touches core parts of > GDB. There's no way an outsider is going to be able to fix that > properly, especially since changes will have to be tested on a > multitude of platforms. There is also absolutely no visible benefit > from making the required changes. This is something the shared > library maintainer and core maintainers have to sort out. It's going > to take quite a bit of time to do so. Blank [puzzled] expression. This code is generic. We already have optional svr4 shlibs working. All our key platforms are svr4. We've never required testing across a ``multitude of platforms''. We strongly encourage cleanups. So what's so hard about this? Especially when, the core maintainers will be helping with the task. Andrew