public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug preprocessor/58379] New: default mmap based implementation (mmap_gt_pch_get_address/mmap_gt_pch_use_address) is useless
@ 2013-09-10 10:19 martin at netbsd dot org
  2013-09-10 11:32 ` [Bug preprocessor/58379] " rguenth at gcc dot gnu.org
                   ` (2 more replies)
  0 siblings, 3 replies; 4+ messages in thread
From: martin at netbsd dot org @ 2013-09-10 10:19 UTC (permalink / raw)
  To: gcc-bugs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58379

            Bug ID: 58379
           Summary: default mmap based implementation
                    (mmap_gt_pch_get_address/mmap_gt_pch_use_address) is
                    useless
           Product: gcc
           Version: 4.8.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: preprocessor
          Assignee: unassigned at gcc dot gnu.org
          Reporter: martin at netbsd dot org

I may be misunderstanding the interface - but it looks to me like it lets the
kernel chose an arbitrary mapping address for different compiler invocations
but relies on the assumption that the returned address will be the same. If
not, the compiler fails with a fatal_error when trying to read a precompiled
header file ("had to relocate PCH").

I can not imagine a host system where this would work reliably (or even
typically twice in a row).

Please tell me I misunderstood, or consider disabling PCH support for host
platforms without host_hooks overriding this function.


^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug preprocessor/58379] default mmap based implementation (mmap_gt_pch_get_address/mmap_gt_pch_use_address) is useless
  2013-09-10 10:19 [Bug preprocessor/58379] New: default mmap based implementation (mmap_gt_pch_get_address/mmap_gt_pch_use_address) is useless martin at netbsd dot org
@ 2013-09-10 11:32 ` rguenth at gcc dot gnu.org
  2013-09-10 13:13 ` martin at netbsd dot org
  2021-12-08 18:21 ` pinskia at gcc dot gnu.org
  2 siblings, 0 replies; 4+ messages in thread
From: rguenth at gcc dot gnu.org @ 2013-09-10 11:32 UTC (permalink / raw)
  To: gcc-bugs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58379

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Well, it doesn't _rely_ on it - it basically makes systems where that is the
case work out of the box (every system pre address-space-randomization area).

If you have a system that randomizes then you have to re-define the hook.


^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug preprocessor/58379] default mmap based implementation (mmap_gt_pch_get_address/mmap_gt_pch_use_address) is useless
  2013-09-10 10:19 [Bug preprocessor/58379] New: default mmap based implementation (mmap_gt_pch_get_address/mmap_gt_pch_use_address) is useless martin at netbsd dot org
  2013-09-10 11:32 ` [Bug preprocessor/58379] " rguenth at gcc dot gnu.org
@ 2013-09-10 13:13 ` martin at netbsd dot org
  2021-12-08 18:21 ` pinskia at gcc dot gnu.org
  2 siblings, 0 replies; 4+ messages in thread
From: martin at netbsd dot org @ 2013-09-10 13:13 UTC (permalink / raw)
  To: gcc-bugs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58379

--- Comment #2 from Martin Husemann <martin at netbsd dot org> ---
(In reply to Richard Biener from comment #1)
> If you have a system that randomizes then you have to re-define the hook.

Besides ASLR there are various things out of control of the compiler that do
result in varying mapping adresses (like malloc using mmap instead of brk), so
chances are low in any modern system.

I'm not opposed to create a hook for NetBSD, but I have a hard time seeing a
possible sensible implementation. Look at the #ifdef cascade in
config/host-openbsd.c for a disgusting example of code that should not be in a
compiler (IMHO).

How hard is making the externalized format address neutral?


^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug preprocessor/58379] default mmap based implementation (mmap_gt_pch_get_address/mmap_gt_pch_use_address) is useless
  2013-09-10 10:19 [Bug preprocessor/58379] New: default mmap based implementation (mmap_gt_pch_get_address/mmap_gt_pch_use_address) is useless martin at netbsd dot org
  2013-09-10 11:32 ` [Bug preprocessor/58379] " rguenth at gcc dot gnu.org
  2013-09-10 13:13 ` martin at netbsd dot org
@ 2021-12-08 18:21 ` pinskia at gcc dot gnu.org
  2 siblings, 0 replies; 4+ messages in thread
From: pinskia at gcc dot gnu.org @ 2021-12-08 18:21 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58379

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=71934

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I think this is getting fixed via PR 71934.

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2021-12-08 18:21 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-09-10 10:19 [Bug preprocessor/58379] New: default mmap based implementation (mmap_gt_pch_get_address/mmap_gt_pch_use_address) is useless martin at netbsd dot org
2013-09-10 11:32 ` [Bug preprocessor/58379] " rguenth at gcc dot gnu.org
2013-09-10 13:13 ` martin at netbsd dot org
2021-12-08 18:21 ` pinskia at gcc dot gnu.org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).