This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
Hello Indraneel, I think I fixed this bug in git repo, see attached patch. I was only able to test it with arm emulator and cross-compiler and probes located in the kernel itself, not in modules, so if you could test it with native compilation and probes in modules it will be very good. This patch skips saving of build-id for kernels like one for ARM. I think the previous patch only worked because build-id check was skipped because of check in sym.c:261 (comment says "shouldn't happen"). Regards, Eugeniy Meshcheryakov 14 ÐÑÑÐÐÑ 2009 Ð 17:55 +0530 Indraneel Mukherjee ÐÐÐÐÑÐÐ(-ÐÐ): > On Mon, Dec 14, 2009 at 4:30 PM, Eugeniy Meshcheryakov <eugen@debian.org> wrote: > > Yes, I know about that problem. But I'm not sure whether proposed patch > > fixes anything. Were you able to _use_ modules made with that patch applied? > > Yes, i was able to _use_ SystemTap on ARM after applying that patch + > your fix. I ran the following script and it worked absolutely fine: > > global reads > probe kernel.function("do_writepages") { > reads[execname()]++ > } > probe timer.s(3) > { > foreach (count in reads) > printf("%s : %d \n", count, reads[count]) > } > > OUTPUT of script: > pdflush : 4 > pdflush : 4 > pdflush : 8 > pdflush : 8 > pdflush : 12 > pdflush : 12 > pdflush : 12 > ... > ... > > Or does it fixes only compilation? My guess is that module > > initialization will fail because build-id does not match. > > No it does not fail. > > Regards, > Indro > > > > > 14 ÐÑÑÐÐÑ 2009 Ð 16:11 +0530 Indraneel Mukherjee ÐÐÐÐÑÐÐ(-ÐÐ): > >> Thanks for the fix. Also, there was another patch that i had to apply > >> to get Systemtap working for ARM. I checked the latest git and the fix > >> is not available for ARM. The fix is here: > >> http://sources.redhat.com/ml/systemtap/2009-q4/msg00574.html > >> Without the above fix, the ARM(arm-linux is non-relocatable) stap FAILS. > >> > >> This is related to > >> http://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg690166.html > >> > >> Shouldn't this fix be added to the Systemtap tree to get it right for ARM? > > > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v1.4.10 (GNU/Linux) > > > > iEYEARECAAYFAksmGt0ACgkQKaC6+zmozOLZtwCfasFxn9Q8LgZgLQ59sKIEyJT3 > > dEMAoJC1rOkL/NN+mABa5p16hDqXMMV1 > > =ud4E > > -----END PGP SIGNATURE----- > > > >
commit 66f65c4fb0ddcdf8a85a29662a23a546cfd5dffe Author: Eugeniy Meshcheryakov <eugen@debian.org> Date: Tue Dec 15 14:17:51 2009 +0100 Don't save build-id if it is located before _stext This probably means that build-id will not be loaded at all and happens for example with ARM kernel. See also: http://sources.redhat.com/ml/systemtap/2009-q4/msg00574.html diff --git a/translate.cxx b/translate.cxx index 4b00615..aca0d86 100644 --- a/translate.cxx +++ b/translate.cxx @@ -4909,7 +4909,14 @@ dump_unwindsyms (Dwfl_Module *m, c->output << ".num_sections = sizeof(_stp_module_" << stpmod_idx << "_sections)/" << "sizeof(struct _stp_section),\n"; - if (build_id_len > 0) { + /* Don't save build-id if it is located before _stext. + * This probably means that build-id will not be loaded at all and + * happens for example with ARM kernel. + * + * See also: + * http://sources.redhat.com/ml/systemtap/2009-q4/msg00574.html + */ + if (build_id_len > 0 && (build_id_vaddr > base + extra_offset)) { c->output << ".build_id_bits = \"" ; for (int j=0; j<build_id_len;j++) c->output << "\\x" << hex
Attachment:
signature.asc
Description: Digital signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |