Re: [git commit future 1/1] dl-string.h: change IS_IN_libdl guard to IS_IN_rtld

[Mike Frysinger]

On Sat, Mar 19, 2011 at 2:51 PM, Khem Raj wrote:
> The guard is changed to allow to be used the file in libc as well.
> Include string.h (although already included by ldso.h).

this doesnt make much sense.  if you want to use it in libc as well,
then check for libc.

#if !defined(IS_IN_libdl) && !defined(IS_IN_libc)
-mike
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: changes to ld-uClibc.so

[Mike Frysinger]

On Fri, Mar 25, 2011 at 7:53 PM, Peter Mazinger wrote:
> Hello,

your line wrapping is still screwed up

> - get all archs behave similar (currently the files were copied from one
> arch and adapted to another one, mostly inconstitenly), I tend to have
> a common file/function and show only the diffs from one arch to
>  another, use same messages for errors, use same names for functions ...

it really depends on the changes.  there are obviously many things
which cannot be shared.

> - introduce GLRO use (target is to have the only thing exported
> from ld-uClibc.so a structure with pointers to some internal functions

there are some functions which the ldso must export all the time and a
structure of function pointers wont work.  like __tls_get_addr.

> - detect pagesize and "export" to __uClibc_main.c

if you add GLRO, then simply use that

> Is there interest for this in public (should I provide the branch on 
> uclibc.org)?

branches are easy to delete, so putting your own onto uclibc.org isnt an issue
-mike
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: Dynamic linker

[Mike Frysinger]

On Thu, Mar 24, 2011 at 1:32 PM, bruce bushby wrote:
> The "prize" it turned into a bit of a group effort so I split it between
> Mark Frysinger and Joakim Tjernlund. Mark suggested a donate $100.00 to

i dont know who this Mark guy is but he sounds like a dick
-mike
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [PATCH] libdl: rudimentary locking for dlopen/dlsym/dlclose

[Mike Frysinger]

2011/3/24 Timo Teräs:
> On 03/24/2011 04:58 PM, Mike Frysinger wrote:
>> 2011/3/24 Timo Teräs:
>>> This implements big-dlfcn lock to allow multithreaded usage of
>>> dlopen/dlsym/dlclose. We should really clean up the dl code so
>>> we can use more fine grained locking or even RCU where appropriate.
>>> But at least we won't crash now.
>>
>> looks straight forward enough ... i'm assuming it actually fixes the
>> crashes you were seeing ?
>
> Yes. No crashes on my box anymore. Valgrind is happy too.

good enough for me :)

let's see what Carmelo finds out before we merge ...
-mike
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [PATCH] libdl: rudimentary locking for dlopen/dlsym/dlclose

[Mike Frysinger]

2011/3/24 Timo Teräs:
> This implements big-dlfcn lock to allow multithreaded usage of
> dlopen/dlsym/dlclose. We should really clean up the dl code so
> we can use more fine grained locking or even RCU where appropriate.
> But at least we won't crash now.

looks straight forward enough ... i'm assuming it actually fixes the
crashes you were seeing ?
-mike
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: dlopen/dlclose thread safety

[Mike Frysinger]

2011/3/24 Timo Teräs :
> On 03/24/2011 12:27 AM, Mike Frysinger wrote:
>> mmm my understanding was that each thread got its own chunk of TLS
>> area at thread creation time, and after that the ldso only existed
>> when the thread needed to know the address of its TLS.  what port are
>> you talking about exactly ?
>
> But if after startup, someone does dlopen(libfoo.so) and libfoo defines
> global TLS variables, those variables need to be allocated from the
> global TLS tables. I believe that's mostly done in _dl_add_to_slotinfo.

duh, i really should have seen that

> So. As immediate bandage aid, we probably need to add rwlock (or just
> regular mutex) to dlopen (rw)/dlsym (ro)/dlclose (rw). That should at
> least prevent crashes. But yes, more fine grained locking (or even RCU)
> would be preferable.

i think a patch to that effect with a note in the TODO of making it
suck less would be fine
-mike
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: NO_MMU archs / relation to uClinux

[Mike Frysinger]

On Wed, Mar 23, 2011 at 8:37 PM, David McCullough wrote:
> Jivin Mike Frysinger lays it down ...
>> the uClinux.org guys are just very bad at pushing anything back
>> upstream.
>
> I would beg to differ :-)  We do what we can with the small resources we
> have while making and supporting products to pay the bills.  We are not
> the uClinux.org guys though,  that would be Arcturus, we are the uClinux-dist
> guys that you talk about below, most known as SnapGear, though we have
> officially changed company names more times than most can remember :-)

damn, didnt you were trollin this list too ;).  yes, i was referring
to the uClinux-dist (i.e. you) and not Arcturus.  although i doubt
anyone outside of the small groups who have actually been to Arcturus
even knows about them.  i'd venture to guess that most everyone
associates the two as being the same.

> There are plenty of examples of large and small scale "push-back" from us
> at various times to the upstream projects (ie., kernel, openssl, openswan,
> gcc, binutils, pptp and yes, uClibc at one point).

i was making my statements based on my experience with poking through
all the packages that uclinux-dist has as i updated them in the
blackfin uclinux-dist.  lots of patches, many not terribly clean, and
not a mention in the upstream projects as to what's going on.

> As everyone knows (or should know) getting changes merged upstream can be
> time consuming and tedious, depending on the project and the maintainers
> and their particular goals.   We have limited resources and we choose our
> fights.  The uClinux-dist releases are our way or reducing the load but
> ensuring all the work we do is out there for people to find.

sorry, i didnt mean it as a slight against you, i was just stating
"this is how it is".  you guys want to make money, so that's your
prerogative.  it is certainly not my place to tell you what to do or
how to run your business.  i'm not paying you after all ;).
-mike
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [git commit future 1/1] Revert "wchar.c, iconv.c: do not include __iconv_codesets into iconv utility"

[Mike Frysinger]

On Sat, Mar 19, 2011 at 2:51 PM, Khem Raj  wrote:
> This reverts commit ad7a3878c789a15dd50e74799a02af7eef37a723.

when doing reverts, please mention the reason for it
-mike
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: generalize errno handling

[Mike Frysinger]

On Wed, Mar 23, 2011 at 5:57 PM, Peter Mazinger wrote:
>> >> the point is to not have the overhead of an indirect pointer in the
>> >> non-threaded case.  are you suggesting we force that overhead when it
>> >> is unnecessary ?
>> >
>> > yes
>>
>> then i'd say find a different way.  it cant be that hard to hide the
>> indirection in a header with CPP.
>>
> now that I look closer, the
> #define h_errno (*__h_errno_location ())
> is already unguarded by THREADS since a commit for NPTL, see below

then it's a bug that needs fixing, not further enshrining
-mike
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: Dynamic linker

[Mike Frysinger]

from Gentoo:
# force ncurses linking #71420
sed -i -e 's:^SHLIB_LIBS=:SHLIB_LIBS=-lncurses:' support/shobj-conf || die "sed"
-mike
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: dlopen/dlclose thread safety

[Mike Frysinger]

2011/3/23 Timo Teräs:
> On 03/23/2011 06:33 PM, Mike Frysinger wrote:
>> On Wed, Mar 23, 2011 at 12:29 PM, Carmelo AMOROSO wrote:
>>> indeed we have seen also some issue with dlopen, when TLS variables were
>>> involved. One suspect we have is actually thread-safety. glibc use some
>>> locking primitives to access TLS block, while we don't.
>>> Not yet had a free time slot to look at this deeply.
>>
>> i'm not sure how thread safety would play a role with TLS variables.
>> TLS, by definition, is per-thread and that is guaranteed by the
>> ABI/compiler/C lib/kernel down to the variable level, and that whole
>> stack shouldnt be poking into any shared state (beyond shared .text).
>
> ldso needs to allocate each global TLS variable from globally single
> place. That's how it organises the per-thread data area. So yes, when dl
> allocates the TLS variables it needs to go fiddle global variables.

mmm my understanding was that each thread got its own chunk of TLS
area at thread creation time, and after that the ldso only existed
when the thread needed to know the address of its TLS.  what port are
you talking about exactly ?
-mike
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: Dynamic linker

[Mike Frysinger]

On Wed, Mar 23, 2011 at 2:15 PM, Joakim Tjernlund wrote:
> vapierfil...@gmail.com wrote on 2011/03/23 18:57:04:
>> On Wed, Mar 23, 2011 at 1:19 PM, Joakim Tjernlund wrote:
>> > From: Salvatore CRO 
>> >> We have been looking at the same problem in the last days...
>> >> Libreadline needs either libncurses or libtermcap to provide these 
>> >> symbols.
>> >> Even though one of the two is supposed to be linked to libreadline 
>> >> (depending on
>> >> Certain logic in its build configure), it seems this is not actual the 
>> >> case.
>> >> We'll keep investigating into libreadline package configure.
>> >
>> > Unless someone changed this, uClibc needs to have either
>> > libncurses or libtermcap linked to readline(needs to be in
>> > readline's NEEDED list) or uClibc will fail. glibc doesn't require this, 
>> > but I believe the specs says that all deps should be listed.
>>
>> i'm pretty sure that's the intended behavior we still have.  i wonder
>> if we should FAQ this ...
>
> Yes, since this is not the first time this problem has happened.

ive added an entry (including Peter's -z,defs suggestion)
-mike
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: ldd broken with HARDWIRED_ABSPATH=n

[Mike Frysinger]

On Wed, Mar 23, 2011 at 3:16 PM, Peter Mazinger wrote:
>> On Wed, Mar 23, 2011 at 7:18 AM, Peter Mazinger wrote:
>> >> Your commit 5dffed7dd1a413f3965af702fa7ecd79809d1988 removed absolute
>> >> path from the interpreter binary name embedded in ELF files.
>> >
>> > do you consider my patch wrong?
>>
>> yes.  the absolute path to the ldso must be encoded in binaries.  the
>> point of HARDWIRED_ABSPATH is purely for sysroot/non-sysroot
>> toolchain, and the interp path isnt involved with that.
>>
>> are you sure this even works at runtime ?  i'm pretty sure the kernel
>> doesnt do any path lookups on the interp string.
>
> on an x86 I have recompiled only uClibc and rebooted, no problem with it
> Should I recompile some apps too to be sure that it copes with the change?

you'll have to because the interp path is compiled into the apps
itself at link time.  rebuilding uClibc itself would make absolutely
no difference.
-mike
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: Dynamic linker

[Mike Frysinger]

On Wed, Mar 23, 2011 at 1:19 PM, Joakim Tjernlund wrote:
> From: Salvatore CRO 
>> We have been looking at the same problem in the last days...
>> Libreadline needs either libncurses or libtermcap to provide these symbols.
>> Even though one of the two is supposed to be linked to libreadline 
>> (depending on
>> Certain logic in its build configure), it seems this is not actual the case.
>> We'll keep investigating into libreadline package configure.
>
> Unless someone changed this, uClibc needs to have either
> libncurses or libtermcap linked to readline(needs to be in
> readline's NEEDED list) or uClibc will fail. glibc doesn't require this, but 
> I believe the specs says that all deps should be listed.

i'm pretty sure that's the intended behavior we still have.  i wonder
if we should FAQ this ...
-mike
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: generalize errno handling

[Mike Frysinger]

On Wed, Mar 23, 2011 at 11:03 AM, Peter Mazinger wrote:
>> On Tue, Mar 22, 2011 at 3:35 PM, Peter Mazinger wrote:
>> > Hello,
>>
>> please fix your e-mail client to properly wrap lines
>
> not really doable, as it is a web-client. Will see to use some "normal" email 
> client for the list

so hit "enter" every now and then.  or use a web client that isnt
brain dead.  gmail certainly works, and supports sending from any
e-mail address (i'm using it right now :P).

>> > I would propose to define errno always by __errno_location independently
>> of THREADS enabled/disabled (similarly h_errno and res_state).
>>
>> the point is to not have the overhead of an indirect pointer in the
>> non-threaded case.  are you suggesting we force that overhead when it
>> is unnecessary ?
>
> yes

then i'd say find a different way.  it cant be that hard to hide the
indirection in a header with CPP.

as for the rest of the cleanup, seems like it's a no brainer, but
orthogonal issue.
-mike
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: dlopen/dlclose thread safety

[Mike Frysinger]

On Wed, Mar 23, 2011 at 12:29 PM, Carmelo AMOROSO wrote:
> indeed we have seen also some issue with dlopen, when TLS variables were
> involved. One suspect we have is actually thread-safety. glibc use some
> locking primitives to access TLS block, while we don't.
> Not yet had a free time slot to look at this deeply.

i'm not sure how thread safety would play a role with TLS variables.
TLS, by definition, is per-thread and that is guaranteed by the
ABI/compiler/C lib/kernel down to the variable level, and that whole
stack shouldnt be poking into any shared state (beyond shared .text).
-mike
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: Dynamic linker

[Mike Frysinger]

On Wed, Mar 23, 2011 at 10:12 AM, bruce bushby wrote:
> I'm new to uclibc and buildroot so please forgive any stupid statements. I'm
> stuck on a problem that I can't fix, as a last resort I'm wondering if it
> could be (ld-uClibc.so.0)

what version of uClibc exactly are you using ?

> [root@vx-200 ~]# strings /usr/lib/libreadline.so.6 | grep tgetent
> tgetent
> [root@vx-200 ~]# strings /usr/lib/libreadline.so.6 | grep tgetnum
> tgetnum

this is a terrible way of looking for symbols.  what you're actually
seeing is that readline *needs* those; it does not *provide* them.
use `readelf -s` to actually see the difference.

> So far everything looks perfect, Python's "lib-dynload/readline.so" is
> linked against "libreadline"and "libreadline" has the curses terminfo
> symbols (tgetent, tgetflag, tgetnum, tgetstr, tgoto, tputs)
>
> python: symbol 'BC': can't resolve symbol
> python: symbol 'PC': can't resolve symbol
> python: symbol 'UP': can't resolve symbol
> python: symbol 'tgetnum': can't resolve symbol
> python: symbol 'tgoto': can't resolve symbol
> python: symbol 'tgetflag': can't resolve symbol
> python: symbol 'tputs': can't resolve symbol
> python: symbol 'tgetent': can't resolve symbol
> python: symbol 'tgetstr': can't resolve symbol

no, readline does not provide any of these ... ncurses does.  verify
ncurses is correctly exporting these symbols with readelf.

> So the Python binary opens "lib-dynload/readline.so" ...and the necessary
> libreadline and libncurses . and lastly it opens "ld-uClibc" which, from
> my limited understanding would link the addresses

not quite.  ld-uClibc in the output above is opened only because it
was listed as DT_NEEDED.  python, assuming it is a dynamic ELF,
already had ld-uClibc loaded up and resolving symbols for you.
-mike
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: dlopen/dlclose thread safety

[Mike Frysinger]

2011/3/23 Timo Teräs:
> Is uclibc dlopen/dlclose thread safe?

last i looked, it was not

> Valgrind says that we always do bad things at:
>  ldso/libdl/libdl.c:453: if (!(runp->tpnt->rtld_flags & RTLD_GLOBAL)) {
> accessing uninitialized (or unmapped) memory.

i'm sure we do many more bad things ;).  look at any place that
touches static data.  like _dl_init in dlopen().

> Could someone with some ld knowledge at least add very basic
> mutexes to essential parts so that we do not crash?

"very basic" -> "BKL"

> And yes, in libdl.so we should be able to use mutexes at least in NPTL
> as the main libc.so provides pthread_mutex_* symbols, and forwards them
> to libpthread if it's loaded. Though depending on how the code is
> shared, we might need extra care to make sure that the loader .so does
> not use those (as it can't depend on anything).

glibc seems to get by just fine without mutexes
-mike
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: ldd broken with HARDWIRED_ABSPATH=n

[Mike Frysinger]

On Wed, Mar 23, 2011 at 7:18 AM, Peter Mazinger wrote:
>> Your commit 5dffed7dd1a413f3965af702fa7ecd79809d1988 removed absolute
>> path from the interpreter binary name embedded in ELF files.
>
> do you consider my patch wrong?

yes.  the absolute path to the ldso must be encoded in binaries.  the
point of HARDWIRED_ABSPATH is purely for sysroot/non-sysroot
toolchain, and the interp path isnt involved with that.

are you sure this even works at runtime ?  i'm pretty sure the kernel
doesnt do any path lookups on the interp string.

> I can revert it to the old behaviour in master

please do
-mike
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: NO_MMU archs / relation to uClinux

[Mike Frysinger]

On Wed, Mar 23, 2011 at 8:59 AM, Peter Mazinger wrote:
> I have a testboard based on MCF5329 and have some additions
> to support it in uClibc. Should I care here to get a bit support
> (m68k without MMU) to build it or would one prefer to leave that
> job to uclinux?
>
> It seems that many parts in the uClinux sources are not back/forward-ported
> to uClibc (no_MMU related stuff, sensors, but also CPU specific options...).
> Does anyone know the reason?

the uClinux.org guys are just very bad at pushing anything back
upstream.  so dont rely on them sending anything at all.  the uClinux
distro is very much run as "suck in sources, patch it until it works,
and then never touch again unless things break".  i dont know what
their future even holds though considering the company developing it
were taken over by mcafee purely to buy up the competition and squash
it.

so if you want something fixed, you'll need to integrate it yourself.
-mike
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: Can't build m4 or bison with -rc3.

[Mike Frysinger]

On Tue, Mar 22, 2011 at 8:24 PM, Rob Landley wrote:
> On 03/22/2011 06:53 PM, Mike Frysinger wrote:
>>>> heh so you mean whatever glibc does is right ?
>>>
>>> If the package is expecting something specifically because we're
>>> exporting _GLIBC_?  Yes.
>>
>> which is a compatibility hack intended to go away.
>
> And yet it hasn't, and there's no CONFIG entry to test without it.

here's an idea ... submit patches that are correct so they can be merged

> For some reason uClibc is #defining __GLIBC__ in bits/socket.h, but I
> don't see that in any checks for that in the kernel's assembly code.
> (Ok, it shows up in arch/mn10300/include/asm/posix_types.h but that
> doesn't count.)  Possibly this is support for the 7 year old 2.4 series?

no, it took quite a while for linux's socket.h to get updated.  try
reading linux's git history.  it was only removed in 2.6 at the end
2009.

linux's stat.h is still fucked up, and attempts to fix it have hit
stupid developers.

> So my position was that in the previous version we _were_ implementing
> this interface (with a trivial patch to uClibc that didn't touch any
> third party code), the current version is not, and that this is an
> obvious regression.
>
> Your position is that at some unknown point in the future some unnamed
> person is going to change how uClibc does stuff and retest everything,
> and in the meantime we should start polluting third party packages with
> #ifdef uClibc to work around... this obvious regression.

that's nice that you think that.  good thing i dont care.  help out
fixing the actual problems such as the need for __GLIBC__ in the first
place.
-mike
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: Can't build m4 or bison with -rc3.

[Mike Frysinger]

On Tue, Mar 22, 2011 at 7:46 PM, Rob Landley wrote:
> On 03/22/2011 06:01 PM, Khem Raj wrote:
>> On (22/03/11 16:42), Rob Landley wrote:
>>> On 03/20/2011 01:02 AM, Khem Raj wrote:
 On 3/19/2011 10:17 PM, Rob Landley wrote:
> I'm running my Linux From Scratch 6.7 build under a uClibc root
> filesystem, and building m4 1.14.4 has this error:
>
> gcc -std=gnu99  -I.     -g -O2 -MT execute.o -MD -MP -MF
> .deps/execute.Tpo -c -o execute.o execute.c
> In file included from execute.c:47:
> ./spawn.h:112: error: field '_sp' has incomplete type
> distcc[23848] ERROR: compile execute.c on localhost failed
> make[3]: *** [execute.o] Error 1
> make[3]: Leaving directory `/home/m4/lib'

 Apply the fixes e.g.
 http://git.openembedded.org/cgit.cgi/openembedded/tree/recipes/bison/bison-2.4.3/uclibc-sched_param-def.patch
>>>
>>> Translation: uClibc is permanently broken, we have no choice but to
>>> start crapping #ifdef uClibc all over other packages to get them to work
>>> with special cases just for us, when in the previous version we could
>>> actually fix uClibc.
>>>
>>
>> heh so you mean whatever glibc does is right ?
>
> If the package is expecting something specifically because we're
> exporting _GLIBC_?  Yes.

which is a compatibility hack intended to go away.  if you want to
actually *fix* things, start building packages without uClibc
exporting those compat defines.
-mike
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: Can't build m4 or bison with -rc3.

[Mike Frysinger]

On Tue, Mar 22, 2011 at 7:01 PM, Khem Raj wrote:
> On (22/03/11 16:42), Rob Landley wrote:
>> On 03/20/2011 01:02 AM, Khem Raj wrote:
>> > On 3/19/2011 10:17 PM, Rob Landley wrote:
>> >> I'm running my Linux From Scratch 6.7 build under a uClibc root
>> >> filesystem, and building m4 1.14.4 has this error:
>> >>
>> >> gcc -std=gnu99  -I.     -g -O2 -MT execute.o -MD -MP -MF
>> >> .deps/execute.Tpo -c -o execute.o execute.c
>> >> In file included from execute.c:47:
>> >> ./spawn.h:112: error: field '_sp' has incomplete type
>> >> distcc[23848] ERROR: compile execute.c on localhost failed
>> >> make[3]: *** [execute.o] Error 1
>> >> make[3]: Leaving directory `/home/m4/lib'
>> >
>> > Apply the fixes e.g.
>> > http://git.openembedded.org/cgit.cgi/openembedded/tree/recipes/bison/bison-2.4.3/uclibc-sched_param-def.patch
>>
>> Translation: uClibc is permanently broken, we have no choice but to
>> start crapping #ifdef uClibc all over other packages to get them to work
>> with special cases just for us, when in the previous version we could
>> actually fix uClibc.
>>
>
> heh so you mean whatever glibc does is right ?
> and if packages use those incantations then those should be universally
> accepted

i didnt think it needed saying ;)
-mike
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: Can't build m4 or bison with -rc3.

[Mike Frysinger]

On Tue, Mar 22, 2011 at 6:08 PM, Rob Landley wrote:
> Unless that goes upstream into m4 and those maintainers accept the
> permanent burden of regression testing against our broken special case,
> it's a workaround, not a fix.

it was merged long ago in gnulib.  m4 doesnt care what's happening in gnulib.
-mike
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: generalize errno handling

[Mike Frysinger]

On Tue, Mar 22, 2011 at 3:35 PM, Peter Mazinger wrote:
> Hello,

please fix your e-mail client to properly wrap lines

> I would propose to define errno always by __errno_location independently of 
> THREADS enabled/disabled (similarly h_errno and res_state).

the point is to not have the overhead of an indirect pointer in the
non-threaded case.  are you suggesting we force that overhead when it
is unnecessary ?
-mike
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: unbreak vfork on cris architecture

[Mike Frysinger]

On Tue, Mar 22, 2011 at 3:15 PM, Waldemar Brodkorb wrote:
> On Mar 21, 2011, at 6:01 PM, Mike Frysinger wrote:
>> i have nothing to do with cris.  but the answer here is not "fix it"
>> but rather "patch not merged".  no sweat off my back since i dont have
>> any cris hardware.
>
> I already asked about the problem here:
> http://www.mail-archive.com/uclibc@uclibc.org/msg06089.html
>
> Unfortunately it is your commit, which breaks it for the unpopular cris 
> architecture:

if you actually read the code, before my commit, vfork() wasnt a
vfork().  it was a fork().  so no, my commit didnt "break" cris.  it
was already broken.

>> then file a bug in bugzilla so someone else will fix it eventually
>
> So getting the info of my two mails into a bug report is the best way to get
> a working uclibc for my two Foxboards?

if you arent going to fix the issue yourself, then yes
-mike
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [git commit future 1/1] __uClibc_main.c: make __uClibc_init hidden

[Mike Frysinger]

On Sat, Mar 19, 2011 at 2:51 PM, Khem Raj  wrote:
> -extern void __uClibc_init(void);
> -libc_hidden_proto(__uClibc_init)
> +extern void __uClibc_init(void) attribute_hidden;
>  void __uClibc_init(void)
>  {

no need for a prototype.  simply put attribute_hidden before the def.
-mike
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: unbreak vfork on cris architecture

[Mike Frysinger]

On Mon, Mar 21, 2011 at 11:14 AM, Thorsten Glaser wrote:
>>> your simple implementation is probably incorrect -- errno cannot be
>>> referenced directly.
>
> Mh. On the other hand, the manpage says:
>
>     In a multithreaded application,  vfork()  borrows  only  the
>     thread  of  control  that called vfork() in the parent; that
>     is, the child contains only one thread. The use  of  vfork()
>     in  multithreaded  applications,  however,  is unsafe due to
>     race conditons that can cause the child  process  to  become
>     deadlocked  and consequently block both the child and parent
>     process from execution indefinitely.

which is irrelevant in the case of updating errno -- the vfork failed
and thus no 2nd process is running

> But if that’s a concern… fix it

i have nothing to do with cris.  but the answer here is not "fix it"
but rather "patch not merged".  no sweat off my back since i dont have
any cris hardware.

> He found a problem and a WFM-style fix, which at
> least improves the situation.

then file a bug in bugzilla so someone else will fix it eventually

> By all means, replace the errno
> access with a jump to __syscall_error after setting up registers
> in a way that routine (from sysdeps/linux/cris/sysdep.S) expects
> it; I don’t know cris assembly but it doesn’t look _too_ hard…

tailing to __syscall_error is probably a wise decision
-mike
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [PATCH] unbreak vfork on cris architecture

[Mike Frysinger]

On Mon, Mar 21, 2011 at 10:24 AM, Waldemar Brodkorb wrote:
> unfortunately the common vfork implementation, which just use
> the syscall function to interact with the kernel, does not work
> on the cris architecture. The system call vfork is special, on most
> architectures just calling syscall is not enough.
> The patch below adds the vfork implementation from klibc.
> License should be compatible.

this lacks an explanation as to why vfork is so special on cris.
different calling convention ?  different return values ?  something
else ?

your simple implementation is probably incorrect -- errno cannot be
referenced directly.
-mike
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [uClinux-dev] usleep in uClibc/uClinux

[Mike Frysinger]

On Tue, Mar 8, 2011 at 9:14 AM, Drasko DRASKOVIC wrote:
> in uClibc/include/unistd.h I can see :
>
> #if defined __USE_BSD || defined __USE_XOPEN_EXTENDED
> /* Set an alarm to go off (generating a SIGALRM signal) in VALUE
>   microseconds.  If INTERVAL is nonzero, when the alarm goes off, the
>   timer is reset to go off every INTERVAL microseconds thereafter.
>   Returns the number of microseconds remaining before the alarm.  */
> extern __useconds_t ualarm (__useconds_t __value, __useconds_t __interval)
>     __THROW;
>
> /* Sleep USECONDS microseconds, or until a signal arrives that is not blocked
>   or ignored.
>
>   This function is a cancellation point and therefore not marked with
>   __THROW.  */
> extern int usleep (__useconds_t __useconds);
> #endif
>
> So, usleep() is defined only if __USE_BSD.

you ignored a pretty large part of the code:
> #if defined __USE_BSD || defined __USE_XOPEN_EXTENDED

BSD *or* the xopen extended spec

> 1) Why so ?
>
> 2) What if I do not use BSD system, but uClinux ?

that isnt what it means.  please read the feature_test_macros man page.
-mike
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: LEGAL: LG Electronics LGPL violations

[Mike Frysinger]

On Wednesday, February 23, 2011 18:51:15 Rob Landley wrote:
> If Jenya decided not to go through with it, fine, but you saying that
> the SFLC isn't ever worth messing with is yet another strange judgement
> call of yours which I strongly disagree with.

i never said any such thing.  Jenya was asking for feedback, so i gave it to 
*him* from *his* point of view.  like i already said.  if the SFLC wants to go 
further, great.  they, unlike Jenya, have actual copyright standing.
-mike


signature.asc
Description: This is a digitally signed message part.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: LEGAL: LG Electronics LGPL violations

[Mike Frysinger]

bah, sent this out too soon due to stuck ctrl key.

summary point: neither of us are lawyers, so this whole discussion is 
pointless in the first place.  i believe i'm right, and i imagine it's the 
other way round for you, but who cares.  this is a waste of time.
-mike


signature.asc
Description: This is a digitally signed message part.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: LEGAL: LG Electronics LGPL violations

[Mike Frysinger]

On Wednesday, February 23, 2011 14:18:11 Rob Landley wrote:
> On 02/23/2011 12:20 AM, Mike Frysinger wrote:
> > On Tuesday, February 22, 2011 23:38:02 Rob Landley wrote:
> >> On 02/22/2011 05:18 PM, Mike Frysinger wrote:
> >>> On Wednesday, January 12, 2011 02:52:19 jenya wrote:
> >>>> "RELEASE of 50PK550-ZE is dynamically linked now.
> >>>> We recommend you update your TV with latest version and you can make
> >>>> RELEASE without object files. "
> >>>> 
> >>>> I replied that they were required to provide the object files for the
> >>>> version that is installed on my TV when buying (am I right? Correct me
> >>>> if not).
> >>> 
> >>> i think this question is better posed to the SFLC.  from my non-lawyer
> >>> understanding, if they are no longer distributing binary releases, the
> >>> fact you received one in the past is no longer relevant.
> >> 
> >> By that logic, if I pirate a bunch copies of Office, Microsoft can't go
> >> after me for damages but can only get a cease and desist preventing me
> >> from shipping any _more_ copies in future.  That's not actually how
> >> copyright law works.
> > 
> > i was talking about license enforcement from jenya's point of view. 
> > copyright law is irrelevant when jenya doesnt hold any copyrights on the
> > code in question.
> 
> No it isn't

yeah, it really is.  you yourself said so:
> You're right that if the company isn't in compliance with the license
> terms Jenya hasn't got standing to sue
> .  The license terms obligate them to provide source code to
> him, even years after they distribute the binaries.

3 years isnt relevant if the company simply doesnt bother to comply with that 
release (which is what LV seems to be doing for their static builds).  the 
penalty for non-compliance from Jeny'a pov is that they no longer get to 
distribute the binaries.  which is what they've done.
-mike


signature.asc
Description: This is a digitally signed message part.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [PATCH 3/6] Add support for DSBT ELF to ld.so

[Mike Frysinger]

On Wednesday, February 23, 2011 14:05:49 Bernd Schmidt wrote:
> --- a/ldso/include/dl-defs.h
> +++ b/ldso/include/dl-defs.h
> @@ -212,7 +212,7 @@ typedef struct {
> _dl_find_hash for this reloc TYPE.  TPNT is the module in which the
> matching SYM was found.  */
>  #ifndef DL_FIND_HASH_VALUE
> -# define DL_FIND_HASH_VALUE(TPNT, TYPE, SYM) (DL_RELOC_ADDR
> ((SYM)->st_value, (TPNT)->loadaddr))
> +# define DL_FIND_HASH_VALUE(TPNT, TYPE, SYM) (DL_RELOC_ADDR ((TPNT)-
> loadaddr, (SYM)->st_value))
> #endif

is this correct ?  this is non-fdpic code, and seems like it should be a sep 
change if it's a common ELF code bugfix.  the changelog makes no mention of 
this either ...
-mike


signature.asc
Description: This is a digitally signed message part.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: Does uclibc support TLS

[Mike Frysinger]

On Wednesday, February 23, 2011 13:24:43 raymond zhao wrote:
> I am building some application with uclibc. and got an error:
> 
> uclibc/sysroot/lib/libstdc++.so: undefined reference to `__tls_get_addr'
> 
> Does this mean uclibc doesn't support TLS? My uclibc is 0.90.30.3

TLS isnt in that version

> Is there some trick to solve the problem?

disable tls in your gcc
-mike


signature.asc
Description: This is a digitally signed message part.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: about __fgetc_unlocked function

[Mike Frysinger]

On Wednesday, February 23, 2011 12:55:32 raymond zhao wrote:
> The tool chain build smoothly, but when I build eXtremDB package, I got an
> error:
> pass1.c:(.text+0x1f7): undefined reference to `__fgetc_unlocked'

sorry, but this is a fairly slim bug report and we need more details.  post 
the exact compile line used to build pass1.c, and then post the exact compile 
line used to link the code that lead to this error.
-mike


signature.asc
Description: This is a digitally signed message part.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [git commit prelink 1/1] sparc: check for log double support in gcc

[Mike Frysinger]

On Sunday, January 02, 2011 02:00:47 Konrad Eisele wrote:
> +# check weather __LONG_DOUBLE_128__ is defined (long double support)
> +UCLIBC_SPARC_HAS_LONG_DOUBLE=
> $(shell if [ "x`$(CC) -E -dM -xc /dev/null 2>&1 | grep __LONG_DOUBLE_128__`" 
!= "x" ]; then echo "y"; fi)

this probably should be generalized into a "check_cpp" or something.

at any rate, this would be a lot simpler written as:
$(CC) -E -dM -xc /dev/null | grep -qs __LONG_DOUBLE_128__ && echo y
-mike


signature.asc
Description: This is a digitally signed message part.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: LEGAL: LG Electronics LGPL violations

[Mike Frysinger]

On Wednesday, February 23, 2011 02:07:31 Evgenij Vorobev wrote:
> 2011/2/23 Mike Frysinger :
> > On Wednesday, January 12, 2011 02:52:19 jenya wrote:
> >> "RELEASE of 50PK550-ZE is dynamically linked now.
> >> We recommend you update your TV with latest version and you can make
> >> RELEASE without object files. "
> >> 
> >> I replied that they were required to provide the object files for the
> >> version that is installed on my TV when buying (am I right? Correct me
> >> if not).
> > 
> > i think this question is better posed to the SFLC.  from my non-lawyer
> > understanding, if they are no longer distributing binary releases, the
> > fact you received one in the past is no longer relevant.  so you could
> > in theory attempt to go after say best buy if they're still selling the
> > outdated models which include static linked binaries.
> 
> Erik Andersen (maintainer of uClibc) know about this. He already
> forward my mail to SFLC.
> LG still selling models with firmware with static linked binary. Few
> weeks ago company where I work, bought two TV LG 50PK250 (build on
> same platform). This TV have firmware version 3.17, which static too.

thanks for the update.  now we can let SFLC do all the legal wrangling and we 
can focus on the code :)
-mike


signature.asc
Description: This is a digitally signed message part.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [ANNOUNCE] 0.9.32-rc1 released

[Mike Frysinger]

On Tuesday, February 22, 2011 23:41:35 Rob Landley wrote:
> On 02/22/2011 05:23 PM, Mike Frysinger wrote:
> > On Monday, December 27, 2010 15:30:21 Peter Korsgaard wrote:
> >> There unfortunately seems to be an issue on ppc with NPTL and
> >> UCLIBC_USE_NETLINK=y
> >> 
> >>   CC libc/inet/herror.os
> >>   CC libc/inet/if_index.os
> >> 
> >> In file included from libc/inet/if_index.c:37:
> >> libc/inet/netlinkaccess.h:29: error: redefinition of typedef '__u8'
> >> /home/peko/source/buildroot/output/toolchain/linux/include/asm-generic/i
> >> nt- ll64.h:20: note: previous declaration of '__u8' was here
> >> 
> >> stdio.h seems to eventually include asm/types.h, which then conflicts
> >> with the local typedefs in netlinkaccess.h. The same config works on
> >> ARM.
> >> 
> >> Why are we adding those local typedefs in the first place? They were
> >> added back in 2006 by Mike, but the commit message doesn't really
> > 
> >> explain why:
> >
> > i think you forget how screwed up kernel headers used to be
> 
> Which is why Maszur provided sanitized headers and distros provided
> sanitized headers before make headers_install was introduced (circa
> 2.6.15) to sanitize its own headers.  An environment that used
> unsanitized (or improperly sanitized) 2.6 headers was always broken, and
> adding bugs to uClibc to work around a broken toolchain or environment
> was never the correct approach.

that's nice that you think that, wholly irrelevant as it is.  reality was that 
at the time, things were breaking constantly, and defacto standard was for the 
C library to work around kernel header issues.  there was no stable standard 
to work off of (not everyone was using Maszur's work), and people still were 
trying to build against linux-2.4.
-mike


signature.asc
Description: This is a digitally signed message part.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: LEGAL: LG Electronics LGPL violations

[Mike Frysinger]

On Tuesday, February 22, 2011 23:38:02 Rob Landley wrote:
> On 02/22/2011 05:18 PM, Mike Frysinger wrote:
> > On Wednesday, January 12, 2011 02:52:19 jenya wrote:
> >> "RELEASE of 50PK550-ZE is dynamically linked now.
> >> We recommend you update your TV with latest version and you can make
> >> RELEASE without object files. "
> >> 
> >> I replied that they were required to provide the object files for the
> >> version that is installed on my TV when buying (am I right? Correct me
> >> if not).
> > 
> > i think this question is better posed to the SFLC.  from my non-lawyer
> > understanding, if they are no longer distributing binary releases, the
> > fact you received one in the past is no longer relevant.
> 
> By that logic, if I pirate a bunch copies of Office, Microsoft can't go
> after me for damages but can only get a cease and desist preventing me
> from shipping any _more_ copies in future.  That's not actually how
> copyright law works.

i was talking about license enforcement from jenya's point of view.  copyright 
law is irrelevant when jenya doesnt hold any copyrights on the code in 
question.
-mike


signature.asc
Description: This is a digitally signed message part.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [ANNOUNCE] 0.9.32-rc1 released

[Mike Frysinger]

On Monday, December 27, 2010 15:30:21 Peter Korsgaard wrote:
> There unfortunately seems to be an issue on ppc with NPTL and
> UCLIBC_USE_NETLINK=y
> 
>   CC libc/inet/herror.os
>   CC libc/inet/if_index.os
> In file included from libc/inet/if_index.c:37:
> libc/inet/netlinkaccess.h:29: error: redefinition of typedef '__u8'
> /home/peko/source/buildroot/output/toolchain/linux/include/asm-generic/int-
> ll64.h:20: note: previous declaration of '__u8' was here
> 
> stdio.h seems to eventually include asm/types.h, which then conflicts
> with the local typedefs in netlinkaccess.h. The same config works on
> ARM.
> 
> Why are we adding those local typedefs in the first place? They were
> added back in 2006 by Mike, but the commit message doesn't really
> explain why:

i think you forget how screwed up kernel headers used to be
-mike


signature.asc
Description: This is a digitally signed message part.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: LEGAL: LG Electronics LGPL violations

[Mike Frysinger]

On Wednesday, January 12, 2011 02:52:19 jenya wrote:
> "RELEASE of 50PK550-ZE is dynamically linked now.
> We recommend you update your TV with latest version and you can make
> RELEASE without object files. "
> 
> I replied that they were required to provide the object files for the
> version that is installed on my TV when buying (am I right? Correct me
> if not).

i think this question is better posed to the SFLC.  from my non-lawyer 
understanding, if they are no longer distributing binary releases, the fact 
you received one in the past is no longer relevant.  so you could in theory 
attempt to go after say best buy if they're still selling the outdated models 
which include static linked binaries.
-mike


signature.asc
Description: This is a digitally signed message part.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: Porting uclibc to the other OS

[Mike Frysinger]

On Wednesday, January 26, 2011 05:02:05 Alfeiks Kaänoken wrote:
> My first review of the existing sysdeps and other source code
> shows me that there are many linux-specific code (yes,
> I mean linux specific code that resides within non-os specific
> code).

patches welcome.  linuxisms should only exist under libc/sysdeps/linux/ for 
the C library.

> btw, the main difference with linux (or other monolithic OSes) is
> many OS functions (open() for example) aren't syscalls - it's
> RPC functions (yes, actually it will be a syscall that call IPC
> function to send an RPC message). In this case I need to
> find a better way to port it (i.e. without heavy modifications to
> keep uclibc sources tree more closely to the upstream one).
> Could you advice me something ?

the linux syscalls should all live in libc/sysdeps/linux/ already, so if you 
had libc/sysdeps/jari/, it should be OK.
-mike


signature.asc
Description: This is a digitally signed message part.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

[PATCH v2] linuxthreads.old: fix nommu initial thread stack detection

[Mike Frysinger]

Because the nommu address space is flat, and the application stack can
literally be located anywhere, we cannot rely on the assumptions that the
mmu port gets away with.  Namely, that the first thread's stack lives at
the top of memory and nothing will be created above it.

Currently, the code rounds the current stack up a page and sets that as
the "top" of the stack, and then marks the "bottom" of the stack as "1".
Then as new threads are created, this assumption is further refined by
slowly backing off the "bottom" when a new stack is created within the
range of the initial stack.

Simple ascii example (tid0 is the initial thread):

1 thread:
 [bos  tid0 stack   tos]

2 threads:
 [ tid0 stack  ]
  [tid1 stack]

3 threads:
 [ tid0 stack  ]
  [tid1 stack]
[tid2 stack]

As you can kind of see, this algorithm operates on one basic assumption:
the initial top of stack calculation is the absolute top of the stack.
While this assumption was fairly safe in the original nommu days of yore
where the only file format was FLAT (which defaults to a 4KiB stack --
exactly 1 page), and memory was fairly tight, we can see that this falls
apart pretty quickly as soon as the initial stack is larger than a page.

The issue that crops up now is simple to hit: start an application with
an 8KiB stack, execute some functions that put pressure on the stack so
that it exceeds 4KiB, then start up some threads.  The initial tos will
be rounded up by a page, but this is actually the middle of the stack.
Now when the initial thread returns from its functions (thus unwinding
the stack) and tries to call something which calls back into libpthread,
the thread_self() func fails to detect itself as the initial thread as
the current stack is now above the tos.  The __pthread_find_self() func
kicks in, walks all the thread arrays, fails to find a hit, and then
walks into uninitialized memory for the thread descriptor.  Use of this
garbage memory has obvious results -- things fall down & go boom.

To address this, I extend the current algorithm to automatically scale
back both the bottom and the top stack limits of the initial thread.
We use the current stack pointer at "thread boot time" only as a single
known point.  The initial thread stack bottom is set to the bottom of
memory and the initial thread stack top is set to the top of memory.
Then as we create new stack threads, we figure out whether the new stack
is above or below the single known good address, and then scale back
either the tos or the bos accordingly.

Reviewed-by: Steven J. Magnani 
Signed-off-by: Mike Frysinger 
---
v2
- improve comments and fix build warning based on Steven's feedback

 libpthread/linuxthreads.old/internals.h |   24 
 libpthread/linuxthreads.old/pthread.c   |   23 ++-
 2 files changed, 30 insertions(+), 17 deletions(-)

diff --git a/libpthread/linuxthreads.old/internals.h 
b/libpthread/linuxthreads.old/internals.h
index 637fcea..110dd9d 100644
--- a/libpthread/linuxthreads.old/internals.h
+++ b/libpthread/linuxthreads.old/internals.h
@@ -252,17 +252,25 @@ extern pthread_descr __pthread_main_thread;
Initially 0, meaning that the current thread is (by definition)
the initial thread. */
 
-/* For non-MMU systems also remember to stack top of the initial thread.
- * This is adapted when other stacks are malloc'ed since we don't know
- * the bounds a-priori. -StS */
-
 extern char *__pthread_initial_thread_bos;
 #ifndef __ARCH_USE_MMU__
-extern char *__pthread_initial_thread_tos;
+/* For non-MMU systems, we have no idea the bounds of the initial thread
+ * stack, so we have to track it on the fly relative to other stacks.  Do
+ * so by scaling back our assumptions on the limits of the bos/tos relative
+ * to the known mid point.  See also the comments in pthread_initialize(). */
+extern char *__pthread_initial_thread_tos, *__pthread_initial_thread_mid;
 #define NOMMU_INITIAL_THREAD_BOUNDS(tos,bos) \
-   if ((tos)>=__pthread_initial_thread_bos \
-   && (bos)<__pthread_initial_thread_tos) \
-   __pthread_initial_thread_bos = (tos)+1
+   do { \
+   char *__tos = (tos); \
+   char *__bos = (bos); \
+   if (__tos >= __pthread_initial_thread_bos && \
+   __bos < __pthread_initial_thread_tos) { \
+   if (__bos < __pthread_initial_thread_mid) \
+   __pthread_initial_thread_bos = __tos; \
+   else \
+   __pthread_initial_thread_tos = __bos; \
+   } \
+   } while (0)
 #else
 #define NOMMU_INITIAL_THREAD_BOUNDS(tos,bos) /* empty */
 #endif /* __ARCH_USE_MMU__ */
diff --git a/libpthread/linuxthre

Re: [PATCH] ldso: auto disable lazy relocation for some fdpic ports when using threads

[Mike Frysinger]

On Tuesday, February 22, 2011 12:40:08 Andrew Stubbs wrote:
> On 22/02/11 17:06, Joseph S. Myers wrote:
> > On Mon, 21 Feb 2011, Mike Frysinger wrote:
> >> >  The fdpic code requires two 32bit values to be read/written
> >> >  atomically (one pointer for the GOT and one for the PLT).  FRV has
> >> >  an insn to do this sort of thing, but Blackfin does not.  So in
> >> >  order to use FDPIC on a threaded system, we need to disable lazy
> >> >  relocation.
> > 
> > This is what the SH FDPIC ABI has to say on this subject.  I'm not sure
> > what was needed in the resolver to implement it (though when I wrote the
> > ABI we convinced ourselves it was implementable).
> 
> Right, the resolver makes sure that it does not make any assumptions
> about the FDPIC value passed in.
> 
> It compares the value given with the load-map, and if it falls outside
> the address range for the proper module, it walks the module list, and
> finds the correct one.

hmm, interesting approach.  i'd def like to take a look at this.

> The patches were never posted to uClibc because the GCC patches were not
> accepted. At the time, there were also problems with upstream uClibc not
> building for MMU-less targets.

i dont think gcc superh support in mainline is a hard requirement to merge the 
FDPIC bits.  especially since some of it sounds like it's arch independent.

> I can provide the work-in-progress patches for reference, if you wish,
> or you could look at the sources for Sourcery G++ Lite for SH uClinux
> here: http://www.codesourcery.com/sgpp/lite/superh

is it in a git tree somewhere ?  how about creating a superh-fdpic branch in 
the uclibc.org git tree and pushing that out ?

i dont think we use branches enough :)
-mike


signature.asc
Description: This is a digitally signed message part.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

[PATCH] tempname: fix int precision warnings

[Mike Frysinger]

The printf precision takes an integer, not a size_t.  Otherwise we get:

libc/misc/internals/tempname.c: In function '___path_search':
libc/misc/internals/tempname.c:116: warning:
field precision should have type 'int', but argument 3 has type 'size_t'
field precision should have type 'int', but argument 5 has type 'size_t'

Signed-off-by: Mike Frysinger 
---
 libc/misc/internals/tempname.c |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/libc/misc/internals/tempname.c b/libc/misc/internals/tempname.c
index 4145c94..0db2845 100644
--- a/libc/misc/internals/tempname.c
+++ b/libc/misc/internals/tempname.c
@@ -62,7 +62,10 @@ int attribute_hidden ___path_search (char *tmpl, size_t 
tmpl_len, const char *di
const char *pfx /*, int try_tmpdir*/)
 {
 /*const char *d; */
-size_t dlen, plen;
+/* dir and pfx lengths should always fit into an int,
+   so don't bother using size_t here.  Especially since
+   the printf func requires an int for precision (%*s).  */
+int dlen, plen;
 
 if (!pfx || !pfx[0])
 {
-- 
1.7.4.1

___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

[PATCH] ldso: auto disable lazy relocation for some fdpic ports when using threads

[Mike Frysinger]

From: Bernd Schmidt 

The fdpic code requires two 32bit values to be read/written atomically
(one pointer for the GOT and one for the PLT).  FRV has an insn to do
this sort of thing, but Blackfin does not.  So in order to use FDPIC on
a threaded system, we need to disable lazy relocation.

Rather than disable it for all applications (non-threaded included),
take a middle ground.  When the ldso detects loading of the libpthread
library, automatically turn off lazy relocation.  This isn't a perfect
fix as it doesn't detect when someone calls clone() manually, but in
practice, it works for every realistic case.  For the 1 person in the
world doing weird stuff, they can build with -Wl,-z,now themselves.

Signed-off-by: Bernd Schmidt 
Signed-off-by: Mike Frysinger 
---
 Rules.mak  |1 +
 ldso/ldso/Makefile.in  |2 +-
 ldso/ldso/ldso.c   |   16 +++-
 .../sysdeps/linux/bfin/bits/uClibc_arch_features.h |3 +++
 libc/sysdeps/linux/frv/bits/uClibc_arch_features.h |3 +++
 5 files changed, 23 insertions(+), 2 deletions(-)

diff --git a/Rules.mak b/Rules.mak
index 8165cca..f23f159 100644
--- a/Rules.mak
+++ b/Rules.mak
@@ -136,6 +136,7 @@ endif
 ifneq ($(HAS_NO_THREADS),y)
 libpthread.depend := $(top_builddir)lib/libpthread.so
 endif
+UCLIBC_LIBPTHREAD = libpthread.so.$(ABI_VERSION)
 interp := $(top_builddir)lib/interp.os
 ldso := $(top_builddir)lib/$(UCLIBC_LDSO)
 headers_dep := $(top_builddir)include/bits/sysnum.h
diff --git a/ldso/ldso/Makefile.in b/ldso/ldso/Makefile.in
index e71ae15..2a5a81b 100644
--- a/ldso/ldso/Makefile.in
+++ b/ldso/ldso/Makefile.in
@@ -13,7 +13,7 @@ CFLAGS-ldso := -DNOT_IN_libc -DIS_IN_rtld $(SSP_DISABLE_FLAGS)
 CFLAGS-ldso += -fno-omit-frame-pointer
 
 CFLAGS-ldso += -I$(top_srcdir)ldso/ldso/$(TARGET_ARCH) 
-I$(top_srcdir)ldso/include -I$(top_srcdir)ldso/ldso
-CFLAGS-ldso += -DUCLIBC_RUNTIME_PREFIX=\"$(RUNTIME_PREFIX)\" 
-DUCLIBC_LDSO=\"$(UCLIBC_LDSO)\"
+CFLAGS-ldso += -DUCLIBC_RUNTIME_PREFIX=\"$(RUNTIME_PREFIX)\" 
-DUCLIBC_LDSO=\"$(UCLIBC_LDSO)\" -DUCLIBC_LIBPTHREAD=\"$(UCLIBC_LIBPTHREAD)\"
 
 ifeq ($(DODEBUG),y)
 # Not really much point in including debugging info, since gdb
diff --git a/ldso/ldso/ldso.c b/ldso/ldso/ldso.c
index ea4ad0f..5bcdfec 100644
--- a/ldso/ldso/ldso.c
+++ b/ldso/ldso/ldso.c
@@ -284,7 +284,7 @@ void _dl_get_ready_to_run(struct elf_resolve *tpnt, 
DL_LOADADDR_TYPE load_addr,
ElfW(Dyn) *dpnt;
char *lpntstr;
unsigned int i;
-   int unlazy = 0, trace_loaded_objects = 0;
+   int unlazy = 0, must_unlazy = 0, trace_loaded_objects = 0;
struct dyn_elf *rpnt;
struct elf_resolve *tcurr;
struct elf_resolve *tpnt1;
@@ -777,6 +777,15 @@ void _dl_get_ready_to_run(struct elf_resolve *tpnt, 
DL_LOADADDR_TYPE load_addr,
name = _dl_get_last_path_component(lpntstr);
if (_dl_strcmp(name, UCLIBC_LDSO) == 0)
continue;
+#if !defined(__UCLIBC_HAVE_64BIT_LDST__) && defined(__FDPIC__)
+   /* An FDPIC entry consists of two 32bit values 
-- a GOT
+  pointer and a PLT pointer.  In order to be 
thread safe,
+  the ldso has to read/write those entries 
atomically.
+  But if the arch cannot load/store 64bits in 
one go,
+  we cannot safely do lazy relocation.  */
+   if (_dl_strcmp(name, UCLIBC_LIBPTHREAD) == 0)
+   must_unlazy = 1;
+#endif
 
_dl_if_debug_dprint("\tfile='%s';  needed by 
'%s'\n", lpntstr, _dl_progname);
 
@@ -815,6 +824,11 @@ void _dl_get_ready_to_run(struct elf_resolve *tpnt, 
DL_LOADADDR_TYPE load_addr,
}
_dl_unmap_cache();
 
+   if (must_unlazy)
+   for (tcurr = _dl_loaded_modules; tcurr; tcurr = tcurr->next) {
+   tcurr->rtld_flags |= RTLD_NOW;
+   }
+
--nlist; /* Exclude the application. */
init_fini_list = _dl_malloc(nlist * sizeof(struct elf_resolve *));
i = 0;
diff --git a/libc/sysdeps/linux/bfin/bits/uClibc_arch_features.h 
b/libc/sysdeps/linux/bfin/bits/uClibc_arch_features.h
index 4bab547..90abc45 100644
--- a/libc/sysdeps/linux/bfin/bits/uClibc_arch_features.h
+++ b/libc/sysdeps/linux/bfin/bits/uClibc_arch_features.h
@@ -45,4 +45,7 @@
 /* only weird assemblers generally need this */
 #undef __UCLIBC_ASM_LINE_SEP__
 
+/* does your target have atomic 64bit loads/stores ? */
+#undef __UCLIBC_HAVE_ATOMIC_64_LDST__
+
 #endif /* _BITS_UCLIBC_ARCH_FEATURES_H */
diff --git a/libc/sysdeps/linux/frv/bits/uClibc_arch_features.h 
b/libc/sysdeps/linux/frv/bits/uClib

Re: Ah, figured out the -mfdpic thing, [PATCH] included.

[Mike Frysinger]

On Monday, February 21, 2011 19:31:48 Rob Landley wrote:
> On 02/21/2011 06:03 PM, Mike Frysinger wrote:
> > On Friday, February 11, 2011 21:34:22 Rob Landley wrote:
> >> Why do you want to have two user-visible symbols that mean exactly the
> >> same thing?  (What part of my explanation was incorrect?)
> > 
> > no, the "has mmu" is there for the kconfig tree to make the the "use mmu"
> > available to the user.  the source then keys off of "use mmu".  nowhere
> > does the user select "i have a mmu", they only select "i want to use the
> > mmu". seems pretty straightforward to me.
> 
> Do a "make allnoconfig", then select target architecture "arm".
> 
> Now go to the "target architecture features and options menu",
> and confirm the following cut and paste:
> 
>   │ │Target ABI (OABI)  --->  │
> │ │ │Target Processor Type (Generic Arm)  --->   
> │ │ │ │Target File Format (FDPIC ELF)  --->   
>  │ │ │ │Target Processor Endianness (Big Endian)  --->
>   │ │ │ │[*] Target CPU has a memory management unit (MMU)
>│ │ │ │[ ]   Do you want to utilize the MMU?   
> │ │ │ │[ ] Enable floating point number support   
>  │ │ │ │(/usr/include) Linux kernel header location
> 
> There is ARCH_HAS_MMU, user selectable, and ARCH_USE_MMU,
> being separately user selectable.

ok, for ambiguous arches, that's true

> There is no reason for both symbols to even EXIST, let alone
> the user having to separately select both of them.

it makes the intention pretty clear.  at the time, common code was frequently 
getting the idea of "having" and "using" wrong.  plus, you had to manually 
select either "i have an mmu" or "i do not have an mmu".  since the rewording, 
ive hardly seen the source go wrong, or the selection be confusing.  i also 
vaguely recall the Kconfig syntax not working out correctly, but i'd have to 
play to figure out what exactly necessitated the split ... perhaps the issue 
has shaken itself out since.

back to the point, perhaps the two could be merged in some form, but there is 
0 harm in having two explicit symbols.  it lets the Kconfig arches explicitly 
select options without ultimately screwing the user (which was happening in 
the past).  in the 5 years since i first added this, i havent heard anyone 
complain or mention issues with it.  all i see in this thread is you 
complaining about practical irrelevance.  i'm not inclined to research 
something that has been proven to work to satisfy that one case.

> this is just arm, it's not like anybody actually _uses_
> the single most common CPU type on the planet...

no, it isnt just arm, as the trivial kconfig logic shows.  any arch that has 
both MMU and NOMMU ports makes it an option.
-mike


signature.asc
Description: This is a digitally signed message part.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: Ah, figured out the -mfdpic thing, [PATCH] included.

[Mike Frysinger]

On Friday, February 11, 2011 13:55:25 Bernhard Reutner-Fischer wrote:
> On Thu, Feb 10, 2011 at 01:42:01PM -0600, Rob Landley wrote:
> >I mentioned that my build was dying due to trying to use -mfdpic which
> 
> >is a target-specific option for the FRV processor:
> It's not only for FRV, it's also used on bfin (should be fixed in the
> docs).

not really.  SuperH certainly has an FDPIC port, and i vaguelly recall mention 
of ARM and m68k/coldfire FDPIC ports.  but maybe i'm just remembering those 
latter ones wrong.
-mike


signature.asc
Description: This is a digitally signed message part.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

[PATCH v2] unify stub logic

[Mike Frysinger]

Signed-off-by: Mike Frysinger 
---
i never got around to committing this sucker, and no one responded back,
so i'll push this updated version in a bit.

 extra/Configs/Config.in   |9 --
 libc/sysdeps/linux/arm/posix_fadvise.c|2 +-
 libc/sysdeps/linux/arm/posix_fadvise64.c  |2 +-
 libc/sysdeps/linux/common/__rt_sigtimedwait.c |   12 +--
 libc/sysdeps/linux/common/__rt_sigwaitinfo.c  |   11 +--
 libc/sysdeps/linux/common/bdflush.c   |6 -
 libc/sysdeps/linux/common/capget.c|6 -
 libc/sysdeps/linux/common/capset.c|7 +-
 libc/sysdeps/linux/common/create_module.c |7 -
 libc/sysdeps/linux/common/delete_module.c |6 -
 libc/sysdeps/linux/common/epoll.c |   18 ---
 libc/sysdeps/linux/common/fdatasync.c |7 -
 libc/sysdeps/linux/common/fork.c  |   12 --
 libc/sysdeps/linux/common/get_kernel_syms.c   |6 -
 libc/sysdeps/linux/common/getpgrp.c   |6 -
 libc/sysdeps/linux/common/init_module.c   |6 -
 libc/sysdeps/linux/common/pivot_root.c|6 -
 libc/sysdeps/linux/common/posix_fadvise.c |3 +-
 libc/sysdeps/linux/common/posix_fadvise64.c   |3 +-
 libc/sysdeps/linux/common/query_module.c  |7 -
 libc/sysdeps/linux/common/sched_getaffinity.c |6 -
 libc/sysdeps/linux/common/sched_setaffinity.c |   11 --
 libc/sysdeps/linux/common/signalfd.c  |6 +-
 libc/sysdeps/linux/common/splice.c|7 -
 libc/sysdeps/linux/common/stubs.c |  183 +
 libc/sysdeps/linux/common/sync_file_range.c   |6 -
 libc/sysdeps/linux/common/umount.c|9 --
 libc/sysdeps/linux/common/umount2.c   |6 -
 libc/sysdeps/linux/common/vmsplice.c  |7 -
 libc/sysdeps/linux/common/xattr.c |   78 ---
 libc/sysdeps/linux/i386/posix_fadvise64.S |9 +-
 31 files changed, 195 insertions(+), 275 deletions(-)
 create mode 100644 libc/sysdeps/linux/common/stubs.c

diff --git a/extra/Configs/Config.in b/extra/Configs/Config.in
index aa459e0..f152a96 100644
--- a/extra/Configs/Config.in
+++ b/extra/Configs/Config.in
@@ -665,15 +665,6 @@ config UCLIBC_HAS_STUBS
  functions which are impossible to implement on the target
  architecture. Otherwise, such functions are simply omitted.
 
- As of 2008-07, this option makes uClibc provide fork() stub
- on NOMMU targets. It always sets errno to ENOSYS and returns -1.
-
- This may be useful if you port a lot of software and cannot
- audit all of it and replace or disable fork() usage.
- With this option, a program which uses fork() will build
- successfully. Of course, it may be useless if fork()
- is essential for its operation.
-
 config UCLIBC_HAS_SHADOW
bool "Shadow Password Support"
default y
diff --git a/libc/sysdeps/linux/arm/posix_fadvise.c 
b/libc/sysdeps/linux/arm/posix_fadvise.c
index 278bff9..80d3c50 100644
--- a/libc/sysdeps/linux/arm/posix_fadvise.c
+++ b/libc/sysdeps/linux/arm/posix_fadvise.c
@@ -39,7 +39,7 @@ int posix_fadvise(int fd, off_t offset, off_t len, int advise)
 
 /* weak_alias(__libc_posix_fadvise, posix_fadvise); */
 
-#else
+#elif defined __UCLIBC_HAS_STUBS__
 
 int posix_fadvise(int fd attribute_unused, off_t offset attribute_unused, 
off_t len attribute_unused, int advice attribute_unused)
 {
diff --git a/libc/sysdeps/linux/arm/posix_fadvise64.c 
b/libc/sysdeps/linux/arm/posix_fadvise64.c
index 4b27381..678c42f 100644
--- a/libc/sysdeps/linux/arm/posix_fadvise64.c
+++ b/libc/sysdeps/linux/arm/posix_fadvise64.c
@@ -47,7 +47,7 @@ int posix_fadvise64(int fd, __off64_t offset, __off64_t len, 
int advise)
 
 /* weak_alias(__libc_posix_fadvise64, posix_fadvise64); */
 
-#else
+#elif defined __UCLIBC_HAS_STUBS__
 
 int posix_fadvise64(int fd, __off64_t offset, __off64_t len, int advise)
 {
diff --git a/libc/sysdeps/linux/common/__rt_sigtimedwait.c 
b/libc/sysdeps/linux/common/__rt_sigtimedwait.c
index a7ab8fb..26860d2 100644
--- a/libc/sysdeps/linux/common/__rt_sigtimedwait.c
+++ b/libc/sysdeps/linux/common/__rt_sigtimedwait.c
@@ -86,16 +86,6 @@ int attribute_hidden __sigtimedwait(const sigset_t * set, 
siginfo_t * info,
return __rt_sigtimedwait(set, info, timeout, _NSIG / 8);
 }
 # endif /* !__UCLIBC_HAS_THREADS_NATIVE__ */
-#else
-int attribute_hidden __sigtimedwait(const sigset_t * set, siginfo_t * info,
-   const 
struct timespec *timeout)
-{
-   if (set == NULL)
-   __set_errno(EINVAL);
-   else
-   __set_errno(ENOSYS);
-   return -1;
-}
-#endif
 weak_alias(__sigtimedwait,sigtimedwait)
 libc_hidden_weak(sigtimedwait)
+#endif
diff --git a/libc/sysdeps/linux/common/__rt_sigwaitinfo.c 
b/libc/sysdeps/linux/common/__rt_sigwaitinfo.c
index 92a11c9..6b43327 100644
--- a/libc/sysde

Re: Ah, figured out the -mfdpic thing, [PATCH] included.

[Mike Frysinger]

On Friday, February 11, 2011 21:34:22 Rob Landley wrote:
> On 02/11/2011 12:55 PM, Bernhard Reutner-Fischer wrote:
> > On Thu, Feb 10, 2011 at 01:42:01PM -0600, Rob Landley wrote:
> >> I mentioned that my build was dying due to trying to use -mfdpic which
> > 
> >> is a target-specific option for the FRV processor:
> >
> > It's not only for FRV, it's also used on bfin (should be fixed in the
> > docs).
> 
> Right, so when mike changed that in gcc he didn't bother to update the
> docs, when he changed it in uClibc he didn't bother to put any docs on
> the config entry...

no idea what you're talking about.  i didnt do the gcc nor uClibc port for 
FDPIC for Blackfin processors.

> >>  http://lists.uclibc.org/pipermail/uclibc/2011-January/044701.html
> >>  https://bugs.busybox.net/show_bug.cgi?id=3193
> >> 
> >> The problem is that uClibc has an utterly useless user-visible
> >> "TARGET_HAS_MMU" as well as "TARGET_USE_MMU", and I took the first out
> >> of miniconfig because I'd complained about the redundant option during
> >> the dev cycle and thought it was gone.
> >> 
> >> Here's a patch to remove the redundant option.  The only decision the
> >> end user has to make is "Do I want MMU or NOMMU?", and TARGET_USE_MMU is
> >> the thing that selects that.  (There's even code in the test suite
> >> making sure nothing in the actual build ever uses ARCH_HAS_MMU, it's
> >> JUST a dependency guard on the only symbol that actually matters.)
> >> 
> >> Architectures that have no MMU still set ARCH_HAS_NO_MMU, and that's
> >> used directly as the visibility guard for TARGET_USE_MMU which is the
> >> only user visible setting, and which defaults to y just like it always
> >> did.  (The previous code that selected TARGET_HAS_MMU was selecting a
> >> symbol that defaulted to Y, for no apparent reason.  There was a whole
> >> lotta NOP going on, and I've removed it.)
> >> 
> >> The fact that when you select a nommu system, it defaults to creating a
> >> binary format that's only available on the FRV architecture with no hint
> >> that it's a target-specific format, is a separate bug introduced without
> >> explanation in commit 14db067a8bdcdc7a25.  I'm leaving that for now, in
> >> hopes somebody either fixes it or writes a help option explaining what
> >> they were thinking.
> > 
> > NAK.
> 
> Why?
> 
> > I also think a
> > 
> > prompt "Target File Format"
> > 
> > +   default UCLIBC_FORMAT_ELF if ARCH_USE_MMU
> > +   default UCLIBC_FORMAT_FDPIC if !ARCH_USE_MMU && TARGET_frv
> > +   default UCLIBC_FORMAT_SHARED_FLAT if !ARCH_USE_MMU
> > 
> > is not ideal, please just configure your format properly according to
> > your needs (throughout your setup).
> 
> Why do you want to have two user-visible symbols that mean exactly the
> same thing?  (What part of my explanation was incorrect?)

no, the "has mmu" is there for the kconfig tree to make the the "use mmu" 
available to the user.  the source then keys off of "use mmu".  nowhere does 
the user select "i have a mmu", they only select "i want to use the mmu".  
seems pretty straightforward to me.
-mike


signature.asc
Description: This is a digitally signed message part.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

[PATCH] linuxthreads.old: fix nommu initial thread stack detection

[Mike Frysinger]

Because the nommu address space is flat, and the application stack can
literally be located anywhere, we cannot rely on the assumptions that the
mmu port gets away with.  Namely, that the first thread's stack lives at
the top of memory and nothing will be created above it.

Currently, the code rounds the current stack up a page and sets that as
the "top" of the stack, and then marks the "bottom" of the stack as "1".
Then as new threads are created, this assumption is further refined by
slowly backing off the "bottom" when a new stack is created within the
range of the initial stack.

Simple ascii example (tid0 is the initial thread):

1 thread:
 [bos  tid0 stack   tos]

2 threads:
 [ tid0 stack  ]
  [tid1 stack]

3 threads:
 [ tid0 stack  ]
  [tid1 stack]
[tid2 stack]

As you can kind of see, this algorithm operates on one basic assumption:
the initial top of stack calculation is the absolute top of the stack.
While this assumption was fairly safe in the original nommu days of yore
where the only file format was FLAT (which defaults to a 4KiB stack --
exactly 1 page), and memory was fairly tight, we can see that this falls
apart pretty quickly as soon as the initial stack is larger than a page.

The issue that crops up now is simple to hit: start an application with
an 8KiB stack, execute some functions that put pressure on the stack so
that it exceeds 4KiB, then start up some threads.  The initial tos will
be rounded up by a page, but this is actually the middle of the stack.
Now when the initial thread returns from its functions (thus unwinding
the stack) and tries to call something which calls back into libpthread,
the thread_self() func fails to detect itself as the initial thread as
the current stack is now above the tos.  The __pthread_find_self() func
kicks in, walks all the thread arrays, fails to find a hit, and then
walks into uninitialized memory for the thread descriptor.  Use of this
garbage memory has obvious results -- things fall down & go boom.

To address this, I extend the current algorithm to automatically scale
back both the bottom and the top stack limits of the initial thread.
We use the current stack pointer at "thread boot time" only as a single
known point.  The initial thread stack bottom is set to the bottom of
memory and the initial thread stack top is set to the top of memory.
Then as we create new stack threads, we figure out whether the new stack
is above or below the single known good address, and then scale back
either the tos or the bos accordingly.

Signed-off-by: Mike Frysinger 
---
 libpthread/linuxthreads.old/internals.h |   16 
 libpthread/linuxthreads.old/pthread.c   |   13 -
 2 files changed, 20 insertions(+), 9 deletions(-)

diff --git a/libpthread/linuxthreads.old/internals.h 
b/libpthread/linuxthreads.old/internals.h
index 637fcea..2999baf 100644
--- a/libpthread/linuxthreads.old/internals.h
+++ b/libpthread/linuxthreads.old/internals.h
@@ -258,11 +258,19 @@ extern pthread_descr __pthread_main_thread;
 
 extern char *__pthread_initial_thread_bos;
 #ifndef __ARCH_USE_MMU__
-extern char *__pthread_initial_thread_tos;
+extern char *__pthread_initial_thread_tos, *__pthread_initial_thread_mid;
 #define NOMMU_INITIAL_THREAD_BOUNDS(tos,bos) \
-   if ((tos)>=__pthread_initial_thread_bos \
-   && (bos)<__pthread_initial_thread_tos) \
-   __pthread_initial_thread_bos = (tos)+1
+   do { \
+   char *__tos = (tos); \
+   char *__bos = (bos); \
+   if (__tos >= __pthread_initial_thread_bos && \
+   __bos < __pthread_initial_thread_tos) { \
+   if (__bos < __pthread_initial_thread_mid) \
+   __pthread_initial_thread_bos = __tos; \
+   else \
+   __pthread_initial_thread_tos = __bos; \
+   } \
+   } while (0)
 #else
 #define NOMMU_INITIAL_THREAD_BOUNDS(tos,bos) /* empty */
 #endif /* __ARCH_USE_MMU__ */
diff --git a/libpthread/linuxthreads.old/pthread.c 
b/libpthread/linuxthreads.old/pthread.c
index ad392e3..3878984 100644
--- a/libpthread/linuxthreads.old/pthread.c
+++ b/libpthread/linuxthreads.old/pthread.c
@@ -174,6 +174,7 @@ char *__pthread_initial_thread_bos = NULL;
 
 #ifndef __ARCH_USE_MMU__
 char *__pthread_initial_thread_tos = NULL;
+char *__pthread_initial_thread_mid = NULL;
 #endif /* __ARCH_USE_MMU__ */
 
 /* File descriptor for sending requests to the thread manager. */
@@ -457,12 +458,14 @@ static void pthread_initialize(void)
 setrlimit(RLIMIT_STACK, &limit);
   }
 #else
-  /* For non-MMU assume __pthread_initial_thread_tos at upper page boundary, 
and
-   * __pthread_initial_thread_bos at address 0. These bounds are refined as we
-

Re: [PATCH] netdb: increase line size for /etc/services

[Mike Frysinger]

On Thursday, August 19, 2010 12:49:28 Natanael Copa wrote:
> but it does not seem to solve same issue with getprotobyame("gre") if
> there are any comment longer than 80 chars in /etc/protocols.

i imagine that comments should be skipped rather than needed to be read into 
memory and then thrown away.  then the line length wouldnt matter unless the 
contents themselves exceeding the length.
-mike


signature.asc
Description: This is a digitally signed message part.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [PATCH 2/2] en_US.UTF-8 is not mandatory, just one UTF-8 locale

[Mike Frysinger]

On Wed, Aug 11, 2010 at 6:48 AM, Thomas Petazzoni wrote:
>  locale_failure:
> -               fprintf(stderr, "could not find a UTF8 locale ... please 
> enable en_US.UTF-8\n");
> +               fprintf(stderr, "could not find a UTF8 locale ... at least 
> one is needed\n");

i'd suggest:
  fprintf(stderr, "could not find a UTF8 locale ... at least one is
needed (like en_US.UTF-8)\n");
-mike
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [git commit master 1/1] add config parser

[Mike Frysinger]

On Thursday, August 05, 2010 17:42:41 Bernhard Reutner-Fischer wrote:
>  include/internal/parse_config.h|   50 +++

we've been using bits/uClibc_xxx for internal stuff.  is this implicitly 
proposing we change to internal/ ?

> --- /dev/null
> +++ b/include/internal/parse_config.h

seems to be lacking ifdef multiple inclusion protection

> --- a/libc/misc/internals/Makefile.in
> +++ b/libc/misc/internals/Makefile.in
> @@ -7,9 +7,8 @@
> 
>  subdirs += libc/misc/internals
> 
> -CFLAGS-__uClibc_main.c := $(SSP_DISABLE_FLAGS)
> -
> -CSRC := tempname.c errno.c __errno_location.c __h_errno_location.c
> +CSRC := tempname.c errno.c __errno_location.c __h_errno_location.c \
> + parse_config.c
> 
>  MISC_INTERNALS_DIR := $(top_srcdir)libc/misc/internals
>  MISC_INTERNALS_OUT := $(top_builddir)libc/misc/internals
> @@ -17,6 +16,9 @@ MISC_INTERNALS_OUT := $(top_builddir)libc/misc/internals
>  MISC_INTERNALS_SRC := $(patsubst %.c,$(MISC_INTERNALS_DIR)/%.c,$(CSRC))
>  MISC_INTERNALS_OBJ := $(patsubst %.c,$(MISC_INTERNALS_OUT)/%.o,$(CSRC))
> 
> +CFLAGS-__uClibc_main.c := $(SSP_DISABLE_FLAGS)
> +
> +
>  libc-y += $(MISC_INTERNALS_OBJ)
>  ifneq ($(UCLIBC_FORMAT_SHARED_FLAT),y)
>  libc-shared-y += $(MISC_INTERNALS_OUT)/__uClibc_main.oS

the uClibc_main change seems like useless thrashing, but too late now i guess

> --- /dev/null
> +++ b/libc/misc/internals/parse_config.c
>
> +static off_t bb_get_chunk_with_continuation(parser_t* parsr)
> +{
> + off_t pos = 0;
> + char *chp;
> +
> + while (1) {
> + if (fgets(parsr->line + pos, parsr->line_len, parsr->fp) == 
> NULL) {
> + memset(parsr->line, 0, parsr->line_len);

if line is a normal C string, why do we need to waste time on memset() ?  or 
if this is an error path, why not treat "-1" return as "buffer is undefined" ?

> +config_open2()
> +{
> + parser = malloc(sizeof(*parser));
> + if (parser) {
> + memset(parser, 0, sizeof(*parser));

calloc() ?

> +parser_t attribute_hidden * FAST_FUNC config_open(const char *filename)

the header file already has hidden/fast_func markings on the prototype.  
putting them on the func definition is just noise that makes it harder to 
read.
-mike


signature.asc
Description: This is a digitally signed message part.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [PATCH][noMMU] malloc-simple: Make calloc() return zeroed memory

[Mike Frysinger]

On Wednesday, June 09, 2010 10:02:21 Steven J. Magnani wrote:
> The 0.9.31 release included a change to malloc-simple to request
> uninitialized memory from noMMU kernels. Unfortunately, the corresponding
> calloc() code assumed that memory returned by malloc() was already zeroed,
> which leads to all kinds of nastiness.

sorry, i dropped the ball on that one.  i had def changed that in the Blackfin 
branch, but missed merging it into mainline :/.
-mike


signature.asc
Description: This is a digitally signed message part.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [PATCH] nptl i686: fix pthread_cond_wait.S compilation

[Mike Frysinger]

On Wednesday, July 14, 2010 09:19:29 Roman I Khimov wrote:
> __i686 is a gcc-defined macro, so i686 build failed with:
> libpthread/nptl/sysdeps/unix/sysv/linux/i386/i686/../i486/pthread_cond_wait
> .S: Assembler messages:
> 
> --- a/libpthread/nptl/sysdeps/unix/sysv/linux/i386/i686/pthread_cond_wait.S
> +++ b/libpthread/nptl/sysdeps/unix/sysv/linux/i386/i686/pthread_cond_wait.S
> @@ -17,4 +17,5 @@
> Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
> 02111-1307 USA.  */
> 
> +#undef __i686
>  #include "../i486/pthread_cond_wait.S"

i dont think this is the proper way to fix this.  put the undef in the i386 
sysdep.h header file so all random files with a thunk section get fixed 
automatically.
-mike


signature.asc
Description: This is a digitally signed message part.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [patch] avoid c99 declaration

[Mike Frysinger]

On Saturday, July 31, 2010 16:22:35 Khem Raj wrote:
> On Tue, Jul 27, 2010 at 11:37 PM, Carmelo AMOROSO wrote:
> > On 7/28/2010 7:51 AM, Mike Frysinger wrote:
> >> On Monday, June 21, 2010 06:39:12 Gianluigi Tiesi wrote:
> >>> While compiling uClibc inside openwrt build system I have somehow the
> >>> compiler
> >>> without -std=c99 flash (since adding id causes me some troubles)
> >> 
> >> why dont we fix uClibc to use c99 then ?  if your toolchain is new
> >> enough to support TLS as NPTL requires, then it's new enough to support
> >> c99 features. we shouldnt go throwing frivolous patches at the NPTL
> >> code when we're merely importing it from glibc.  realistically, we dont
> >> have the man power to maintain a fork which means we need to be
> >> sticking as lose to glibc as possible here.
> > 
> > I definitely agree with Mike. Even if changes are dummy, merging effort
> > with updated version of NPTL/glibc could be too huge.
> 
> yes I agree. I proposed to make C99 a requirement for uclibc.

i'm not necessarily set on all of uClibc, but certainly any part that utilizes 
TLS.  i guess we could enable -std=gnu99 in the build and see who (if any) 
complains.

if no one has anything else, i'll revert the changes in question and add -
std=gnu99.
-mike


signature.asc
Description: This is a digitally signed message part.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [patch] avoid c99 declaration

[Mike Frysinger]

On Monday, June 21, 2010 06:39:12 Gianluigi Tiesi wrote:
> While compiling uClibc inside openwrt build system I have somehow the
> compiler
> without -std=c99 flash (since adding id causes me some troubles)

why dont we fix uClibc to use c99 then ?  if your toolchain is new enough to 
support TLS as NPTL requires, then it's new enough to support c99 features.  
we shouldnt go throwing frivolous patches at the NPTL code when we're merely 
importing it from glibc.  realistically, we dont have the man power to 
maintain a fork which means we need to be sticking as lose to glibc as 
possible here.
-mike


signature.asc
Description: This is a digitally signed message part.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [RFC] new helper funcs for alloca/malloc with mmu/nommu

[Mike Frysinger]

On Tuesday, July 27, 2010 14:46:09 Bernhard Reutner-Fischer wrote:
> Still, don't you think it would be better to do this in gcc instead of
> touching every user?

no, i dont.  alloca() is still usable on nommu systems.  just not in the same 
ways as mmu.
-mike


signature.asc
Description: This is a digitally signed message part.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [RFC] new helper funcs for alloca/malloc with mmu/nommu

[Mike Frysinger]

On Tuesday, July 27, 2010 09:18:43 Bernhard Reutner-Fischer wrote:
> On Tue, Jul 27, 2010 at 01:57:23AM -0400, Mike Frysinger wrote:
> >The rpc rcmd code has some ugly ifdef mazes to handle mmu/nommu
> >differences just to select alloca or malloc.  Unify those with some
> >helper macros in a new header, and then convert the rcmd code over to it.
> >
> >This is all geared towards fixing the getdents helper functions which only
> >use alloca() atm.  Now that we have helper functions, convert the getdents
> >functions over too.
> 
> uClibc_alloc.h would need a copyright statement.
> 
> Short of tweaking gcc to use malloc/free for bfin perhaps we could
> convert the alloca users inside libc to just use malloc/free instead.
> I think that would be less ugly..

this isnt Blackfin specific at all.  it's for all nommu users.  and what 
you're suggesting is exactly what this commit is doing.

so you'll need to be more specific as to what you're referring to.
-mike


signature.asc
Description: This is a digitally signed message part.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [git commit master 1/1] nptl: fix buildsys

[Mike Frysinger]

On Tuesday, July 06, 2010 13:14:19 Bernhard Reutner-Fischer wrote:
> On Tue, Jul 06, 2010 at 06:33:22PM +0200, Bernhard Reutner-Fischer wrote:
> >commit:
> >http://git.uclibc.org/uClibc/commit/?id=9381d622e2411a35a5fd73a5a573eb269
> >e2dd9c9 branch: http://git.uclibc.org/uClibc/commit/?id=refs/heads/master
> >
> >Now automatically picks the correct (arch and subarch specific) impls in
> >favour of generic impls.
> >make O=/tmp/objs PREFIX=/my/sysroot -j
> >works now as expected (both out-of-tree as well as parallel-safe).
> 
> I'm tempted to forbid building in-tree for non-release versions to
> prevent people from breaking O= again.

terrible idea imo
-mike


signature.asc
Description: This is a digitally signed message part.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: uClibc-0.30.3 related

[Mike Frysinger]

On Tuesday, July 20, 2010 01:09:04 Praveen J C (RBEI/EST1) wrote:
> Can I get busybox built already with the uClibc?

we provide a C library only.  we dont provide random precompiled applications.
-mike


signature.asc
Description: This is a digitally signed message part.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [RFC] new helper funcs for alloca/malloc with mmu/nommu

[Mike Frysinger]

On Tuesday, July 27, 2010 02:02:07 Carmelo AMOROSO wrote:
> do you think it could be extended to other part of the library ?

i dont follow.  the macros merely switch between alloca() and malloc(), so the 
header should be usable anywhere those funcs are usable.
-mike


signature.asc
Description: This is a digitally signed message part.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

[RFC] new helper funcs for alloca/malloc with mmu/nommu

[Mike Frysinger]

The rpc rcmd code has some ugly ifdef mazes to handle mmu/nommu differences
just to select alloca or malloc.  Unify those with some helper macros in a
new header, and then convert the rcmd code over to it.

This is all geared towards fixing the getdents helper functions which only
use alloca() atm.  Now that we have helper functions, convert the getdents
functions over too.

Signed-off-by: Mike Frysinger 
---
 libc/inet/rpc/rcmd.c  |   60 ++---
 libc/stdlib/malloc-standard/malloc.h  |   11 ++---
 libc/sysdeps/linux/common/bits/uClibc_alloc.h |   23 +
 libc/sysdeps/linux/common/getdents.c  |   10 +++-
 libc/sysdeps/linux/common/getdents64.c|   10 +++-
 5 files changed, 55 insertions(+), 59 deletions(-)
 create mode 100644 libc/sysdeps/linux/common/bits/uClibc_alloc.h

diff --git a/libc/inet/rpc/rcmd.c b/libc/inet/rpc/rcmd.c
index 628c291..fb1bd93 100644
--- a/libc/inet/rpc/rcmd.c
+++ b/libc/inet/rpc/rcmd.c
@@ -69,7 +69,6 @@ static char sccsid[] = "@(#)rcmd.c8.3 (Berkeley) 3/26/94";
 #include 
 #include 
 
-#include 
 #include 
 #include 
 #include 
@@ -86,6 +85,7 @@ static char sccsid[] = "@(#)rcmd.c8.3 (Berkeley) 3/26/94";
 #include 
 #endif
 #include 
+#include 
 
 
 /* some forward declarations */
@@ -116,11 +116,7 @@ int rcmd(char **ahost, u_short rport, const char *locuser, 
const char *remuser,
 
 #ifdef __UCLIBC_HAS_REENTRANT_RPC__
hstbuflen = 1024;
-#ifdef __ARCH_USE_MMU__
-   tmphstbuf = alloca (hstbuflen);
-#else
-   tmphstbuf = malloc (hstbuflen);
-#endif
+   tmphstbuf = stack_heap_alloc(hstbuflen);
 
while (gethostbyname_r (*ahost, &hostbuf, tmphstbuf,
hstbuflen, &hp, &herr) != 0 || hp == NULL)
@@ -128,9 +124,7 @@ int rcmd(char **ahost, u_short rport, const char *locuser, 
const char *remuser,
if (herr != NETDB_INTERNAL || errno != ERANGE)
{
__set_h_errno (herr);
-#ifndef __ARCH_USE_MMU__
-   free(tmphstbuf);
-#endif
+   stack_heap_free(tmphstbuf);
herror(*ahost);
return -1;
}
@@ -138,17 +132,11 @@ int rcmd(char **ahost, u_short rport, const char 
*locuser, const char *remuser,
{
/* Enlarge the buffer.  */
hstbuflen *= 2;
-#ifdef __ARCH_USE_MMU__
-   tmphstbuf = alloca (hstbuflen);
-#else
-   free(tmphstbuf);
-   tmphstbuf = malloc (hstbuflen);
-#endif
+   stack_heap_free(tmphstbuf);
+   tmphstbuf = stack_heap_alloc(hstbuflen);
}
}
-#ifndef __ARCH_USE_MMU__
-   free(tmphstbuf);
-#endif
+   stack_heap_free(tmphstbuf);
 #else /* call the non-reentrant version */
if ((hp = gethostbyname(*ahost)) == NULL) {
return -1;
@@ -331,35 +319,23 @@ int ruserok(const char *rhost, int superuser, const char 
*ruser,
 
 #ifdef __UCLIBC_HAS_REENTRANT_RPC__
buflen = 1024;
-#ifdef __ARCH_USE_MMU__
-   buffer = alloca (buflen);
-#else
-   buffer = malloc (buflen);
-#endif
+   buffer = stack_heap_alloc(buflen);
 
while (gethostbyname_r (rhost, &hostbuf, buffer,
buflen, &hp, &herr) != 0 || hp == NULL)
{
if (herr != NETDB_INTERNAL || errno != ERANGE) {
-#ifndef __ARCH_USE_MMU__
-   free(buffer);
-#endif
+   stack_heap_free(buffer);
return -1;
} else
{
/* Enlarge the buffer.  */
buflen *= 2;
-#ifdef __ARCH_USE_MMU__
-   buffer = alloca (buflen);
-#else
-   free(buffer);
-   buffer = malloc (buflen);
-#endif
+   stack_heap_free(buffer);
+   buffer = stack_heap_alloc(buflen);
}
}
-#ifndef __ARCH_USE_MMU__
-   free(buffer);
-#endif
+   stack_heap_free(buffer);
 #else
if ((hp = gethostbyname(rhost)) == NULL) {
return -1;
@@ -452,23 +428,15 @@ iruserok2 (u_int32_t raddr, int superuser, const char 
*ruser, const char *luser,
 #ifdef __UCLIBC_HAS_REENTRANT_RPC__
size_t buflen = sysconf (_SC_GETPW_R_SIZE_MAX);
struct passwd pwdbuf;
-#ifdef __ARCH_USE_MMU__
-   char *buffer = alloca (buflen);
-#else
-   char *buffer = malloc (buflen);
-#endif
+   char *buffer = stack_heap_alloc(buflen);
 
if (getpwnam_r (luser, &pwdbuf, buffer,
buflen, &pwd) != 0 || pwd == NULL)
{
-#ifndef __ARCH_USE_MMU__
-   free(buffer);
-#endif
+   stack_heap_free(buffer);
return -1;
}
-#ifndef __ARCH_USE_MMU__
-   free(buffer);
-#endif
+   stack_heap_free(buffer);
 #else
if ((pwd = getpwnam(luser)) == N

Re: bugs in malloc

[Mike Frysinger]

On Monday 23 November 2009 14:55:26 Freeman Wang wrote:
> 1. We found with some special application, the application would get
> stuck at line 162 of malloc.c and the reason was mem->next points back
> to itself.

please try to reduce the allocation patterns of your 'special' application.  
it should be easy to enable debugging and capture the malloc/free sequences 
and run them again manually.

> It turns out, we believe, to be because new_mmb is allocated after the
> mmb list is iterated throught to find the insertion point. When the
> mmb_heap also runs out and needs to be extended when the regular heap is
> just extended, the mmb list could be messed up. We moved the new_mmb
> allocation up and the problem seems to have been fixed.

i dont see why the current code is a problem.  it's a singly linked list which 
means if the list is walked to the end, the new_mmb will be 'inserted' as the 
last item in the linked list.  prev_mmb points to the last valid entry in the 
list and mmb is null.  so the last valid entry will be updated to point to 
new_mmb and it will have its next member set to null.  i dont see any place 
where the mmb list 'could be messed up'.

if you look a few lines up, the recursive memory-full-issue should already be 
handled because a mmap for more memory is done, and that mmap is put into the 
heap by the heap free call.

> 2. While trying to fix the above issue, we read the code and found a
> multi-threading issue with this mmb list handling. This list is halfway
> protected in free.c and not protected by any lock at all in malloc.c. Is
> it intentional?

looks like the locking fixes we have in the blackfin tree werent pushed 
upstream.  i'll have to rebase them first, but it should at least partially 
cover what you see.  if it doesnt, i'll stitch in your pieces.

> 3. In an embedded world without MMU, it is not garanteed that the mmap
> syscall would always get back a valid block, and that's probably why the
> return value, block, is checked immediately after the syscall. But it
> seems we are not checking the return value of new_mmb which is allocated
> from the mmb_heap? Is it a potential issue?

you have no guarantee of mmap returning valid memory under a mmu-system 
either.  typically an oom situation will have an application crash quickly, so 
this particular missing check isnt a big deal, but it should probably still be 
added.  i imagine in a threaded situation, one thread could grab the fresh 
memory before the original thread got a chance to use it and thus got null 
back.
-mike


signature.asc
Description: This is a digitally signed message part.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

[PATCH/RFC] bits/mmap.h: unify ala linux asm-generic efforts

[Mike Frysinger]

Most ports have the same exact mman bit defines, so let's unify things
like the linux kernel has with the asm-generic efforts.

A few ports are left behind as they are non-trivial to merge -- the arch
maintainers can tackle it if they care.

Signed-off-by: Mike Frysinger 
---
i've omitted the files that were deleted entirely to cut down on noise

 libc/sysdeps/linux/arm/bits/mman.h   |  103 
 libc/sysdeps/linux/avr32/bits/mman.h |  103 
 libc/sysdeps/linux/bfin/bits/mman.h  |   96 --
 libc/sysdeps/linux/common/bits/mman-common.h |  109 ++
 libc/sysdeps/linux/common/bits/mman.h|   98 +---
 libc/sysdeps/linux/cris/bits/mman.h  |   98 ---
 libc/sysdeps/linux/e1/bits/mman.h|   76 --
 libc/sysdeps/linux/frv/bits/mman.h   |   76 --
 libc/sysdeps/linux/h8300/bits/mman.h |   76 --
 libc/sysdeps/linux/i386/bits/mman.h  |  103 
 libc/sysdeps/linux/i960/bits/mman.h  |   94 --
 libc/sysdeps/linux/ia64/bits/mman.h  |  102 +
 libc/sysdeps/linux/m68k/bits/mman.h  |  102 
 libc/sysdeps/linux/microblaze/bits/mman.h|   99 ---
 libc/sysdeps/linux/nios/bits/mman.h  |   76 --
 libc/sysdeps/linux/nios2/bits/mman.h |   85 
 libc/sysdeps/linux/sh/bits/mman.h|  103 
 libc/sysdeps/linux/sh64/bits/mman.h  |   97 ---
 libc/sysdeps/linux/v850/bits/mman.h  |   99 ---
 libc/sysdeps/linux/vax/bits/mman.h   |   94 --
 libc/sysdeps/linux/x86_64/bits/mman.h|  102 +
 21 files changed, 112 insertions(+), 1879 deletions(-)
 delete mode 100644 libc/sysdeps/linux/arm/bits/mman.h
 delete mode 100644 libc/sysdeps/linux/avr32/bits/mman.h
 delete mode 100644 libc/sysdeps/linux/bfin/bits/mman.h
 create mode 100644 libc/sysdeps/linux/common/bits/mman-common.h
 delete mode 100644 libc/sysdeps/linux/cris/bits/mman.h
 delete mode 100644 libc/sysdeps/linux/e1/bits/mman.h
 delete mode 100644 libc/sysdeps/linux/frv/bits/mman.h
 delete mode 100644 libc/sysdeps/linux/h8300/bits/mman.h
 delete mode 100644 libc/sysdeps/linux/i386/bits/mman.h
 delete mode 100644 libc/sysdeps/linux/i960/bits/mman.h
 delete mode 100644 libc/sysdeps/linux/m68k/bits/mman.h
 delete mode 100644 libc/sysdeps/linux/microblaze/bits/mman.h
 delete mode 100644 libc/sysdeps/linux/nios/bits/mman.h
 delete mode 100644 libc/sysdeps/linux/nios2/bits/mman.h
 delete mode 100644 libc/sysdeps/linux/sh/bits/mman.h
 delete mode 100644 libc/sysdeps/linux/sh64/bits/mman.h
 delete mode 100644 libc/sysdeps/linux/v850/bits/mman.h
 delete mode 100644 libc/sysdeps/linux/vax/bits/mman.h

diff --git a/libc/sysdeps/linux/common/bits/mman-common.h 
b/libc/sysdeps/linux/common/bits/mman-common.h
new file mode 100644
index 000..f00cb1a
--- /dev/null
+++ b/libc/sysdeps/linux/common/bits/mman-common.h
@@ -0,0 +1,109 @@
+/* Definitions for POSIX memory map interface.  Linux/generic version.
+   Copyright (C) 1997,2000,2003,2005,2006,2009 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, write to the Free
+   Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
+   02111-1307 USA.  */
+
+#ifndef _SYS_MMAN_H
+# error "Never use  directly; include  instead."
+#endif
+
+/* The following definitions basically come from the kernel headers.
+   But the kernel header is not namespace clean.  */
+
+
+/* Protections are chosen from these bits, OR'd together.  The
+   implementation does not necessarily support PROT_EXEC or PROT_WRITE
+   without PROT_READ.  The only guarantees are that no writing will be
+   allowed without PROT_WRITE and no access will be allowed for PROT_NONE. */
+
+#define PROT_READ  0x1 /* Page can be read.  */
+#define PROT_WRITE 0x2 /* Page can be written.  */
+#define PROT_EXEC  0x4 /* Page can be executed.  */
+#define PROT_NONE  0x0 /*

Re: [PATCH] implement futimes

[Mike Frysinger]

On Monday 23 November 2009 05:20:22 Rob Landley wrote:
> On Sunday 22 November 2009 21:26:56 Mike Frysinger wrote:
> > On Sunday 22 November 2009 22:19:47 Austin Foxley wrote:
> > > First step towards sanity: Let me commit the nptl_merge branch to
> > > master. If you haven't looked at it, I've got all the relevant changes
> > > for nptl grouped into related commits, and it's up to date with master
> > > as of today.
> > >
> > > I'm going ahead with Step 1 in a day or so, unless someone yells
> > > loudly.
> >
> > i would like to go through it first, at least as a "fresh set of eyes". 
> > i dont want to see more accidental merge commits throwing out good code.
> 
> More code review's always nice, but it's been pending for three years now.
> Couldn't a fresh set of eyes go through it as easily after the merge as
> before?

it hasnt been put up for merging before.  so either you can review the pending 
branch, or you can sit back and wait.
-mike


signature.asc
Description: This is a digitally signed message part.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: Is current -git working for anybody else?

[Mike Frysinger]

On Sunday 22 November 2009 22:22:23 Austin Foxley wrote:
> On 11/11/2009 02:40 PM, Rob Landley wrote:
> > I bisected the problem to:
> >
> > land...@driftwood:~/uclibc/git$ git bisect bad
> > e0ac4efbdb498319f03a2a95d75d061ab6c68491 is first bad commit
> > commit e0ac4efbdb498319f03a2a95d75d061ab6c68491
> > Author: Mike Frysinger
> > Date:   Thu Oct 22 01:05:28 2009 -0400
> >
> >  libc: add hidden calls to pthread cleanup funcs
> >
> >  A lot of libc code calls the pthread cleanup funcs implicitly (for
> > stdio) which currently goes through the PLT.  Since we already have
> > forwarding symbols for these funcs, it's safe to declare the internal
> > libc usage hidden as a loaded libpthread will have the real symbols
> > found.
> >
> >  Signed-off-by: Mike Frysinger
> >
> > I confirmed that reversing that patch fixes the problem.
> 
> I can confirm that crash now as well, I'm going to revert this commit
> until another fix can be made.
> 
> Thanks for the bisecting work!

how exactly did you confirm ?  dynamic x86_64 binaries seem to be running fine 
for me.
-mike


signature.asc
Description: This is a digitally signed message part.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [PATCH] implement futimes

[Mike Frysinger]

On Sunday 22 November 2009 22:19:47 Austin Foxley wrote:
> First step towards sanity: Let me commit the nptl_merge branch to
> master. If you haven't looked at it, I've got all the relevant changes
> for nptl grouped into related commits, and it's up to date with master
> as of today.
> 
> I'm going ahead with Step 1 in a day or so, unless someone yells loudly.

i would like to go through it first, at least as a "fresh set of eyes".  i 
dont want to see more accidental merge commits throwing out good code.
-mike


signature.asc
Description: This is a digitally signed message part.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [PATCH] implement futimes

[Mike Frysinger]

after skimming the noise, i think you failed to address concerns with the 
patch itself.  i never say "futimes wont be added", i merely suggested you 
encourage the UML guys to use POSIX interfaces instead of glibc-specific ones.
-mike


signature.asc
Description: This is a digitally signed message part.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [PATCH 1/2] Extend __gen_tempname with mode argument

[Mike Frysinger]

On Tuesday 17 November 2009 04:09:28 Mikhail Gusarov wrote:
> Twas brillig at 17:25:22 07.11.2009 UTC-05 gyre and gimble:
>>> -extern int __gen_tempname (char *__tmpl, int __kind) attribute_hidden;
>>> +extern int __gen_tempname (char *__tmpl, int __kind, mode_t mode)
>> 
>> can you do a file size comparison between this and a varags
>> approach ?  if kind == __GT_NOCREATE, the mode will always be 0.
>> if it isnt, you can use varargs to rip it off the stack.
> 
> Found a time to test it: varargs variant is a 32bytes longer (at least
> libc.a - still yet to build a working shared library for arm eabi from
> this branch).

that's fine.  thanks for checking this out.
-mike


signature.asc
Description: This is a digitally signed message part.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [PATCH] implement futimes

[Mike Frysinger]

On Wednesday 18 November 2009 19:32:14 Rob Landley wrote:
> User Mode Linux uses futimes(), and thus won't build against uClibc.  This
>  was my quick and dirty first stab at implementing it.  Not very heavily
>  tested.

convince them to convert to futimens() which is in POSIX.  ignoring that:
- hidden proto's go in the header file where the prototype can be found
- we dont bother adding hidden aliases unless something else wants them
- instead of doing INLINE_SYSCALL(), why not call the utimensat() in 
uClibc
- a few style issues ...
- "f+1" -> "f + 1"
- the statement for the else goes on its own line
-mike


signature.asc
Description: This is a digitally signed message part.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [git commit master] futimens: add function

[Mike Frysinger]

On Friday 20 November 2009 14:05:07 Bernhard Reutner-Fischer wrote:
> --- /dev/null
> +++ b/libc/sysdeps/linux/common/futimens.c
> @@ -0,0 +1,23 @@
> +#include 
> +#define __need_timespec
> +#include 
> +#ifdef __NR_utimensat
> +extern int utimensat (int __fd, __const char *__path,
> + __const struct timespec __times[2],
> + int __flags) __THROW;
> +libc_hidden_proto(utimensat)
> +
> +int futimens (int fd, __const struct timespec ts[2])
> +{
> + return utimensat(fd, 0, ts, 0);
> +}
> +#endif

you've added the hidden proto to the header which defines utimensat, so why 
are you duplicating it here ?  makes no sense to do this ...

also, these sprinkling of __need_xxx around in source files looks wrong
-mike


signature.asc
Description: This is a digitally signed message part.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: SOCK_CLOEXEC support in uClibc

[Mike Frysinger]

On Tuesday 10 November 2009 13:40:09 Stephan Raue wrote:
> is there an plan to include SOCK_CLOEXEC for building udev-147+ to uClibc?

people implement features when it interests them.  [good] patches however get 
integrated quickly.
-mike


signature.asc
Description: This is a digitally signed message part.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: Weirdness in elf.h?

[Mike Frysinger]

On Sunday 08 November 2009 19:12:57 Rob Landley wrote:
> #define EM_XTENSA   94  /* Tensilica Xtensa Architecture */
> #define EM_IP2K 101 /* Ubicom IP2022 micro controller
> #define EM_CR   103 /* National Semiconductor
> 3define EM_MSP430   105 /* TI msp430 micro controller */
> #define EM_BLACKFIN 106 /* Analog Devices Blackfin */
> #define EM_ALTERA_NIOS2 113 /* Altera Nios II soft-core processor */
> #define EM_CRX  114 /* National Semiconductor CRX */
> #define EM_NUM  95
> 
> Isn't EM_NUM supposed to be one higher than the largest number used?

yes, but i dont think anyone actually uses this thing.  might be easier to 
just punt it.  if we do fix it, we should important the holes from binutils.
-mike


signature.asc
Description: This is a digitally signed message part.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: Compiling latest master snapshot and _res missing in pthreads error

[Mike Frysinger]

On Sunday 08 November 2009 19:11:38 Sergio M. Ammirata, Ph.D. wrote:
> Hello, I am trying to compile the latest snapshot of master for x86 but
> there is a problem with a missing _res reference in pthreads.
> 
> Does the latest trunk support TLS?

largely, no.  linuxthreads is buyer-beware.  linuxthreads.old doesnt support 
tls at all.

unless you plan on helping fix/debug things, dont use tls.
-mike


signature.asc
Description: This is a digitally signed message part.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: gdb cannot recognize symbol format elf32-i386

[Mike Frysinger]

On Sunday 08 November 2009 09:27:42 Sergio M. Ammirata, Ph.D. wrote:
> With the malloc-simple uclibc, my main buildscript goes to 100% CPU usage
> and never comes back.
> 
> According to Mike, the most likely scenario is the calling application
> corrupting memory. So, I am going down the path of trying to upgrade
> VLC/x264 to the latest version.

malloc-simple is as simple as you can get -- it's based entirely on calling 
mmap/munmap from the kernel.  so the likely hood of that code having a bug is 
very small.  that doesnt mean other things (like pthread) are bug free, just 
that you probably have to look elsewhere.
-mike


signature.asc
Description: This is a digitally signed message part.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [PATCH 1/2] Extend __gen_tempname with mode argument

[Mike Frysinger]

On Saturday 07 November 2009 15:33:15 Mikhail Gusarov wrote:
>   if (__path_search(buf, L_tmpnam, NULL, NULL, 0) != 0
> -  || __gen_tempname(buf, __GT_NOCREATE) != 0
> +  || __gen_tempname(buf, __GT_NOCREATE, 0) != 0
>   ) {
> ...
> -extern int __gen_tempname (char *__tmpl, int __kind) attribute_hidden;
> +extern int __gen_tempname (char *__tmpl, int __kind, mode_t mode)

can you do a file size comparison between this and a varags approach ?  if 
kind == __GT_NOCREATE, the mode will always be 0.  if it isnt, you can use 
varargs to rip it off the stack.
-mike


signature.asc
Description: This is a digitally signed message part.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: gdb cannot recognize symbol format elf32-i386

[Mike Frysinger]

On Saturday 07 November 2009 07:04:40 Sergio M. Ammirata, Ph.D. wrote:
> Apparently the crash is coming from the malloc function under libc.

or someone tromped on memory they shouldnt and uClibc crashed due to that

try using the malloc-simple implementation and see if that crashes as well

or post some simple code that reproduces the crash for someone else to verify
-mike


signature.asc
Description: This is a digitally signed message part.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: Problems compiling autoconf on latest toolchain (10.31.2009)

[Mike Frysinger]

On Thursday 05 November 2009 15:40:22 Sergio M. Ammirata, Ph.D. wrote:
> The autoconf is looking for m4 and fails to configure.
> 
> To make it work on my machine I edited packages/autoconf/autoconf.mk and
> changed:

i guess you meant to send this to buildroot or something ?  this mailing list 
is for uClibc only, and autoconf/m4 is neither.
-mike


signature.asc
Description: This is a digitally signed message part.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: Problem compiling coreutils on toolchain trunk and patch to fix it

[Mike Frysinger]

On Thursday 05 November 2009 15:36:18 Sergio M. Ammirata, Ph.D. wrote:
> The coreutils on the latest snapshot (10.31.2009) of the toolchain does not
> compile. You can put this patch in the packages/coreutils folder to fix it:

this isnt a coreutils list, nor is it a general package building list.  not 
sure if you meant to send this to uClibc or some other list.  ignoring that, 
you shouldnt be patching random configure scripts like this.  *_cv_* vars 
exist for a reason -- set them in your env and/or site and/or cache.
-mike


signature.asc
Description: This is a digitally signed message part.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: Quick and dirty malloc() support for realpath.

[Mike Frysinger]

On Wednesday 28 October 2009 08:08:40 Peter Kjellerstedt wrote:
> > From: Mike Frysinger [mailto:vap...@gentoo.org]
> > On Wednesday 28 October 2009 04:57:01 Peter Kjellerstedt wrote:
> > > From: Mike Frysinger
> > > > our friend goto solves the leak.  stick it in the middle of the file
> > > > to maximize short forward/backward jumps and we only get a small
> > > > increase:
> > > >
> > > > @@ -114,6 +114,8 @@ char got_path[];
> > > > while (*path != '\0' && *path != '/') {
> > > > if (new_path > max_path) {
> > > > __set_errno(ENAMETOOLONG);
> > > > + err:
> > > > +   free(allocated_path);
> > > > return NULL;
> > >
> > > Fore readability, wouldn't it be better to put the three lines
> > > above at the end of the function, and just put another goto err
> > > here? Or is there some other reason to have the error exit path
> > > in the middle of the function?
>
> So, in effect it is an architecture specific optimization.

if it's an optimization that most arches can utilize, and there is no 
difference to arches that lack short forward/backward jumps, then it's 
certainly a valid one to utilize imo.  sad that gcc itself didnt do it, but 
handling of jumps is pretty hard to do.

> With that kind of optimization, isn't it a sign that the
> function is too long and should be split?

feel free to tackle that pig, but considering it's all going to be done with 
static functions that are used once so gcc's going to inline anyways, i dont 
see much point here.  unless doing so allows gcc to do some crazy magic and 
get smaller code ...

> In any case, there should be a comment explaining why the exit path
> is in the middle of the function, or someone is bound to rearrange
> the code for readability at a later stage.

certainly
-mike


signature.asc
Description: This is a digitally signed message part.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: Quick and dirty malloc() support for realpath.

[Mike Frysinger]

On Wednesday 28 October 2009 07:57:50 Bernhard Reutner-Fischer wrote:
> On Wed, Oct 28, 2009 at 05:12:55AM -0400, Mike Frysinger wrote:
> >On Wednesday 28 October 2009 04:57:01 Peter Kjellerstedt wrote:
> >> From: Mike Frysinger
> 
> better but the prototype part is missing (and a note that this
> particular func now adheres to SUSv4 base, eventually)

i wasnt proposing dropping your changes, i just wrote things from scratch.  
the point was to highlight the changes.

did you want me to commit then ?
-mike


signature.asc
Description: This is a digitally signed message part.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: Quick and dirty malloc() support for realpath.

[Mike Frysinger]

On Wednesday 28 October 2009 04:57:01 Peter Kjellerstedt wrote:
> From: Mike Frysinger
> 
> [ cut ]
> 
> > @@ -114,6 +114,8 @@ char got_path[];
> > while (*path != '\0' && *path != '/') {
> > if (new_path > max_path) {
> > __set_errno(ENAMETOOLONG);
> > + err:
> > +   free(allocated_path);
> > return NULL;
> 
> Fore readability, wouldn't it be better to put the three lines
> above at the end of the function, and just put another goto err
> here? Or is there some other reason to have the error exit path
> in the middle of the function?

i stated the reason for doing this in the part you "[ cut ]".  it was all of 
two sentences :P.
-mike


signature.asc
Description: This is a digitally signed message part.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: Quick and dirty malloc() support for realpath.

[Mike Frysinger]

On Tuesday 27 October 2009 15:44:42 Rob Landley wrote:
> On Tuesday 27 October 2009 05:51:05 Bernhard Reutner-Fischer wrote:
> > On Tue, Oct 27, 2009 at 08:54:50AM +0100, Ricard Wanderlof wrote:
> > >On Mon, 26 Oct 2009, Rob Landley wrote:
> > >>... Also, in my experience _Bool is about as real-world useful as
> > >>the bit field notation with the colons, and is really there to keep
> > >>the language pedants and the c++ guys happy without actually
> > >>accomplishing much.  I've never seen it actually produce better
> > >>code.
> > >
> > >It can produce more readable, less error-prone C code though. We use
> >
> > $ size libc/stdlib/realpath.o*
> >textdata bss dec hex filename
> > 555   0   0 555 22b libc/stdlib/realpath.os.oorig
> > 735   0   0 735 2df libc/stdlib/realpath.os.rob
> > 586   0   0 586 24a libc/stdlib/realpath.os
> >
> > perhaps that would do as well and doesn't cost 180b (!) but about 31b..
> 
> The problem is that leaks memory if realpath ever returns failure, such as
>  the lines right after that patch:

our friend goto solves the leak.  stick it in the middle of the file to 
maximize short forward/backward jumps and we only get a small increase:

578   0   0 578 242 libc/stdlib/realpath.os.orig
609   0   0 609 261 libc/stdlib/realpath.os

diff --git a/libc/stdlib/realpath.c b/libc/stdlib/realpath.c
index 1a00c31..146d1d8 100644
--- a/libc/stdlib/realpath.c
+++ b/libc/stdlib/realpath.c
@@ -47,8 +47,7 @@ char got_path[];
char copy_path[PATH_MAX];
/* use user supplied buffer directly - reduces stack usage */
/* char got_path[PATH_MAX]; */
-   char *max_path;
-   char *new_path;
+   char *max_path, *new_path, *allocated_path;
size_t path_len;
int readlinks = 0;
 #ifdef S_IFLNK
@@ -72,12 +71,13 @@ char got_path[];
/* Copy so that path is at the end of copy_path[] */
strcpy(copy_path + (PATH_MAX-1) - path_len, path);
path = copy_path + (PATH_MAX-1) - path_len;
+   allocated_path = got_path ? NULL : malloc(PATH_MAX);
max_path = got_path + PATH_MAX - 2; /* points to last non-NUL char */
new_path = got_path;
if (*path != '/') {
/* If it's a relative pathname use getcwd for starters. */
if (!getcwd(new_path, PATH_MAX - 1))
-   return NULL;
+   goto err;
new_path += strlen(new_path);
if (new_path[-1] != '/')
*new_path++ = '/';
@@ -114,6 +114,8 @@ char got_path[];
while (*path != '\0' && *path != '/') {
if (new_path > max_path) {
__set_errno(ENAMETOOLONG);
+ err:
+   free(allocated_path);
return NULL;
}
*new_path++ = *path++;
@@ -122,7 +124,7 @@ char got_path[];
/* Protect against infinite loops. */
if (readlinks++ > MAX_READLINKS) {
__set_errno(ELOOP);
-   return NULL;
+   goto err;
}
path_len = strlen(path);
/* See if last (so far) pathname component is a symlink. */
@@ -133,13 +135,13 @@ char got_path[];
if (link_len < 0) {
/* EINVAL means the file exists but isn't a 
symlink. */
if (errno != EINVAL) {
-   return NULL;
+   goto err;
}
} else {
/* Safe sex check. */
if (path_len + link_len >= PATH_MAX - 2) {
__set_errno(ENAMETOOLONG);
-   return NULL;
+   goto err;
}
/* Note: readlink doesn't add the null byte. */
/* copy_path[link_len] = '\0'; - we don't need 
it too */
-mike


signature.asc
Description: This is a digitally signed message part.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: Quick and dirty malloc() support for realpath.

[Mike Frysinger]

On Wednesday 28 October 2009 03:47:03 Mike Frysinger wrote:
> while the memory leakage needs to be addressed, the answer isnt with
>  alloca. the spec states that it must be via malloc(), but even ignoring
>  that, it also states that the caller must call free() on the returned
>  pointer.  obviously alloca-ed memory is not valid outside of the return of
>  realpath() (which makes me wonder how your code even worked in the first
>  place), nor can you call free() on it.

nm, i'm retarded.  i'd forgotten about the strdup() at the end.
-mike


signature.asc
Description: This is a digitally signed message part.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: Quick and dirty malloc() support for realpath.

[Mike Frysinger]

On Tuesday 27 October 2009 15:44:42 Rob Landley wrote:
> On Tuesday 27 October 2009 05:51:05 Bernhard Reutner-Fischer wrote:
> > On Tue, Oct 27, 2009 at 08:54:50AM +0100, Ricard Wanderlof wrote:
> > >On Mon, 26 Oct 2009, Rob Landley wrote:
> > >>... Also, in my experience _Bool is about as real-world useful as
> > >>the bit field notation with the colons, and is really there to keep
> > >>the language pedants and the c++ guys happy without actually
> > >>accomplishing much.  I've never seen it actually produce better
> > >>code.
> > >
> > >It can produce more readable, less error-prone C code though. We use
> >
> > $ size libc/stdlib/realpath.o*
> >textdata bss dec hex filename
> > 555   0   0 555 22b libc/stdlib/realpath.os.oorig
> > 735   0   0 735 2df libc/stdlib/realpath.os.rob
> > 586   0   0 586 24a libc/stdlib/realpath.os
> >
> > perhaps that would do as well and doesn't cost 180b (!) but about 31b..
> 
> The problem is that leaks memory if realpath ever returns failure, such as
>  the lines right after that patch:
> 
> path_len = strlen(path);
> if (path_len >= PATH_MAX - 2) {
> __set_errno(ENAMETOOLONG);
> return NULL;
> }
> 
> And at least a half-dozen other "return NULL;" error cases later in the
> function.
> 
> Possibly there's some way to not inline the alloca?  This was, as I said, a
> quick and dirty fix.  Someday we should properly make it handle more than
> PATH_MAX, but that's a big change and I'm just trying to get software using
> Linux libc extensions (and now SUSv4) to work.

while the memory leakage needs to be addressed, the answer isnt with alloca.  
the spec states that it must be via malloc(), but even ignoring that, it also 
states that the caller must call free() on the returned pointer.  obviously 
alloca-ed memory is not valid outside of the return of realpath() (which makes 
me wonder how your code even worked in the first place), nor can you call 
free() on it.
-mike


signature.asc
Description: This is a digitally signed message part.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: Quick and dirty malloc() support for realpath.

[Mike Frysinger]

On Tuesday 27 October 2009 13:46:19 Chris Gray wrote:
> On Tuesday 27 October 2009 08:54:50 Ricard Wanderlof wrote:
> > It can produce more readable, less error-prone C code though. We use
> > hardware register definitions such as
> >
> > typedef struct {
> >unsigned int x : 8;
> >unsigned int y : 8;
> >unsigned int control_bit : 1;
> >unsigned int dummy1  : 15;
> > } reg_foo;
> >
> > at great length for the C definitions for the registers in our chips, and
> > it really does avoid nasty errors that crop up when using shifting and
> > masking.
> 
> I gave up on bitfields the day I ran something like that through two
>  compilers and one decided that x was "obviously" the high-order byte of
>  the word and the other decided it was "obviously" the low-order one. Oh
>  yes and they made opposite decisions about signedness too, but at least
>  you can control that (as in your example). So now I just write little
>  inlined functions or macros to do the manipulations.

since i dont know the exact issue with the compilers in question (endianness 
maybe ?), i dont think those drawbacks are applicable to Ricard's usage.  
doing bit fields for a specific platform means your code is constrained to 
that platform, so portability isnt a real concern.  we do similar things for 
hardware registers for the same reasons Ricard's cites.
-mike


signature.asc
Description: This is a digitally signed message part.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: I just uploaded a photo that I want you to see!

[Mike Frysinger]

ive punted this guy from the list
-mike


signature.asc
Description: This is a digitally signed message part.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: Quick and dirty malloc() support for realpath.

[Mike Frysinger]

On Sunday 25 October 2009 15:19:49 Rob Landley wrote:
> - int readlinks = 0;
> + int readlinks = 0, allocated = 0;
> ...
> + if (!got_path) {
> + got_path = alloca(PATH_MAX);
> + allocated++;
> + }
> ...
> + if (allocated) got_path = strdup(got_path);

it doesnt make any sense to treat "allocated" as an integer that gets 
incremented.  you're pointlessly forcing gcc to generate load/update/store 
instructions when it only needs a store instruction.  i.e. use stdbool like 
evolution intended.
-mike


signature.asc
Description: This is a digitally signed message part.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: preparing 0.9.30.2

[Mike Frysinger]

On Sunday 25 October 2009 17:40:02 Rob Landley wrote:
> On Sunday 25 October 2009 16:13:25 Mike Frysinger wrote:
> > On Sunday 25 October 2009 16:14:17 Rob Landley wrote:
> > > On Monday 12 October 2009 12:38:07 Bernhard Reutner-Fischer wrote:
> > > > I've pushed a couple of fixes from master to the 0_9_30 branch in
> > > > preparation of a 0.9.30.2 bugfix release.
> > >
> > > Ok, I think I've exhausted the menu on the left.  How do I test this
> > > thing?
> >
> > use `git branch` to see all branches
> 
> $ cd ~/uclibc/git
> $ git branch
> * master

`man git-branch` then and read the info.  a simple query shows that you should 
have used the -a and/or -r options.

> > and use `git checkout` to check out a
> > branch/tag/ref/whatever
> 
> And if my clone of the repository hasn't got this branch, and apparently
>  never had this branch, the magic incantation I do to get the branch is...?

that isnt how git works.  a clone is just that -- a clone.  you have the 
entire repo already.
-mike


signature.asc
Description: This is a digitally signed message part.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: preparing 0.9.30.2

[Mike Frysinger]

On Sunday 25 October 2009 16:14:17 Rob Landley wrote:
> On Monday 12 October 2009 12:38:07 Bernhard Reutner-Fischer wrote:
> > I've pushed a couple of fixes from master to the 0_9_30 branch in
> > preparation of a 0.9.30.2 bugfix release.
> 
> Ok, I think I've exhausted the menu on the left.  How do I test this thing?

use `git branch` to see all branches and use `git checkout` to check out a 
branch/tag/ref/whatever
-mike


signature.asc
Description: This is a digitally signed message part.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: uClibc & prelink

[Mike Frysinger]

On Friday 23 October 2009 15:53:53 Carmelo Amoroso wrote:
> Joakim Tjernlund wrote:
> >> Hi All,
> >> just to inform you that we (@STMicroelectronics) are working
> >> to extend uClibc ld.so to support prelinking.
> >> This would go through several steps because there are some
> >> missing feature in uClibc.
> >>
> >> So in he near future I'm planning to post some patches for review.
> >>
> >> Steps should be as follows
> >>
> >> 1 Support for ld.so stand-alone mode (done)
> >
> > Great, I have been meaning to do this for a long time but never gotten
> > around to do it. My motivation was to simplify debugging and to support
> > --library-path PATH as this has been requested a few times.
> 
> now we have --library-path support too.
> 
> Please, hold on for a while; we are working to prepare a set of patch
> for review.

please put it behind a new config option like the original stand alone code 
should have been
CONFIG_LDSO_STANDALONE

while this is great for development, it has very limited application in actual 
deployment
-mike


signature.asc
Description: This is a digitally signed message part.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: preparing 0.9.30.2

[Mike Frysinger]

On Saturday 17 October 2009 18:30:53 Stephan Raue wrote:
> when i am compiling uClibc-0.9.30.2 from today i become follow error:
> 
>CC libc/string/wcslcpy.os
> libc/string/strlcpy.c:62: error: '__EI_wcsxfrm' aliased to undefined
> symbol '__GI_wcsxfrm'
> make: *** [libc/string/wcslcpy.os] Error 1
> make: Leaving directory
> `/home/stephan/projects/OpenELEC/build.OpenELEC.intel.i386.uClibc.devel/uCl
> ibc-0.9.30.2-20091017'

you need to post your .config file when reporting bugs like this
-mike


signature.asc
Description: This is a digitally signed message part.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [PATCH] libc/stdlib/malloc/realloc.c: Fix failure when doing realloc(mem, -1).

[Mike Frysinger]

On Thursday 30 July 2009 15:58:31 James Coleman wrote:
> Now check that new_size is > ((unsigned long)-(MALLOC_HEADER_SIZE*2)),
> which is the same test that is found in malloc.
> 
> This fixes a test failure in test/malloc/tst-mcheck.
> 
> -  /* Check for special cases.  */
> -  if (! new_size)
> +  /* Check for special cases, such as realloc(mem, 0) or if they are
> + doing something dumb like realloc(mem, -1) */
> +  if (unlikely(! new_size) ||
> +  unlikely(((unsigned long)new_size > (unsigned
>  long)(MALLOC_HEADER_SIZE*-2 {
>free (mem);
>return malloc (new_size);

if we do overflow the size field, i dont think we should bother calling down 
to malloc().  it's going to come to the same conclusion and return NULL.  so i 
updated the realloc() code to return NULL itself if this case.
-mike


signature.asc
Description: This is a digitally signed message part.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [git commit master] ldso: define MAP_FAILED for everyone

[Mike Frysinger]

On Thursday 15 October 2009 19:15:41 Mike Frysinger wrote:
> commit:
>  http://git.uclibc.org/uClibc/commit/?id=69a320ec04e71203d7be2117ffef6d0ec6
> 788b7d branch: http://git.uclibc.org/uClibc/commit/?id=refs/heads/master
> 
> This fixes build errors where common code has started using MAP_FAILED.

hrm, thought i squashed this into the _dl_mmap change.  oh well.
-mike


signature.asc
Description: This is a digitally signed message part.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: preparing 0.9.30.2

[Mike Frysinger]

On Thursday 15 October 2009 15:39:28 rhabarber1848 wrote:
> Am Thu, 15 Oct 2009 13:07:25 -0400 schrieb Mike Frysinger:
> > does git master also fail for you ?
> 
> yes:

thanks for testing.  looks like the _dl_mmap() got the best of me.  enough is 
enough for me ... ive finally cleaned up the _dl_mmap() stuff and things 
should build again.
-mike


signature.asc
Description: This is a digitally signed message part.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [git commit master] ldso/: tls support for dynamic linker

[Mike Frysinger]

On Thursday 15 October 2009 17:15:26 Austin Foxley wrote:
> On 10/15/2009 02:11 PM, Joseph S. Myers wrote:
> > "The" NPTL branch certainly once effectively had a lot of bogus
> > reversions of trunk changes, stemming from SVN's inability to track the
> > state of merges that had only merged some trunk changes but not others to
> > the branch.  I pointed that out over three years ago
> > .  I
> > had thought however that whatever the descent of any present NPTL branch,
> > such issues had been fixed by now.
> 
> It has gotten better...but obviously lots of work left to do..

if there's something you want to bang on, then i'd suggest trying to convert 
the #if USE_TLS to if (USE_TLS).  the inline #if USE_TLS all over the place 
doesnt make things easy to digest.

-mike


signature.asc
Description: This is a digitally signed message part.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [git commit] support building out-of-tree

[Mike Frysinger]

On Saturday 10 October 2009 13:18:22 Bernhard Reutner-Fischer wrote:
> On Oct 8, 2009 3:55 AM, "Mike Frysinger" wrote:
>> On Monday 17 August 2009 13:33:41 Bernhard Reutner-Fischer wrote: > commit:
>> > http://git.uclibc.org...
>> > 334e38 branch: http://git.uclibc.org/uClibc/commit/?id=refs/heads/master
>> >
>> >   Handle O=
>> 
>> this causes warnings now because it seems like
>>  extra/config/Makefile.kconfig was mostly duplicated into
>>  extra/config/Makefile
>> 
>> $ git clean -x -d
>> $ make defconfig
>> Makefile:31: warning: overriding commands for target
>> `../../extra/config/dochecklxdialog'
>> /usr/local/src/uClibc/extra/config/Makefile.kconfig:154: warning: ignoring
>> old
>> commands for target `../../extra/config/dochecklxdialog'
>>  HOSTCC-o extra/config/conf.o
>
> This is due to us using the makefile from the kernel while avoiding to
>  touch it up (to make syncs easier).

so you're going to fix it ? ;)
-mike


signature.asc
Description: This is a digitally signed message part.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc