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