Re: [Valgrind-developers] AT_UME_PADFD/AT_UME_EXECFD

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

On Sun, 2004-07-04 at 19:56 +0100, Tom Hughes wrote:
> 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.

Hm.  Current glibc (on FC2) defines AT_ entries up to 37, so I presume
the limit has been removed, or at least increased (even SYSINFO_EHDR is
33).  On the other hand, these entries won't appear on older systems, so
there's no issue there.  I guess we could just hijack some lower numbers
and hope for the best (we could use different constants on different
systems, but I'm not terribly keen on that).

Is this causing real problems?

	J