public inbox for systemtap@sourceware.org
 help / color / mirror / Atom feed
From: Eugeniy Meshcheryakov <eugen@debian.org>
To: Indraneel Mukherjee <indro.ml@gmail.com>
Cc: systemtap@sources.redhat.com
Subject: Re: systemtap-1.0.0 runtime failure on ARM - simple stap script  translation fails
Date: Tue, 15 Dec 2009 13:50:00 -0000	[thread overview]
Message-ID: <20091215135017.GA17553@localhost.localdomain> (raw)
In-Reply-To: <48e37220912140425h3ce1a3en3efb276d69d9ee9d@mail.gmail.com>


[-- Attachment #1.1: Type: text/plain, Size: 2464 bytes --]

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-----
> >
> >

[-- Attachment #1.2: build-id-arm.diff --]
[-- Type: text/x-diff, Size: 1204 bytes --]

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 #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

  parent reply	other threads:[~2009-12-15 13:50 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-14  5:55 Indraneel Mukherjee
2009-12-14  7:09 ` Eugeniy Meshcheryakov
2009-12-14  7:12   ` Eugeniy Meshcheryakov
2009-12-14 10:41     ` Indraneel Mukherjee
2009-12-14 11:00       ` Eugeniy Meshcheryakov
2009-12-14 12:25         ` Indraneel Mukherjee
2009-12-14 15:26           ` Eugeniy Meshcheryakov
2009-12-15 13:50           ` Eugeniy Meshcheryakov [this message]
2009-12-17  6:09             ` naresh kamboju

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20091215135017.GA17553@localhost.localdomain \
    --to=eugen@debian.org \
    --cc=indro.ml@gmail.com \
    --cc=systemtap@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).