Opened 13 years ago

Closed 13 years ago

Last modified 13 years ago

#8421 closed bug (fixed)

GCC4 precompiled headers are broken

Reported by: hamish Owned by: bonefish
Priority: normal Milestone: R1
Component: Build System Version: R1/Development
Keywords: gcc precompiled headers pch gsoc2012 Cc:
Blocked By: Blocking:
Platform: All

Description

When trying to compile a source file against a precompiled header, cc1 segfaults.

Attachments (2)

0001-Fix-precompiled-header-support.patch (3.7 KB ) - added by hamish 13 years ago.
0001-mmap-should-try-to-honour-the-address-hint.patch (901 bytes ) - added by hamish 13 years ago.

Download all attachments as: .zip

Change History (13)

comment:1 by hamish, 13 years ago

patch: 01

comment:2 by hamish, 13 years ago

GCC's PCH implementation relies on mmap honouring the address hint exactly when MAP_FIXED is not set. POSIX does not require this, so I added added a workaround in GCC that tests whether the desired region is free using create_area with B_EXACT_ADDRESS, and then mmaps with MAP_FIXED.

comment:3 by bonefish, 13 years ago

I'd rather see our mmap() implementation be adjusted. Unless I miss something that should be rather simple, too -- just use B_BASE_ADDRESS in this case.

At any rate, nice job tracking the issue down!

comment:4 by hamish, 13 years ago

Using B_BASE_ADDRESS does indeed fix the issue. Though it would be nice to search lower addresses for a free region too. What about if I added a B_NEAREST_ADDRESS?

in reply to:  4 comment:5 by bonefish, 13 years ago

Replying to hamish:

Using B_BASE_ADDRESS does indeed fix the issue. Though it would be nice to search lower addresses for a free region too. What about if I added a B_NEAREST_ADDRESS?

I'm not really sure I see when/why one would want to use that feature. B_BASE_ADDRESS is useful for managing the address space (so would be a B_TOP_ADDRESS which would search backwards), but I fail to imaging a use for B_NEAREST_ADDRESS. It would basically mean that some address has ideal properties and the farther away an address the worse its properties get.

comment:6 by hamish, 13 years ago

Well if mmap() is to honour the address hint it would make sense for it to try to find the nearest free space, regardless of direction. If B_BASE_ADDRESS is used in a situation where there is free space nearby below the address, but the free space above the address is far away, the returned address will be further away from the hint than necessary.

comment:7 by bonefish, 13 years ago

Yes, it would make sense to find the nearest free space, but it makes just as much sense to find the nearest free space in one direction. POSIX specifies the given address to be a suggestion to find a suitable near address. So even ignoring the hint, as we currently do, would be OK. Neither the Linux nor the FreeBSD man page say that the respective kernel finds the nearest address. I find using B_BASE_ADDRESS a perfectly adequate solution (probably the most relevant property is actually using the given address if it is usable, anyway -- I guess that's what gcc relies on either intentionally or by mistake).

Sure, if we already had a B_NEAREST_ADDRESS it would be fine to use that, but I wouldn't just add it for that purpose. Particularly because -- as I wrote before -- I don't see any actual use case for it.

comment:8 by hamish, 13 years ago

OK, fair enough. This way is also much less work, so I'm not complaining. :)

comment:9 by bonefish, 13 years ago

Patch looks good. I don't know, when I'll get to apply it. So, if anyone wants to beat me to it, please do so.

comment:10 by korli, 13 years ago

Resolution: fixed
Status: newclosed

Applied in hrev43901. Thanks!

comment:11 by mmadia, 13 years ago

Keywords: gsoc2012 added
Note: See TracTickets for help on using tickets.