2015-12-11 22:55:23 +00:00
|
|
|
/* LINTLIBRARY */
|
|
|
|
/*-
|
|
|
|
* Copyright 1996-1998 John D. Polstra.
|
2017-08-10 14:18:09 +00:00
|
|
|
* Copyright (c) 2015-2017 Ruslan Bukin <br@bsdpad.com>
|
2015-12-11 22:55:23 +00:00
|
|
|
* All rights reserved.
|
|
|
|
*
|
|
|
|
* Portions of this software were developed by SRI International and the
|
|
|
|
* University of Cambridge Computer Laboratory under DARPA/AFRL contract
|
|
|
|
* FA8750-10-C-0237 ("CTSRD"), as part of the DARPA CRASH research programme.
|
|
|
|
*
|
|
|
|
* Portions of this software were developed by the University of Cambridge
|
|
|
|
* Computer Laboratory as part of the CTSRD Project, with support from the
|
|
|
|
* UK Higher Education Innovation Fund (HEIF).
|
|
|
|
*
|
|
|
|
* Redistribution and use in source and binary forms, with or without
|
|
|
|
* modification, are permitted provided that the following conditions
|
|
|
|
* are met:
|
|
|
|
* 1. Redistributions of source code must retain the above copyright
|
|
|
|
* notice, this list of conditions and the following disclaimer.
|
|
|
|
* 2. Redistributions in binary form must reproduce the above copyright
|
|
|
|
* notice, this list of conditions and the following disclaimer in the
|
|
|
|
* documentation and/or other materials provided with the distribution.
|
|
|
|
*
|
|
|
|
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
|
|
|
|
* IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
|
|
|
|
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
|
|
|
|
* IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
|
|
|
|
* INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
|
|
|
|
* NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
|
|
|
|
* DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
|
|
|
|
* THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
|
|
|
|
* (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
|
|
|
|
* THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <sys/cdefs.h>
|
|
|
|
__FBSDID("$FreeBSD$");
|
|
|
|
|
|
|
|
#include "libc_private.h"
|
csu: move common code to libc
Why? Most trivial point, it shaves around 600 bytes from the dynamic
binaries on amd64. Less trivial, the removed code is no longer part of
the ABI, and we can ship updates to it with libc updates. Right now most
of the csu is linked into the binaries and require us to do somewhat
tricky ABI compat when it needs to change. For instance, the init_array
change would be much simpler and does not require note tagging if we
have init calling code in libc.
This could be improved more, by splitting dynamic and static
initialization. For instance, &_DYNAMIC tests can be removed then.
Such change, nonetheless, would require building libc three times.
I left this for later, after this change stabilizes, if ever.
Reviewed by: markj
Discussed with: jrtc27 (some objections, see the review), imp
Tested by: markj (aarch64)
Sponsored by: The FreeBSD Foundation
MFC after: 3 weeks
Differential revision: https://reviews.freebsd.org/D37220
2022-10-30 23:47:44 +00:00
|
|
|
#include "csu_common.h"
|
2015-12-11 22:55:23 +00:00
|
|
|
|
csu: move common code to libc
Why? Most trivial point, it shaves around 600 bytes from the dynamic
binaries on amd64. Less trivial, the removed code is no longer part of
the ABI, and we can ship updates to it with libc updates. Right now most
of the csu is linked into the binaries and require us to do somewhat
tricky ABI compat when it needs to change. For instance, the init_array
change would be much simpler and does not require note tagging if we
have init calling code in libc.
This could be improved more, by splitting dynamic and static
initialization. For instance, &_DYNAMIC tests can be removed then.
Such change, nonetheless, would require building libc three times.
I left this for later, after this change stabilizes, if ever.
Reviewed by: markj
Discussed with: jrtc27 (some objections, see the review), imp
Tested by: markj (aarch64)
Sponsored by: The FreeBSD Foundation
MFC after: 3 weeks
Differential revision: https://reviews.freebsd.org/D37220
2022-10-30 23:47:44 +00:00
|
|
|
void __start(int argc, char **argv, char **env, void (*cleanup)(void)) __dead2;
|
2015-12-11 22:55:23 +00:00
|
|
|
|
|
|
|
void
|
|
|
|
__start(int argc, char **argv, char **env, void (*cleanup)(void))
|
|
|
|
{
|
|
|
|
#ifdef GCRT
|
csu: move common code to libc
Why? Most trivial point, it shaves around 600 bytes from the dynamic
binaries on amd64. Less trivial, the removed code is no longer part of
the ABI, and we can ship updates to it with libc updates. Right now most
of the csu is linked into the binaries and require us to do somewhat
tricky ABI compat when it needs to change. For instance, the init_array
change would be much simpler and does not require note tagging if we
have init calling code in libc.
This could be improved more, by splitting dynamic and static
initialization. For instance, &_DYNAMIC tests can be removed then.
Such change, nonetheless, would require building libc three times.
I left this for later, after this change stabilizes, if ever.
Reviewed by: markj
Discussed with: jrtc27 (some objections, see the review), imp
Tested by: markj (aarch64)
Sponsored by: The FreeBSD Foundation
MFC after: 3 weeks
Differential revision: https://reviews.freebsd.org/D37220
2022-10-30 23:47:44 +00:00
|
|
|
__libc_start1_gcrt(argc, argv, env, cleanup, main, &eprol, &etext);
|
2015-12-11 22:55:23 +00:00
|
|
|
__asm__("eprol:");
|
csu: move common code to libc
Why? Most trivial point, it shaves around 600 bytes from the dynamic
binaries on amd64. Less trivial, the removed code is no longer part of
the ABI, and we can ship updates to it with libc updates. Right now most
of the csu is linked into the binaries and require us to do somewhat
tricky ABI compat when it needs to change. For instance, the init_array
change would be much simpler and does not require note tagging if we
have init calling code in libc.
This could be improved more, by splitting dynamic and static
initialization. For instance, &_DYNAMIC tests can be removed then.
Such change, nonetheless, would require building libc three times.
I left this for later, after this change stabilizes, if ever.
Reviewed by: markj
Discussed with: jrtc27 (some objections, see the review), imp
Tested by: markj (aarch64)
Sponsored by: The FreeBSD Foundation
MFC after: 3 weeks
Differential revision: https://reviews.freebsd.org/D37220
2022-10-30 23:47:44 +00:00
|
|
|
#else
|
|
|
|
__libc_start1(argc, argv, env, cleanup, main);
|
2015-12-11 22:55:23 +00:00
|
|
|
#endif
|
|
|
|
}
|