public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "howarth at nitro dot med.uc.edu" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug target/55610] New: cc1 is calling munmap() on part of itself on darwin Date: Thu, 06 Dec 2012 15:19:00 -0000 [thread overview] Message-ID: <bug-55610-4@http.gcc.gnu.org/bugzilla/> (raw) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55610 Bug #: 55610 Summary: cc1 is calling munmap() on part of itself on darwin Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned@gcc.gnu.org ReportedBy: howarth@nitro.med.uc.edu The use of the dragonegg.so plugin with the LLVMPolly.so plugin exposes a flaw where when dyld queries for free memory it is getting a block in the middle of gcc4.7's __DATA segment. The cc1 binary has a 1GB __DATA segment which is huge, but should work, but somehow LLVMPolly.so is being loaded into the middle of the cc1's DATA segment. That causes problems with lazy binding because dyld has a data structure to map from an address to an image. That data structure assumes mach-o images do not overlap. So when dyld is trying to find which image is requesting the lazy binding, it thinks it is cc1 when in fact LLVMPolly.so is requesting the lazy binding. This leads to the binding error. Why does this cc1 have such a huge __DATA segment? Most of the room is in the __bss12 section. Is there some code that calls vm_deallocate on the interior of the __DATA segment? size -l /sw/lib/gcc4.7/libexec/gcc/x86_64-apple-darwin12.2.0/4.7.2/cc1 Segment __PAGEZERO: 4294967296 (vmaddr 0x0 fileoff 0) Segment __TEXT: 11014144 (vmaddr 0x100000000 fileoff 0) Section __text: 8725244 (addr 0x100000c80 offset 3200) Section __text_startup: 5 (addr 0x100852f80 offset 8728448) Section __text_cold: 69721 (addr 0x100852f88 offset 8728456) Section __stubs: 984 (addr 0x100863fe2 offset 8798178) Section __stub_helper: 1656 (addr 0x1008643bc offset 8799164) Section __cstring: 573443 (addr 0x100864a38 offset 8800824) Section __const: 534272 (addr 0x1008f0a40 offset 9374272) Section __eh_frame: 1105584 (addr 0x100973140 offset 9908544) total 11010909 Segment __DATA: 1075826688 (vmaddr 0x100a81000 fileoff 11014144) Section __got: 816 (addr 0x100a81000 offset 11014144) Section __nl_symbol_ptr: 16 (addr 0x100a81330 offset 11014960) Section __la_symbol_ptr: 1312 (addr 0x100a81340 offset 11014976) Section __const: 598856 (addr 0x100a81860 offset 11016288) Section __data: 41152 (addr 0x100b13bc0 offset 11615168) Section __static_data: 136 (addr 0x100b1dc80 offset 11656320) Section __pu_bss5: 1202272 (addr 0x100b1dd20 offset 0) Section __bss4: 792 (addr 0x100c43580 offset 0) Section __bss2: 1640 (addr 0x100c43898 offset 0) Section __bss0: 26 (addr 0x100c43f00 offset 0) Section __pu_bss4: 112 (addr 0x100c43f20 offset 0) Section __pu_bss0: 5 (addr 0x100c43f90 offset 0) Section __common: 24 (addr 0x100c43f98 offset 0) Section __pu_bss2: 496 (addr 0x100c43fb0 offset 0) Section __bss12: 1073741824 (addr 0x100c45000 offset 0) Section __bss5: 221067 (addr 0x140c45000 offset 0) Section __bss3: 7632 (addr 0x140c7af90 offset 0) Section __pu_bss3: 1432 (addr 0x140c7cd60 offset 0) total 1075819610 Segment __LINKEDIT: 3719168 (vmaddr 0x140c7e000 fileoff 11661312) For the FSF gcc 4.7.2/dragonegg/LLVMPolly.so combination cc1 is calling munmap() on part of itself which is not legal. If we skip over that munmap, the program runs fine. (gdb) set env DYLD_PRINT_SEGMENTS (gdb) br munmap (gdb) r dyld: Main executable mapped /sw/lib/gcc4.7/libexec/gcc/x86_64-apple-darwin12.2.0/4.7.2/cc1 __PAGEZERO at 0x00000000->0x100000000 __TEXT at 0x100000000->0x100A81000 __DATA at 0x100A81000->0x140C7E000 __LINKEDIT at 0x140C7E000->0x14100A000 ... Breakpoint 14, 0x00007fff86b94fbc in munmap () 1: x/i $pc 0x7fff86b94fbc <munmap>: mov $0x2000049,%eax $17 = 0x14122e000 $18 = 0xd2000 (gdb) c Continuing. Breakpoint 14, 0x00007fff86b94fbc in munmap () 1: x/i $pc 0x7fff86b94fbc <munmap>: mov $0x2000049,%eax $19 = 0x141400000 $20 = 0x2e000 (gdb) c Continuing. Breakpoint 14, 0x00007fff86b94fbc in munmap () 1: x/i $pc 0x7fff86b94fbc <munmap>: mov $0x2000049,%eax $21 = 0x141400000 $22 = 0x400000 (gdb) c Continuing. Breakpoint 14, 0x00007fff86b94fbc in munmap () 1: x/i $pc 0x7fff86b94fbc <munmap>: mov $0x2000049,%eax $23 = 0x142000000 $24 = 0x400000 (gdb) c Continuing. Breakpoint 14, 0x00007fff86b94fbc in munmap () 1: x/i $pc 0x7fff86b94fbc <munmap>: mov $0x2000049,%eax $26 = 0x144ba3000 $27 = 0x5d000 (gdb) c Continuing. Breakpoint 14, 0x00007fff86b94fbc in munmap () 1: x/i $pc 0x7fff86b94fbc <munmap>: mov $0x2000049,%eax $28 = 0x144d00000 $29 = 0xa3000 (gdb) c Continuing. GNU C (GCC) version 4.7.2 (x86_64-apple-darwin12.2.0) compiled by GNU C version 4.7.2, GMP version 5.0.5, MPFR version 3.1.1, MPC version 1.0.1 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Versions of loaded plugins: dragonegg: 3.2svn ignoring nonexistent directory +"/sw/lib/gcc4.7/lib/gcc/x86_64-apple-darwin12.2.0/4.7.2/../../../../x86_64-apple-darwin12.2.0/include" #include "..." search starts here: #include <...> search starts here: /sw/lib/gcc4.7/lib/gcc/x86_64-apple-darwin12.2.0/4.7.2/include /usr/local/include /sw/lib/gcc4.7/include /sw/lib/gcc4.7/lib/gcc/x86_64-apple-darwin12.2.0/4.7.2/include-fixed /usr/include /System/Library/Frameworks /Library/Frameworks End of search list. GNU C (GCC) version 4.7.2 (x86_64-apple-darwin12.2.0) compiled by GNU C version 4.7.2, GMP version 5.0.5, MPFR version 3.1.1, MPC version 1.0.1 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Versions of loaded plugins: dragonegg: 3.2svn Compiler executable checksum: 5da987f9ed3a860be7067d00a0e39a8f Breakpoint 14, 0x00007fff86b94fbc in munmap () 1: x/i $pc 0x7fff86b94fbc <munmap>: mov $0x2000049,%eax $30 = 0x100c45000 $31 = 0x40000000 (gdb) bt #0 0x00007fff86b94fbc in munmap () #1 0x0000000100808efc in darwin_gt_pch_use_address (addr=Cannot access memory at address 0xffffffff 0x0, sz=<value temporarily unavailable, due to optimizations>, fd=-1, off=0) at +../../gcc-4.7.2/gcc/config/host-darwin.c:60 Previous frame inner to this frame (gdb could not unwind past this frame) (gdb) info shared 0x0000000100808efc 5 cc1 - 0x100000000 exec Y Y +/sw/lib/gcc4.7/libexec/gcc/x86_64-apple-darwin12.2.0/4.7.2/cc1 (offset 0x0) Note the address range being unmapped (0x100c45000 - 0x140c45000) which is all in the __DATA segment of cc1: __DATA at 0x100A81000->0x140C7E000 gdb, shows that darwin_gt_pch_use_address is being called with parameters darwin_gt_pch_use_address(NULL, 0, -1, 0); maybe it was a feature in the 32-bit days to free up the space that would have been used by pch if pch was not +active. But for 64-bits there is no shortage of address space. This code also only worked in the past because cc1 did not dlopen() anything. Now that it is, the hole in the +__DATA segment is causing problems. Nick says this goes to Mike Stump to fix it to not unmap.
next reply other threads:[~2012-12-06 15:19 UTC|newest] Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top 2012-12-06 15:19 howarth at nitro dot med.uc.edu [this message] 2012-12-06 15:25 ` [Bug target/55610] " howarth at nitro dot med.uc.edu 2012-12-06 15:28 ` howarth at nitro dot med.uc.edu 2012-12-06 23:58 ` mrs at gcc dot gnu.org 2012-12-07 17:35 ` howarth at nitro dot med.uc.edu 2012-12-07 18:03 ` howarth at nitro dot med.uc.edu 2021-11-11 15:49 ` egallager at gcc dot gnu.org 2021-11-11 15:55 ` iains at gcc dot gnu.org 2021-12-02 19:45 ` cvs-commit at gcc dot gnu.org 2021-12-20 4:05 ` egallager at gcc dot gnu.org 2023-05-16 19:18 ` iains at gcc dot gnu.org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-55610-4@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
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).