From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6603 invoked by alias); 11 Nov 2003 16:31:01 -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 6589 invoked from network); 11 Nov 2003 16:31:01 -0000 Received: from unknown (HELO hall.mail.mindspring.net) (207.69.200.60) by sources.redhat.com with SMTP; 11 Nov 2003 16:31:01 -0000 Received: from user-119a90a.biz.mindspring.com ([66.149.36.10] helo=berman.michael-chastain.com) by hall.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1AJbOo-00000c-00; Tue, 11 Nov 2003 11:29:50 -0500 Received: by berman.michael-chastain.com (Postfix, from userid 502) id 2FC244B361; Tue, 11 Nov 2003 11:29:51 -0500 (EST) To: ezannoni@redhat.com, mec.gnu@mindspring.com Subject: Re: [rfc] msymbol.size Cc: brobecker@gnat.com, gdb-patches@sources.redhat.com Message-Id: <20031111162951.2FC244B361@berman.michael-chastain.com> Date: Tue, 11 Nov 2003 16:31:00 -0000 From: mec.gnu@mindspring.com (Michael Elizabeth Chastain) X-SW-Source: 2003-11/txt/msg00214.txt.bz2 [I added gdb.patches back because we aren't attaching huge files, so might as well share and enjoy]. eza> I did a build w/o your patch but w/ the fprintf. No output :-( eza> A build w/ your patch : still no output from the printf. Okay. This means that gdb does not use the "texthigh hack" with gcc and /usr/ccs/bin/as. So, we could do anything we want to msymbol.size and there would be no effect on gdb, as long as gcc is the compiler and /usr/ccs/bin/as is the assembler. Any chance of running the gdb test suite with Sun's compiler? Or even just debugging a 'hello world' program built with Sun's compiler and seeing if the texthigh hack is still used at all. Or even ... running gdb on random Solaris utilities like /usr/bin/ls and seeing what happens. eza> So I think that the diff in pthreads.exp could be a fluctuation. eza> Given the roblems with that test. I have run into into similar problems on x86 two or three times. What happens is: pthreads.exp fluctuates because it is a thread test. Sometimes some of the threads are in states that are deterministically bad for gdb. That is: when a thread is in state S0, gdb always prints a good backtrace when a thread is in state S1, gdb always prints a bad backtrace the thread is in S0 on some runs and S1 on some runs But it is a little dangerous to extrapolate from x86-linux to sparc-solaris so I am hoping to see the gdb.log for the FAIL result in that test. Michael C