Re: libc size
According to Terry Lambert: The PIC overhead is likely unavoidable. I'd actually like to see the benchmark run on statically linked PIC vs. non-PIC code, so I remember that when I was working on Perl and the FreeBSD port (back in the early 5.000 days), having libperl shared was adding a fairly large overhead. make test ran in between 15% and 25% more time in the shared libperl case... -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- [EMAIL PROTECTED] FreeBSD keltia.freenix.fr 5.0-CURRENT #80: Sun Jun 4 22:44:19 CEST 2000 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: libc size
According to David Schultz: Memory is even less of an issue; if a thousand copies of a shell are running, their text gets shared regardless of how they are linked. IIRC not exactly. In the dynamic case, some fixups are done by the dynamic linker to link with the shared libs and that force the pages to be COW'd thus taking more VM. That's why static binaries are more efficient too. (someone who understand these issues please correct me if necessary) -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- [EMAIL PROTECTED] FreeBSD keltia.freenix.fr 5.0-CURRENT #80: Sun Jun 4 22:44:19 CEST 2000 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Lack of real long double support
In message: [EMAIL PROTECTED] Terry Lambert [EMAIL PROTECTED] writes: : M. Warner Losh wrote: : : This : : example shows that we don't support it in printf, since the above : : example does ***NOT*** give +Inf, but rather whatever 2*DBL_MAX is. : : [ ... ] : : Terry you are wrong. This has to do with the RANGE not the PRECISION : of the floating point number. It is ***NOT*** +Inf. : : I await an explanation of how you can fit 2*DBL_MAX into a double, : which has a range of DBL_MIN..DBL_MAX. Look at the code. long double a = DBL_MAX; long double b = DBL_MAX * 2; The original posting said that b would be +Inf at this point, which is not correct. I think that Bruce was confused there. The more correct example to look at was the one that rittle@ posted which was 1 + LDBL_EPSILON. : : The main issue that I think is outstanding is that you can't get : : both exception behaviour and non-exception behaviour, and it is : : going to have to be the compiler's job to force the issue, because : : it can't dictate implementaiton to the host OS. : : I don't follow. : : I think that a number that's a 64 bit mantissa reaised to an exponent : N takes a larger N if you have only 53 bits of mantissa, if you want : to represent the same value. Nope. The only difference between 53 bits and 64 bits of precision is just that: precision. The number of bits for expoentent is independent of this. : The obvious example in the FreeBSD case is the default value of the : expression (fpgetprec() == FP_PE). The compiler is not permitted to : assume, one way or the other; it has to do runtime testing, at the : time you compile the compiler, to comply with a completely strict : interpretation of C99 (IMO). This is true. Granting, for the moment, that fpgetprec() == FP_PE isn't a standards conforming expression. But I think that the rest of this is going off into the weeds. I'm just trying to get things working in a sane way for long doubles. It looks like gcc 3.2 really wants the fpu to start off in FP_PE. Before I go forward on this further, I've got a lot of testing to do with kernels and such to find out what really works and what does (and doesn't) break paranoia.c. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH: libc]Re: gnome on current
On Wed, Oct 30, 2002 at 06:02:38PM -0800, Juli Mallett wrote: Considering that I built the same applications and ran the same applications fine a while ago, and we've had a binutils upgrade, and things don't break on other systems, I'm inclined to assume there are linker bugs afoot, and all the other speculative stuff seems to be based on misunderstandings or bad information. Huh? Your statement is rather speculative stuff. Other systems (say Linux) are using the same linker we are. Please speculate less. Please grab an older ld and try to prove your speculation. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Lack of real long double support
On Wed, 30 Oct 2002, Terry Lambert wrote: This is the basis of Bruce's complaint: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1099099+0+archive/2002/freebsd-current/20021027.freebsd-current | gcc can't actually support the full range, since it doesn't control | the runtime environement (it could issue a fninit before main() to | change the default, but it shouldn't and doesn't). The exponent | range is lost long before printf() is reached. E.g., | | long double x= DBL_MAX; | long double y = 2 * x; | | gives +Inf for y since the result is doesn't fit in 53-bit precision. | The system header correctly reports this default precision. Any header | genrated by the gcc build should be no different, since the build should | run in the target environment. Please forget this wrong example :-). The precision doesn't affect the exponent range. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH: libc]Re: gnome on current
On Wed, 30 Oct 2002, Juli Mallett wrote: * De: Terry Lambert [EMAIL PROTECTED] [ Data: 2002-10-30 ] [ Subjecte: Re: [PATCH: libc]Re: gnome on current ] Maybe the workaround for now is to make the symbols in libXThrStub.so weak? They *are* weak Terry. The problem is that every bloody definition is weak so the linker has no way of picking the one definition which will actually work. The real problem is that the actual working threads library doesn't provide strong symbols to allow it to override all the other stubs. First strong/last weak should win. You are saying last weak is not winning. That's a linker bug. Considering that I built the same applications and ran the same applications fine a while ago, and we've had a binutils upgrade, and things don't break on other systems, I'm inclined to assume there are linker bugs afoot, and all the other speculative stuff seems to be based on misunderstandings or bad information. I'm not misunderstanding things. I single stepped through the call to pthread_setspecific(), watched the linker lookup the symbol and followed it through into the wrong place (i.e. the stub instead of the real implementation). -- Doug Rabson Mail: [EMAIL PROTECTED] Phone: +44 20 8348 6160 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH: libc]Re: gnome on current
On Wed, 30 Oct 2002, Daniel Eischen wrote: On Wed, 30 Oct 2002, Alexander Kabaev wrote: On Wed, 30 Oct 2002 15:51:48 -0800 Terry Lambert [EMAIL PROTECTED] wrote: NO. If you have a library that's linked to a library containing string symbols, then no other library gets a chance to replace to symbols with its own strong symbols. The first strong symbol always wins, and the search is defined to be depth-first. You are ignoring the fact, that objects, loaded at the application startup time are getting searched first, followed RTLD_GLOBAL objects, and finally by the loaded object DAG. LD_PRELOAD objects override them all. First strong/last weak should win. You are saying last weak is not winning. That's a linker bug. If last weak will win, the normal case when Xthrstub is loaded _after_ libc_r will break. The only way to really fix this is to export pthread_ symbols as strong in libc_r. Exporting them as weak sounds like is a mistake which should be fixed. I disagree. See Solaris 6, 7, 8 9 for an example. Actually, I don't much care about Solaris. I care that a popular desktop package which we have supported for earlier releases does not work. I don't expect anyone to ever run gnome on Solaris but people certainly run gnome on FreeBSD. If you can find some other way that pthread calls can be directed reliably to libc_r even if some random stub library was loaded first, then fine. Otherwise, it seems that strong definitions for pthread symbols is the only reasonable option (which is why gnome2 works on FreeBSD 4.7 presumably). -- Doug Rabson Mail: [EMAIL PROTECTED] Phone: +44 20 8348 6160 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH: libc]Re: gnome on current
On Thu, 31 Oct 2002, Alexander Kabaev wrote: On Wed, 30 Oct 2002 22:25:12 -0500 (EST) Daniel Eischen [EMAIL PROTECTED] wrote: If last weak will win, the normal case when Xthrstub is loaded _after_ libc_r will break. The only way to really fix this is to export pthread_ symbols as strong in libc_r. Exporting them as weak sounds like is a mistake which should be fixed. I disagree. See Solaris 6, 7, 8 9 for an example. Cool. Then let's be consistent and follow Solaris all the way. Libc on Solaris provides full set of pthread_? functions which in turn call weakly defined _pthread_?? counterparts. libpthread in turn provides strong definitions for _pthread_??. Since in absolute majority of cases libc is the first library searched for symbols, all pthread references will be bound to it and failure described by Doug will not happen. Any library providing strong pthread_ definitions will be able to override ones provided by the system. Our libc is quite different. We define a (weak) set of _pthread_* symbols and libc_r defines a set of strong _pthread_* symbols and a set of weak pthread_* aliases for them. It sounds like libc should define weak _pthread_*, and weak pthread_* aliases for them. Libc_r should define strong _pthread_* symbols and libc's aliases will then resolve to them. That ought to work quite well in this situation and should satisfy everyone. -- Doug Rabson Mail: [EMAIL PROTECTED] Phone: +44 20 8348 6160 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Lack of real long double support
On Wed, 30 Oct 2002, M. Warner Losh wrote:
The one issue that I've seen is
long double a = 1.0L;
long double b = 1.0L + LDBL_EPSION
if (a == b) abort();
which is what I'm trying to fix. (note, 1.0L must be spelled
oneld() and long double oneld() { return (1.0L);}) to avoid the
optimizer getting it right.
Example of how fixing this breaks a similar assertion for DBL_ESPILON:
%%%
$ cat z.c
#include float.h
#include floatingpoint.h
long double oneld = 1.0L;
double oned = 1.0;
int
main()
{
test(2);
test(3);
}
int
test(int prec)
{
long double la, lb;
double a, b;
fpsetprec(prec);
la = oneld;
lb = oneld + LDBL_EPSILON;
if (la == lb)
printf(LDBL_EPSILON failed test 1 with prec %d\n, prec);
la = oneld;
lb = oneld + LDBL_EPSILON / 2;
if (la != lb)
printf(LDBL_EPSILON failed test 2 with prec %d\n, prec);
a = oned;
b = oned + DBL_EPSILON;
if (a == b)
printf(DBL_EPSILON failed test 1 with prec %d\n, prec);
a = oned;
b = oned + DBL_EPSILON / 2;
if (a != b)
printf(DBL_EPSILON failed test 2 with prec %d\n, prec);
}
$ cc -o z z.c
$ ./z
LDBL_EPSILON failed test 1 with prec 2
$ cc -O -o z z.c.
$ ./z
LDBL_EPSILON failed test 1 with prec 2
DBL_EPSILON failed test 2 with prec 3
%%%
The full brokenness only shows up with -O.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: [PATCH: libc]Re: gnome on current
hi, there! On Thu, Oct 31, 2002 at 12:39:10AM -0800, David O'Brien wrote: Considering that I built the same applications and ran the same applications fine a while ago, and we've had a binutils upgrade, and things don't break on other systems, I'm inclined to assume there are linker bugs afoot, and all the other speculative stuff seems to be based on misunderstandings or bad information. Huh? Your statement is rather speculative stuff. Other systems (say Linux) are using the same linker we are. Please speculate less. Please grab an older ld and try to prove your speculation. I think the problem is in our dynamic linker or in the way we link dynamic libraries or in the way we compile and link X11 libraries. Linux also has pthreads symbols weakly defined (some of them are defined in glibc, some of them in libpthread) and does not have such problems. /fjoe To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Lack of real long double support
On Wed, 30 Oct 2002, M. Warner Losh wrote:
In message: [EMAIL PROTECTED]
Bruce Evans [EMAIL PROTECTED] writes:
: The reasons are the same as they used to be: incomplete language support
: and incomplete library support. Language support is being completed but
: is far from here yet. See the paper referenced in Loren's reply for more
: details than anyone should want to know.
OK. I'll have to go back and find that reference. I'd really like to
change the __INITIAL_NPXCW__ from 0x127f to 0x137f in npx.h. I think
that we can get the library support in place over time, as this
already is a bullet item in the standards todo list web page. The gcc
3.2 compiler does a decent, but not perfect, job of dealing with the
floating point stuff.
Er, it does the same very imperfect job that it did in when it first
implemented long doubles.
: C99 encourages having a behaviour that is known at compile time and
: telling applications about it in FLT_EVAL_METHOD (this can be set to
: -1 == indeterminable, but that would not be very useful although it
: is the only correct setting now). The compiler should implement the
: system implementor's choice or enforce its own choice. gcc doesn't
: really understand this this. gcc-3.2 thinks that it implementing
: method 0 (no extension of precision) but the npx hardware is nothing
: like that.
I don't understand this completely. ARe you saying that gcc is doing
something worng?
Yes. It doesn't attempt to implement C99 stuff and depends on a fuzzy
reading of C90 to conform to C90. Example of gcc-3.2's schizophrenia
with precision:
%%%
$ cat z.c
double x = 1.0F / 3.0F;
float y = 1.0F;
float z = 3.0F;
double u;
int
main()
{
u = y / z;
printf(x = %.17g\n, x);
printf(u = %.17g\n, u);
return (x == u ? 0 : 1);
}
$ cc -o z z.c
$ ./z
x = 0.333432674408
u = 0.1
%%%
Evaluation at compile time is different that at runtime because gcc
thinks that float operations are performed in float precision and
performs them at that precision at compile time. But float operations
at runtime are actually performed in the ambient precision due to
white lies like the following in i386.md:
%%%
(define_expand divsf3
[(set (match_operand:SF 0 register_operand )
(div:SF (match_operand:SF 1 register_operand )
(match_operand:SF 2 nonimmediate_operand )))]
TARGET_80387 || TARGET_SSE_MATH
)
%%%
(This says that the result of dividing a single-precision float by a
single precision float is a single-precision float, but the result is
actually an ambient-precision float.)
The above example is for float precision. The FreeBSD default basically
insulates users from surprises due to precision when everything is a long
double.
BTW, NetBSD is kinda schizophrenic about this:
It just supports a lot of cases.
/*
* The i387 defaults to Intel extended precision mode and round to nearest,
* with all exceptions masked.
*/
#define __INITIAL_NPXCW__ 0x037f
/* NetBSD uses IEEE double precision. */
#define __NetBSD_NPXCW__0x127f
/* FreeBSD leaves some exceptions unmasked as well. */
#define __FreeBSD_NPXCW__ 0x1272
This is the FreeBSD[1-3] default.
/* iBCS2 goes a bit further and leaves the underflow exception unmasked. */
#define __iBCS2_NPXCW__ 0x0262
FreeBSD and NetBSD are both derived from 386BSD which had this. I added
the 0x1000 bit in case 386BSD ever got run with a 287.
/* Linux just uses the default control word. */
#define __Linux_NPXCW__ 0x037f
/* SVR4 uses the same control word as iBCS2. */
#define __SVR4_NPXCW__ 0x0262
So their float.h values are correct only for Linux binaries and
emulation. Also, it looks like FreeBSD_NPXCW is incorrect, since we
Linux binaries are just differently incorrect :-).
have:
#define __INITIAL_NPXCW__ 0x127F
And there's a comment:
* 64-bit precision often gives bad results with high level languages
* because it makes the results of calculations depend on whether
* intermediate values are stored in memory or in FPU registers.
which seems like a compiler issue, not an OS issue to me.
Indeed it is mostly a language issue, so this is not a very good place to
decide the setting. You would not be wrong to set it in crt0 if you removed
it in the kernel (just set the hardware default in the kernel). But the
library can still override any unwanted defaults.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: [PATCH: libc]Re: gnome on current
On Thu, 31 Oct 2002, Alexander Kabaev wrote:
On Wed, 30 Oct 2002 22:25:12 -0500 (EST)
Daniel Eischen [EMAIL PROTECTED] wrote:
If last weak will win, the normal case when Xthrstub is loaded
_after_ libc_r will break. The only way to really fix this is to
export pthread_ symbols as strong in libc_r. Exporting them as weak
sounds like is a mistake which should be fixed.
I disagree. See Solaris 6, 7, 8 9 for an example.
Cool. Then let's be consistent and follow Solaris all the way. Libc on
Solaris provides full set of pthread_? functions which in turn call
weakly defined _pthread_?? counterparts. libpthread in turn provides
strong definitions for _pthread_??.
Since in absolute majority of cases libc is the first library searched
for symbols, all pthread references will be bound to it and failure
described by Doug will not happen.
Any library providing strong pthread_ definitions will be able to
override ones provided by the system.
Something along these lines appears to work nicely and ought to work
either with or without libXThrStub, which is now redundant since libc will
be providing strong symbols that override all the weak symbols in
libXThrStub. We should adjust the XFree86-4-libraries port to avoid
building and using that library.
Index: gen/_pthread_stubs.c
===
RCS file: /home/ncvs/src/lib/libc/gen/_pthread_stubs.c,v
retrieving revision 1.7
diff -u -r1.7 _pthread_stubs.c
--- gen/_pthread_stubs.c19 Sep 2002 01:09:49 - 1.7
+++ gen/_pthread_stubs.c31 Oct 2002 09:31:25 -
@@ -31,6 +31,9 @@
#include pthread.h
#include pthread_np.h
+void *_pthread_getspecific(pthread_key_t key);
+pthread_t _pthread_self(void);
+
/*
* Weak symbols: All libc internal usage of these functions should
* use the weak symbol versions (_pthread_XXX). If libpthread is
@@ -42,6 +45,7 @@
*/
__weak_reference(_pthread_cond_init_stub, _pthread_cond_init);
__weak_reference(_pthread_cond_signal_stub,_pthread_cond_signal);
+__weak_reference(_pthread_cond_broadcast_stub, _pthread_cond_broadcast);
__weak_reference(_pthread_cond_wait_stub, _pthread_cond_wait);
__weak_reference(_pthread_cond_destroy_stub, _pthread_cond_destroy);
__weak_reference(_pthread_getspecific_stub,_pthread_getspecific);
@@ -87,6 +91,12 @@
}
int
+_pthread_cond_broadcast_stub(pthread_cond_t *cond)
+{
+ return (0);
+}
+
+int
_pthread_cond_wait_stub(pthread_cond_t *cond, pthread_mutex_t *mutex)
{
return (0);
@@ -235,4 +245,174 @@
_pthread_sigmask_stub(int how, const sigset_t *set, sigset_t *oset)
{
return (0);
+}
+
+int
+pthread_cond_init(pthread_cond_t *cond,
+const pthread_condattr_t *cond_attr)
+{
+ return (_pthread_cond_init(cond, cond_attr));
+}
+
+int
+pthread_cond_signal(pthread_cond_t *cond)
+{
+ return (_pthread_cond_signal(cond));
+}
+
+int
+pthread_cond_broadcast(pthread_cond_t *cond)
+{
+ return (_pthread_cond_broadcast(cond));
+}
+
+int
+pthread_cond_wait(pthread_cond_t *cond, pthread_mutex_t *mutex)
+{
+ return (_pthread_cond_wait(cond, mutex));
+}
+
+int
+pthread_cond_destroy(pthread_cond_t *cond)
+{
+ return (_pthread_cond_destroy(cond));
+}
+
+void *
+pthread_getspecific(pthread_key_t key)
+{
+ return (_pthread_getspecific(key));
+}
+
+int
+pthread_key_create(pthread_key_t *key, void (*destructor) (void *))
+{
+ return (_pthread_key_create(key, destructor));
+}
+
+int
+pthread_key_delete(pthread_key_t key)
+{
+ return (_pthread_key_delete(key));
+}
+
+int
+pthread_main_np()
+{
+ return (_pthread_main_np());
+}
+
+int
+pthread_mutex_destroy(pthread_mutex_t *mattr)
+{
+ return (_pthread_mutex_destroy(mattr));
+}
+
+int
+pthread_mutex_init(pthread_mutex_t *mutex, const pthread_mutexattr_t *mattr)
+{
+ return (_pthread_mutex_init(mutex, mattr));
+}
+
+int
+pthread_mutex_lock(pthread_mutex_t *mutex)
+{
+ return (_pthread_mutex_lock(mutex));
+}
+
+int
+pthread_mutex_trylock(pthread_mutex_t *mutex)
+{
+ return (_pthread_mutex_trylock(mutex));
+}
+
+int
+pthread_mutex_unlock(pthread_mutex_t *mutex)
+{
+ return (_pthread_mutex_unlock(mutex));
+}
+
+int
+pthread_mutexattr_init(pthread_mutexattr_t *mattr)
+{
+ return (_pthread_mutexattr_init(mattr));
+}
+
+int
+pthread_mutexattr_destroy(pthread_mutexattr_t *mattr)
+{
+ return (_pthread_mutexattr_destroy(mattr));
+}
+
+int
+pthread_mutexattr_settype(pthread_mutexattr_t *mattr, int type)
+{
+ return (_pthread_mutexattr_settype(mattr, type));
+}
+
+int
+pthread_once(pthread_once_t *once_control, void (*init_routine) (void))
+{
+ return (_pthread_once(once_control, init_routine));
+}
+
+int
+pthread_rwlock_init(pthread_rwlock_t *rwlock,
+const pthread_rwlockattr_t *attr)
+{
+ return (_pthread_rwlock_init(rwlock, attr));
+}
+
+int
+pthread_rwlock_destroy(pthread_rwlock_t *rwlock)
+{
+ return
Re: [PATCH: libc]Re: gnome on current
On Thu, 31 Oct 2002, Doug Rabson wrote:
On Thu, 31 Oct 2002, Alexander Kabaev wrote:
On Wed, 30 Oct 2002 22:25:12 -0500 (EST)
Daniel Eischen [EMAIL PROTECTED] wrote:
If last weak will win, the normal case when Xthrstub is loaded
_after_ libc_r will break. The only way to really fix this is to
export pthread_ symbols as strong in libc_r. Exporting them as weak
sounds like is a mistake which should be fixed.
I disagree. See Solaris 6, 7, 8 9 for an example.
Cool. Then let's be consistent and follow Solaris all the way. Libc on
Solaris provides full set of pthread_? functions which in turn call
weakly defined _pthread_?? counterparts. libpthread in turn provides
strong definitions for _pthread_??.
Since in absolute majority of cases libc is the first library searched
for symbols, all pthread references will be bound to it and failure
described by Doug will not happen.
Any library providing strong pthread_ definitions will be able to
override ones provided by the system.
Something along these lines appears to work nicely and ought to work
either with or without libXThrStub, which is now redundant since libc will
be providing strong symbols that override all the weak symbols in
libXThrStub. We should adjust the XFree86-4-libraries port to avoid
building and using that library.
This version works better - it fixes some typos in the rwlock stubs.
Index: gen/_pthread_stubs.c
===
RCS file: /home/ncvs/src/lib/libc/gen/_pthread_stubs.c,v
retrieving revision 1.7
diff -u -r1.7 _pthread_stubs.c
--- gen/_pthread_stubs.c19 Sep 2002 01:09:49 - 1.7
+++ gen/_pthread_stubs.c31 Oct 2002 10:10:42 -
@@ -31,6 +31,9 @@
#include pthread.h
#include pthread_np.h
+void *_pthread_getspecific(pthread_key_t key);
+pthread_t _pthread_self(void);
+
/*
* Weak symbols: All libc internal usage of these functions should
* use the weak symbol versions (_pthread_XXX). If libpthread is
@@ -42,6 +45,7 @@
*/
__weak_reference(_pthread_cond_init_stub, _pthread_cond_init);
__weak_reference(_pthread_cond_signal_stub,_pthread_cond_signal);
+__weak_reference(_pthread_cond_broadcast_stub, _pthread_cond_broadcast);
__weak_reference(_pthread_cond_wait_stub, _pthread_cond_wait);
__weak_reference(_pthread_cond_destroy_stub, _pthread_cond_destroy);
__weak_reference(_pthread_getspecific_stub,_pthread_getspecific);
@@ -59,9 +63,10 @@
__weak_reference(_pthread_once_stub, _pthread_once);
__weak_reference(_pthread_self_stub, _pthread_self);
__weak_reference(_pthread_rwlock_init_stub,_pthread_rwlock_init);
+__weak_reference(_pthread_rwlock_destroy_stub, _pthread_rwlock_destroy);
__weak_reference(_pthread_rwlock_rdlock_stub, _pthread_rwlock_rdlock);
__weak_reference(_pthread_rwlock_tryrdlock_stub, _pthread_rwlock_tryrdlock);
-__weak_reference(_pthread_rwlock_trywrlock_stub, _pthread_rwlock_trywrloc);
+__weak_reference(_pthread_rwlock_trywrlock_stub, _pthread_rwlock_trywrlock);
__weak_reference(_pthread_rwlock_unlock_stub, _pthread_rwlock_unlock);
__weak_reference(_pthread_rwlock_wrlock_stub, _pthread_rwlock_wrlock);
__weak_reference(_pthread_setspecific_stub,_pthread_setspecific);
@@ -87,6 +92,12 @@
}
int
+_pthread_cond_broadcast_stub(pthread_cond_t *cond)
+{
+ return (0);
+}
+
+int
_pthread_cond_wait_stub(pthread_cond_t *cond, pthread_mutex_t *mutex)
{
return (0);
@@ -235,4 +246,174 @@
_pthread_sigmask_stub(int how, const sigset_t *set, sigset_t *oset)
{
return (0);
+}
+
+int
+pthread_cond_init(pthread_cond_t *cond,
+const pthread_condattr_t *cond_attr)
+{
+ return (_pthread_cond_init(cond, cond_attr));
+}
+
+int
+pthread_cond_signal(pthread_cond_t *cond)
+{
+ return (_pthread_cond_signal(cond));
+}
+
+int
+pthread_cond_broadcast(pthread_cond_t *cond)
+{
+ return (_pthread_cond_broadcast(cond));
+}
+
+int
+pthread_cond_wait(pthread_cond_t *cond, pthread_mutex_t *mutex)
+{
+ return (_pthread_cond_wait(cond, mutex));
+}
+
+int
+pthread_cond_destroy(pthread_cond_t *cond)
+{
+ return (_pthread_cond_destroy(cond));
+}
+
+void *
+pthread_getspecific(pthread_key_t key)
+{
+ return (_pthread_getspecific(key));
+}
+
+int
+pthread_key_create(pthread_key_t *key, void (*destructor) (void *))
+{
+ return (_pthread_key_create(key, destructor));
+}
+
+int
+pthread_key_delete(pthread_key_t key)
+{
+ return (_pthread_key_delete(key));
+}
+
+int
+pthread_main_np()
+{
+ return (_pthread_main_np());
+}
+
+int
+pthread_mutex_destroy(pthread_mutex_t *mattr)
+{
+ return (_pthread_mutex_destroy(mattr));
+}
+
+int
+pthread_mutex_init(pthread_mutex_t *mutex, const pthread_mutexattr_t *mattr)
+{
+ return (_pthread_mutex_init(mutex, mattr));
+}
+
+int
+pthread_mutex_lock(pthread_mutex_t *mutex)
+{
+ return (_pthread_mutex_lock(mutex));
+}
+
+int
Re: adaptec scsi - seagate da -- current
On Wed, Oct 30, 2002 at 10:00:29AM -0700, Justin T. Gibbs wrote: Can you provide the model number and firmware revision for this drive? According to the controller, the drive is failing to respond to a whole slew of commands that we have queued to it. You might have better luck if you reduce the tag depth to the disk via camcontrol. Here is more from the dmesg about the scsi adapter and the drive . ahc0: Adaptec aic7890/91 Ultra2 SCSI adapter port 0xa400-0xa4ff mem 0xe410 -0xe4100fff irq 10 at device 8.0 on pci2 aic7890/91: Ultra2 Wide Channel A, SCSI Id=7, 32/253 SCBs da0 at ahc0 bus 0 target 3 lun 0 da0: SEAGATE SX910800N 8514 Fixed Direct Access SCSI-2 device da0: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled da0: 8669MB (17755614 512 byte sectors: 255H 63S/T 1105C) strangely the model number printed on the drive is ST410800N as opposed to what da lists above. the scsi bios also recognizes it as SX910800N always has been only I never noticed I have no idea how to get the firmware!! nothing to that effect is printed on the drive there are a whole bunch of other numbers on it tho: part number : 9A7001-035 lot number : K-01-9718-4 serial no. : SH410798 download code revision : 8511 finally a separate sticker with a number and a barcode without any mention of what it is (__may__ be this is the firmware revision) 70768238 Thanks in advance and please keep me posted... regards, Saurabh Gupta To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: burncd/cdcontrol
It seems Nate Lawson wrote: On Sun, 27 Oct 2002, Soeren Schmidt wrote: Hmm, it is true that I could use ATAPI command directly in burncd, and I actually have a version in the lab that is ~75% converted to that, I'd love to see that once you're ready to release. I'm not sure it will ever be, but the ongoing DVD stuff might bring it to that... but that is not the only issue here. The ATAPI cd driver has quite a bit of functionality that the SCSI cd driver hasn't, fx the ability to read all kinds of CD's no matter what the block size, the ablity to read individual tracks, and supporting ATAPI changer devices just to mention a few :) We need to fixup cd(4) then. Right, problem is that some of this will need serious changes to the CAM system as far as I've been told during the last years... Besides for some of us that uses small systems without SCSI in them, saving the +100k of compiled code for the CAM overhead is important. Oh, and besides the SCSI/CAM cd driver didn't exist when I did the first version of the ATAPI cd driver, that was the old SCSI system back then... That's surprising to me since the man page claimed CAM cd(4) (not scd) appeared in 3.0R while acd(4) appeared in 4.0R. I guess you mean the predecessor to acd (was it wcd)? I did an atapi-cd.c that fitted into the old wd based system to support ATAPI burners back when there was a common ioctl interface to do that. CAM did away with the compatiblity so the ATA world was left to use the ioctl interface alone. To ram a nail through all the crap about the ATAPI drivers being reinventions, here is the deal: When I set out to write the current ATA driver, all I had was the ATAPI cd and tape drivers, those are just evolvements of what I had written for the old wd based driver. Now the real job was to get the ATA part and the lowlevel ATAPI code done, and to that purpose having existing and working ATAPI drivers was a huge winn. Back then CAM was just barely in the tree yet, so that was not really an option to use. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: burncd/cdcontrol
Le 2002-10-27, Soeren Schmidt écrivait : Hmm, it is true that I could use ATAPI command directly in burncd, and I actually have a version in the lab that is ~75% converted to that, Nice! but that is not the only issue here. The ATAPI cd driver has quite a bit of functionality that the SCSI cd driver hasn't, fx the ability I plan to work on these. Thomas. -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
alpha tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /home/des/tinderbox/alpha/obj/h/des/src/alpha/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- Kernel build for GENERIC started on Thu Oct 31 03:06:15 PST 2002 -- === vinum cc1: warnings being treated as errors /h/des/src/sys/dev/amr/amr.c: In function `amr_setup_ccbmap': /h/des/src/sys/dev/amr/amr.c:1055: warning: initialization from incompatible pointer type *** Error code 1 Stop in /h/des/obj/h/des/src/sys/GENERIC. *** Error code 1 Stop in /h/des/src. *** Error code 1 Stop in /h/des/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Lack of real long double support
Thus spake Bruce Evans [EMAIL PROTECTED]: $ cc -o z z.c $ ./z LDBL_EPSILON failed test 1 with prec 2 $ cc -O -o z z.c. $ ./z LDBL_EPSILON failed test 1 with prec 2 DBL_EPSILON failed test 2 with prec 3 %%% The full brokenness only shows up with -O. Actually, the _full_ brokenness of floating point in FreeBSD shows up only with -O2. :-( A number of library functions (e.g. isinf()) use unions for type punning, which violates C's aliasing rules. It turns out that there's a bad interaction between gcc3's -fschedule-insns and -fstrict-aliasing (both implied by -O2) that can cause problems. The best fix I know of is to use unions in the limited way that gcc's optimizer knows how to handle in a reasonable way. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH: libc]Re: gnome on current
On Thu, 31 Oct 2002, Max Khon wrote: hi, there! On Thu, Oct 31, 2002 at 12:39:10AM -0800, David O'Brien wrote: Considering that I built the same applications and ran the same applications fine a while ago, and we've had a binutils upgrade, and things don't break on other systems, I'm inclined to assume there are linker bugs afoot, and all the other speculative stuff seems to be based on misunderstandings or bad information. Huh? Your statement is rather speculative stuff. Other systems (say Linux) are using the same linker we are. Please speculate less. Please grab an older ld and try to prove your speculation. I think the problem is in our dynamic linker or in the way we link dynamic libraries or in the way we compile and link X11 libraries. Linux also has pthreads symbols weakly defined (some of them are defined in glibc, some of them in libpthread) and does not have such problems. I think you are mistaken. On my RedHat 8.0 system, there are weak pthread_* symbols in libc.so and strong ones in libpthread.so. Linux doesn't use libXThrStub.so, presumably because libc.so's pthread_* symbols are suitable stubs. -- Doug Rabson Mail: [EMAIL PROTECTED] Phone: +44 20 8348 6160 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
port security/p5-Authen-PAM doesn't build
Hi folks, I tried to build webmin on 5.0-current and the required port security/p5-Authen-PAM fails to build. At first there was an error in configuration which I have fixed and send the patch (PR ports/ports/44769). Now comes up another error which I'm not able to fix, because it seems that PAM.c has contains more than 1 source file and I never have seen such a thing before and don't know how to handle. Could please anyone applies the patch in his own environment and tries to help me to fix the port? Thanks in advance, Jens -- L i W W W i Jens Rehsack LW W W L i W W W W i nnnLiWing IT-Services L iW W W Wi n n g g i W W i n n g gFriesenstraße 2 06112 Halle g g g Tel.: +49 - 3 45 - 5 17 05 91ggg e-Mail: [EMAIL PROTECTED] Fax: +49 - 3 45 - 5 17 05 92http://www.liwing.de/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
GENERIC bórken...
cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstric t-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fforma t-extensions -ansi -g -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/dev -I/us r/src/sys/contrib/dev/acpica -I/usr/src/sys/contrib/ipfilter -D_KERNEL -include opt_global.h -fno-common -mno-align-long-strings -mpreferred-stack-boundary=2 - ffreestanding -Werror /usr/src/sys/dev/amr/amr.c cc1: warnings being treated as errors /usr/src/sys/dev/amr/amr.c: In function `amr_setup_ccbmap': /usr/src/sys/dev/amr/amr.c:1055: warning: initialization from incompatible point er type *** Error code 1 Stop in /usr/obj/usr/src/sys/GENERIC. *** Error code 1 Stop in /usr/src. *** Error code 1 -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Lack of real long double support
On Thu, 31 Oct 2002, David Schultz wrote:
Thus spake Bruce Evans [EMAIL PROTECTED]:
$ cc -o z z.c
$ ./z
LDBL_EPSILON failed test 1 with prec 2
$ cc -O -o z z.c.
$ ./z
LDBL_EPSILON failed test 1 with prec 2
DBL_EPSILON failed test 2 with prec 3
%%%
The full brokenness only shows up with -O.
Actually, the _full_ brokenness of floating point in FreeBSD shows
up only with -O2. :-( A number of library functions
(e.g. isinf()) use unions for type punning, which violates C's
aliasing rules.
It turns out that there's a bad interaction
between gcc3's -fschedule-insns and -fstrict-aliasing (both
implied by -O2) that can cause problems. The best fix I know of
is to use unions in the limited way that gcc's optimizer knows how
to handle in a reasonable way.
Eeek.
gcc.info says one version is required to work even with -fstrict-aliasing.
The problems seems to be limited, since msun was fixed before rev.1.1
to use this version. From msun/src/math_private.h:
%%%
/*
* The original fdlibm code used statements like:
* n0 = ((*(int*)one)29)^1; * index of high word *
* ix0 = *(n0+(int*)x); * high word of x *
* ix1 = *((1-n0)+(int*)x); * low word of x *
* to dig two 32 bit words out of the 64 bit IEEE floating point
* value. That is non-ANSI, and, moreover, the gcc instruction
* scheduler gets it wrong. We instead use the following macros.
* Unlike the original code, we determine the endianness at compile
* time, not at run time; I don't see much benefit to selecting
* endianness at run time.
*/
...
#define EXTRACT_WORDS(ix0,ix1,d)\
do {\
ieee_double_shape_type ew_u; \
ew_u.value = (d); \
(ix0) = ew_u.parts.msw; \
(ix1) = ew_u.parts.lsw; \
} while (0)
...
%%%
This stores the double into the union and doesn't use any pointers to
access the results, so it should work. isinf.c and even the fixed
version of strtod.c uses a dubious cast to pun the double to a union.
I think the store gets optimized away as far as possible.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
ia64 tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /home/tinderbox/ia64/obj/home/tinderbox/ia64/src/ia64/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- Kernel build for GENERIC started on Thu Oct 31 04:06:07 PST 2002 -- === xe /home/tinderbox/ia64/src/sys/contrib/dev/acpica/hwregs.c: In function `AcpiGetSleepTypeData': /home/tinderbox/ia64/src/sys/contrib/dev/acpica/hwregs.c:242: warning: cast discards qualifiers from pointer target type /home/tinderbox/ia64/src/sys/contrib/dev/acpica/utglobal.c: In function `AcpiUtGetRegionName': /home/tinderbox/ia64/src/sys/contrib/dev/acpica/utglobal.c:489: warning: cast discards qualifiers from pointer target type /home/tinderbox/ia64/src/sys/contrib/dev/acpica/utglobal.c: In function `AcpiUtGetEventName': /home/tinderbox/ia64/src/sys/contrib/dev/acpica/utglobal.c:527: warning: cast discards qualifiers from pointer target type /home/tinderbox/ia64/src/sys/contrib/dev/acpica/utglobal.c: In function `AcpiUtGetTypeName': /home/tinderbox/ia64/src/sys/contrib/dev/acpica/utglobal.c:604: warning: cast discards qualifiers from pointer target type /home/tinderbox/ia64/src/sys/contrib/dev/acpica/utglobal.c:607: warning: cast discards qualifiers from pointer target type /home/tinderbox/ia64/src/sys/dev/acpica/acpi_powerres.c:272: warning: `acpi_pwr_deregister_consumer' defined but not used /home/tinderbox/ia64/src/sys/dev/acpica/acpi_powerres.c:210: warning: `acpi_pwr_deregister_resource' defined but not used cc1: warnings being treated as errors /home/tinderbox/ia64/src/sys/dev/amr/amr.c: In function `amr_setup_ccbmap': /home/tinderbox/ia64/src/sys/dev/amr/amr.c:1055: warning: initialization from incompatible pointer type *** Error code 1 Stop in /home/tinderbox/ia64/obj/home/tinderbox/ia64/src/sys/GENERIC. *** Error code 1 Stop in /home/tinderbox/ia64/src. *** Error code 1 Stop in /home/tinderbox/ia64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH: libc]Re: gnome on current
* De: David O'Brien [EMAIL PROTECTED] [ Data: 2002-10-31 ] [ Subjecte: Re: [PATCH: libc]Re: gnome on current ] On Wed, Oct 30, 2002 at 06:02:38PM -0800, Juli Mallett wrote: Considering that I built the same applications and ran the same applications fine a while ago, and we've had a binutils upgrade, and things don't break on other systems, I'm inclined to assume there are linker bugs afoot, and all the other speculative stuff seems to be based on misunderstandings or bad information. Huh? Your statement is rather speculative stuff. Other systems (say Linux) are using the same linker we are. Please speculate less. Please grab an older ld and try to prove your speculation. It's deductive. Other systems are using similar library setups, in terms of weak vs. strong systems, and some of those are very well supported by GNOME by a commercial vendor, or will be if not now for GNOME2. I'm running GNOME2 right now that was built about two weeks before the last binutils upgrade, which had about 900 lines of ChangeLog entries associated with it. The symbol strength in libc and libc_r has not changed similarly in that time. I was just throwing my speculation based on my experiences with what is working, trying to keep in mind what has changed in the mean time, and what is involved with what's going on. Which Linux distributions have the symbol strength as we do, have libXThrStub in their link lines, -and- are using the same binutils as us? I'm not saying that has to be it, I'm saying given what I'm writing this reply on/inside, I'm saying I doubt dfr's insistance on breaking non libc_r.so thread libraries being the only thing is seeming more and more wrong, as I ldd every binary I'm currently running. juli. -- Juli Mallett [EMAIL PROTECTED] | FreeBSD: The Power To Serve Will break world for fulltime employment. | finger [EMAIL PROTECTED] http://people.FreeBSD.org/~jmallett/ | Support my FreeBSD hacking! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: GENERIC bórken...
On Thu, Oct 31, 2002 at 01:21:38PM +0100, Poul-Henning Kamp wrote: ffreestanding -Werror /usr/src/sys/dev/amr/amr.c cc1: warnings being treated as errors /usr/src/sys/dev/amr/amr.c: In function `amr_setup_ccbmap': /usr/src/sys/dev/amr/amr.c:1055: warning: initialization from incompatible point er type *** Error code 1 It's a good practice to compile things before checking them in. --- amr.c.orig Thu Oct 31 18:19:32 2002 +++ amr.c Thu Oct 31 18:19:59 2002 @@ -1052,7 +1052,7 @@ struct amr_softc*sc = ac-ac_sc; struct amr_sgentry *sg; struct amr_passthrough *ap = (struct amr_passthrough *)ac-ac_data; -struct amr_ext_passthrough *aep = (struct amr_passthrough *)ac-ac_data; +struct amr_ext_passthrough *aep = (struct amr_ext_passthrough *)ac-ac_data; int i; /* get base address of s/g table */ -- Craig Rodrigues http://www.gis.net/~craigr [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH: libc]Re: gnome on current
On Thu, 31 Oct 2002, Alexander Kabaev wrote: On Wed, 30 Oct 2002 22:25:12 -0500 (EST) Daniel Eischen [EMAIL PROTECTED] wrote: If last weak will win, the normal case when Xthrstub is loaded _after_ libc_r will break. The only way to really fix this is to export pthread_ symbols as strong in libc_r. Exporting them as weak sounds like is a mistake which should be fixed. I disagree. See Solaris 6, 7, 8 9 for an example. Cool. Then let's be consistent and follow Solaris all the way. Libc on Solaris provides full set of pthread_? functions which in turn call weakly defined _pthread_?? counterparts. libpthread in turn provides strong definitions for _pthread_??. No, please see earlier messages in this thread. -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: changes to make(1)
On Thu, Oct 31, 2002 at 04:37:32AM -0500, AlanE wrote:
On Thu, Oct 31, 2002 at 11:20:26AM +0200, Ruslan Ermilov wrote:
On Thu, Oct 31, 2002 at 01:12:46AM -0500, AlanE wrote:
On Wed, Oct 30, 2002 at 10:08:20PM -0800, David O'Brien wrote:
On Thu, Oct 31, 2002 at 01:03:20AM -0500, AlanE wrote:
There is also an expression parser bug that I would like to fix; it is
a confusing error that causes make(1) to reject perfectly legitimate
conditional expressions. We'll see about that one when I get to it; I
suspect it should wait until after 5.0-RELEASE.
If make release isn't broken, it should 100% wait until after
5.0-RELEASE.
I tend to agree here. No existing Makefiles are broken, so it can
wait. (Besides, I haven't even begun to investigate the problem...)
What is this problem you're talking about? I might have already
looked at it recently.
This code works correctly.
.if ${PERL_MAJOR} 5 || ${PERL_MAJOR} == 5 ${PERL_MINOR} 8
${ECHO_CMD} This port might need the p5-File-Spec port.
.endif # ${PERL_MAJOR} 5 || ${PERL_MAJOR} == 5 ${PERL_MINOR} 8
This code, differing only in the use of ()'s to group the expressions,
causes make(1) to think it is doing *string* comparisons, and then
complain very loudly about only using == and != in said comparison.
.if (${PERL_MAJOR} 5) || (${PERL_MAJOR} == 5 ${PERL_MINOR} 8)
${ECHO_CMD} This port might need the p5-File-Spec port.
.endif # (${PERL_MAJOR} 5) || (${PERL_MAJOR} == 5 ${PERL_MINOR} 8)
Heh, I wondered about that too when I first these strange lines in
bsd.port.mk with spaces surronding parentheses -- it also works if
you insert spaces after digits before right parentheses:
.if (${PERL_MAJOR} 5 ) || (${PERL_MAJOR} == 5 ${PERL_MINOR} 8 )
Here is the fix:
%%%
Index: cond.c
===
RCS file: /home/ncvs/src/usr.bin/make/cond.c,v
retrieving revision 1.25
diff -u -p -r1.25 cond.c
--- cond.c 23 Oct 2002 23:16:42 - 1.25
+++ cond.c 31 Oct 2002 13:10:13 -
@@ -688,14 +688,15 @@ do_string_compare:
}
} else {
char *c = CondCvtArg(rhs, right);
- if (*c != '\0' !isspace((unsigned char) *c))
+ if (*c != '\0' *c != ')'
+ !isspace((unsigned char) *c))
goto do_string_compare;
if (rhs == condExpr) {
/*
* Skip over the right-hand side
*/
while(!isspace((unsigned char) *condExpr)
- (*condExpr != '\0')) {
+ *condExpr != ')' *condExpr != '\0') {
condExpr++;
}
}
%%%
ports/devel/pmake is also vulnerable to this (even the latest beta),
and unless I'm dreadfully mistaken, OpenBSD's make(1) too.
Cheers,
--
Ruslan Ermilov Sysadmin and DBA,
[EMAIL PROTECTED] Sunbay Software AG,
[EMAIL PROTECTED] FreeBSD committer,
+380.652.512.251Simferopol, Ukraine
http://www.FreeBSD.org The Power To Serve
http://www.oracle.com Enabling The Information Age
msg45776/pgp0.pgp
Description: PGP signature
Re: [PATCH: libc]Re: gnome on current
On Thu, 31 Oct 2002, Doug Rabson wrote:
On Wed, 30 Oct 2002, Daniel Eischen wrote:
On Wed, 30 Oct 2002, Alexander Kabaev wrote:
On Wed, 30 Oct 2002 15:51:48 -0800
Terry Lambert [EMAIL PROTECTED] wrote:
NO.
If you have a library that's linked to a library containing string
symbols, then no other library gets a chance to replace to symbols
with its own strong symbols. The first strong symbol always wins,
and the search is defined to be depth-first.
You are ignoring the fact, that objects, loaded at the application startup
time are getting searched first, followed RTLD_GLOBAL objects, and finally by
the loaded object DAG. LD_PRELOAD objects override them all.
First strong/last weak should win. You are saying last weak is not
winning. That's a linker bug.
If last weak will win, the normal case when Xthrstub is loaded _after_ libc_r
will break. The only way to really fix this is to export pthread_ symbols as
strong in libc_r. Exporting them as weak sounds like is a mistake which
should be fixed.
I disagree. See Solaris 6, 7, 8 9 for an example.
Actually, I don't much care about Solaris. I care that a popular desktop
package which we have supported for earlier releases does not work. I
don't expect anyone to ever run gnome on Solaris but people certainly run
gnome on FreeBSD.
Umm, isn't GNOME going to be Solaris' window toolkit. Sun said this
months ago, upsetting some of the KDE folks.
Have you looked at how libgcc uses pthread routines? It doesn't
have a problem.
Basically, it wraps all the pthread functions which could be done
something like this:
--
Dan Eischen
%%% libxthr.h %%%
#ifndef _LIBXTHR_H_
#define _LIBXTHR_H_
#include pthread.h
int xthr_isthreaded(void);
int xthr_mutex_lock(pthread_mutex_t *);
int xthr_mutex_unlock(pthread_mutex_t *);
#endif
%%%
%%% libxthr.c %%%
#include unistd.h
#include stdlib.h
#include libxthr.h
#pragma weak pthread_create;
#pragma weak pthread_mutex_lock;
#pragma weak pthread_mutex_unlock;
static void *pthread_create_addr = (void *)pthread_create;
int
xthr_isthreaded(void)
{
return (pthread_create_addr != NULL);
}
int
xthr_mutex_lock(pthread_mutex_t *mutex);
{
if (xthr_isthreaded())
return (pthread_mutex_lock(mutex));
else
return (0);
}
int
xthr_mutex_unlock(pthread_mutex_t *mutex);
{
if (xthr_isthreaded())
return (pthread_mutex_unlock(mutex));
else
return (0);
}
%%%
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: [PATCH: libc]Re: gnome on current
On Thu, 31 Oct 2002, Doug Rabson wrote: On Thu, 31 Oct 2002, Alexander Kabaev wrote: On Wed, 30 Oct 2002 22:25:12 -0500 (EST) Daniel Eischen [EMAIL PROTECTED] wrote: If last weak will win, the normal case when Xthrstub is loaded _after_ libc_r will break. The only way to really fix this is to export pthread_ symbols as strong in libc_r. Exporting them as weak sounds like is a mistake which should be fixed. I disagree. See Solaris 6, 7, 8 9 for an example. Cool. Then let's be consistent and follow Solaris all the way. Libc on Solaris provides full set of pthread_? functions which in turn call weakly defined _pthread_?? counterparts. libpthread in turn provides strong definitions for _pthread_??. Since in absolute majority of cases libc is the first library searched for symbols, all pthread references will be bound to it and failure described by Doug will not happen. Any library providing strong pthread_ definitions will be able to override ones provided by the system. Something along these lines appears to work nicely and ought to work either with or without libXThrStub, which is now redundant since libc will be providing strong symbols that override all the weak symbols in libXThrStub. We should adjust the XFree86-4-libraries port to avoid building and using that library. Please no, you've got strong pthread_* symbols in libc. I'd rather see them as strong in libpthread (but don't really want that either). You can also play the libgcc game inside of libc for those applications or libraries that are too lazy to do it for themselves. Have the libc pthread stubs key on a weak reference to pthread_create and call the pthread_* if they are present. libXThrStub should be able to do that though. -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: libc size
On Wed, Oct 30, 2002 at 12:46:15PM -0800, Nate Lawson wrote: After a discussion on cvs-all regarding size of our libc, I wrote a quick script to see where the problems are. A cursory glance at its output shows there are numerous things we can improve, including: * setproctitle(3) uses 4k of static scratch buffers when it could allocate these on the stack (let alone reducing the length of the proc title to something more reasonable than 2k). * vfwprintf and vfprintf are near duplicates of each other (in fact, the former is derived from the latter). Each uses 14k of text so this could be split in half by combining them and selecting different behavior with a flag. They are similar enough at the C source level to be merged into a single source file (in fact, Microsoft's C library does this), but they are probably not similar enough at the machine code level to merge and save text space. I have no idea how you could merge them in C to save a significant amount of text space given that sizeof(char) != sizeof(wchar_t). Basically, if you don't want wide character printf/scanf support in libc for some kind of embedded system, remove them from stdio/Makefile.inc. Nothing in the base system uses them, and few programs in the ports collection do either. You could also replace the locale stuff with the dummy versions from 4.4BSD if you don't want it (see OpenBSD's src/lib/libc/stdlib/multibyte.c, etc.). Tim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH: libc]Re: gnome on current
On Thu, 31 Oct 2002 09:08:12 -0500 (EST) Daniel Eischen [EMAIL PROTECTED] wrote: Cool. Then let's be consistent and follow Solaris all the way. Libc on Solaris provides full set of pthread_? functions which in turn call weakly defined _pthread_?? counterparts. libpthread in turn provides strong definitions for _pthread_??. No, please see earlier messages in this thread. Dan, could you please be consistent? You cited Solaris as an example against making all the symbols in libc_r strong. I gave you an answer that the only way why this works on Solaris is because libc itself provides weak pthread_ definitions. pthread_ functions in libc simply call their _pthread counterparts, which are also weekly defined in libc. libpthread defines _pthread_ symbols as strong and consequently its symbols override one provided by libc. Saying 'NO' to strong symbols in libc_r because Solaris does not do that and then saying 'NO' again to description on how Solaris really does things - that's where I lost you. -- Alexander Kabaev To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH: libc]Re: gnome on current
* De: Juli Mallett [EMAIL PROTECTED] [ Data: 2002-10-31 ] [ Subjecte: Re: [PATCH: libc]Re: gnome on current ] * De: David O'Brien [EMAIL PROTECTED] [ Data: 2002-10-31 ] [ Subjecte: Re: [PATCH: libc]Re: gnome on current ] On Wed, Oct 30, 2002 at 06:02:38PM -0800, Juli Mallett wrote: Considering that I built the same applications and ran the same applications fine a while ago, and we've had a binutils upgrade, and things don't break on other systems, I'm inclined to assume there are linker bugs afoot, and all the other speculative stuff seems to be based on misunderstandings or bad information. Huh? Your statement is rather speculative stuff. Other systems (say Linux) are using the same linker we are. Please speculate less. Please grab an older ld and try to prove your speculation. It's deductive. And wrong, too! Finally took a simple testcase, an old libexec/elf/ld, etc., and it still goes boom. On to checking the runtime linker, I suppose. -- Juli Mallett [EMAIL PROTECTED] | FreeBSD: The Power To Serve Will break world for fulltime employment. | finger [EMAIL PROTECTED] http://people.FreeBSD.org/~jmallett/ | Support my FreeBSD hacking! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH: libc]Re: gnome on current
On Thu, 31 Oct 2002, Daniel Eischen wrote: On Thu, 31 Oct 2002, Doug Rabson wrote: On Thu, 31 Oct 2002, Alexander Kabaev wrote: On Wed, 30 Oct 2002 22:25:12 -0500 (EST) Daniel Eischen [EMAIL PROTECTED] wrote: If last weak will win, the normal case when Xthrstub is loaded _after_ libc_r will break. The only way to really fix this is to export pthread_ symbols as strong in libc_r. Exporting them as weak sounds like is a mistake which should be fixed. I disagree. See Solaris 6, 7, 8 9 for an example. Cool. Then let's be consistent and follow Solaris all the way. Libc on Solaris provides full set of pthread_? functions which in turn call weakly defined _pthread_?? counterparts. libpthread in turn provides strong definitions for _pthread_??. Since in absolute majority of cases libc is the first library searched for symbols, all pthread references will be bound to it and failure described by Doug will not happen. Any library providing strong pthread_ definitions will be able to override ones provided by the system. Something along these lines appears to work nicely and ought to work either with or without libXThrStub, which is now redundant since libc will be providing strong symbols that override all the weak symbols in libXThrStub. We should adjust the XFree86-4-libraries port to avoid building and using that library. Please no, you've got strong pthread_* symbols in libc. I'd rather see them as strong in libpthread (but don't really want that either). You can also play the libgcc game inside of libc for those applications or libraries that are too lazy to do it for themselves. Have the libc pthread stubs key on a weak reference to pthread_create and call the pthread_* if they are present. libXThrStub should be able to do that though. It almost doesn't matter which of the solutions we use as long as we do something. What we currently have is clearly wrong but I'll list it along with the others. Solutions so far proposed are: 0. (Current behaviour). Define _pthread_* weakly in libc. A pthreads implementation defines strong _pthread_* symbols and weak pthread_* aliases for them. Anyone else which defines pthread_* symbols (either weak or strong) can take over and will normally end up breaking libc. 1. Define pthread_* strongly in libc. Make these strong symbols call weak _pthread_* counterparts also defined in libc. A pthreads implementation defines strong _pthread_* symbols allowing it to 'take over' from libc. 2. Define weak _pthread_* symbols in libc and probably weak pthread_* symbols either in libc or somewhere else (libXThrStub?). A pthreads implementation defines strong _pthread_* and strong pthread_*. This is the linux solution (without the _pthread_* indirection). 3. Like (0) but rewrite X11's thread code so that every call looks something like: if (pthreads) return pthread_foo(args); else return 0; This isn't likely to be easy to get back into the XFree86 codebase and makes us gratuitously different from the rest of the world, most of which neither need nor have libXThrStub. 4. Something else, e.g. more fine-grained control over symbol resolution beyond strong/weak. Probably not worth the effort. Right now, I can't tell what Solaris does. Alexander suggested that it was (1) but you disagree. It would be interesting to see the output of 'nm | grep pthread' for both libc.so and libpthread.so. -- Doug Rabson Mail: [EMAIL PROTECTED] Phone: +44 20 8348 6160 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH: libc]Re: gnome on current
On Thu, 31 Oct 2002, Alexander Kabaev wrote: On Thu, 31 Oct 2002 09:08:12 -0500 (EST) Daniel Eischen [EMAIL PROTECTED] wrote: Cool. Then let's be consistent and follow Solaris all the way. Libc on Solaris provides full set of pthread_? functions which in turn call weakly defined _pthread_?? counterparts. libpthread in turn provides strong definitions for _pthread_??. No, please see earlier messages in this thread. Dan, could you please be consistent? You cited Solaris as an example against making all the symbols in libc_r strong. I gave you an answer that the only way why this works on Solaris is because libc itself provides weak pthread_ definitions. pthread_ functions in libc simply call their _pthread counterparts, which are also weekly defined in libc. libpthread defines _pthread_ symbols as strong and consequently its symbols override one provided by libc. No, you stated that Solaris libpthread defines pthread_ symbols strong. It doesn't. Perhaps you really meant _pthread_ symbols, which is what you say above. For the record, neither libc nor libthread or libpthread in Solaris provide strong pthread_* symbols. They (Solaris) do provide strong _pthread_* symbols in libpthread, as we do in libc_r. bash-2.05$ uname -rvs SunOS 5.8 Generic_108528-12 bash-2.05$ nm /usr/lib/libpthread.so.1 | grep pthread_mutex_lock 3c80 T _pthread_mutex_lock 3c80 W pthread_mutex_lock bash-2.05$ nm /usr/lib/libc.so.1 | grep pthread_mutex_lock 00096c38 W _pthread_mutex_lock 00096c38 W pthread_mutex_lock We also have an additional requirement in libc. Our uses of _pthread_* in libc must correspond to the [single underscore] _pthread_* in libc_r (and libpthread eventually). All references to [non underscore] pthread_* routines must correspond to the [two underscore] __pthread_* routines in libc_r. This is so our threads libraries can tell the difference between application and implementation locks. -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH: libc]Re: gnome on current
On Thu, 31 Oct 2002 05:45:43 -0800 Juli Mallett [EMAIL PROTECTED] wrote: * De: David O'Brien [EMAIL PROTECTED] [ Data: 2002-10-31 ] [ Subjecte: Re: [PATCH: libc]Re: gnome on current ] On Wed, Oct 30, 2002 at 06:02:38PM -0800, Juli Mallett wrote: Considering that I built the same applications and ran the same applications fine a while ago, and we've had a binutils upgrade, and things don't break on other systems, I'm inclined to assume there are linker bugs afoot, and all the other speculative stuff seems to be based on misunderstandings or bad information. Huh? Your statement is rather speculative stuff. Other systems (say Linux) are using the same linker we are. Please speculate less. Please grab an older ld and try to prove your speculation. It's deductive. Other systems are using similar library setups, in terms of weak vs. strong systems, Wrong. Solaris and Linux differ from FreeBSD each in its own way. Linuxprovides strong pthread definitions in libpthread Solaris provides weak pthread and _pthread definitions in Libc with libpthread providing strong _pthread and weak pthread We are the weird one it seems. -- Alexander Kabaev To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: Networking
I can't run the -CURRENT kernel of the last several days and get any networking performance at all-but this is a desktop machine with a dc. Something's seriously wrong. Michael D. Harnois 2L, University of St. Thomas School of Law Minneapolis, Minnesota -Original Message- From: [EMAIL PROTECTED] [mailto:owner-freebsd-current;FreeBSD.ORG]On Behalf Of M. Warner Losh Sent: Monday, October 28, 2002 10:07 To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: Networking In message: [EMAIL PROTECTED] Niklas Johannes Saers [EMAIL PROTECTED] writes: : Hi all, : I'm wondering a bit on the state of the network-drivers in -CURRENT. : On my laptop running a fairly recent -CURRENT whenever I do a : ifconfig an0 inet 192.168.1.2 netmask 255.255.255.0 : my laptop will freeze until I unplug the card. My fxp0 works great on the : same computer. On another box I'm running, the 3Com 509B card that worked : great with -STABLE gets pings of about 9-10 seconds to a computer it's : hooked directly against. My an0 is a Cisco Aironet 350 card. : : These are probably known problems, but since they've been ongoing for : quite a while now, I thought I'd mention it. If they are not known : problems, I'd be happy to provide additional data. Hmmm, sounds like you have interrupt problems on the laptop. I'm sending this mail with an 'an' card right now and it works w/o a hitch. I can dhclient an address, or set one manually. It does take it about a second to configure the network in either case. I've used both the 340 and the 350 cards with this laptop in recent memory. As for your 509B card, I have no clue. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH: libc]Re: gnome on current
On Thu, 31 Oct 2002, Alexander Kabaev wrote: On Thu, 31 Oct 2002 05:45:43 -0800 Juli Mallett [EMAIL PROTECTED] wrote: * De: David O'Brien [EMAIL PROTECTED] [ Data: 2002-10-31 ] [ Subjecte: Re: [PATCH: libc]Re: gnome on current ] On Wed, Oct 30, 2002 at 06:02:38PM -0800, Juli Mallett wrote: Considering that I built the same applications and ran the same applications fine a while ago, and we've had a binutils upgrade, and things don't break on other systems, I'm inclined to assume there are linker bugs afoot, and all the other speculative stuff seems to be based on misunderstandings or bad information. Huh? Your statement is rather speculative stuff. Other systems (say Linux) are using the same linker we are. Please speculate less. Please grab an older ld and try to prove your speculation. It's deductive. Other systems are using similar library setups, in terms of weak vs. strong systems, Wrong. Solaris and Linux differ from FreeBSD each in its own way. Linuxprovides strong pthread definitions in libpthread Solaris provides weak pthread and _pthread definitions in Libc with libpthread providing strong _pthread and weak pthread We are the weird one it seems. The only thing that we don't do that Solaris does, is provide weak pthread_ definitions in libc. I'm not opposed to that; I'm opposed to providing strong pthread_ definitions either in libc or libc_r. I added all the weak definitions so that we would look exactly like Solaris libpthread. This was the model I chose when I did this almost 2 years ago. We've been using it that long without any problems until now. -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH: libc]Re: gnome on current
On Thu, 31 Oct 2002, Daniel Eischen wrote: On Thu, 31 Oct 2002, Alexander Kabaev wrote: On Thu, 31 Oct 2002 09:08:12 -0500 (EST) Daniel Eischen [EMAIL PROTECTED] wrote: Cool. Then let's be consistent and follow Solaris all the way. Libc on Solaris provides full set of pthread_? functions which in turn call weakly defined _pthread_?? counterparts. libpthread in turn provides strong definitions for _pthread_??. No, please see earlier messages in this thread. Dan, could you please be consistent? You cited Solaris as an example against making all the symbols in libc_r strong. I gave you an answer that the only way why this works on Solaris is because libc itself provides weak pthread_ definitions. pthread_ functions in libc simply call their _pthread counterparts, which are also weekly defined in libc. libpthread defines _pthread_ symbols as strong and consequently its symbols override one provided by libc. No, you stated that Solaris libpthread defines pthread_ symbols strong. It doesn't. Perhaps you really meant _pthread_ symbols, which is what you say above. For the record, neither libc nor libthread or libpthread in Solaris provide strong pthread_* symbols. They (Solaris) do provide strong _pthread_* symbols in libpthread, as we do in libc_r. bash-2.05$ uname -rvs SunOS 5.8 Generic_108528-12 bash-2.05$ nm /usr/lib/libpthread.so.1 | grep pthread_mutex_lock 3c80 T _pthread_mutex_lock 3c80 W pthread_mutex_lock bash-2.05$ nm /usr/lib/libc.so.1 | grep pthread_mutex_lock 00096c38 W _pthread_mutex_lock 00096c38 W pthread_mutex_lock Now I'm really confused. I can't see how this can work properly. Imagine the following scenario: An application 'base' is linked against libc and is not threaded. This application loads a plugin 'Xplug.so' via dlopen(). Xplug doesn't use threads but it does link against libX11.so which calls pthread_mutex_* etc. to ensure thread-safety. Since libX11 doesn't want to force threading unless its needed, it just uses libc's weak versions. Finally, 'Threadplug.so' is loaded which does use threads. This object is linked with libpthread.so which is now in the list of libs, crucially *after* libc.so. After all this loading and runtime linking, the question is how does libX11 manage to call the right pthread routines? It isn't linked directly to libpthread.so and the first weak definition of pthread_foo is from libc.so. -- Doug Rabson Mail: [EMAIL PROTECTED] Phone: +44 20 8348 6160 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH: libc]Re: gnome on current
I'll respond to two messages in one. No, you stated that Solaris libpthread defines pthread_ symbols strong. It doesn't. Perhaps you really meant _pthread_ symbols, which is what you say above. No, I meant a simple fact that Solaris provides weak definition for both _pthread and pthread symbols. I assumed you have seen the pthread definition in libc since you brought that example up. I apologize if 'weak' got omitted from my message and got you confused. In another message: The only thing that we don't do that Solaris does, is provide weak pthread_ definitions in libc. I'm not opposed to that; I'm opposed to providing strong pthread_ definitions either in libc or libc_r. Then we are in complete agreement. Adding weak aliases for pthread symbols is what I mean under following Solaris all the way. We've been using it that long without any problems until now. But loading libc_r linked libraries into non-threaded processes din't work ever since libc_r got split from libc. This is a weird case which does not happen a lot in the wild anyway. -- Alexander Kabaev To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH: libc]Re: gnome on current
On Thu, 31 Oct 2002, Doug Rabson wrote: On Thu, 31 Oct 2002, Daniel Eischen wrote: You can also play the libgcc game inside of libc for those applications or libraries that are too lazy to do it for themselves. Have the libc pthread stubs key on a weak reference to pthread_create and call the pthread_* if they are present. libXThrStub should be able to do that though. It almost doesn't matter which of the solutions we use as long as we do something. What we currently have is clearly wrong but I'll list it along with the others. Solutions so far proposed are: 0. (Current behaviour). Define _pthread_* weakly in libc. A pthreads implementation defines strong _pthread_* symbols and weak pthread_* aliases for them. Anyone else which defines pthread_* symbols (either weak or strong) can take over and will normally end up breaking libc. We only use _pthread_* in libc, so it doesn't break libc unless they provide strong symbols for _pthread_*. Our implementation relies on the use of single underscore versions in libc so we can tell the difference between the implementation locks and application locks. The weak references from pthread_* in libc_r are to the double underscore versions (mostly, the locking functions) so that applications actually resolve to __pthread_mutex_lock and libc uses will resolve to _pthread_mutex_lock. 1. Define pthread_* strongly in libc. Make these strong symbols call weak _pthread_* counterparts also defined in libc. A pthreads implementation defines strong _pthread_* symbols allowing it to 'take over' from libc. 2. Define weak _pthread_* symbols in libc and probably weak pthread_* symbols either in libc or somewhere else (libXThrStub?). A pthreads implementation defines strong _pthread_* and strong pthread_*. This is the linux solution (without the _pthread_* indirection). 3. Like (0) but rewrite X11's thread code so that every call looks something like: if (pthreads) return pthread_foo(args); else return 0; This isn't likely to be easy to get back into the XFree86 codebase and makes us gratuitously different from the rest of the world, most of which neither need nor have libXThrStub. 4. Something else, e.g. more fine-grained control over symbol resolution beyond strong/weak. Probably not worth the effort. Right now, I can't tell what Solaris does. Alexander suggested that it was (1) but you disagree. It would be interesting to see the output of 'nm | grep pthread' for both libc.so and libpthread.so. I've already done that and posted it. Here it is again. bash-2.05$ uname -rvs SunOS 5.8 Generic_108528-12 bash-2.05$ nm /usr/lib/libc.so.1 | grep pthread_mutex_ 00054a08 t _libc_pthread_mutex_init 00096bc0 W _pthread_mutex_destroy 00096be8 W _pthread_mutex_getprioceiling 00096c10 W _pthread_mutex_init 00096c38 W _pthread_mutex_lock 00096c60 W _pthread_mutex_setprioceiling 00096c88 W _pthread_mutex_trylock 00096cb0 W _pthread_mutex_unlock 00096bc0 W pthread_mutex_destroy 00096be8 W pthread_mutex_getprioceiling 00096c10 W pthread_mutex_init 00096c38 W pthread_mutex_lock 00096c60 W pthread_mutex_setprioceiling 00096c88 W pthread_mutex_trylock 00096cb0 W pthread_mutex_unlock bash-2.05$ nm /usr/lib/libpthread.so.1 | grep pthread_mutex_ 3d28 T _pthread_mutex_attr_gettype 3d20 T _pthread_mutex_attr_settype 3c38 T _pthread_mutex_consistent_np 3c78 T _pthread_mutex_destroy 3ca0 T _pthread_mutex_getprioceiling 3c70 T _pthread_mutex_init 3c80 T _pthread_mutex_lock 3c98 T _pthread_mutex_setprioceiling 3c90 T _pthread_mutex_trylock 3c88 T _pthread_mutex_unlock 3d28 W pthread_mutex_attr_gettype 3d20 W pthread_mutex_attr_settype 3c38 W pthread_mutex_consistent_np 3c78 W pthread_mutex_destroy 3ca0 W pthread_mutex_getprioceiling 3c70 W pthread_mutex_init 3c80 W pthread_mutex_lock 3c98 W pthread_mutex_setprioceiling 3c90 W pthread_mutex_trylock 3c88 W pthread_mutex_unlock -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Cannot find my Linux partition
Hi, I have in my kernel config: options EXT2FS On -STABLE, and on -CURRENT from a week ago, one my SCSI drives looked like this: = /dev/da1s1 standard input: x86 boot sector /dev/da1s2 standard input: x86 boot sector, extended partition table /dev/da1s3 standard input: empty /dev/da1s4 standard input: empty /dev/da1s5 standard input: x86 boot sector /dev/da1s6 standard input: Linux rev 0.0 ext2 filesystem data /dev/da1s7 standard input: x86 boot sector = I used to be able to mount my Linux partition with: mount -r -t ext2fs /dev/da1s7 /linuxmount I just cvsup'd and rebuilt kernel/world on -CURRENT today, and now the same SCSI disk looks like: = for i in $(/bin/ls -1 /dev/da1*); do printf $i $(file - $i)\n; done /dev/da1 standard input: x86 boot sector /dev/da1s1 standard input: x86 boot sector /dev/da1s2 standard input: x86 boot sector, extended partition table /dev/da1s5 standard input: x86 boot sector = da1s7 is no longer there, and I can't figure out how to mount my Linux partition. None of the combinations of: mount -r -t ext2fs /dev/da1s[125] /linuxmount works. Any help appreciated. -- Craig Rodrigues http://www.gis.net/~craigr [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: Problems with 5.0 current release in case of multiple PCI bu
On 30-Oct-2002 Manish Lachwani wrote: Hello, pcib2: ACPI Host-PCI bridge on acpi0 pcib2: duplicate bus number 0 - not probing bus pcib4: ACPI Host-PCI bridge on acpi0 pcib4: duplicate bus number 0 - not probing bus pcib5: ACPI Host-PCI bridge on acpi0 pcib5: duplicate bus number 0 - not probing bus pcib6: ACPI Host-PCI bridge on acpi0 pcib6: duplicate bus number 0 - not probing bus Any ideas how to fix this? Please try http://www.FreeBSD.org/~jhb/patches/acpi_pci.patch -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: changes to make(1)
On Thu, Oct 31, 2002 at 06:21:25AM -0800, Juli Mallett wrote:
* De: Ruslan Ermilov [EMAIL PROTECTED] [ Data: 2002-10-31 ]
[ Subjecte: Re: changes to make(1) ]
Interesting. It seems to me we really need a 'CondIsExpressionTerminator'
or something. ')' should only be a terminator if we are inside a '('. are
both of those cases in '(' code? If so then everything else is bogus, so
I'd bet not :(
')' should either be escaped or quoted to be recognized properly here.
With or without my patch (make -r -dc):
STR=foo
.if ${STR} == foo) == lhs = foo, rhs = foo, op = == (malformed conditional)
.if ${STR} == foo\) == lhs = foo, rhs = foo), op = ==
.if ${STR} == foo)== lhs = foo, rhs = foo), op = ==
You'll get the similar results with the NUM=1 and .if ${NUM} == 1
except here:
.if ${NUM} == 1)
old version will== lhs = 1, rhs = 1, op = ==
new version will== left = 1.00, right = 1.00, op = ==
(both will fail with malformed conditional)
If we go further and back out the change in rev. 1.9, we can
even make the following code work (no surrounding spaces for ):
NUM=1
num:
.if (${NUM}==1${NUM}==1)
@echo OK.
.endif
But this will cost us the following:
.if ${NUM} 0z
@echo OK.
.endif
make(1) won't now complain about z. A small improvement gives us:
%%%
Index: cond.c
===
RCS file: /home/ncvs/src/usr.bin/make/cond.c,v
retrieving revision 1.25
diff -u -p -u -r1.25 cond.c
--- cond.c 23 Oct 2002 23:16:42 - 1.25
+++ cond.c 31 Oct 2002 15:26:16 -
@@ -688,16 +688,13 @@ do_string_compare:
}
} else {
char *c = CondCvtArg(rhs, right);
- if (*c != '\0' !isspace((unsigned char) *c))
+ if (c == rhs)
goto do_string_compare;
if (rhs == condExpr) {
/*
* Skip over the right-hand side
*/
- while(!isspace((unsigned char) *condExpr)
- (*condExpr != '\0')) {
- condExpr++;
- }
+ condExpr = c;
}
}
%%%
%%%
Index: cond.c
===
RCS file: /home/ncvs/src/usr.bin/make/cond.c,v
retrieving revision 1.25
diff -u -p -r1.25 cond.c
--- cond.c 23 Oct 2002 23:16:42 - 1.25
+++ cond.c 31 Oct 2002 13:10:13 -
@@ -688,14 +688,15 @@ do_string_compare:
}
} else {
char *c = CondCvtArg(rhs, right);
- if (*c != '\0' !isspace((unsigned char) *c))
+ if (*c != '\0' *c != ')'
+ !isspace((unsigned char) *c))
goto do_string_compare;
if (rhs == condExpr) {
/*
* Skip over the right-hand side
*/
while(!isspace((unsigned char) *condExpr)
- (*condExpr != '\0')) {
+ *condExpr != ')' *condExpr != '\0') {
condExpr++;
}
}
%%%
ports/devel/pmake is also vulnerable to this (even the latest beta),
and unless I'm dreadfully mistaken, OpenBSD's make(1) too.
Cheers,
--
Ruslan Ermilov Sysadmin and DBA,
[EMAIL PROTECTED] Sunbay Software AG,
[EMAIL PROTECTED] FreeBSD committer,
+380.652.512.251Simferopol, Ukraine
http://www.FreeBSD.org The Power To Serve
http://www.oracle.com Enabling The Information Age
msg45792/pgp0.pgp
Description: PGP signature
Re: [PATCH: libc]Re: gnome on current
On Thu, 31 Oct 2002, Daniel Eischen wrote:
On Thu, 31 Oct 2002, Doug Rabson wrote:
On Thu, 31 Oct 2002, Daniel Eischen wrote:
You can also play the libgcc game inside of libc for those applications
or libraries that are too lazy to do it for themselves. Have the
libc pthread stubs key on a weak reference to pthread_create and
call the pthread_* if they are present. libXThrStub should be
able to do that though.
It almost doesn't matter which of the solutions we use as long as we do
something. What we currently have is clearly wrong but I'll list it along
with the others. Solutions so far proposed are:
0. (Current behaviour). Define _pthread_* weakly in libc. A pthreads
implementation defines strong _pthread_* symbols and weak pthread_*
aliases for them. Anyone else which defines pthread_* symbols (either weak
or strong) can take over and will normally end up breaking libc.
We only use _pthread_* in libc, so it doesn't break libc unless
they provide strong symbols for _pthread_*. Our implementation
relies on the use of single underscore versions in libc so we
can tell the difference between the implementation locks and
application locks. The weak references from pthread_* in libc_r
are to the double underscore versions (mostly, the locking
functions) so that applications actually resolve to __pthread_mutex_lock
and libc uses will resolve to _pthread_mutex_lock.
Actually its pretty easy to break libc. Someone calls flockfile() which in
turn calls _pthread_mutex_lock(). This ends up in libc_r which notices
that the mutex is uninitialised and calls init_static(). That calls
pthread_mutex_init() and dies shortly afterwards (note the non-_pthread
call from init_static()).
Right now, I can't tell what Solaris does. Alexander suggested that it was
(1) but you disagree. It would be interesting to see the output of 'nm |
grep pthread' for both libc.so and libpthread.so.
I've already done that and posted it. Here it is again.
...
Ok then. Next attempt. This one defines weak pthread_foo stubs which call
_pthread_foo. It also defines weak _pthread_foo stubs which are noops. All
symbols weak. Everyone happy. Actually, I haven't tested this since my
test system is at home. For kicks, I also staticised the stubs.
Index: gen/_pthread_stubs.c
===
RCS file: /home/ncvs/src/lib/libc/gen/_pthread_stubs.c,v
retrieving revision 1.7
diff -u -r1.7 _pthread_stubs.c
--- gen/_pthread_stubs.c19 Sep 2002 01:09:49 - 1.7
+++ gen/_pthread_stubs.c31 Oct 2002 15:39:50 -
@@ -31,6 +31,9 @@
#include pthread.h
#include pthread_np.h
+void *_pthread_getspecific(pthread_key_t key);
+pthread_t _pthread_self(void);
+
/*
* Weak symbols: All libc internal usage of these functions should
* use the weak symbol versions (_pthread_XXX). If libpthread is
@@ -42,6 +45,7 @@
*/
__weak_reference(_pthread_cond_init_stub, _pthread_cond_init);
__weak_reference(_pthread_cond_signal_stub,_pthread_cond_signal);
+__weak_reference(_pthread_cond_broadcast_stub, _pthread_cond_broadcast);
__weak_reference(_pthread_cond_wait_stub, _pthread_cond_wait);
__weak_reference(_pthread_cond_destroy_stub, _pthread_cond_destroy);
__weak_reference(_pthread_getspecific_stub,_pthread_getspecific);
@@ -59,9 +63,10 @@
__weak_reference(_pthread_once_stub, _pthread_once);
__weak_reference(_pthread_self_stub, _pthread_self);
__weak_reference(_pthread_rwlock_init_stub,_pthread_rwlock_init);
+__weak_reference(_pthread_rwlock_destroy_stub, _pthread_rwlock_destroy);
__weak_reference(_pthread_rwlock_rdlock_stub, _pthread_rwlock_rdlock);
__weak_reference(_pthread_rwlock_tryrdlock_stub, _pthread_rwlock_tryrdlock);
-__weak_reference(_pthread_rwlock_trywrlock_stub, _pthread_rwlock_trywrloc);
+__weak_reference(_pthread_rwlock_trywrlock_stub, _pthread_rwlock_trywrlock);
__weak_reference(_pthread_rwlock_unlock_stub, _pthread_rwlock_unlock);
__weak_reference(_pthread_rwlock_wrlock_stub, _pthread_rwlock_wrlock);
__weak_reference(_pthread_setspecific_stub,_pthread_setspecific);
@@ -73,166 +78,371 @@
static struct pthread main_thread;
-int
+static int
_pthread_cond_init_stub(pthread_cond_t *cond,
const pthread_condattr_t *cond_attr)
{
return (0);
}
-int
+static int
_pthread_cond_signal_stub(pthread_cond_t *cond)
{
return (0);
}
-int
+static int
+_pthread_cond_broadcast_stub(pthread_cond_t *cond)
+{
+ return (0);
+}
+
+static int
_pthread_cond_wait_stub(pthread_cond_t *cond, pthread_mutex_t *mutex)
{
return (0);
}
-int
+static int
_pthread_cond_destroy_stub(pthread_cond_t *cond)
{
return (0);
}
-void *
+static void *
_pthread_getspecific_stub(pthread_key_t key)
{
return (NULL);
}
-int
+static int
_pthread_key_create_stub(pthread_key_t *key, void (*destructor) (void *))
{
return (0);
}
-int
Re: Cannot find my Linux partition
In message [EMAIL PROTECTED], Craig Rodrigues writes: I just cvsup'd and rebuilt kernel/world on -CURRENT today, and now the same SCSI disk looks like: = for i in $(/bin/ls -1 /dev/da1*); do printf $i $(file - $i)\n; done /dev/da1 standard input: x86 boot sector /dev/da1s1 standard input: x86 boot sector /dev/da1s2 standard input: x86 boot sector, extended partition table /dev/da1s5 standard input: x86 boot sector = Hi Craig, Can you please email me: boot -v console output (use serial console if you can) sysctl -n kern.geom.confxml Thanks in advance! -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH: libc]Re: gnome on current
On Thu, 31 Oct 2002, Doug Rabson wrote: On Thu, 31 Oct 2002, Daniel Eischen wrote: On Thu, 31 Oct 2002, Doug Rabson wrote: On Thu, 31 Oct 2002, Daniel Eischen wrote: You can also play the libgcc game inside of libc for those applications or libraries that are too lazy to do it for themselves. Have the libc pthread stubs key on a weak reference to pthread_create and call the pthread_* if they are present. libXThrStub should be able to do that though. It almost doesn't matter which of the solutions we use as long as we do something. What we currently have is clearly wrong but I'll list it along with the others. Solutions so far proposed are: 0. (Current behaviour). Define _pthread_* weakly in libc. A pthreads implementation defines strong _pthread_* symbols and weak pthread_* aliases for them. Anyone else which defines pthread_* symbols (either weak or strong) can take over and will normally end up breaking libc. We only use _pthread_* in libc, so it doesn't break libc unless they provide strong symbols for _pthread_*. Our implementation relies on the use of single underscore versions in libc so we can tell the difference between the implementation locks and application locks. The weak references from pthread_* in libc_r are to the double underscore versions (mostly, the locking functions) so that applications actually resolve to __pthread_mutex_lock and libc uses will resolve to _pthread_mutex_lock. Actually its pretty easy to break libc. Someone calls flockfile() which in turn calls _pthread_mutex_lock(). This ends up in libc_r which notices that the mutex is uninitialised and calls init_static(). That calls pthread_mutex_init() and dies shortly afterwards (note the non-_pthread call from init_static()). I don't see how that can be. _pthread_mutex_lock() in libc_r calls init_static_private(), not init_static(). Right now, I can't tell what Solaris does. Alexander suggested that it was (1) but you disagree. It would be interesting to see the output of 'nm | grep pthread' for both libc.so and libpthread.so. I've already done that and posted it. Here it is again. ... Ok then. Next attempt. This one defines weak pthread_foo stubs which call _pthread_foo. It also defines weak _pthread_foo stubs which are noops. All symbols weak. Everyone happy. Actually, I haven't tested this since my test system is at home. For kicks, I also staticised the stubs. This is better, although it has two stubs for each routine. Adding a weak definition from pthread_foo() to _pthread_foo() (note the lack of _stub) doesn't do the same thing? -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH: libc]Re: gnome on current
On Thu, 31 Oct 2002, Daniel Eischen wrote: On Thu, 31 Oct 2002, Doug Rabson wrote: On Thu, 31 Oct 2002, Daniel Eischen wrote: On Thu, 31 Oct 2002, Doug Rabson wrote: On Thu, 31 Oct 2002, Daniel Eischen wrote: You can also play the libgcc game inside of libc for those applications or libraries that are too lazy to do it for themselves. Have the libc pthread stubs key on a weak reference to pthread_create and call the pthread_* if they are present. libXThrStub should be able to do that though. It almost doesn't matter which of the solutions we use as long as we do something. What we currently have is clearly wrong but I'll list it along with the others. Solutions so far proposed are: 0. (Current behaviour). Define _pthread_* weakly in libc. A pthreads implementation defines strong _pthread_* symbols and weak pthread_* aliases for them. Anyone else which defines pthread_* symbols (either weak or strong) can take over and will normally end up breaking libc. We only use _pthread_* in libc, so it doesn't break libc unless they provide strong symbols for _pthread_*. Our implementation relies on the use of single underscore versions in libc so we can tell the difference between the implementation locks and application locks. The weak references from pthread_* in libc_r are to the double underscore versions (mostly, the locking functions) so that applications actually resolve to __pthread_mutex_lock and libc uses will resolve to _pthread_mutex_lock. Actually its pretty easy to break libc. Someone calls flockfile() which in turn calls _pthread_mutex_lock(). This ends up in libc_r which notices that the mutex is uninitialised and calls init_static(). That calls pthread_mutex_init() and dies shortly afterwards (note the non-_pthread call from init_static()). I don't see how that can be. _pthread_mutex_lock() in libc_r calls init_static_private(), not init_static(). That was it (I single stepped through this in the debugger a couple of days ago). Unfortunately init_static_private() also calls pthread_mutex_init() without the leading underscore. Right now, I can't tell what Solaris does. Alexander suggested that it was (1) but you disagree. It would be interesting to see the output of 'nm | grep pthread' for both libc.so and libpthread.so. I've already done that and posted it. Here it is again. ... Ok then. Next attempt. This one defines weak pthread_foo stubs which call _pthread_foo. It also defines weak _pthread_foo stubs which are noops. All symbols weak. Everyone happy. Actually, I haven't tested this since my test system is at home. For kicks, I also staticised the stubs. This is better, although it has two stubs for each routine. Adding a weak definition from pthread_foo() to _pthread_foo() (note the lack of _stub) doesn't do the same thing? I already tried that one this morning. The assignment happens at compile time unfortunately. What I wanted was for pthread_foo to be resolved in rtld to the best available _pthread_foo. Unforunately the resolution happens at link time and by the time we get to rtld, we just have a pthread_foo which happens to have the same value as _pthread_foo. -- Doug Rabson Mail: [EMAIL PROTECTED] Phone: +44 20 8348 6160 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Cannot find my Linux partition
On Thu, Oct 31, 2002 at 04:56:49PM +0100, Poul-Henning Kamp wrote: Can you please email me: boot -v console output (use serial console if you can) sysctl -n kern.geom.confxml Thanks in advance! I am not physically at the machine in question right now, and am leaving in a few hours for a week of vacation (out of FreeBSD range :). I am attaching the kern.geom.confxml and dmesg.boot. I will try to get the boot -v output, if I have time, otherwise it will have to wait. :( -- Craig Rodrigues http://www.gis.net/~craigr [EMAIL PROTECTED] kern.geom.confxml.gz Description: application/gunzip dmesg.boot.gz Description: application/gunzip
Question about boot(8) man page
Hi, I just read the boot(8) man page on my system. Is the FILES section still correct for -CURRENT? FILES /boot.config parameters for the boot blocks (optional) /boot/boot1 first stage bootstrap file /boot/boot2 second stage bootstrap file /boot/loader third stage bootstrap /kernel default kernel /kernel.old typical non-default kernel (optional) On my system, the default kernel is /boot/kernel/kernel and the old kernel is /boot/kernel.old/kernel . -- Craig Rodrigues http://www.gis.net/~craigr [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Cannot find my Linux partition
On Thu, Oct 31, 2002 at 04:56:49PM +0100, Poul-Henning Kamp wrote: Can you please email me: boot -v console output (use serial console if you can) sysctl -n kern.geom.confxml OK, I edited /boot/default/loader.conf, and added set boot_verbose=YES and rebooted. (I'm still not at the machine physically :). dmesg.boot has more stuff now, hopefully it helps. -- Craig Rodrigues http://www.gis.net/~craigr [EMAIL PROTECTED] dmesg.boot.2.gz Description: application/gunzip
Re: [PATCH: libc]Re: gnome on current
On Thu, 31 Oct 2002, Doug Rabson wrote: On Thu, 31 Oct 2002, Daniel Eischen wrote: On Thu, 31 Oct 2002, Doug Rabson wrote: We only use _pthread_* in libc, so it doesn't break libc unless they provide strong symbols for _pthread_*. Our implementation relies on the use of single underscore versions in libc so we can tell the difference between the implementation locks and application locks. The weak references from pthread_* in libc_r are to the double underscore versions (mostly, the locking functions) so that applications actually resolve to __pthread_mutex_lock and libc uses will resolve to _pthread_mutex_lock. Actually its pretty easy to break libc. Someone calls flockfile() which in turn calls _pthread_mutex_lock(). This ends up in libc_r which notices that the mutex is uninitialised and calls init_static(). That calls pthread_mutex_init() and dies shortly afterwards (note the non-_pthread call from init_static()). I don't see how that can be. _pthread_mutex_lock() in libc_r calls init_static_private(), not init_static(). That was it (I single stepped through this in the debugger a couple of days ago). Unfortunately init_static_private() also calls pthread_mutex_init() without the leading underscore. And because it calls the non-underscore version, this breaks something? I guess both init_static_private and init_static should both call _pthread_mutex_init. Right now, I can't tell what Solaris does. Alexander suggested that it was (1) but you disagree. It would be interesting to see the output of 'nm | grep pthread' for both libc.so and libpthread.so. I've already done that and posted it. Here it is again. ... Ok then. Next attempt. This one defines weak pthread_foo stubs which call _pthread_foo. It also defines weak _pthread_foo stubs which are noops. All symbols weak. Everyone happy. Actually, I haven't tested this since my test system is at home. For kicks, I also staticised the stubs. This is better, although it has two stubs for each routine. Adding a weak definition from pthread_foo() to _pthread_foo() (note the lack of _stub) doesn't do the same thing? I already tried that one this morning. The assignment happens at compile time unfortunately. What I wanted was for pthread_foo to be resolved in rtld to the best available _pthread_foo. Unforunately the resolution happens at link time and by the time we get to rtld, we just have a pthread_foo which happens to have the same value as _pthread_foo. I wonder how it works for Solaris (you can see both the non-underscore and single-underscore symbols resolve to the same thing)? Perhaps their stubs in libc pull the libgcc trick? -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Cannot find my Linux partition
In message [EMAIL PROTECTED], Craig Rodrigues writes:
--qDbXVdCdHGoSgWSk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
On Thu, Oct 31, 2002 at 04:56:49PM +0100, Poul-Henning Kamp wrote:
Can you please email me:
boot -v console output (use serial console if you can)
sysctl -n kern.geom.confxml
OK, I edited /boot/default/loader.conf, and added set boot_verbose=YES
and rebooted. (I'm still not at the machine physically :).
I think it did. I wasn't aware that extended partitions could have
a boot me! flag (0x80).
Please try this patch:
Index: geom_mbr.c
===
RCS file: /home/ncvs/src/sys/geom/geom_mbr.c,v
retrieving revision 1.22
diff -u -r1.22 geom_mbr.c
--- geom_mbr.c 28 Oct 2002 07:50:47 - 1.22
+++ geom_mbr.c 31 Oct 2002 17:30:44 -
@@ -159,7 +159,7 @@
};
static void
-g_mbr_print(int i __unused, struct dos_partition *dp __unused)
+g_mbr_print(int i, struct dos_partition *dp)
{
g_hexdump(dp, sizeof(dp[0]));
@@ -247,7 +247,7 @@
if (dp[i].dp_size == 0)
continue;
if (bootverbose) {
- printf(Slice %d:\n, i + 1);
+ printf(Slice %d on %s:\n, i + 1, gp-name);
g_mbr_print(i, dp + i);
}
npart++;
@@ -324,16 +324,6 @@
}
}
-static void
-g_mbrext_print(int i, struct dos_partition *dp)
-{
- g_hexdump(dp, sizeof(dp[0]));
- printf([%d] f:%02x typ:%d, i, dp-dp_flag, dp-dp_typ);
- printf( s(CHS):%d/%d/%d, dp-dp_scyl, dp-dp_shd, dp-dp_ssect);
- printf( e(CHS):%d/%d/%d, dp-dp_ecyl, dp-dp_ehd, dp-dp_esect);
- printf( s:%d l:%d\n, dp-dp_start, dp-dp_size);
-}
-
static struct g_geom *
g_mbrext_taste(struct g_class *mp, struct g_provider *pp, int insist __unused)
{
@@ -379,12 +369,13 @@
break;
for (i = 0; i NDOSPART; i++)
g_dec_dos_partition(
- buf + DOSPARTOFF + i * sizeof(struct
dos_partition),
- dp + i);
+ buf + DOSPARTOFF +
+ i * sizeof(struct dos_partition), dp + i);
g_free(buf);
- g_mbrext_print(0, dp);
- g_mbrext_print(1, dp + 1);
- if (dp[0].dp_flag == 0 dp[0].dp_size != 0) {
+ printf(Slice %d on %s:\n, slice + 5, gp-name);
+ g_mbr_print(0, dp);
+ g_mbr_print(1, dp + 1);
+ if ((dp[0].dp_flag 0x7f) == 0 dp[0].dp_size != 0) {
g_topology_lock();
pp2 = g_slice_addslice(gp, slice,
(((off_t)dp[0].dp_start) 9ULL) + off,
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: [PATCH: libc]Re: gnome on current
On Thu, 31 Oct 2002, Daniel Eischen wrote: On Thu, 31 Oct 2002, Doug Rabson wrote: On Thu, 31 Oct 2002, Daniel Eischen wrote: I don't see how that can be. _pthread_mutex_lock() in libc_r calls init_static_private(), not init_static(). That was it (I single stepped through this in the debugger a couple of days ago). Unfortunately init_static_private() also calls pthread_mutex_init() without the leading underscore. And because it calls the non-underscore version, this breaks something? I guess both init_static_private and init_static should both call _pthread_mutex_init. Yes. In my case it ended up in a noop stub defined by libXThrStub.so. Right afterwards libc_r bombed because the mutex it tried to initialise wasn't initialised. -- Doug Rabson Mail: [EMAIL PROTECTED] Phone: +44 20 8348 6160 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Objective-C threads
On Wed, Oct 30, 2002 at 09:47:02PM -0600, Loren James Rittle wrote: Use thr-objc not thr-posix. thr-objc maps to the gcc generic thread abstration layer and is better supported these days. It will also correctly disable overhead related to threading when a program is single-threaded using weak symbols. thr-posix doesn't do that... I've been trying to get it to work with weak symbols, but have not had any luck yet. I'm pretty sure I'm just missing something simple, but if you have a working config for FreeBSD I'd love to see it. The current situation doesn't seem optimal, ie. requiring -pthread for none threaded programs. There is also the issue of config.h.in, which needs to become config.h. This shouldn't be a big deal, I'm just not sure what the prefered method is (just repo copy it?). -- Chad David[EMAIL PROTECTED] www.FreeBSD.org [EMAIL PROTECTED] ISSci Inc.Calgary, Alberta Canada To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH: libc]Re: gnome on current
On Thu, 31 Oct 2002 12:20:14 -0500 (EST) Daniel Eischen [EMAIL PROTECTED] wrote: I wonder how it works for Solaris (you can see both the non-underscore and single-underscore symbols resolve to the same thing)? Perhaps their stubs in libc pull the libgcc trick? Solaris libc uses something called ti_jmp_table to locate pthread symbols. Both _pthread and pthread functions resolve to the same stub which does something like this: 1) fetch a function pointer from the ti_jmp_table 2) jump to it. By default, ti_jump_table entries contain pointers to dummy function like _return_zero if no threading library is loaded. When the threading library is loaded, ti_jump_table is populated with new pointers to functions implemented in threading library library. GDB did not allow me to track down where exactly this happens, I presume .init function in libpthread.so does that. Just FYI. -- Alexander Kabaev To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
ia64 tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /home/tinderbox/ia64/obj/home/tinderbox/ia64/src/ia64/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- Kernel build for GENERIC started on Thu Oct 31 10:05:39 PST 2002 -- === xe /home/tinderbox/ia64/src/sys/contrib/dev/acpica/hwregs.c: In function `AcpiGetSleepTypeData': /home/tinderbox/ia64/src/sys/contrib/dev/acpica/hwregs.c:242: warning: cast discards qualifiers from pointer target type /home/tinderbox/ia64/src/sys/contrib/dev/acpica/utglobal.c: In function `AcpiUtGetRegionName': /home/tinderbox/ia64/src/sys/contrib/dev/acpica/utglobal.c:489: warning: cast discards qualifiers from pointer target type /home/tinderbox/ia64/src/sys/contrib/dev/acpica/utglobal.c: In function `AcpiUtGetEventName': /home/tinderbox/ia64/src/sys/contrib/dev/acpica/utglobal.c:527: warning: cast discards qualifiers from pointer target type /home/tinderbox/ia64/src/sys/contrib/dev/acpica/utglobal.c: In function `AcpiUtGetTypeName': /home/tinderbox/ia64/src/sys/contrib/dev/acpica/utglobal.c:604: warning: cast discards qualifiers from pointer target type /home/tinderbox/ia64/src/sys/contrib/dev/acpica/utglobal.c:607: warning: cast discards qualifiers from pointer target type /home/tinderbox/ia64/src/sys/dev/acpica/acpi_powerres.c:272: warning: `acpi_pwr_deregister_consumer' defined but not used /home/tinderbox/ia64/src/sys/dev/acpica/acpi_powerres.c:210: warning: `acpi_pwr_deregister_resource' defined but not used cc1: warnings being treated as errors /home/tinderbox/ia64/src/sys/dev/amr/amr.c: In function `amr_setup_ccbmap': /home/tinderbox/ia64/src/sys/dev/amr/amr.c:1055: warning: initialization from incompatible pointer type *** Error code 1 Stop in /home/tinderbox/ia64/obj/home/tinderbox/ia64/src/sys/GENERIC. *** Error code 1 Stop in /home/tinderbox/ia64/src. *** Error code 1 Stop in /home/tinderbox/ia64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: libc size
Ollivier Robert wrote: According to Terry Lambert: The PIC overhead is likely unavoidable. I'd actually like to see the benchmark run on statically linked PIC vs. non-PIC code, so I remember that when I was working on Perl and the FreeBSD port (back in the early 5.000 days), having libperl shared was adding a fairly large overhead. make test ran in between 15% and 25% more time in the shared libperl case... I'm talking about statically linking the PIC code, to differentiate the PIC overhead from the shared library mechanism overhead. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: libc size
Ollivier Robert wrote: According to David Schultz: Memory is even less of an issue; if a thousand copies of a shell are running, their text gets shared regardless of how they are linked. IIRC not exactly. In the dynamic case, some fixups are done by the dynamic linker to link with the shared libs and that force the pages to be COW'd thus taking more VM. That's why static binaries are more efficient too. (someone who understand these issues please correct me if necessary) There are one or more pages of indirection pointers that will initially point to fixup code, so that the first time you indirect through them, they get fixed up and then indirect through to the real code, and subsequent indirects indirect to the real code, rather than the fixup code. The number of pages that end up COW'ed is pretty minimal. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
bob
To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Cannot find my Linux partition
On Thu, Oct 31, 2002 at 06:33:13PM +0100, Poul-Henning Kamp wrote: Please try this patch: Hi, I tried your patch. This is what I get now: = for i in `/bin/ls /dev/da1*`; do printf $i $(file - $i)\n; done /dev/da1 standard input: x86 boot sector /dev/da1s1 standard input: x86 boot sector /dev/da1s2 standard input: x86 boot sector, extended partition table /dev/da1s5 standard input: x86 boot sector /dev/da1s6 standard input: Linux rev 0.0 ext2 filesystem data /dev/da1s7 standard input: x86 boot sector /dev/da1s8 standard input: Linux/i386 swap file = I am also attaching the dmesg.boot file. I can now mount my Linux partition with: mount -r -t ext2fs /dev/da1s7 /linuxmount You rule, man! Now I can go on vacation. :) -- Craig Rodrigues http://www.gis.net/~craigr [EMAIL PROTECTED] dmesg.boot.3.gz Description: application/gunzip
Re: [PATCH: libc]Re: gnome on current
On Thu, 31 Oct 2002, Alexander Kabaev wrote: On Thu, 31 Oct 2002 12:20:14 -0500 (EST) Daniel Eischen [EMAIL PROTECTED] wrote: I wonder how it works for Solaris (you can see both the non-underscore and single-underscore symbols resolve to the same thing)? Perhaps their stubs in libc pull the libgcc trick? Solaris libc uses something called ti_jmp_table to locate pthread symbols. Both _pthread and pthread functions resolve to the same stub which does something like this: 1) fetch a function pointer from the ti_jmp_table 2) jump to it. By default, ti_jump_table entries contain pointers to dummy function like _return_zero if no threading library is loaded. When the threading library is loaded, ti_jump_table is populated with new pointers to functions implemented in threading library library. GDB did not allow me to track down where exactly this happens, I presume .init function in libpthread.so does that. That sounds easy enough to do. Anyone think this is a bad idea? -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Cannot find my Linux partition
On Thu, 31 Oct 2002, Craig Rodrigues wrote: On Thu, Oct 31, 2002 at 06:33:13PM +0100, Poul-Henning Kamp wrote: Please try this patch: I am also attaching the dmesg.boot file. I can now mount my Linux partition with: mount -r -t ext2fs /dev/da1s7 /linuxmount This might be a dumb question, but would the GEOM layer enable freebsd to be installed on an extended partition (with the proper mods to the bootloader??) -- Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: libc size
I agree with David Schultz that dynamically linking /bin and /sbin is playing with fire. I, too, have had ugly experiences on systems that did this: When /usr won't mount, it is not pleasant to be stuck with no tools. (Consider a network environment where /usr is NFS-mounted as an extreme example.) As for the disk space concerns, I spent a couple of hours with some of the smaller utilities. Identical functionality to the originals, still statically linked. Compare with 'ls -l /bin' on your system: * echo: 3k * sleep: 3k * sync: 3k * cat: 40k with setlocale, 12k without (cat uses setlocale for non-standard -v option) Total savings: over 150k just from these four. This is under 4.x, though; last I checked, -CURRENT still had some ugly bloat in crt. (crt requires atexit, which requires malloc, ugh. Maybe this has been fixed?) Easily-commitable details on request. As for the resolver issue, maybe there's another way to separate the resolver? For example, a simple command-line resolver utility (something like a stripped-down 'dig') could be invoked. That would leave one utility with the resolver libs statically-linked, and remove it from many other places. There's an obvious performance hit, but resolving is a fairly high-overhead operation in any case. Alternatively, some sort of simple resolver daemon could be implemented. The BIND folks are already moving in this direction because of IP6 resolver bloat, I understand. Either approach would shed resolver bloat from a lot of places without the headaches of dynamic linking. Tim Kientzle To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: libc size
On Thu, 31 Oct 2002, Tim Kientzle wrote: I agree with David Schultz that dynamically linking /bin and /sbin is playing with fire. I, too, have had ugly experiences on systems that did this: When /usr won't mount, it is not pleasant to be stuck with no tools. (Consider a network environment where /usr is NFS-mounted as an extreme example.) And of course the answer to that is to create a /lib. Something that I would *never ever* want to see. Sure, a few people might throw around the idea of an extremely light-weight set of libraries to go into /lib blah blah. But I just don't like the idea. Why not create a minimalist C library, build with -nostdlib and staticly link against exactly what you need. I usually create a 128 or 64mb root, and the only time this gets tight is when I keep too many kernels around in /boot. I seem to recall other arguments being settled by the disk space is extremely cheap issue. Call me crazy, but FreeBSD just has this zen feeling to it, and making this kind of change doesnt feel very zennish. I'm sure there are greater minds than mine working over this issue, but thats my $0.02. -- Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH: libc]Re: gnome on current
On Thu, 31 Oct 2002, Daniel Eischen wrote:
This is better, although it has two stubs for each routine. Adding
a weak definition from pthread_foo() to _pthread_foo() (note the
lack of _stub) doesn't do the same thing?
Ok, this version works and seems to be a reasonably tidy solution, at
least until/if the jump-table version a-la solaris is available. I
tweaked it slightly to move all the __weak_reference() calls together. Can
I commit this?
Index: gen/_pthread_stubs.c
===
RCS file: /home/ncvs/src/lib/libc/gen/_pthread_stubs.c,v
retrieving revision 1.7
diff -u -r1.7 _pthread_stubs.c
--- gen/_pthread_stubs.c19 Sep 2002 01:09:49 - 1.7
+++ gen/_pthread_stubs.c31 Oct 2002 19:30:24 -
@@ -31,6 +31,9 @@
#include pthread.h
#include pthread_np.h
+void *_pthread_getspecific(pthread_key_t key);
+pthread_t _pthread_self(void);
+
/*
* Weak symbols: All libc internal usage of these functions should
* use the weak symbol versions (_pthread_XXX). If libpthread is
@@ -42,6 +45,7 @@
*/
__weak_reference(_pthread_cond_init_stub, _pthread_cond_init);
__weak_reference(_pthread_cond_signal_stub,_pthread_cond_signal);
+__weak_reference(_pthread_cond_broadcast_stub, _pthread_cond_broadcast);
__weak_reference(_pthread_cond_wait_stub, _pthread_cond_wait);
__weak_reference(_pthread_cond_destroy_stub, _pthread_cond_destroy);
__weak_reference(_pthread_getspecific_stub,_pthread_getspecific);
@@ -59,180 +63,386 @@
__weak_reference(_pthread_once_stub, _pthread_once);
__weak_reference(_pthread_self_stub, _pthread_self);
__weak_reference(_pthread_rwlock_init_stub,_pthread_rwlock_init);
+__weak_reference(_pthread_rwlock_destroy_stub, _pthread_rwlock_destroy);
__weak_reference(_pthread_rwlock_rdlock_stub, _pthread_rwlock_rdlock);
__weak_reference(_pthread_rwlock_tryrdlock_stub, _pthread_rwlock_tryrdlock);
-__weak_reference(_pthread_rwlock_trywrlock_stub, _pthread_rwlock_trywrloc);
+__weak_reference(_pthread_rwlock_trywrlock_stub, _pthread_rwlock_trywrlock);
__weak_reference(_pthread_rwlock_unlock_stub, _pthread_rwlock_unlock);
__weak_reference(_pthread_rwlock_wrlock_stub, _pthread_rwlock_wrlock);
__weak_reference(_pthread_setspecific_stub,_pthread_setspecific);
__weak_reference(_pthread_sigmask_stub,_pthread_sigmask);
+__weak_reference(pthread_cond_init_stub, pthread_cond_init);
+__weak_reference(pthread_cond_signal_stub, pthread_cond_signal);
+__weak_reference(pthread_cond_broadcast_stub, pthread_cond_broadcast);
+__weak_reference(pthread_cond_wait_stub, pthread_cond_wait);
+__weak_reference(pthread_cond_destroy_stub,pthread_cond_destroy);
+__weak_reference(pthread_getspecific_stub, pthread_getspecific);
+__weak_reference(pthread_key_create_stub, pthread_key_create);
+__weak_reference(pthread_key_delete_stub, pthread_key_delete);
+__weak_reference(pthread_main_np_stub, pthread_main_np);
+__weak_reference(pthread_mutex_destroy_stub, pthread_mutex_destroy);
+__weak_reference(pthread_mutex_init_stub, pthread_mutex_init);
+__weak_reference(pthread_mutex_lock_stub, pthread_mutex_lock);
+__weak_reference(pthread_mutex_trylock_stub, pthread_mutex_trylock);
+__weak_reference(pthread_mutex_unlock_stub,pthread_mutex_unlock);
+__weak_reference(pthread_mutexattr_init_stub, pthread_mutexattr_init);
+__weak_reference(pthread_mutexattr_destroy_stub, pthread_mutexattr_destroy);
+__weak_reference(pthread_mutexattr_settype_stub, pthread_mutexattr_settype);
+__weak_reference(pthread_once_stub,pthread_once);
+__weak_reference(pthread_self_stub,pthread_self);
+__weak_reference(pthread_rwlock_init_stub, pthread_rwlock_init);
+__weak_reference(pthread_rwlock_destroy_stub, pthread_rwlock_destroy);
+__weak_reference(pthread_rwlock_rdlock_stub, pthread_rwlock_rdlock);
+__weak_reference(pthread_rwlock_tryrdlock_stub, pthread_rwlock_tryrdlock);
+__weak_reference(pthread_rwlock_trywrlock_stub, pthread_rwlock_trywrlock);
+__weak_reference(pthread_rwlock_unlock_stub, pthread_rwlock_unlock);
+__weak_reference(pthread_rwlock_wrlock_stub, pthread_rwlock_wrlock);
+__weak_reference(pthread_setspecific_stub, pthread_setspecific);
+__weak_reference(pthread_sigmask_stub, pthread_sigmask);
+
/* Define a null pthread structure just to satisfy _pthread_self. */
struct pthread {
};
static struct pthread main_thread;
-int
+static int
_pthread_cond_init_stub(pthread_cond_t *cond,
const pthread_condattr_t *cond_attr)
{
return (0);
}
-int
+static int
_pthread_cond_signal_stub(pthread_cond_t *cond)
{
return (0);
}
-int
+static int
+_pthread_cond_broadcast_stub(pthread_cond_t *cond)
+{
+ return (0);
+}
+
+static int
_pthread_cond_wait_stub(pthread_cond_t *cond, pthread_mutex_t *mutex)
{
return (0);
}
-int
+static int
Re: [PATCH: libc]Re: gnome on current
On Thu, 31 Oct 2002, Doug Rabson wrote: On Thu, 31 Oct 2002, Daniel Eischen wrote: This is better, although it has two stubs for each routine. Adding a weak definition from pthread_foo() to _pthread_foo() (note the lack of _stub) doesn't do the same thing? Ok, this version works and seems to be a reasonably tidy solution, at least until/if the jump-table version a-la solaris is available. I tweaked it slightly to move all the __weak_reference() calls together. Can I commit this? Yes, it looks OK. I started a slightly different version that automatically added both references with one macro. Something like: #define WEAK_REF(sym, alias)__weak_reference(sym, alias) #define DUAL_WEAK_STUB(sym) \ WEAK_REF(__CONCAT(sym, _stub), __CONCAT(_, sym)); \ WEAK_REF(__CONCAT(sym, _stub), sym) DUAL_WEAK_STUB(pthread_mutex_lock); ... or something like that. Go ahead and commit yours if you don't care to fiddle any more with it. I won't be able to get to the jump table thing for a few days. -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: libc size
On Thu, 31 Oct 2002 14:19:39 -0500 (EST)
Wesley Morgan [EMAIL PROTECTED] wrote:
Hi,
And of course the answer to that is to create a /lib. Something that
I would *never ever* want to see. Sure, a few people might throw
around the
^^
Why? I'd love to hear some real reasons for this. NetBSD-current has
just gone fully dynamic, let's see how much space that needs...
christine: {16} uname -srnm
NetBSD christine.energyhq.tk 1.6J i386
christine: {17} du -h /bin /sbin /lib
999K/bin
1.7M/sbin
2.0M/lib
/lib keeps the required shared libs for those programs residing in
/[s]bin.
IMHO it would be beneficial to, at least, have the option to build a
fully dynamic system on FreeBSD.
NetBSD now defaults to fully dynamic, but you can set a knob in
/etc/mk.conf to get the old behaviour, how about something like that?
Cheers,
--
Miguel Mendez - [EMAIL PROTECTED]
GPG Public Key :: http://energyhq.homeip.net/files/pubkey.txt
EnergyHQ :: http://www.energyhq.tk
NetBSD :: Unix without hype
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Boot-time hang after init, still (VAIO R505ES again)
CVSUP as of last night about 10PM PST: Well, phk's stuff now appears to work right (even finds the memory stick most of the time) and the bad malloc in acpi is fixed. This seems to leave irq issues (still!!) PSM0 still can't allocate irq even though 12 isn't used anywhere else. on the init hang, 3 processes are normally in RUNQ (one more on this boot, but I've never seen this before); irq9, pagezero (I presume this is the idle loop so should be in run) and init. If I can get some pointers on what further to do with kdb, I'd be glad to do so. It somehow looks like irq9 process is never finishing; with 4 or 5 devices hung off one irq does the dispatch software work right? (and why do irq 10 and 11 not get used?; I thought routed interrupts weren't stuck with the 16-irq 2x8259 limitation either (I know apic ones aren't).) -- Pete SMAP type=01 base= len= 0009e000 SMAP type=02 base= 0009e000 len= 2000 SMAP type=02 base= 000d8000 len= 8000 SMAP type=02 base= 000e4000 len= 0001c000 SMAP type=01 base= 0010 len= 1fbf SMAP type=03 base= 1fcf len= c000 SMAP type=04 base= 1fcfc000 len= 4000 SMAP type=01 base= 1fd0 len= 0018 SMAP type=02 base= 1fe8 len= 0010 SMAP type=02 base= 1ff8 len= 0008 SMAP type=02 base= ff80 len= 0040 SMAP type=02 base= fc00 len= 0400 Copyright (c) 1992-2002 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #19: Thu Oct 31 08:08:53 PST 2002 [EMAIL PROTECTED]:/d/obj-s/current/usr/src/sys/PORT2 Preloaded elf kernel /boot/kernel/kernel at 0xc04e7000. Preloaded elf module /boot/kernel/firewire.ko at 0xc04e70a8. Preloaded elf module /boot/kernel/acpi.ko at 0xc04e7158. Calibrating clock(s) ... TSC clock: 795410300 Hz, i8254 clock: 1193194 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter i8254 frequency 1193182 Hz CLK_USE_TSC_CALIBRATION not specified - using old calibration method Timecounter TSC frequency 795407830 Hz CPU: Pentium III/Pentium III Xeon/Celeron (795.41-MHz 686-class CPU) Origin = GenuineIntel Id = 0x6b1 Stepping = 1 Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE real memory = 535298048 (522752K bytes) Physical memory chunk(s): 0x1000 - 0x0009dfff, 643072 bytes (157 pages) 0x0050e000 - 0x1fce, 528359424 bytes (128994 pages) 0x1fd0 - 0x1fe77fff, 1540096 bytes (376 pages) avail memory = 513654784 (501616K bytes) bios32: Found BIOS32 Service Directory header at 0xc00f6ba0 bios32: Entry = 0xfd871 (c00fd871) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xfd870+0x13a pnpbios: Found PnP BIOS data at 0xc00f6bd0 pnpbios: Entry = f:880c Rev = 1.0 Other BIOS signatures found: Initializing GEOMetry subsystem null: null device, zero device mem: memory I/O Pentium Pro MTRR support enabled random: entropy source npx0: math processor on motherboard npx0: INT 16 interface acpi0: SONY C1 on motherboard pci_open(1):mode 1 addr port (0x0cf8) is 0x8000f904 pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=35758086) Using $PIR table, 9 entries at 0xc00fdf30 PCI-Only Interrupts: none Location Bus Device Pin Link IRQs embedded25A 0x69 3 embedded28A 0x68 9 embedded0 29A 0x60 9 embedded0 29B 0x63 9 embedded02A 0x60 9 embedded01A 0x60 9 ACPI timer looks GOOD min = 2, max = 3, width = 2 ACPI timer looks GOOD min = 2, max = 3, width = 2 ACPI timer looks GOOD min = 2, max = 3, width = 2 ACPI timer looks GOOD min = 2, max = 3, width = 2 ACPI timer looks GOOD min = 2, max = 3, width = 2 ACPI timer looks GOOD min = 2, max = 3, width = 2 ACPI timer looks GOOD min = 2, max = 3, width = 2 ACPI timer looks GOOD min = 2, max = 3, width = 2 ACPI timer looks GOOD min = 2, max = 3, width = 2 ACPI timer looks GOOD min = 2, max = 3, width = 2 Timecounter ACPI-fast frequency 3579545 Hz acpi_timer0: 24-bit timer at 3.579545MHz port 0x1008-0x100b on acpi0 acpi_cpu0: CPU on acpi0 acpi_tz0: thermal zone on acpi0 acpi_lid0: Control Method Lid Switch on acpi0 acpi_button0: Power Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 initial configuration \_SB_.LNKA irq 9: [ 9] low,level,sharable 0.1.0 \_SB_.LNKD irq 9: [ 9] low,level,sharable 0.1.3 \_SB_.LNKA irq 9: [ 9] low,level,sharable 0.2.0 \_SB_.LNKA irq 9: [ 9] low,level,sharable 0.29.0 \_SB_.LNKD irq 9: [ 9] low,level,sharable 0.29.1 before setting priority
Re: [PATCH] NEWCARD: pccardc power support
Hi, In message: [EMAIL PROTECTED] Mitsuru IWASAKI [EMAIL PROTECTED] writes: : I've implemented pccardc power and boot_deactivated support code for : NEWCARD. They are needed for some mobile users including me. : : - Add pccardc power support code. Yes, it's OLDCARD compatible. : - Add new loader tunable hw.cbb.boot_deactivated to prevent pccards :from attaching automatically. [snip] So this is a good hack, and likely useful to a lot of people. However, I'd like to see a more thoughtful design of a good device control interface. I think that it dovetails nicely with the work I'm doing for devd. Yes, my understanding of the goal of devd is that. Also I understand that NEWCARD users will be eager for suggested features until devd development is completed. So I'll leave the patches for such a people for a while at: http://people.freebsd.org/~iwasaki/pccard/cbb-pccardc-power-support-20021029.diff BTW, I think that some developers are interested in devd. Do we have mailing list for it? Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH] NEWCARD: pccardc power support
In message: [EMAIL PROTECTED] Mitsuru IWASAKI [EMAIL PROTECTED] writes: : BTW, I think that some developers are interested in devd. : Do we have mailing list for it? Not currently. I can create one if people are interested. I've also been thinking of a good way we can have the above power support in current until we can make it generic. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: Problems with 5.0 current release in case of multiple PCI bu
It did work and detected the devices on startup. However, in case of the Force 4203 board which has onboard BCM5704 NICs, the kernel hung after detecting the second NIC. I will try to get the logs but I will have to get a serial console connectivity. Any ideas ? Thanks manish -Original Message- From: John Baldwin [mailto:jhb;FreeBSD.org] Sent: Thursday, October 31, 2002 7:41 AM To: Manish Lachwani Cc: [EMAIL PROTECTED] Subject: RE: Problems with 5.0 current release in case of multiple PCI bu On 30-Oct-2002 Manish Lachwani wrote: Hello, pcib2: ACPI Host-PCI bridge on acpi0 pcib2: duplicate bus number 0 - not probing bus pcib4: ACPI Host-PCI bridge on acpi0 pcib4: duplicate bus number 0 - not probing bus pcib5: ACPI Host-PCI bridge on acpi0 pcib5: duplicate bus number 0 - not probing bus pcib6: ACPI Host-PCI bridge on acpi0 pcib6: duplicate bus number 0 - not probing bus Any ideas how to fix this? Please try http://www.FreeBSD.org/~jhb/patches/acpi_pci.patch -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Lack of real long double support
In article [EMAIL PROTECTED], Bruce Evans[EMAIL PROTECTED] writes: Example of how fixing this breaks a similar assertion for DBL_ESPILON: %%% $ cat z.c [...] $ cc -o z z.c $ ./z LDBL_EPSILON failed test 1 with prec 2 $ cc -O -o z z.c. $ ./z LDBL_EPSILON failed test 1 with prec 2 DBL_EPSILON failed test 2 with prec 3 %%% The full brokenness only shows up with -O. When I run your program against gcc mainline (for 3.3 release) with the patch I have staged from RTH to correctly match our FP hardware default setup, I see: S rittle@latour; /usr/local/beta-gcc/bin/gcc t.c S rittle@latour; a.out LDBL_EPSILON failed test 2 with prec 3 S rittle@latour; /usr/local/beta-gcc/bin/gcc -O t.c S rittle@latour; a.out LDBL_EPSILON failed test 2 with prec 3 DBL_EPSILON failed test 2 with prec 3 S rittle@latour; /usr/local/beta-gcc/bin/gcc -O2 t.c S rittle@latour; a.out LDBL_EPSILON failed test 2 with prec 3 DBL_EPSILON failed test 2 with prec 3 S rittle@latour; /usr/local/beta-gcc/bin/gcc -O3 t.c S rittle@latour; a.out LDBL_EPSILON failed test 2 with prec 3 DBL_EPSILON failed test 2 with prec 3 I.e. the only time it fails is when the user made a call to change the default precision. Is that gcc 3.3 behavior acceptable (at least until gcc can be further refined to attempt to handle user override of the FP control word)? Regards, Loren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH: libc]Re: gnome on current
Doug Rabson wrote: On Thu, 31 Oct 2002, Daniel Eischen wrote: It almost doesn't matter which of the solutions we use as long as we do something. What we currently have is clearly wrong but I'll list it along with the others. Solutions so far proposed are: [ ... ] 2. Define weak _pthread_* symbols in libc and probably weak pthread_* symbols either in libc or somewhere else (libXThrStub?). A pthreads implementation defines strong _pthread_* and strong pthread_*. This is the linux solution (without the _pthread_* indirection). Actually, Alexander was suggesting: 2. Define weak _pthread_* symbols in libc and weak pthread_* symbols in libc. A pthreads implementation defines strong _pthread_* and **does not define** pthread_*. This is the Solaris solution. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH: libc]Re: gnome on current
Alexander Kabaev wrote: Wrong. Solaris and Linux differ from FreeBSD each in its own way. Linuxprovides strong pthread definitions in libpthread Solaris provides weak pthread and _pthread definitions in Libc with libpthread providing strong _pthread and weak pthread We are the weird one it seems. Exactly. My only question is the necessity of the weak pthread in libpthread (our libc_r). It seems to not be needed, but is harmless (IMO). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Lack of real long double support
Bruce Evans wrote: Please forget this wrong example :-). The precision doesn't affect the exponent range. Done. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Lack of real long double support
M. Warner Losh wrote: : I await an explanation of how you can fit 2*DBL_MAX into a double, : which has a range of DBL_MIN..DBL_MAX. Look at the code. long double a = DBL_MAX; long double b = DBL_MAX * 2; The original posting said that b would be +Inf at this point, which is not correct. I think that Bruce was confused there. The more correct example to look at was the one that rittle@ posted which was 1 + LDBL_EPSILON. I guess I must not be understanding. What will b be, at this point, then? How can it have a value larger than DBL_MAX that's not +Inf? If it's possible to represent a value larger than DBL_MAX in a double, then the value of DBL_MAX is wrong, right? Maximum means maximum, doesn't it? : I think that a number that's a 64 bit mantissa reaised to an exponent : N takes a larger N if you have only 53 bits of mantissa, if you want : to represent the same value. Nope. The only difference between 53 bits and 64 bits of precision is just that: precision. The number of bits for expoentent is independent of this. .125 ^ 2 = 0.015625 .25 ^ 3 = 0.015625 So if I go from 3 digits of precision to 2 digits of precision for my mantissa, in order to represent the same number, I need a larger exponent. This is true. Granting, for the moment, that fpgetprec() == FP_PE isn't a standards conforming expression. But I think that the rest of this is going off into the weeds. I'm just trying to get things working in a sane way for long doubles. It looks like gcc 3.2 really wants the fpu to start off in FP_PE. There has to be an agreement between the host OS and the compiler; that's what makes C99 more complicated than it needed to be. Before I go forward on this further, I've got a lot of testing to do with kernels and such to find out what really works and what does (and doesn't) break paranoia.c. That's one test. Another is: http://www.glenmccl.com/c9suite.htm Unfortunately, it's $8495 for everything. 8-(. There's also the stuff I wrote, which doesn't test range/domain overflows, etc., but at least complains when things are not defined or prototypes are out of scope (i.e. it mostly just complains about header file contents). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH: libc]Re: gnome on current
Daniel Eischen wrote: We also have an additional requirement in libc. Our uses of _pthread_* in libc must correspond to the [single underscore] _pthread_* in libc_r (and libpthread eventually). All references to [non underscore] pthread_* routines must correspond to the [two underscore] __pthread_* routines in libc_r. This is so our threads libraries can tell the difference between application and implementation locks. I understand the distinction being drawn there, but the X11 lib XThrStub.so is really an attempt to erase it. It doesn't make a lot of sense to make such a distinction, if you're just going to have to do a lot of work to cover it up again. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH: libc]Re: gnome on current
Doug Rabson wrote: Now I'm really confused. I can't see how this can work properly. Imagine the following scenario: An application 'base' is linked against libc and is not threaded. This application loads a plugin 'Xplug.so' via dlopen(). Xplug doesn't use threads but it does link against libX11.so which calls pthread_mutex_* etc. to ensure thread-safety. Since libX11 doesn't want to force threading unless its needed, it just uses libc's weak versions. Finally, 'Threadplug.so' is loaded which does use threads. This object is linked with libpthread.so which is now in the list of libs, crucially *after* libc.so. After all this loading and runtime linking, the question is how does libX11 manage to call the right pthread routines? It isn't linked directly to libpthread.so and the first weak definition of pthread_foo is from libc.so. It's ugly, but... The answer is that it's expected to do one of two things: o The framework supports loading of threaded modules, and therefore the framework itself is limked against libc_r, which means that libX11 is linked against libc_r, and get the pthreads complete mutex/cond/etc. code. o The framework doesn't support loading of threaded modules, in which case a threaded module is either expected to: o Serialize calls to X11 functions through a single worker thread, OR o dlopen libX11 after dlopen of libc_r, and then use threads through its own stub references, OR o Be linked against libc_r and libX11 (in that order) so that it gets a different instance of the library in question; the reentrancy issue only applies to the threads against a given library instance -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH: libc]Re: gnome on current
Alexander Kabaev wrote: By default, ti_jump_table entries contain pointers to dummy function like _return_zero if no threading library is loaded. When the threading library is loaded, ti_jump_table is populated with new pointers to functions implemented in threading library library. GDB did not allow me to track down where exactly this happens, I presume .init function in libpthread.so does that. Using .init for this isn't strictly possible. Only one .init is invoked by the crt0, so if you replace it, you displace the code that would normally call the static constructors. You can't use a static constructor, because you don't get the environment block as a parameter to each constructor in the linker set traversed by the default .init. I ran into this same problem when creating a libdlopen; the other issue in the area is that even if you fix the parameter to be void * instead of void (with a coincidental value of the value of the address of the environment block), you don't necessarily get the correct order. The only way you can really deal with this is to either have a secondary linker set, or to have a priority parameter, and convert the thing to structure pointers instead of function pointers, and then bubble sort on priority (kind of like what I did in the SYSINIT() code). The same thing goes for a library that creates its own worker thread, and then serializes requests in a queue to wrap a non-reentrant library with a thread-safe wrapper (e.g. the Netscape LDAP client library). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: libc size
Wesley Morgan [EMAIL PROTECTED] wrote:
... create a /lib ... that I would *never ever* want to see.
Miguel Mendez wrote:
Why? I'd love to hear some real reasons for this.
I can think of three concerns:
1) Fragility. Could a naive sysadmin (or a dying
disk) break /[s]bin?
What if the ldconfig hints files were hosed?
Is ld-elf.so truly bulletproof?
2) Security. Can LD_LIBRARY_PATH (or other mechanisms)
be used to deliberately subvert any of these programs?
(especially the handful of suid/sgid programs here)
3) Upgrade breakage. Will this make upgrades more fragile?
A broken or incomplete upgrade could damage ld-elf.so
or introduce version skew between /bin and libc.so.
(Yes, people do rebuild libc without rebuilding world.)
I am certain these concerns could be addressed,
and a dynamic /bin could be made workable, but
it would require a lot of care.
christine: {16} uname -srnm
NetBSD christine.energyhq.tk 1.6J i386
christine: {17} du -h /bin /sbin /lib
999K/bin
1.7M/sbin
2.0M/lib
That's impressive; FreeBSD's /bin is over 7M by
itself right now. I would be curious to see
the results from ls -l /bin on your NetBSD system
as well.
... a knob in /etc/mk.conf to get the old behaviour,
how about something like that?
Knobs are dangerous because you have to test
all of the settings.
Tim Kientzle
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
newfs chokes, cores, dies if inode density too high; patch attached
For various reasons (most of which are likely historical), I tend
to mount /tmp as a swap-backed memory file system (and allocate
quite a bit of space to swap). Thus, in -STABLE, I use an mfs; in
-CURRENT, I use a little shell script (cribbed almost verbatim from
man mdconfig).
Some months back, my (daily) make buildworld failed, and I
determined that the reason was that I had exhausted the inode supply
in /tmp.
OK; I figured I could address that by overriding some defaults when
I did the newfs, such as specifying -i to provide a density override.
(The only flag I had been using on newfs was -U, so soft updates would
be enabled.)
Now, I had made the file system 512 MB in size, and (as noted above)
left defaults in for everything else. Given that, the effective value
that was being used for density was 8192. (Unit of measure here is
number of bytes per inode, so a smaller density yields more inodes.)
So I dropped the density to 2048, and things were generally OK (in this
respect, anyway) until about a month or so ago. Then newfs started
dumping core. (Since I had enough space on the root file system, this
just prevented the swap-backed /tmp from being mounted.)
Today, I finally decided to find out what was causing this.
Turns out that the newfs mainline calls mkfs() (which is in mkfs.c --
all of the referenced source files are in src/sbin/newfs). And it was
mkfs() that was choking; in particular, on line 308 of
$FreeBSD: src/sbin/newfs/mkfs.c,v 1.63 2002/10/18 23:17:30 mckusick Exp $;
sblock.fs_ipg = roundup(howmany(sblock.fs_fpg, fragsperinode),
INOPB(sblock));
howmany() is actually a macro (from sys/param.h -- as is roundup()),
and it divides by fragsperinode, which (if density is 4096) is set to 0
at line 299:
fragsperinode = numfrags(sblock, density);
OK; I recall that dividing by 0 is Generally Bad. On the other hand,
this seemed to be a less-than-graceful way to deal with the issue. But
I wasn't willing (at this time) to try figuring out just what the Right
Thing To Do would be, and settled on:
Index: mkfs.c
===
RCS file: /cvs/freebsd/src/sbin/newfs/mkfs.c,v
retrieving revision 1.63
diff -u -r1.63 mkfs.c
--- mkfs.c 18 Oct 2002 23:17:30 - 1.63
+++ mkfs.c 31 Oct 2002 21:22:41 -
@@ -297,6 +297,8 @@
origdensity = density;
for (;;) {
fragsperinode = numfrags(sblock, density);
+ if (fragsperinode 1)
+ fragsperinode = 1;
minfpg = fragsperinode * INOPB(sblock);
if (minfpg sblock.fs_size)
minfpg = sblock.fs_size;
So this is pretty much a Gross Hack; its sole redeeming virtue is
that it prevents newfs from dying under these conditions. Indeed,
it causes it to (silently) behave as if -i 4096 had been specified:
freebeast(5.0-C)[32] sudo /usr/obj/usr/src/sbin/newfs/newfs -U -i 2048 /dev/md10
/dev/md10: 512.0MB (1048576 sectors) block size 16384, fragment size 4096
using 4 cylinder groups of 128.02MB, 8193 blks, 32896 inodes.
with soft updates
super-block backups (for fsck -b #) at:
32, 262208, 524384, 786560
freebeast(5.0-C)[33] sudo df -i !$
sudo df -i /dev/md10
Filesystem 1K-blocks UsedAvail Capacity iused ifree %iused Mounted on
/dev/md10 5076924 467076 0% 1 1315810%
freebeast(5.0-C)[34] sudo /usr/obj/usr/src/sbin/newfs/newfs -U -i 4096 /dev/md10
/dev/md10: 512.0MB (1048576 sectors) block size 16384, fragment size 4096
using 4 cylinder groups of 128.02MB, 8193 blks, 32896 inodes.
with soft updates
super-block backups (for fsck -b #) at:
32, 262208, 524384, 786560
freebeast(5.0-C)[35] sudo df -i /dev/md10
Filesystem 1K-blocks UsedAvail Capacity iused ifree %iused Mounted on
/dev/md10 5076924 467076 0% 1 1315810%
freebeast(5.0-C)[36]
So I won't claim that the patch is in any sense optimal, but it seems
to me that it's somewhat of an improvement. Other alternatives exist,
of course (such as whining about the unusable density value, then
either refusing to run, while suggesting the minimal value that is sane).
Feedback welcome,
david
--
David H. Wolfskill [EMAIL PROTECTED]
To paraphrase David Hilbert, there can be no conflicts between the
discipline of systems administration and Microsoft, since they have
nothing in common.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Lack of real long double support
On Thu, Oct 31, 2002 at 03:18:47PM -0700, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Terry Lambert [EMAIL PROTECTED] writes: : Nope. The only difference between 53 bits and 64 bits of precision is : just that: precision. The number of bits for expoentent is : independent of this. : : .125 ^ 2 = 0.015625 : .25 ^ 3 = 0.015625 : : So if I go from 3 digits of precision to 2 digits of precision for : my mantissa, in order to represent the same number, I need a larger : exponent. That's not how it works. The exponent is more like .125 * 2^3 vs .124 * 2^3 Both have exponent 3, but the differ by a bit or two in the mantissa. Loren already posted a pointer to What Every Scientist Should Know About Floating-Point Arithmetic by David Goldberg. But, for Terry edification http://cch.loria.fr/documentation/IEEE754/ACM/goldberg.pdf This is only 1 of 66100 hits from a google search with keywords floating point scientist. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Objective-C threads
In article [EMAIL PROTECTED], Chad David[EMAIL PROTECTED] writes: Use thr-objc not thr-posix. thr-objc maps to the gcc generic thread abstration layer and is better supported these days. It will also correctly disable overhead related to threading when a program is single-threaded using weak symbols. thr-posix doesn't do that... I've been trying to get it to work with weak symbols, but have not had any luck yet. I'm pretty sure I'm just missing something simple, but if you have a working config for FreeBSD I'd love to see it. (I could tar up a built copy if you want to look at a stable configuration, but it is based on FSF configure not FreeBSD /usr/src Makefiles; however it should be easy for you to get to that point yourself.) The current situation doesn't seem optimal, ie. requiring -pthread for none threaded programs. There is also the issue of config.h.in, which needs to become config.h. This shouldn't be a big deal, I'm just not sure what the prefered method is (just repo copy it?). Sorry, I don't use/support ObjC at all, however gcc 3.2 doesn't require -pthread to link a single-threaded program when built using the FSF configure-generated Makefiles which build against thr-objc (gcc 3.[01].X should have all been similar). To wit: nm /usr/local/lib/libobjc.a|grep pthread w pthread_attr_destroy [...] w pthread_setspecific My only advise might be: A lot of configuration stuff regarding libobjc has subtly changed in the FSF tree, perhaps you should attempt to build a copy using the standard FSF configure technique then resync the master FreeBSD Makefiles for that package. Regards, Loren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
alpha tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /home/des/tinderbox/alpha/obj/h/des/src/alpha/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- Kernel build for GENERIC started on Thu Oct 31 15:09:00 PST 2002 -- Kernel build for GENERIC completed on Thu Oct 31 15:39:51 PST 2002 -- Kernel build for LINT started on Thu Oct 31 15:39:51 PST 2002 -- === vinum Makefile, line 4517: warning: duplicate script for target geom_bsd.o ignored cc1: warnings being treated as errors /h/des/src/sys/dev/aic7xxx/aic79xx.c: In function `ahd_alloc': /h/des/src/sys/dev/aic7xxx/aic79xx.c:4208: warning: unsigned int format, different type arg (arg 3) /h/des/src/sys/dev/aic7xxx/aic79xx.c:4208: warning: unsigned int format, different type arg (arg 4) /h/des/src/sys/dev/aic7xxx/aic79xx.c: In function `ahd_init_scbdata': /h/des/src/sys/dev/aic7xxx/aic79xx.c:4601: warning: unsigned int format, different type arg (arg 3) *** Error code 1 Stop in /h/des/obj/h/des/src/sys/LINT. *** Error code 1 Stop in /h/des/src. *** Error code 1 Stop in /h/des/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
A few questions
I just upgraded a 4.7-STABLE box to current over the weekend. Went off very well, thanks to the great documentation in UPDATING. It's odd, though, that after upgrading again just a few days later, suddenly X (or perhaps just xdm) failed to start due to an unresolved symbol. I had already upgraded X, as well as many other ports, after upgrading to -current, btw. It seems very peculiar that a cvsup just a few days apart from the previous one would require X to be rebuilt. On another note, can someone clue me in as to why I'm getting all these duplicate script errors when building both ports and world? I've looked high and low and can't find the reason for this. Seems harmless enough, but it *is* just slightly annoying. And finally, is there a simple way to ensure that none of the debugging code (including INVARIANTS stuff) is included during a buildworld? It would be nice if there were a simple switch or environment variable to control this. Please forgive if this is all old stuff; I'm new with -current, and I have made a real effort to find the answers to this stuff myself. Thanks. -- Conrad Sabatier [EMAIL PROTECTED] One Page Principle: A specification that will not fit on one page of 8.5x11 inch paper cannot be understood. -- Mark Ardis To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: newfs chokes, cores, dies if inode density too high; patch attached
I don't have time to test this right now, but see also PR bin/30959. Ceri -- you can't see when light's so strong you can't see when light is gone To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: kern/42417 cannot probe Olympus digital camera, C-1
I looked at the change and it seems good. Can someone more familiar with the USB system verify this? Thanks, Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: kern/42417 cannot probe Olympus digital camera, C-1
In message [EMAIL PROTECTED], Nate Lawson wri tes: I looked at the change and it seems good. Can someone more familiar with the USB system verify this? Done - I have a C-1 here, so I was able to test it - obviously I haven't accessed the camera from -current in a while! Ian To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
-current install on large disk in non-LBA mode
tonight i tried once again to install from 5.0-DP1 and the 2002-10-25 snapshot media. it has been interesting. the disk i'm trying to install to is a seagate ST360021A 60G disk with a 30G windows partition already installed. the BIOS accepts it either as a 28733/16/255 Cyl/Hd/Sec CHS, 1915/240/255 Large, or 7297/255/63 LBA disk (yes, both CHS and Large with 255 sectors). I had the BIOS set to auto during the initial install, which apparently defaulted to CHS mode. Windows is happy to work in both CHS and Large modes, so i subsequently tried both settings for the FreeBSD install. However, sysinstall (neither from the 4.7-mini ISO nor the 5.0 snapshots i have) refuses to accept either and insists on the LBA geometry. using G to manually set the geometry doesn't help (you have entered an invalid geometry, a more likely blah blah). Wizard Mode let me enter the BIOS geometry but apparently refused to write anything back to disk. My next try was to create the partitions (er, slices) in Windows and try to go from there, but that didn't work out either. Disklabel just wouldn't cooperate. For the time being I'll wipe out another disk and install there, but i sure wonder which detail i've missed. regards, -stephan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: -current install on large disk in non-LBA mode
On 01-Nov-2002 stephan mantler wrote: tonight i tried once again to install from 5.0-DP1 and the 2002-10-25 snapshot media. it has been interesting. the disk i'm trying to install to is a seagate ST360021A 60G disk with a 30G windows partition already installed. the BIOS accepts it either as a 28733/16/255 Cyl/Hd/Sec CHS, 1915/240/255 Large, or 7297/255/63 LBA disk (yes, both CHS and Large with 255 sectors). I had the BIOS set to auto during the initial install, which apparently defaulted to CHS mode. Windows is happy to work in both CHS and Large modes, so i subsequently tried both settings for the FreeBSD install. However, sysinstall (neither from the 4.7-mini ISO nor the 5.0 snapshots i have) refuses to accept either and insists on the LBA geometry. using G to manually set the geometry doesn't help (you have entered an invalid geometry, a more likely blah blah). Wizard Mode let me enter the BIOS geometry but apparently refused to write anything back to disk. My next try was to create the partitions (er, slices) in Windows and try to go from there, but that didn't work out either. Disklabel just wouldn't cooperate. For the time being I'll wipe out another disk and install there, but i sure wonder which detail i've missed. Sectors more than 63 are not allowed for IDE drives at all. What happens when you use the LBA geometry? Does the drive not boot properly after being installed? -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: kern/42417 cannot probe Olympus digital camera, C-1
On Fri, 1 Nov 2002, Ian Dowse wrote: In message [EMAIL PROTECTED], Nate Lawson wri tes: I looked at the change and it seems good. Can someone more familiar with the USB system verify this? Done - I have a C-1 here, so I was able to test it - obviously I haven't accessed the camera from -current in a while! Anyone care to take a look at kern/43462 and maybe get umass/da working before 5.0-R? Brian Feldman reported that the ohci was not working for him either (it appears to be not camera/umass related, but rather to the ohci driver). I've not had much luck contacting anyone related to USB. -- Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: RCng Awkwardness
On Wed, Oct 30, 2002 at 11:50:45AM -0800, Tim Kientzle wrote: I find the standard arguments used by RCng quite awkward. In particular, especially for people who have worked with SysV-style init scripts, it's We aren't trying to be compatable with SysV. We are compatable with other BSD's with an RCng deployment. I would find it vastly more intuitive if the current arguments were named differently: current 'start' - new 'boot' current 'stop' - new 'shutdown' current 'forcestart' - new 'start' current 'forcestop' - new 'stop' No thank you. This would be a gratitious change from the existing BSD prior art. This better reflects the actual usage: the current 'start' and 'stop' are really intended to be used by RC at system boot and shutdown time. No, they are also used by sysadmins wanting to cycle a service. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Lack of real long double support
On Thu, 31 Oct 2002, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Terry Lambert [EMAIL PROTECTED] writes: : M. Warner Losh wrote: : : I await an explanation of how you can fit 2*DBL_MAX into a double, : : which has a range of DBL_MIN..DBL_MAX. : : Look at the code. : : long double a = DBL_MAX; : long double b = DBL_MAX * 2; : : The original posting said that b would be +Inf at this point, which is : not correct. I think that Bruce was confused there. The more correct : example to look at was the one that rittle@ posted which was 1 + : LDBL_EPSILON. : : I guess I must not be understanding. What will b be, at this point, : then? How can it have a value larger than DBL_MAX that's not +Inf? : : If it's possible to represent a value larger than DBL_MAX in a double, : then the value of DBL_MAX is wrong, right? Maximum means maximum, : doesn't it? *LONG*DOUBLE* is not *DOUBLE*. long double has extended precision and a range compared to double. That's how. To beat this dead horse some more: look at the code carefully. It was long double x= DBL_MAX; long double y = 2 * x; /* (1) */ This is quite different from the above, which (after renaming variables and changing the formatting to be bug for bug compatible) is: long double x= DBL_MAX; long double y = DBL_MAX * 2;/* (2) */ In (1), we have DBL_MAX in a long double, so we can expect to double it if long doubles are longer than doubles (whether they actually are is machine-dependent). In (2), we are doubling DBL_MAX as a double. The result of this is fuzzy, since the computation may be done in double precision or long double precision or perhaps something weirder. There will be no way to tell until C99 is implemented and perhaps not even then. gcc things that it is implementing C99's FLT_EVAL_METHOD of 0, which performs arithmetic on doubles in double precision, so the result of DBL_MAX * 2 is +Inf if the this is evaluated at compile time. gcc (gcc-3.2 on i386's) doesn't actually implement this, since the result is not +Inf if DBL_MAX * 2 is evaluated at runtime. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Lack of real long double support
On Thu, 31 Oct 2002, Loren James Rittle wrote: In article [EMAIL PROTECTED], Bruce Evans[EMAIL PROTECTED] writes: When I run your program against gcc mainline (for 3.3 release) with the patch I have staged from RTH to correctly match our FP hardware default setup, I see: S rittle@latour; /usr/local/beta-gcc/bin/gcc t.c S rittle@latour; a.out LDBL_EPSILON failed test 2 with prec 3 S rittle@latour; /usr/local/beta-gcc/bin/gcc -O t.c S rittle@latour; a.out LDBL_EPSILON failed test 2 with prec 3 DBL_EPSILON failed test 2 with prec 3 S rittle@latour; /usr/local/beta-gcc/bin/gcc -O2 t.c S rittle@latour; a.out LDBL_EPSILON failed test 2 with prec 3 DBL_EPSILON failed test 2 with prec 3 S rittle@latour; /usr/local/beta-gcc/bin/gcc -O3 t.c S rittle@latour; a.out LDBL_EPSILON failed test 2 with prec 3 DBL_EPSILON failed test 2 with prec 3 I.e. the only time it fails is when the user made a call to change the default precision. Is that gcc 3.3 behavior acceptable (at least until gcc can be further refined to attempt to handle user override of the FP control word)? Yes, this is the correct behaviour IMO. I don't see how any user override of the control word (except possibly of the rounding mode) can be expected to work right outside of an FENV_ACCESS section. Constants like DBL_EPSILON presumably don't apply in such sections. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Lack of real long double support
In message: [EMAIL PROTECTED] Bruce Evans [EMAIL PROTECTED] writes: : On Thu, 31 Oct 2002, M. Warner Losh wrote: : : In message: [EMAIL PROTECTED] : Terry Lambert [EMAIL PROTECTED] writes: : : M. Warner Losh wrote: : : : I await an explanation of how you can fit 2*DBL_MAX into a double, : : : which has a range of DBL_MIN..DBL_MAX. : : : : Look at the code. : : : : long double a = DBL_MAX; : : long double b = DBL_MAX * 2; : : : : The original posting said that b would be +Inf at this point, which is : : not correct. I think that Bruce was confused there. The more correct : : example to look at was the one that rittle@ posted which was 1 + : : LDBL_EPSILON. : : : : I guess I must not be understanding. What will b be, at this point, : : then? How can it have a value larger than DBL_MAX that's not +Inf? : : : : If it's possible to represent a value larger than DBL_MAX in a double, : : then the value of DBL_MAX is wrong, right? Maximum means maximum, : : doesn't it? : : *LONG*DOUBLE* is not *DOUBLE*. long double has extended precision and : a range compared to double. That's how. : : To beat this dead horse some more: look at the code carefully. It was : : long double x= DBL_MAX; : long double y = 2 * x; /* (1) */ : : This is quite different from the above, which (after renaming variables : and changing the formatting to be bug for bug compatible) is: : : long double x= DBL_MAX; : long double y = DBL_MAX * 2;/* (2) */ : : In (1), we have DBL_MAX in a long double, so we can expect to double it : if long doubles are longer than doubles (whether they actually are is : machine-dependent). Right, The first example will not be +inf if long doubles have a greater range than doubles. On our i386 implemenation, it does. : In (2), we are doubling DBL_MAX as a double. The result of this is : fuzzy, since the computation may be done in double precision or long : double precision or perhaps something weirder. There will be no way : to tell until C99 is implemented and perhaps not even then. gcc things : that it is implementing C99's FLT_EVAL_METHOD of 0, which performs : arithmetic on doubles in double precision, so the result of DBL_MAX * : 2 is +Inf if the this is evaluated at compile time. gcc (gcc-3.2 on : i386's) doesn't actually implement this, since the result is not +Inf : if DBL_MAX * 2 is evaluated at runtime. That's true, but that's also independed problem.. It is no different than unsigned long long int a = ~0UL; unsigned long long int b = a * 2; vs unsigned long long int a = ~0UL; unsigned long long int b = ~0UL * 2; In the first case, b is twice a. In the second, b is 1 less than a on two's compliment machines. I'd written 2.0L in my test code, and I think that it was originally that way. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
