Re: bi-arch test patch for 64-bit frysk

[Andrew Cagney <cagney at redhat dot com>]

Wu,
Is this problem transient, or permanent?

Its cases like this where adding a test, or test driven development, 
becomes critical.  Can you do the following:

- modify TestAuxv to include a new test that contains the Auxv buffer 
that you've seen; be sure to check that the test fails

- add your patch

- check that the failing test now passes (and none of the others now fail)

The removed code should also be replaced with a comment explaining why a 
AT_NULL test can't be used (with, if needed reference to specific kernel 
versions).  The ChangeLog should just explain what was changed, not why 
--> that's for comments in the code.   The GNU Coding standard's 
ChangeLog section talks about that.

Andrew


Wu Zhou wrote:
> Andrew,
>
> I have a check on x86_64, this is what I see on x86_64 when issuing 
> "info auxv" on 32-bit program:
>
> 32   AT_SYSINFO           Special system info/entry points 0xffffe400^M
> 33   AT_SYSINFO_EHDR      System-supplied DSO's ELF header 0xffffe000^M
> 16   AT_HWCAP             Machine-dependent CPU capability hints 
> 0xbfebfbff^M
> 6    AT_PAGESZ            System page size               4096^M
> 17   AT_CLKTCK            Frequency of times()           100^M
> 3    AT_PHDR              Program headers for program    0x8048034^M
> 4    AT_PHENT             Size of program header entry   32^M
> 5    AT_PHNUM             Number of program headers      7^M
> 7    AT_BASE              Base address of interpreter    0x0^M
> 8    AT_FLAGS             Flags                          0x0^M
> 9    AT_ENTRY             Entry point of program         0x80482f0^M
> 11   AT_UID               Real user ID                   0^M
> 12   AT_EUID              Effective user ID              0^M
> 13   AT_GID               Real group ID                  0^M
> 14   AT_EGID              Effective group ID             0^M
> 23   AT_SECURE            Boolean, was exec setuid-like? 0^M
> 15   AT_PLATFORM          String identifying platform    0xffffcceb 
> "i686"^M
> 0    AT_NULL              End of vector                  0x0^M
> 0    AT_NULL              End of vector                  0x0^M
> 0    AT_NULL              End of vector                  0x0^M
>
> Please note that there are three AT_NULL at the end.  This is the same 
> as what I saw on ppc64 for 32-bit program.
>
> This patch can fix that.  OK for commit?
>
> 2006-08-28  Wu Zhou  <woodzltc@cn.ibm.com>
>
>         * cni/AuxvBuilder.cxx (verify): There might be multiple 
> AT_NULL at
>         the end of auxv vector.
>
> --- proc/cni/AuxvBuilder.cxx.orig       2006-08-28 13:48:53.000000000 
> +0800
> +++ proc/cni/AuxvBuilder.cxx    2006-08-28 13:49:13.000000000 +0800
> @@ -110,9 +110,6 @@
>      // Reasonable value?
>      if (type > 1024 || type < 0)
>        return false;
> -    // AT_NULL value only at end of buffer?
> -    if (type == 0 && i + 2 * wordSize < buf->length)
> -      return false;
>    }
>    return true;
>  }
>
> Andrew Cagney wrote:
> > Wu Zhou wrote:
> > > Yong Zheng wrote:
> > > > hi,
> > > >
> > > > The followings are some difference between the test results of 
> > > > cases in
> > > > 64-bit mode and in 32-bit mode on 64-bit frysk.
> > > >
> > > > All tests are based on the cvs head(08-24).
> > > >
> > > > On X86_64, the following cases fail in 32-bit mode but pass in 64-bit
> > > > mode on 64-bit frysk:
> > > >
> > > > 1)testGetAuxv(frysk.proc.TestProcGet)java.lang.RuntimeException: 
> > > > unknown
> > > > word size for auxv (1|32l|64l|32b|64b 10000)
> > > >    at frysk.sys.proc.AuxvBuilder.construct(TestRunner)
> > >
> > > on ppc64, testGetAuxv fails in 32-bit testcase because there are 
> > > three AT_NULL at the end of aux vectors, which might be actually ok 
> > > (because I don't see any nagative impact it can bring up). I don't 
> > > know what is the situation in x86_64.
> >
> > This is interesting, the lower level 
> > frysk-sys/frysk/sys/proc/TestAuxv.java contains:
> >
> >    /**
> >     * Check that an AUXV taken from a 32-bit PowerPC program running
> >     * on a 64-bit PowerPC machine (PPC970, altivec supported) can be
> >     * parsed.
> >     */
> >
> > so it is attempting to test the case you describe, or at least based 
> > on the AUXV I extracted from an older kernel.  You're saying that the 
> > tail end of the AUXV is now different?   If it is then perhaps that 
> > lower level test should be augmented to also include the AUXV buffer 
> > that you're seeing.
>
> We are on the latest FC5 kernels. So I guess this need to go into the 
> lower level frysk-sys testcase too.  But I don't know how to generate 
> the "byte" array in routine "check".  If you can tell me how, I can 
> code a patch for that.
>
> Regards
> - Wu Zhou