This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: Replacing assembly-implemented glibc functions to C-implemented,how to
- From: Ángel González <keisial at gmail dot com>
- To: "Journeyer J. Joh" <oosaprogrammer at gmail dot com>
- Cc: libc-help at sourceware dot org
- Date: Sun, 01 Jul 2012 19:12:21 +0200
- Subject: Re: Replacing assembly-implemented glibc functions to C-implemented,how to
- References: <CALYKT1htqbzOTGXKzRQP9CZO4hNnkEXey4b7nchfJvhRVaVYKA@mail.gmail.com>
On 01/07/12 14:51, Journeyer J. Joh wrote:
> Hello list,
>
> I am now checking all assembly-implemented parts from glibc.
> I need to replace all of them with C funcions so that I can prepare an
> architecture independent glibc.
>
> In the header file cdefs.h ,in misc/sys of glibc, I found the macro __REDIRECT.
>
> It seems that __REDIRECT redirects C function name to the Assembly
> function name.
>
> And there is a comment about this.
>
> 175 /* __asm__ ("xyz") is used throughout the headers to rename functions
> 176 at the assembly language level. This is wrapped by the __REDIRECT
> 177 macro, in order to support compilers that can do this some other
> 178 way. When compilers don't support asm-names at all, we have to do
> 179 preprocessor tricks instead (which don't have exactly the right
> 180 semantics, but it's the best we can do).
> 181
> 182 Example:
> 183 int __REDIRECT(setpgrp, (__pid_t pid, __pid_t pgrp), setpgid); */
>
>
> But I cannot understand the exact meaning of the comment above.
>
> Could someone explain me how I can get rid of all assembly-implemented
> functions from glibc?
void function() __asm__ ("xyz")
Specifies an assembler name of xyz for function. It isn't providing
assembler code.
So you can keep it. It doesn't add binary dependencies.
> Should I enable the part below and add some plugin to the compiler?
No.
Note you'll need to keep syscall() in assembler. System calls are
architecture specific.