From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30004 invoked by alias); 19 Jan 2003 14:38:36 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 29959 invoked from network); 19 Jan 2003 14:38:35 -0000 Received: from unknown (HELO caip.rutgers.edu) (128.6.236.10) by 172.16.49.205 with SMTP; 19 Jan 2003 14:38:35 -0000 Received: (from ghazi@localhost) by caip.rutgers.edu (8.9.3/8.9.3) id JAA21430; Sun, 19 Jan 2003 09:38:29 -0500 (EST) Date: Sun, 19 Jan 2003 17:37:00 -0000 From: "Kaveh R. Ghazi" Message-Id: <200301191438.JAA21430@caip.rutgers.edu> To: geoffk@geoffk.org Subject: Re: PCH tests fail on sparc-sun-solaris2.7 Cc: gcc-bugs@gcc.gnu.org, gcc@gcc.gnu.org References: <200301132116.QAA28609@caip.rutgers.edu> <200301140034.h0E0Y5L23173@desire.geoffk.org> X-SW-Source: 2003-01/txt/msg00896.txt.bz2 > From: Geoff Keating > > > Date: Mon, 13 Jan 2003 16:16:50 -0500 (EST) > > From: "Kaveh R. Ghazi" > > > pretty much all of the PCH tests fail on sparc-sun-solaris2.7. > > Looking in the log file, all of the error messages look like this: > > > > > gcc.dg/pch/global-1.c:-71: sorry, unimplemented: had to relocate PCH > > > gcc.dg/pch/global-1.c:-71: internal compiler error: Segmentation Fault > > > > this is certainly a host-specific problem. If every test is failing > with this message, that means the heuristic in gt_pch_save ("Try to > arrange things...") isn't working. It'd be possible to implement the > relocation functionality, but this would slow down PCH use on your > system a lot, it'd be better if you could first work out what the > problem with the heuristic is. If I understand things correctly, gt_pch_save is called when the PCH file is generated. However the crash happens later when the PCH file is attempted to be used. So it's the PCH generation that goes wrong? I ran the generation under gdb and set a breakpoint in gt_pch_save. When I get past the mmap, the mmi struct contains: (gdb) print mmi $1 = {offset = 1, size = 311296, preferred_base = 0x5b} I.e. mmap does not return -1 indicating an error. I'm not sure if 0x5b is a suspicious address though. I can't access it. (gdb) print (char*)mmi.preferred_base $4 = 0x5b
It then gets immediately munmapped and the process continues supposedly successfully until program exit. I'm not sure what constitutes a correct "heuristic". What should I look for? Thanks, --Kaveh -- Kaveh R. Ghazi ghazi@caip.rutgers.edu