Re: PCH tests fail on sparc-sun-solaris2.7

[Geoff Keating <geoffk at geoffk dot org>]

> Date: Sun, 19 Jan 2003 09:38:29 -0500 (EST)
> From: "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu>

>  > From: Geoff Keating <geoffk@geoffk.org>
>  > 
>  > > Date: Mon, 13 Jan 2003 16:16:50 -0500 (EST)
>  > > From: "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu>
>  > 
>  > > 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?

The way that PCH works is that it creates and saves a memory image,
then loads it in when the PCH is used.  There are all kinds of
pointers in this image, so it matters where it gets loaded.  The
saving code tries to guess a place to load it, and initially sets the
pointers to be good for that location.  The 'sorry' is because I never
did get around to implementing the code that relocates the image; it's
not hard to do (all the tricky framework stuff is done), but it's not
a high priority since it works without relocation on most systems
(well, linux and Darwin) every time.  The relocation would be
expensive, because it'd have to write to nearly every page in the
loaded image.

> 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.

That's very weird.  0x5b can't possibly be right, it's got to be
page-aligned.

> (gdb) print (char*)mmi.preferred_base
> $4 = 0x5b <Address 0x5b out of bounds>
> 
> 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?

The code is looking for a place where it can mmap 311296 bytes when it
loads the PCH file.

-- 
- Geoffrey Keating <geoffk@geoffk.org>