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]

Re: systemtap-1.0.0 runtime failure on ARM - simple stap script translation fails


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]