Daniel Eischen 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. G
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 i
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
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 agai
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
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
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
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 w
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
lea
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 i
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
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 throug
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 u
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
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 laz
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 pthre
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
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
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 se
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 ]
&g
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:
&
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
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 Xth
* 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, 2
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
> >
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 onl
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
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_ s
* 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
> > f
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
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
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_ sy
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 b
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_ sy
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
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?
&g
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
Alexander Kabaev 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.
You people keep sayin
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
> > sou
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 ow
On Wed, 30 Oct 2002, Doug Rabson wrote:
> On Wed, 30 Oct 2002, Terry Lambert wrote:
>
> >
> > You need to link the library against libc_r.so instead of libXThrStub.so.
>
> Probably not. Doing that breaks the existing 'feature' of being able to
> use X11 in entirely non-threaded programs. I'm not
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
* 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
Doug Rabson wrote:
> > > For what its worth, doing this (defining strong pthread_* symbols in
> > > libc_r) makes everything work fine, with or without libXThrStub.
> >
> > No, this would be bad. There's some justification for not
> > doing this, in allowing programs linked againts libraries linke
Doug Rabson wrote:
> > You can't have a library that's sort of threaded and sort of not
> > threaded: pick one.
>
> Yes you can - libX11 is *thread safe* but doesn't create threads. When a
> real pthreads implementation is present, libX11 uses its implementation of
> mutex, cond etc. to ensure its
On Wed, 30 Oct 2002, Terry Lambert wrote:
> Doug Rabson wrote:
> > > I think the only sensible solution to this problem is for libraries which
> > > provide an actual pthreads implementation (rather than a set of stubs) to
> > > define strong symbols. Wierd debugging wrappers can still be achieved
On Wed, 30 Oct 2002, Terry Lambert wrote:
> Doug Rabson wrote:
> > > You need to link the library against libc_r.so instead of libXThrStub.so.
> >
> > Probably not. Doing that breaks the existing 'feature' of being able to
> > use X11 in entirely non-threaded programs. I'm not sure whether that is
Doug Rabson wrote:
> > I think the only sensible solution to this problem is for libraries which
> > provide an actual pthreads implementation (rather than a set of stubs) to
> > define strong symbols. Wierd debugging wrappers can still be achieved via
> > some dlopen/dlsym hackery.
>
> For what i
Doug Rabson wrote:
> > You need to link the library against libc_r.so instead of libXThrStub.so.
>
> Probably not. Doing that breaks the existing 'feature' of being able to
> use X11 in entirely non-threaded programs. I'm not sure whether that is
> acceptable. It also stops programs from being abl
Doug Rabson wrote:
> On Wed, 30 Oct 2002, Daniel Eischen wrote:
> > Well, it must have the same problem with Solaris then. Somehow,
> > you've got to force it to link libc_r before libc...
>
> The only way I can see to do that is to link libX11, libXt and friends
> against libc_r.
What this com
On Wed, 30 Oct 2002, Doug Rabson wrote:
> On Wed, 30 Oct 2002, Terry Lambert wrote:
>
> > Doug Rabson wrote:
> > > On Wed, 30 Oct 2002, Terry Lambert wrote:
> > > > Daniel Eischen wrote:
> > > > > Patch looks correct.
> > > >
> > > > Please commit? 8-).
> > >
> > > Well I made a libc with this pa
On Wed, 30 Oct 2002, Terry Lambert wrote:
> Doug Rabson wrote:
> > On Wed, 30 Oct 2002, Terry Lambert wrote:
> > > Daniel Eischen wrote:
> > > > Patch looks correct.
> > >
> > > Please commit? 8-).
> >
> > Well I made a libc with this patch and rebuilt XFree86-4-libraries without
> > libXThrStub
On Wed, 30 Oct 2002, Daniel Eischen wrote:
> On Wed, 30 Oct 2002, Doug Rabson wrote:
>
> > On Wed, 30 Oct 2002, Terry Lambert wrote:
> >
> > > Daniel Eischen wrote:
> > > > > That's bizarre... it's defined in libc_r, so there's no reason for
> > > > > the omission in libc.
> > > >
> > > > I only a
On Wed, 30 Oct 2002, Doug Rabson wrote:
> On Wed, 30 Oct 2002, Terry Lambert wrote:
>
> > Daniel Eischen wrote:
> > > > That's bizarre... it's defined in libc_r, so there's no reason for
> > > > the omission in libc.
> > >
> > > I only added stubs that I thought the implementation of libc used
>
Doug Rabson wrote:
> On Wed, 30 Oct 2002, Terry Lambert wrote:
> > Daniel Eischen wrote:
> > > Patch looks correct.
> >
> > Please commit? 8-).
>
> Well I made a libc with this patch and rebuilt XFree86-4-libraries without
> libXThrStub but I ran into problems compiling the clients. The clients
>
On Wed, 30 Oct 2002, Terry Lambert wrote:
> Daniel Eischen wrote:
> > > That's bizarre... it's defined in libc_r, so there's no reason for
> > > the omission in libc.
> >
> > I only added stubs that I thought the implementation of libc used
> > (or would use).
>
> Makes sense.
>
> Actually, it loo
Daniel Eischen wrote:
> > That's bizarre... it's defined in libc_r, so there's no reason for
> > the omission in libc.
>
> I only added stubs that I thought the implementation of libc used
> (or would use).
Makes sense.
Actually, it looks like most of this could be done with macros,
including th
On Wed, 30 Oct 2002, Terry Lambert wrote:
> Doug Rabson wrote:
> > > > All you have to do is create a situation where a shared object that links
> > > > to libc_r is loaded after libX11 and the thing breaks into little pieces.
> > >
> > > So let's dike out libXThrStub.so, and be done with it.
> >
Doug Rabson wrote:
> > > All you have to do is create a situation where a shared object that links
> > > to libc_r is loaded after libX11 and the thing breaks into little pieces.
> >
> > So let's dike out libXThrStub.so, and be done with it.
>
> I think the only stub which it defines that libc.so
59 matches
Mail list logo
