Re: About testGetAuxv (in frysk-core) and TestAuxv (in frysk-sys)

[Andrew Cagney <cagney at redhat dot com>]

Wu Zhou wrote:
> I add a new case to TestAuxv as per your idea, it does fail with the 
> original code.  After applying my patch, the case can pass now.  But 
> it trigger another failure on case testPPC64.
>
> I did some anlysis, and found that routine "verify" will return true 
> for get32l and get32b in this case after applying my patch.
>
> The further analysis shows that for byte array in testPPC64:
>
>            new byte[] {
>            0, 0, 0, 0, 0, 0, 0, 22, 0, 0, 0, 0, 0, 0, 0, 22,
>            0, 0, 0, 0, 0, 0, 0, 22, 0, 0, 0, 0, 0, 0, 0, 22,
>            0, 0, 0, 0, 0, 0, 0, 19, 0, 0, 0, 0, 0, 0, 0, -128,
>            0, 0, 0, 0, 0, 0, 0, 20, 0, 0, 0, 0, 0, 0, 0, -128,
>            0, 0, 0, 0, 0, 0, 0, 21, 0, 0, 0, 0, 0, 0, 0, 0,
>            0, 0, 0, 0, 0, 0, 0, 33, 0, 0, 0, 0, 0, 16, 0, 0,
>            0, 0, 0, 0, 0, 0, 0, 16, 0, 0, 0, 0, -36, 0, 0, 0,
>            0, 0, 0, 0, 0, 0, 0, 6, 0, 0, 0, 0, 0, 0, 16, 0,
>            0, 0, 0, 0, 0, 0, 0, 17, 0, 0, 0, 0, 0, 0, 0, 100,
>            0, 0, 0, 0, 0, 0, 0, 3, 0, 0, 0, 0, 16, 0, 0, 64,
>            0, 0, 0, 0, 0, 0, 0, 4, 0, 0, 0, 0, 0, 0, 0, 56,
>            0, 0, 0, 0, 0, 0, 0, 5, 0, 0, 0, 0, 0, 0, 0, 7,
>            0, 0, 0, 0, 0, 0, 0, 7, 0, 0, 0, 0, 0, 0, 0, 0,
>            0, 0, 0, 0, 0, 0, 0, 8, 0, 0, 0, 0, 0, 0, 0, 0,
>            0, 0, 0, 0, 0, 0, 0, 9, 0, 0, 0, 0, 16, 1, 10, -40,
>            0, 0, 0, 0, 0, 0, 0, 11, 0, 0, 0, 0, 0, 0, 9, -12,
>            0, 0, 0, 0, 0, 0, 0, 12, 0, 0, 0, 0, 0, 0, 9, -12,
>            0, 0, 0, 0, 0, 0, 0, 13, 0, 0, 0, 0, 0, 0, 9, -7,
>            0, 0, 0, 0, 0, 0, 0, 14, 0, 0, 0, 0, 0, 0, 9, -7,
>            0, 0, 0, 0, 0, 0, 0, 23, 0, 0, 0, 0, 0, 0, 0, 0,
>            0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
>            }
FYI, this array came from, I think, an FC-4 PPC64 machine.

> the get32l and get32b will get 4 bytes first, and advance the buffer 
> pointer for 8 bytes (2 * WordSize) and get the next 4 bytes, and go on 
> like that.
>
> In this way, all the get32l/get32b will return 0, which will return 
> false in original code and return true after applying my patch.
>
> So removing the check that AT_NULL can only be at the end of buffer 
> will trigger error for this. But this check is not true for the 
> 32-x-64 cases in x86_64 and ppc64.  Can we figure out some other 
> checks for this?
can the test instead check that the AT_NULL's (plural) are only at the 
end of the file?  For instance, from the AT_NULL on everything is 0?

Andrew