All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Songshan Gong <gongss@linux.vnet.ibm.com>
Cc: Christian Borntraeger <borntraeger@de.ibm.com>,
	jolsa@kernel.org, dsahern@gmail.com,
	linux-kernel@vger.kernel.org,
	Michael Ellerman <mpe@ellerman.id.au>
Subject: Re: [PATCH] s390/perf: fix 'start' address of module's map
Date: Wed, 27 Jul 2016 10:08:08 -0300	[thread overview]
Message-ID: <20160727130808.GD5200@kernel.org> (raw)
In-Reply-To: <a9ea29ea-70da-8931-ff14-637959b03721@linux.vnet.ibm.com>

Em Wed, Jul 27, 2016 at 06:49:48PM +0800, Songshan Gong escreveu:
> 
> 
> 在 7/27/2016 4:29 AM, Arnaldo Carvalho de Melo 写道:
> > Em Tue, Jul 26, 2016 at 10:14:18PM +0200, Christian Borntraeger escreveu:
> > > On 07/26/2016 09:50 PM, Arnaldo Carvalho de Melo wrote:
> > > > Em Thu, Jul 21, 2016 at 11:10:51AM +0800, Song Shan Gong escreveu:
> > > > > At preset, when creating module's map, perf gets 'start' address by parsing
> > > > > '/proc/modules', but it's module base address, isn't the start address of
> > > > > '.text' section. In most archs, it's OK. But for s390, it places 'GOT' and
> > > > > 'PLT' relocations before '.text' section. So there exists an offset between
> > > > > module base address and '.text' section, which will incur wrong symbol
> > > > > resolution for modules.
> > > > 
> > > > I'll apply this as it fixes the problem for you and we need to get fixes
> > > > in ASAP to get this into 4.8, but why can't we just use your method for
> > > > all arches and get rid of this arch__ hook? I.e. if I look here in my
> > > > x86_64 notebook I see:
> > > > 
> > > > [acme@jouet linux]$ cat /sys/module/tun/sections/.text
> > > > 0xffffffffc0af2000
> > > > [acme@jouet linux]$ grep tun /proc/modules
> > > > tun 28672 4 vhost_net, Live 0xffffffffc0af2000
> > > > [acme@jouet linux]$
> > > > 
> > > > So I could as well use what is in /sys/module/tun/sections/.text instead
> > > > of reading it from /proc/modules and, in s390, reading it from
> > > > /sys/module/tun/sections/.text.
> > > > 
> > > > Do you see any problem with using this approach for _all_ arches?
> > > 
> > > I think it should work well for _all_ arches but it will probably be
> > > hard to test this without help.
> > 
> > Well, we could check for the cases we don't know, i.e. read from both
> > and warn about cases where it is different, except for s390 where we now
> > which is the right one to pick.
> > 
> One question: how to get arch info except machine->env->arch? It seems that
> machine->env->arch could be NULL sometimes.

That is not what you want to look at, as it is related to perf.data,
which may not be related to what you want, which is the running machine.

For that use uname() -> utsname.machine.

But then, why would you need it for reading /sys/module/*/sections/.text?
The arch name isn't there :-)

- Arnaldo

  reply	other threads:[~2016-07-27 13:08 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-21  3:10 [RFC PATCH V4]s390/perf:fix 'start' address of module's map Song Shan Gong
2016-07-21  3:10 ` [PATCH] s390/perf: fix " Song Shan Gong
2016-07-22  2:47   ` Songshan Gong
2016-07-26  6:54     ` Jiri Olsa
2016-07-26 19:50   ` Arnaldo Carvalho de Melo
2016-07-26 20:14     ` Christian Borntraeger
2016-07-26 20:29       ` Arnaldo Carvalho de Melo
2016-07-27  9:24         ` Michael Ellerman
2016-07-27 13:05           ` Arnaldo Carvalho de Melo
2016-07-27 10:10         ` Songshan Gong
2016-07-27 10:49         ` Songshan Gong
2016-07-27 13:08           ` Arnaldo Carvalho de Melo [this message]
2016-07-28  2:01             ` Songshan Gong
2016-07-27 10:05     ` Songshan Gong
2016-07-27 10:41   ` [tip:perf/urgent] perf s390: Fix " tip-bot for Song Shan Gong
  -- strict thread matches above, loose matches on Subject: below --
2016-07-19 11:31 [RFC PATCH V3]s390/perf:fix " Song Shan Gong
2016-07-19 11:31 ` [PATCH] s390/perf: fix " Song Shan Gong
2016-07-20 11:51   ` Jiri Olsa

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=20160727130808.GD5200@kernel.org \
    --to=acme@kernel.org \
    --cc=borntraeger@de.ibm.com \
    --cc=dsahern@gmail.com \
    --cc=gongss@linux.vnet.ibm.com \
    --cc=jolsa@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mpe@ellerman.id.au \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.