This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GCC's -fsplit-stack disturbing Mach's vm_allocate


Justus Winter, le Sat 26 Apr 2014 08:53:08 +0200, a écrit :
> task130(pid1182)->vm_map (0 49880 0 1    133<--160(pid1182) 0 1 5 7 1) = 0 2453504
> 
> We map that somewhere.
> 
> task130(pid1182)->mach_port_deallocate (pn{ 25}) = 0 
> 
> Deallocate the port.  Again, for some strange reason 133 == pn{ 25}.
> 
>   158<--157(pid1182)->io_map_request () = 0    133<--162(pid1182)  (null)
> 
> Some more io_map.
> 
> task130(pid1182)->vm_map (2498560 8192 0 0    133<--162(pid1182) 40960 1 3 7 1) = 0x3 ((os/kern) no space available) 
> task130(pid1182)->vm_deallocate (2498560 8192) = 0 
> 
> Hum?
> 
> task130(pid1182)->vm_map (2498560 8192 0 0    133<--162(pid1182) 40960 1 3 7 1) = 0 2498560
> task130(pid1182)->mach_port_deallocate (pn{ 25}) = 0 
> 
> Success!

See the logic in elf/dl-load.c's _dl_map_object_from_fd and
sysdeps/mach/hurd/mmap.c. _dl_map_object_from_fd first gets somewhere
to map the SO (first __mmap call), and then, if bss is big, it maps
anonymous pages for it with MAP_FIXED, replacing the bss part of the SO:

2453504 + 49880 = 0x2632d8
2498560 + 8192 = 0x264000

So this seems like just normal behavior.

Samuel


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]