From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4971 invoked by alias); 14 Feb 2004 20:00:24 -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 4963 invoked from network); 14 Feb 2004 20:00:23 -0000 Received: from unknown (HELO blount.mail.mindspring.net) (207.69.200.226) by sources.redhat.com with SMTP; 14 Feb 2004 20:00:23 -0000 Received: from user-119a90a.biz.mindspring.com ([66.149.36.10] helo=berman.michael-chastain.com) by blount.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1As5xc-0003Jl-00; Sat, 14 Feb 2004 15:00:20 -0500 Received: by berman.michael-chastain.com (Postfix, from userid 502) id B076E4B104; Sat, 14 Feb 2004 15:00:10 -0500 (EST) To: cagney@gnu.org, mec.gnu@mindspring.com Subject: Re: Time for a HP/PA hackathon? Cc: gdb-patches@sources.redhat.com Message-Id: <20040214200010.B076E4B104@berman.michael-chastain.com> Date: Sat, 14 Feb 2004 20:00:00 -0000 From: mec.gnu@mindspring.com (Michael Elizabeth Chastain) X-SW-Source: 2004-02/txt/msg00370.txt.bz2 > The 64-bit off_t, enabling the TUI, the HP/UX frame update, or the BFD > file I/O rewrite? The 64-bit off_t is the part that bothers me. It's using a new host ABI that gdb hasn't used before, which means it's likely to have problems on some hosts. I don't feel as nervous about the TUI as you do. If it doesn't work on some host, then we can just disable it on that host. The HP/UX frame update doesn't bother me at all. We have a test suite. I run it. It's covered, although the coverage is limited to HP's compilers (no gcc) and HP-UX 11.11 (no 10.20 or 11.00). I don't know anything about the BFD file I/O rewrite. We aren't getting enough host-side coverage in gdb-testers. It's a QA issue rather than a development issue. How does anyone know if the new off_t code or the most recent readline code works on Cygwin or AIX or Irix or Solaris? > I do wonder if the next binutils branch should be held off until after > GDB's been released - so that it can learn from GDB's mistakes :-) It's easier for me if gdb doesn't branch until gcc 3.3.3 has released, and a lot easier if binutils doesn't branch until gdb 6.1 has released (preferably until after gdb gdb-6_1-branch has died). Michael C