valgrind-developers

[Valgrind-developers] 1.0.X possibilities

[Julian S. <js...@ac...>]

Good news.  After peering at weird segfaults on Red Hat Null (8.0 beta)
last night, I can see that it might be possible to assemble enough hacks
so that the stable branch will work on R H 8.  Assuming that they haven't
changed the threading model used in the transition between the "null" 
final beta and 8.0 itself, which doesn't sound likely.  I thought that
8.0 would use glibc-2.3, but apparently it is only at 2.2.93, so we 
don't have to deal yet with big threading changes.

I had expected only to be able to support R H 8 on the head, using the
LDT/GDT support, but it seems that might not be necessary.

Vague plan therefore is to assemble this and various other bugfixes into
1.0.4 and release that within about a week.  I still plan to make a 
snapshot release of the head as 1.1.0 in the next couple of days, for
the more adventurous.

J

Re: [Valgrind-developers] 1.0.X possibilities

[Jeremy F. <je...@go...>]

On Fri, 2002-10-04 at 03:21, Julian Seward wrote:
    Good news.  After peering at weird segfaults on Red Hat Null (8.0 beta)
    last night, I can see that it might be possible to assemble enough hacks
    so that the stable branch will work on R H 8.  Assuming that they haven't
    changed the threading model used in the transition between the "null" 
    final beta and 8.0 itself, which doesn't sound likely.  I thought that
    8.0 would use glibc-2.3, but apparently it is only at 2.2.93, so we 
    don't have to deal yet with big threading changes.

How has threading changed in RH8 and/or glibc 2.3?  Have they dropped
LinuxThreads?
    
    I had expected only to be able to support R H 8 on the head, using the
    LDT/GDT support, but it seems that might not be necessary.
    
    Vague plan therefore is to assemble this and various other bugfixes 

What fixes do you intend putting in the 1.0.X branch?

	J

Re: [Valgrind-developers] 1.0.X possibilities

[Julian S. <js...@ac...>]

On Friday 04 October 2002 4:52 pm, Jeremy Fitzhardinge wrote:
> On Fri, 2002-10-04 at 03:21, Julian Seward wrote:
>     Good news.  After peering at weird segfaults on Red Hat Null (8.0 beta)
>     last night, I can see that it might be possible to assemble enough
> hacks so that the stable branch will work on R H 8.  Assuming that they
> haven't changed the threading model used in the transition between the
> "null" final beta and 8.0 itself, which doesn't sound likely.  I thought
> that 8.0 would use glibc-2.3, but apparently it is only at 2.2.93, so we
> don't have to deal yet with big threading changes.
>
> How has threading changed in RH8 and/or glibc 2.3?  Have they dropped
> LinuxThreads?

The important change is to do with thread-specific data.  New scheme on
x86s at least is that the linux kernel creates a GDT entry which points
at a thread's local storage; the thread can then access that merely
by using a suitable segment override prefix on any old memory referencing
insn.  Kernel swizzles the GDT entry when scheduling threads, and 
there is a new syscall by which a thread can tell the kernel
where it's TLD is [i assume because GDT can't be swizzled from user-space]
and because the kernel needs to know this anyway.

This means accesses to TLD can be done in a single insn, which is dozens
of times faster and more convenient doing pthread_key_get or whatever it's
really called.

However, this stuff isn't in R H Null, and I would be surprised if something
that fundamental was changed in the transition from Null (the final RH8 beta)
to RH8 itself.  I'm downloading RH8 now but it takes ~ 4 days on a 64kbit/sec
cable modem.

LinuxThreads will be replaced by "Native Posix Threads" (I think) in due 
course although that will be binary-compatible with current libpthread.so .

>     I had expected only to be able to support R H 8 on the head, using the
>     LDT/GDT support, but it seems that might not be necessary.
>
>     Vague plan therefore is to assemble this and various other bugfixes
>
> What fixes do you intend putting in the 1.0.X branch?

For 1.0.4:

- Support for RH8 if practical; mostly this means some (old-style) TLD
  improvments to do with thread-specific locales

- add in the gcc-3.2 support patch available on the web page

- someone sent a helpful patch to use dynamic symbols in elf executables/so's;
  this improves backtraces sometimes

- the usual round of minor unimplemented opcodes, syscalls and ioctls

- possibly your patches of 25 Sept if they don't cause build problems
  on any test platform I have

No new functionality; that stuff is for the head.  Far more important that
the stable branch is stable.

J

Re: [Valgrind-developers] 1.0.X possibilities

[Jeremy F. <je...@go...>]

On Fri, 2002-10-04 at 09:22, Julian Seward wrote:
    The important change is to do with thread-specific data.  New scheme on
    x86s at least is that the linux kernel creates a GDT entry which points
    at a thread's local storage; the thread can then access that merely
    by using a suitable segment override prefix on any old memory referencing
    insn.  Kernel swizzles the GDT entry when scheduling threads, and 
    there is a new syscall by which a thread can tell the kernel
    where it's TLD is [i assume because GDT can't be swizzled from user-space]
    and because the kernel needs to know this anyway.

But if all this is just implementation detail of libpthreads and you're
replacing all of libpthreads, then surely you wouldn't have to deal with
it anyway?

    - possibly your patches of 25 Sept if they don't cause build problems
      on any test platform I have

Oh, you mean the poll/select name issue and the msgsnd/msgrcv
implementation?

	J
    
    

Re: [Valgrind-developers] 1.0.X possibilities

[Julian S. <js...@ac...>]

On Friday 04 October 2002 5:50 pm, Jeremy Fitzhardinge wrote:
> On Fri, 2002-10-04 at 09:22, Julian Seward wrote:
>     The important change is to do with thread-specific data.  New scheme on
>     x86s at least is that the linux kernel creates a GDT entry which points
>     at a thread's local storage; the thread can then access that merely
>     by using a suitable segment override prefix on any old memory
> referencing insn.  Kernel swizzles the GDT entry when scheduling threads,
> and there is a new syscall by which a thread can tell the kernel
>     where it's TLD is [i assume because GDT can't be swizzled from
> user-space] and because the kernel needs to know this anyway.
>
> But if all this is just implementation detail of libpthreads and you're
> replacing all of libpthreads, then surely you wouldn't have to deal with
> it anyway?

Not exacltly true, because gcc >= 3.2 is roped into this game as well,
and generates TLD-accessing code directly for variables declared with
the __thread qualifier.

>     - possibly your patches of 25 Sept if they don't cause build problems
>       on any test platform I have
>
> Oh, you mean the poll/select name issue and the msgsnd/msgrcv
> implementation?

Yes.

J