From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7595 invoked by alias); 28 Mar 2003 21:34:17 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 7588 invoked from network); 28 Mar 2003 21:34:17 -0000 Received: from unknown (HELO localhost.redhat.com) (207.219.125.105) by sources.redhat.com with SMTP; 28 Mar 2003 21:34:17 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 2DB412B29; Fri, 28 Mar 2003 16:34:14 -0500 (EST) Message-ID: <3E84BFD5.3080304@redhat.com> Date: Fri, 28 Mar 2003 21:34:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030223 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joel Brobecker , gdb@sources.redhat.com Subject: [6] What if EXTRA_FRAME_INFO wasn't required Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-03/txt/msg00389.txt.bz2 Joel, If the need to convert EXTRA_FRAME_INFO was dropped as a barrier to having HP/UX multi-arch partial, would anything else be left? I'm wondering how much further the bar needs to be lowered before HP/UX accidently falls over the multi-arch requirement [#include vision of HP/UX trying to play the `the stick game', where the sole objective is to jump / step / fall / crawl over a stick lying flat on the ground, and still failing :-] -- My cunning plan is to, since GDB has had so much significant recent change, reset slightly peoples expectations for this new release. Even releases are generally associated with stability problems :-) Andrew