tech-toolchain archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: gcc 4.8.1 and precompiled header support for NetBSD hosts



In article <20130911132009.GA7586%mail.duskware.de@localhost>,
Martin Husemann  <martin%duskware.de@localhost> wrote:
>-=-=-=-=-=-
>
>Hey folks,
>
>originating from yet more vax compiler issues I started to look at the newest
>gcc we have in pkgsrc - and as a sanity check did so on sparc64 (compiling
>natively there).
>
>It did not build - so I did a bit of debugging and filed a few upstream
>tickets (58370, 58379, 58381) and am about to commit patches using those
>changes for pkgsrc.
>
>However, one bit is still open, and I'd like to get feedback on the hack
>before pushing it upstream: for precompiled header files gcc assumes it
>can pick a steady (over multiple compiler runs) address and mmap a part of
>the precompiled header file at that address. No relocation supported.
>
>I told them what I think of this design
>(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58379)
>but we have to live with it for now.
>
>Attached is host-netbsd.c, which picks this address for various archs and
>seems to work at least on sparc64, vax, i386 and amd64 (didn't get around to
>test others). Also attached is a tiny test program to test the effect without
>building gcc.
>
>Is there a better way? Should we pick different VAs? (I mostly cloned the ones
>from OpenBSD, adjusting vax and mips for the 2GB border.) I don't know if the
>preprocessor symbols are correct (this is about the host of the compiler).

I don't think it is worth thinking too much about it right now, so I suggest
that we push this upstream and ask them to improve their design so that
the file can be mapped anywhere instead of needing fixed addresses.

christos



Home | Main Index | Thread Index | Old Index