Movatterモバイル変換
[0]ホーム
This is the mail archive of thelibc-alpha@sourceware.orgmailing list for theglibc project.
Re: [PATCH] i386: Add _startup_sbrk and _startup_fatal [BZ #21913]
- From: Zack Weinberg <zackw at panix dot com>
- To: "H.J. Lu" <hjl dot tools at gmail dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Mon, 7 Aug 2017 07:47:07 -0400
- Subject: Re: [PATCH] i386: Add _startup_sbrk and _startup_fatal [BZ #21913]
- Authentication-results: sourceware.org; auth=none
- References: <20170806222606.GA13700@gmail.com>
On Sun, Aug 6, 2017 at 6:26 PM, H.J. Lu <hjl.tools@gmail.com> wrote:> On Linux/x86, there are 3 ways to make a system call:>> 1. call *%gs:SYSINFO_OFFSET. This requires TLS initialization.> 2. call *_dl_sysinfo. This requires relocation of _dl_sysinfo.> 3. int $0x80. This works everywhere.>> When an object file is compiled with PIC, #1 is prefered since it is> faster than #3 and doesn't require relocation of _dl_sysinfo. For> dynamic executables, ld.so initializes TLS. However, for static> executables, before TLS is initialized by __libc_setup_tls, #3 should> be used for syscalls. This patch adds _startup_sbrk and _startup_fatal> to be used in static executables before __libc_setup_tls is called. By> default, they are defined to __sbrk and __libc_fatal, respectively. On> x86, a special _startup_sbrk is provided and _startup_fatal is turned> into ABORT_INSTRUCTION.>> Any comments?I have questions:1) When you say "Linux/x86", do you mean specifically the old 32-bitABI, or does this apply to x32 and/or x64 as well?2) This is described as fixing a bug; please add a test case. (The bugreport describes a crash during 'make install', but that's not goodenough, it should be caught by 'make check' pre-installation.)3) Couldn't we avoid adding complexity in shared code by doing startupin a slightly different order? Specifically, why can't we ensure thatTLS is initialized, at least enough of it that "call*%gs:SYSINFO_OFFSET" works, before we attempt to make any syscalls?zw
[8]ページ先頭