public inbox for glibc-cvs@sourceware.org help / color / mirror / Atom feed
From: Samuel Thibault <sthibaul@sourceware.org> To: glibc-cvs@sourceware.org Subject: [glibc] hurd: Rework sbrk Date: Wed, 5 Aug 2020 21:55:55 +0000 (GMT) [thread overview] Message-ID: <20200805215556.0218A3857037@sourceware.org> (raw) https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=8c6beab4e1c03ac57150241015486e3f497c17cc commit 8c6beab4e1c03ac57150241015486e3f497c17cc Author: Samuel Thibault <samuel.thibault@ens-lyon.org> Date: Wed Aug 5 23:48:58 2020 +0200 hurd: Rework sbrk Making the brk start exactly at the end of the main application binary was requiring to get it through the _end symbol, which does not work any more with recent toolchains, and actually produces in libc.so a confusing external _end symbol that produces odd results, see https://sourceware.org/bugzilla/show_bug.cgi?id=23499 Trying to do so is quite outdated anyway with the tendency for address randomization. Using _end was also allowing to include the main binary data within the RLIMIT_DATA, but this also seems outdated with dynamic library loading, and nowadays' memory consumption via malloc and mmap rather than statically-allocated data. This adds a BRK_START macro in <vm_param.h> that just tells where we want to start the brk, and thus removes the _end symbol. * sysdeps/mach/hurd/i386/vm_param.h: New file. * sysdeps/mach/hurd/brk.c: Use BRK_START as brk start instead of _end. Also ignore __data_start. * hurd/Versions: Remove _end symbol. * sysdeps/mach/hurd/i386/libc.abilist: Remove _end symbol. Diff: --- hurd/Versions | 3 --- sysdeps/mach/hurd/brk.c | 16 ++++++++-------- sysdeps/mach/hurd/i386/libc.abilist | 1 - sysdeps/mach/hurd/i386/vm_param.h | 24 ++++++++++++++++++++++++ 4 files changed, 32 insertions(+), 12 deletions(-) diff --git a/hurd/Versions b/hurd/Versions index f5e8b8cb32..9b5448ab2f 100644 --- a/hurd/Versions +++ b/hurd/Versions @@ -1,8 +1,5 @@ libc { GLIBC_2.0 { - # necessary for the Hurd brk implementation - _end; - # variables used in macros & inline functions __hurd_threadvar_stack_mask; __hurd_threadvar_stack_offset; diff --git a/sysdeps/mach/hurd/brk.c b/sysdeps/mach/hurd/brk.c index 4fac03fcc3..a6d4880028 100644 --- a/sysdeps/mach/hurd/brk.c +++ b/sysdeps/mach/hurd/brk.c @@ -19,6 +19,7 @@ #include <hurd.h> #include <hurd/resource.h> #include <cthreads.h> /* For `struct mutex'. */ +#include <vm_param.h> /* Initial maximum size of the data segment (this is arbitrary). */ @@ -39,9 +40,7 @@ weak_alias (_hurd_brk, ___brk_addr) struct mutex _hurd_brk_lock; -extern int __data_start, _end; -weak_extern (__data_start) -static vm_address_t static_data_start; +static vm_address_t brk_start; /* Set the end of the process's data space to INADDR. @@ -91,7 +90,7 @@ _hurd_set_brk (vm_address_t addr) rlimit = _hurd_rlimits[RLIMIT_DATA].rlim_cur; __mutex_unlock (&_hurd_rlimit_lock); - if (addr - static_data_start > rlimit) + if (addr - brk_start > rlimit) { /* Need to increase the resource limit. */ errno = ENOMEM; @@ -138,17 +137,18 @@ init_brk (void) __mutex_init (&_hurd_brk_lock); - static_data_start = (vm_address_t) (&__data_start ?: &_end); + brk_start = (vm_address_t) BRK_START; /* If _hurd_brk is already set, don't change it. The assumption is that it was set in a previous run before something like Emacs's unexec was called and dumped all the data up to the break at that point. */ - if (_hurd_brk == 0) - _hurd_brk = (vm_address_t) &_end; + if (_hurd_brk == 0) { + _hurd_brk = (vm_address_t) BRK_START; + } pagend = round_page (_hurd_brk); - _hurd_data_end = round_page (static_data_start + DATA_SIZE); + _hurd_data_end = round_page (brk_start + DATA_SIZE); if (pagend < _hurd_data_end) { diff --git a/sysdeps/mach/hurd/i386/libc.abilist b/sysdeps/mach/hurd/i386/libc.abilist index 5f6154d518..72537218ba 100644 --- a/sysdeps/mach/hurd/i386/libc.abilist +++ b/sysdeps/mach/hurd/i386/libc.abilist @@ -554,7 +554,6 @@ GLIBC_2.2.6 __xstat64 F GLIBC_2.2.6 _authenticate F GLIBC_2.2.6 _dl_mcount_wrapper F GLIBC_2.2.6 _dl_mcount_wrapper_check F -GLIBC_2.2.6 _end D 0x0 GLIBC_2.2.6 _environ D 0x4 GLIBC_2.2.6 _exit F GLIBC_2.2.6 _flushlbf F diff --git a/sysdeps/mach/hurd/i386/vm_param.h b/sysdeps/mach/hurd/i386/vm_param.h new file mode 100644 index 0000000000..96230bc149 --- /dev/null +++ b/sysdeps/mach/hurd/i386/vm_param.h @@ -0,0 +1,24 @@ +/* Copyright (C) 2020 Free Software Foundation, Inc. + This file is part of the GNU C Library. + + The GNU C Library is free software; you can redistribute it and/or + modify it under the terms of the GNU Lesser General Public + License as published by the Free Software Foundation; either + version 2.1 of the License, or (at your option) any later version. + + The GNU C Library is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + Lesser General Public License for more details. + + You should have received a copy of the GNU Lesser General Public + License along with the GNU C Library; if not, see + <https://www.gnu.org/licenses/>. */ + +#ifndef _I386_VM_PARAM_H +#define _I386_VM_PARAM_H + +/* Arbitrary start of the brk. This is after usual binary and library mappings. */ +#define BRK_START 0x10000000 + +#endif /* i386/vm_param.h */
reply other threads:[~2020-08-05 21:55 UTC|newest] Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20200805215556.0218A3857037@sourceware.org \ --to=sthibaul@sourceware.org \ --cc=glibc-cvs@sourceware.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).