[Valgrind-developers] AT_UME_PADFD/AT_UME_EXECFD

[Tom H. <th...@cy...>]

I think I did mention this somewhere (probably the users list) some
time ago, but a recent posting on the users list reminded me of it.

We currently add a couple of auxv entries to convery information from
stage 1 to the main program. Currently those entries have high key
values to keeep them separate from existing entries that the kernel
generates. Specifically they have these values:

  AT_UME_PADFD   0xff01
  AT_UME_EXECFD  0xff02

The problem is that _dl_sysdep_start in glibc tries to keep track
of which auxv entries have been seen using an unsigned long and
orring in bits based on the auxv key values.

Obviously 0xff01 and 0xff02 are way out of range for an unsigned
long that can only handle 32 bits. Most of the time we get away with
this because gcc generates code which doesn't set any bits if the
value is out of range.

Some compilers (mostly older ones on 2.2 kernel systems it seems) do
generate problem code that uses the x86 set bit instruction. This code
just ignores the fact that it is out of range and writes to some other
word of memory miles away from the unsigned long.

The point is that there seems to be some sort of assumption in glibc
that AT_xxx values should be in the 0..31 range and we are currently
violating that.

Tom

-- 
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/