From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20983 invoked by alias); 11 Nov 2003 16:50:38 -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 20962 invoked from network); 11 Nov 2003 16:50:37 -0000 Received: from unknown (HELO localhost.redhat.com) (66.30.197.194) by sources.redhat.com with SMTP; 11 Nov 2003 16:50:37 -0000 Received: by localhost.redhat.com (Postfix, from userid 469) id C01391A42DB; Tue, 11 Nov 2003 11:50:36 -0500 (EST) From: Elena Zannoni MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16305.4956.712755.533037@localhost.redhat.com> Date: Tue, 11 Nov 2003 16:50:00 -0000 To: mec.gnu@mindspring.com (Michael Elizabeth Chastain) Cc: ezannoni@redhat.com, brobecker@gnat.com, gdb-patches@sources.redhat.com Subject: Re: [rfc] msymbol.size In-Reply-To: <20031111162951.2FC244B361@berman.michael-chastain.com> References: <20031111162951.2FC244B361@berman.michael-chastain.com> X-SW-Source: 2003-11/txt/msg00215.txt.bz2 Michael Elizabeth Chastain writes: > [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. I don't think I have any machines around here with SUN's compiler on them. :-( I tried a break main - run on ls and /usr/bin/ccs/help, and saw no end_symtab printed either. But there is no symbol info there, I think. > > 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 > I've seen that too on Linux. > 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. > I hope this was clear, on Solaris I got no differences in the pthreads tests before and after the patch. There were failures in the backtraces, but they were failing the same way in both runs. But Joel did. elena > Michael C