This is the mail archive of the
frysk@sources.redhat.com
mailing list for the frysk project.
About testGetAuxv (in frysk-core) and TestAuxv (in frysk-sys)
(I change the subject because it describes what we are discussing more precisely)
Andrew Cagney wrote:
Wu,
Is this problem transient, or permanent?
I am not sure if it is permanent. But it surely is not transient. I see this on FC5 kernel, FC6
test2 kernels, on both x86_64 and ppc64 platforms.
Its cases like this where adding a test, or test driven development,
becomes critical. Can you do the following:
Yes. I can't be agree with you any more. Test driven development is critical for Frysk. The case
Frysk has currently is not too much, it is relatively less I believe.
- 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)
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
}
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?
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.
Thanks. I will keep that in mind when I submit patch later.
Regards
- Wu Zhou
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