#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)
Change History (13)
by , 12 years ago
| Attachment: | 0001-Fix-precompiled-header-support.patch added |
|---|
comment:1 by , 12 years ago
| patch: | 0 → 1 |
|---|
comment:2 by , 12 years ago
comment:3 by , 12 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!
follow-up: 5 comment:4 by , 12 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?
comment:5 by , 12 years ago
Replying to hamish:
Using
B_BASE_ADDRESSdoes indeed fix the issue. Though it would be nice to search lower addresses for a free region too. What about if I added aB_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 , 12 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 , 12 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.
by , 12 years ago
| Attachment: | 0001-mmap-should-try-to-honour-the-address-hint.patch added |
|---|
comment:8 by , 12 years ago
OK, fair enough. This way is also much less work, so I'm not complaining. :)
comment:9 by , 12 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:11 by , 12 years ago
| Keywords: | gsoc2012 added |
|---|
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.