interesting option of stap

[William Cohen]

On 02/19/2011 06:01 PM, Turgis, Frederic wrote:
> Hello,
> 
> Bug is actually present, it was OK only due to a typo (stap instead of ./stap).
> 
> /tmp/staprfxbPV/stap-symbols.h:127376: error: integer constant is too large for 'long' type
> /tmp/staprfxbPV/stap-symbols.h:127376: error: large integer implicitly truncated to unsigned type
> 
> static struct _stp_module _stp_module_0 = {
> ...
> .build_id_len = 20,
> .build_id_offset = 0xffffffff3fff8010, -> here is the issue for ARM
> .notes_sect = 0,
> };
> 
> Regards
> Fred

I looked where the constant is generated, translate.cxx. The constant being printed out is type GElf_Addr. In /usr/include/gelf.h that is a 64 bit type:

typedef Elf64_Addr GElf_Addr;

However, /usr/share/systemtap/runtime/sym.h struct _stp_module has the following:

	unsigned long  build_id_offset;

The attached patch would generate constants that match the type for build_id_offset field. However, I am not sure if that is entirely correct fix. 0xffffffff3fff8010 is a negative number with a really large magnitude. The stap "-vv" option should include output like the following:

Found build-id in kernel, length 20, start at 0xffffffff814d2b50

That would be able to determine whether build_id_vaddr is wrong or whether (base+extra_offset) in translate.cxx:dump_unwindsyms() is wrong.

-Will
-------------- next part --------------
A non-text attachment was scrubbed...
Name: build_cast.diff
Type: text/x-patch
Size: 1280 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/systemtap/attachments/20110221/cd7a07b6/attachment.bin>