public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: libc-alpha@sourceware.org
Cc: Samuel Thibault <samuel.thibault@ens-lyon.org>, commit-hurd@gnu.org
Subject: [hurd,commited] hurd: Rework sbrk
Date: Wed,  5 Aug 2020 23:56:08 +0200	[thread overview]
Message-ID: <20200805215608.387555-1-samuel.thibault@ens-lyon.org> (raw)

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.
---
 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(-)
 create mode 100644 sysdeps/mach/hurd/i386/vm_param.h

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 */
-- 
2.27.0


                 reply	other threads:[~2020-08-05 21:56 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=20200805215608.387555-1-samuel.thibault@ens-lyon.org \
    --to=samuel.thibault@ens-lyon.org \
    --cc=commit-hurd@gnu.org \
    --cc=libc-alpha@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: link
Be 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).