| Gprof reader fails on Power 8 little endian system [message #1740553] |
Mon, 15 August 2016 16:12  |
 David Wootton
Messages: 18
Registered: July 2009 |
Junior Member |
|
|
I'm trying to run the gmon reader to analyze a gmon.out file generated from a Power 8 littel endian executable generated on that system. This is failing in CDT method Addr64.checkAddress with an IllegalArgumentException stating the address must be a positive value. In the case where Addr4 raises an exception, the byte array passed to it contains -24,0,-98,-112,-16, 0, 126,-8, where I think the -24 in bytes[0] is causing the exception.
I think there's a couple problems here. First, the code doesn't seem to be aware of big endian vs little endian and is treating the bytes array as a big endian address. Second, I think when the BigInteger constructor is called, it needs to be called as new BigInteger(1, bytes), which I understand to tell the constructor that the value should be treated as a positive (unsigned) value.
Also, discussing with my team, there's doubts that the logic for calculating 'index' in the PPC64ElfBinaryObjectWrapper.fixAddr() method with references to the data segment is correct. We think this is a method to determine if the symbol is local to the executable or if it's a dynamic call stub to a library function and the code is trying to get the real function address, and where we're not sure the ELF construction for little endian Power 8 works the same way.
Is the gmon reader code supposed to work with this architecture?
[Updated on: Mon, 15 August 2016 21:43] Report message to a moderator |
|
|
| Re: Gprof reader fails on Power 8 little endian system [message #1740583 is a reply to message #1740553] |
Mon, 15 August 2016 21:41  |
David Wootton
Messages: 18
Registered: July 2009 |
Junior Member |
|
|
Looking at this a bit more this afternoon, I think the fixAddr method has several problems.
I found that the 'addr' parameter passed to fixAddr is the actual symbol address, matching what I get if I run 'nm a.out' on the remote system.
I believe the statement 'long index = addr.getValue().longValue() - dataSection.sh_addr.getValue().longValue() + dataSection.sh_offset;' is trying to do two things, attempting to determine if the 'addr' value is the actual address of a symbol local to the a.out or the address of a stub for a shared library function and then in the case of a stub, determine where to seek in the elf executable file.
If it's the address of a local symbol, then I think the check should be to the effect of
if (addr < dataSection.sh_addr) {
return null; // Indicate this is a local address, accept it as-is
}
else {
<processing to resolve stub symbol>
}
I think the processing of the 'bytes' array is incorrect since it does not take into consideration the endianness of the remote system. Other code in the gmon reader does consider endianness.
I don't understand the rationale for the expression
long index = addr.getValue().longValue() - dataSection.sh_addr.getValue().longValue() + dataSection.sh_offset;
to determine where to skip to to read the actual symbol address for a shared library stub. It looks like we are trying to seek somewhere relative to the data segment in the elf file, which doesn't seem right. I thought stubs were in their own .section in the elf, but I'm not familar with elf file construction in depth.
Also, does reading the elf file to get the address of a shared library function actually work? My understanding is that the function address in a stub is invalid (null) until resolved by the system loader or on first call to the function, since the load address of a shared library is not predictable and not known until the shared library is actually loaded. Is this somehow being resolved elsewhere?
Thoughts on the above?
Dave
[Updated on: Mon, 15 August 2016 21:43] Report message to a moderator |
|
|
Powered by
FUDForum. Page generated in 0.02989 seconds
] 
Search
Help
Register
Login
Home
