From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4742 invoked by alias); 10 Jan 2002 08:58:05 -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 4691 invoked from network); 10 Jan 2002 08:58:04 -0000 Received: from unknown (HELO mail.science.uva.nl) (146.50.4.51) by sources.redhat.com with SMTP; 10 Jan 2002 08:58:04 -0000 Received: from soliton.wins.uva.nl [146.50.20.20] by mail.science.uva.nl with ESMTP (sendmail 8.11.6/config 11.24). id g0A8tkL12362; Thu, 10 Jan 2002 09:55:46 +0100 (MET) Received: from localhost by soliton.wins.uva.nl (sendmail 8.11.6/config 11.15). id g0A8tio11478; Thu, 10 Jan 2002 09:55:44 +0100 (MET) X-Organisation: Faculty of Science, University of Amsterdam, The Netherlands X-URL: http://www.science.uva.nl/ To: thorpej@wasabisystems.com Cc: gdb@sources.redhat.com Subject: Re: Anyone using alpha-freebsd target in gdb-current? References: <20020109193418.L17203@dr-evil.shagadelic.org> From: Mark Kettenis Date: Thu, 10 Jan 2002 00:58:00 -0000 In-Reply-To: Jason R Thorpe's message of Wed, 9 Jan 2002 19:34:18 -0800 Message-ID: X-Mailer: Gnus v5.5/Emacs 20.2 X-SW-Source: 2002-01/txt/msg00080.txt.bz2 Jason R Thorpe writes: > Is anyone actually using the alpha-freebsd target in gdb-current? I guess it's not really actively used. I did the port to alpha-freebsd-5.0 (a.k.a. freebsd-current). I still work on it from time to time, and it should work reasonably with a recent gcc. The system compiler for freebsd-current generates unusable debug output, both for stabs and dwarf2. Gcc 3.0 and above should do much better. > I'm working on alpha-netbsd support, and it uses the pre-existing > alphabsd-nat.c. > > ...but I'm having some serious problems. They seem to be related > to breakpoints -- If I skip the implicit breakpoint at __start > (_start on a FreeBSD/alpha system) a test program behaves "more > correctly" (there are still some problems), but completely loses > if I leave that breakpoint there. Isn't NetBSD/alpha using ELF? In that case it shouldn't set any implicit breakpoints at __start. If NetBSD/alpha doesn't use ELF, then you might need to work on getting the old SunOS/a.out shared library support working on NetBSD/alpha. I recently had some problems on FreeBSD/alpha with backtraces. GDB just fell off the stack, because it couldn't determine the top of the stack. This was caused by not having debug info for crt*.o. I fixed it by choosing another way to determine the top of the stack, based on the filename. > Also, NetBSD/alpha requires software single-stepping in gdb (which > I have implemented), which uses breakpoints ... the software single > stepping also gives unexpected results (the PC value when the breakpoint > trips is not what I expect). I'm afraid I cannot help you here. > But, anyway, I'd really like to just know if anyone is successfully using > the alpha bsd native support successfully right now. That would help > eliminate some variables for me. Feel free to ask! Mark