On Wed, 2009-04-22 at 13:02 +0200, Mark Wielaard wrote:

Also investigating some changes in the build_id vaddr logic, which seem to pop up with the new code. Will report when I figure out if it is an stap or libdwfl issue.

This is because the build_id address returned by dwfl_module_build_id() isn't adjusted for with sh_addr + mod->main.bias anymore when the module is ET_EXEC or ET_DYN. This seems to be caused by the guard of mod->e_type == ET_REL before calling __libdwfl_relocate_value() inside __libdwfl_find_build_id(). Of course if the guard wasn't there, then the new assert inside __libdwfl_relocate_value() would trigger.

Cheers,

Mark

On Wed, 2009-04-22 at 11:33 -0700, Roland McGrath wrote:

Oops! Well, that's what regression testing is for. :-) I think I've fixed this (cc48047).

Yes, that fixed the build-id issue I saw.

I fixed the resolve_symbol regression (c65558b). (That one hit just from running eu-unstrip -n -K.)

Thanks, things look fine now. No regressions in the systemtap testsuite on f10/i386 nor on rhel5.3/x86_64 against elfutils git tip.

Cheers,

Mark