[uClibc] close replaced w/ __libc_close

Peter S. Mazinger ps.m at gmx.net
Thu Oct 28 22:59:41 UTC 2004


On Thu, 28 Oct 2004, Manuel Novoa III wrote:

> Hi Peter,
> 
> First, regarding part of your previous patch...
> 
> > diff -urN uClibc-0.9.26.orig/include/unistd.h
> > uClibc-0.9.26/include/unistd.h
> > --- uClibc-0.9.26.orig/include/unistd.h 2004-10-28 14:37:47.000000000
> > +0200
> > +++ uClibc-0.9.26/include/unistd.h      2004-10-28 15:18:10.000000000
> > +0200
> > @@ -302,6 +302,9 @@
> >  /* Read NBYTES into BUF from FD.  Return the
> >     number read, -1 for errors or 0 for EOF.  */
> >  extern ssize_t read (int __fd, void *__buf, size_t __nbytes) __THROW;
> > +#ifdef _LIBC
> > +extern ssize_t __libc_read (int __fd, void *__buf, size_t __nbytes) __THROW;
> > +#endif
> 
> I don't want to see special-case cruft added to the general headers.
> Also, the __libc_read replacement is just a single instance of a larger
> problem.  I'd eventually like to supply hidden alias symbols for lots
> of functions called by the library internally, and would much rather
> see an internal header (or group of them) used for the prototypes.

Agree, you have to consider though that each include has to be added to 
all of the files using these __libc_* functions.

We could do an internals.h (like in libpthread, or replace that and make 
it generic).

> On Thu, Oct 28, 2004 at 06:50:42PM +0200, Peter S. Mazinger wrote:
> > All except stdio are done (again as before, I can't understand 
> > __gcs.close, so do not know what to do)
> 
> gcs is my abbreviation for "glibc custom stream".  If custom streams
> are enabled in the uClibc configuration, then read, write, seek,
> and close are accessed indirectly.  Otherwise they are referenced
> directly.  See the related macros in stdio/_stdio.h and the functions
> in stdio/_cs_stdio.c.

I won't touch stdio, because I don't understand it ;-(

> 
> > I have seen the __attribute_hidden__ addition to cvs.
> > 
> > If we want to hide __libc_* using visibility=hidden, then this can be 
> > done, as I understand it, only if they are used exclusively in libc.
> > 
> > If this is the intention for the future, then only those parts of the 
> > patches should be applied, that do not influence libutil/libresolv....
> 
> The intention is to start using hidden symbols, as well as to use
> export maps when building the shared libs.
> 
> Also, regarding the transition to using hidden symbols internally,
> I'd rather not apply a patch per function.  That's just going to add
> lots of noise to the cvs logs.  Personally, I'd rather see the changes
> go in all at once.
>
>Manuel

Ok, who will do that at once? One function is about 1/2-2 hour work, can 
be better controlled/checked if it is done per function before applying 
it. What about replacing first step-by-step all the functions (won't 
disturb any previous functionality), and change after that all to hidden 
(in one step ;-)

I do not enforce you to do anything, it is only a proposal, you do not 
have to apply these patches at all (as you haven't about 15 of my patches 
that are "open" currently), it is your decision to do what you think is 
correct.

Regarding my uClibc approach:
1. I am interested to get uClibc smaller/load faster (regarding 
this thread make it possible to use visibility=hidden for some of the 
functions), if my patch does not "show" in that direction, then tell me 
what is wrong w/ it
2. I am interested to get uClibc more secure (ssp/pie/ldso changes like 
securevars,RELRO support)
3. Regarding the current thread I am only interested in some of the 
functions that showed up to be "problematic" (only for ssp), so I decided 
to do them generally, for ssp it can be solved w/ a 4-liner modification). 
The others will have to be "provided" by someone else, so if you don't 
accept "partly" patches it is your business, I won't provide all of them 
for sure.
IMHO: The "noise" in the cvs logs can't be a criteria for changes, but you 
can wait until I provide some of the changes, and than wait until others 
provide the rest and apply them at once.
I am sending these, because a patch sent earlier was accepted w/o any 
reaction (only Jocke finding it ok) and I have said, that I will provide 
the same for other functions. You could have objected at that time. These 
patches do the same thing only for another function.

Peter

-- 
Peter S. Mazinger <ps dot m at gmx dot net>           ID: 0xA5F059F2
Key fingerprint = 92A4 31E1 56BC 3D5A 2D08  BB6E C389 975E A5F0 59F2




More information about the uClibc mailing list