Sometimes we want to convert an address in objdump output to
map-relative address to match with a sample data. Let's add
map__objdump_2rip() for that.
Cc: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
---
tools/perf/util/map.c | 20 ++++++++++++++++++++
tools/perf/util/map.h | 3 +++
2 files changed, 23 insertions(+)
diff --git a/tools/perf/util/map.c b/tools/perf/util/map.c
index 54c67cb7ecef..66542864b7b5 100644
--- a/tools/perf/util/map.c
+++ b/tools/perf/util/map.c
@@ -594,6 +594,26 @@ u64 map__objdump_2mem(struct map *map, u64 ip)
return ip + map__reloc(map);
}
+u64 map__objdump_2rip(struct map *map, u64 ip)
+{
+ const struct dso *dso = map__dso(map);
+
+ if (!dso->adjust_symbols)
+ return ip;
+
+ if (dso->rel)
+ return ip + map__pgoff(map);
+
+ /*
+ * kernel modules also have DSO_TYPE_USER in dso->kernel,
+ * but all kernel modules are ET_REL, so won't get here.
+ */
+ if (dso->kernel == DSO_SPACE__USER)
+ return ip - dso->text_offset;
+
+ return map__map_ip(map, ip + map__reloc(map));
+}
+
bool map__contains_symbol(const struct map *map, const struct symbol *sym)
{
u64 ip = map__unmap_ip(map, sym->start);
diff --git a/tools/perf/util/map.h b/tools/perf/util/map.h
index 49756716cb13..65e2609fa1b1 100644
--- a/tools/perf/util/map.h
+++ b/tools/perf/util/map.h
@@ -132,6 +132,9 @@ u64 map__rip_2objdump(struct map *map, u64 rip);
/* objdump address -> memory address */
u64 map__objdump_2mem(struct map *map, u64 ip);
+/* objdump address -> rip */
+u64 map__objdump_2rip(struct map *map, u64 ip);
+
struct symbol;
struct thread;
--
2.43.0.594.gd9cf4e227d-googOn Fri, Feb 2, 2024 at 2:05 PM Namhyung Kim <namhyung@kernel.org> wrote:
>
> Sometimes we want to convert an address in objdump output to
> map-relative address to match with a sample data. Let's add
> map__objdump_2rip() for that.
Hi Namhyung,
I think the naming can be better here. Aren't the objdump addresses
DSO relative offsets? Is the relative IP relative to the map or the
DSO?
Thanks,
Ian
> Cc: Adrian Hunter <adrian.hunter@intel.com>
> Signed-off-by: Namhyung Kim <namhyung@kernel.org>
> ---
> tools/perf/util/map.c | 20 ++++++++++++++++++++
> tools/perf/util/map.h | 3 +++
> 2 files changed, 23 insertions(+)
>
> diff --git a/tools/perf/util/map.c b/tools/perf/util/map.c
> index 54c67cb7ecef..66542864b7b5 100644
> --- a/tools/perf/util/map.c
> +++ b/tools/perf/util/map.c
> @@ -594,6 +594,26 @@ u64 map__objdump_2mem(struct map *map, u64 ip)
> return ip + map__reloc(map);
> }
>
> +u64 map__objdump_2rip(struct map *map, u64 ip)
> +{
> + const struct dso *dso = map__dso(map);
> +
> + if (!dso->adjust_symbols)
> + return ip;
> +
> + if (dso->rel)
> + return ip + map__pgoff(map);
> +
> + /*
> + * kernel modules also have DSO_TYPE_USER in dso->kernel,
> + * but all kernel modules are ET_REL, so won't get here.
> + */
> + if (dso->kernel == DSO_SPACE__USER)
> + return ip - dso->text_offset;
> +
> + return map__map_ip(map, ip + map__reloc(map));
> +}
> +
> bool map__contains_symbol(const struct map *map, const struct symbol *sym)
> {
> u64 ip = map__unmap_ip(map, sym->start);
> diff --git a/tools/perf/util/map.h b/tools/perf/util/map.h
> index 49756716cb13..65e2609fa1b1 100644
> --- a/tools/perf/util/map.h
> +++ b/tools/perf/util/map.h
> @@ -132,6 +132,9 @@ u64 map__rip_2objdump(struct map *map, u64 rip);
> /* objdump address -> memory address */
> u64 map__objdump_2mem(struct map *map, u64 ip);
>
> +/* objdump address -> rip */
> +u64 map__objdump_2rip(struct map *map, u64 ip);
> +
> struct symbol;
> struct thread;
>
> --
> 2.43.0.594.gd9cf4e227d-goog
>
Hi Ian,
On Fri, Feb 2, 2024 at 5:42 PM Ian Rogers <irogers@google.com> wrote:
>
> On Fri, Feb 2, 2024 at 2:05 PM Namhyung Kim <namhyung@kernel.org> wrote:
> >
> > Sometimes we want to convert an address in objdump output to
> > map-relative address to match with a sample data. Let's add
> > map__objdump_2rip() for that.
>
> Hi Namhyung,
>
> I think the naming can be better here. Aren't the objdump addresses
> DSO relative offsets? Is the relative IP relative to the map or the
> DSO?
AFAIK the objdump addresses are DSO-relative and rip is to map.
They are mostly the same but sometimes different due to kASLR
for the kernel.
>
> > Cc: Adrian Hunter <adrian.hunter@intel.com>
> > Signed-off-by: Namhyung Kim <namhyung@kernel.org>
> > ---
> > tools/perf/util/map.c | 20 ++++++++++++++++++++
> > tools/perf/util/map.h | 3 +++
> > 2 files changed, 23 insertions(+)
> >
> > diff --git a/tools/perf/util/map.c b/tools/perf/util/map.c
> > index 54c67cb7ecef..66542864b7b5 100644
> > --- a/tools/perf/util/map.c
> > +++ b/tools/perf/util/map.c
> > @@ -594,6 +594,26 @@ u64 map__objdump_2mem(struct map *map, u64 ip)
> > return ip + map__reloc(map);
> > }
> >
> > +u64 map__objdump_2rip(struct map *map, u64 ip)
> > +{
> > + const struct dso *dso = map__dso(map);
> > +
> > + if (!dso->adjust_symbols)
> > + return ip;
> > +
> > + if (dso->rel)
> > + return ip + map__pgoff(map);
> > +
> > + /*
> > + * kernel modules also have DSO_TYPE_USER in dso->kernel,
> > + * but all kernel modules are ET_REL, so won't get here.
> > + */
Hmm.. This comment is not true anymore. Will remove
in other places too.
Thanks,
Namhyung
> > + if (dso->kernel == DSO_SPACE__USER)
> > + return ip - dso->text_offset;
> > +
> > + return map__map_ip(map, ip + map__reloc(map));
> > +}
> > +
> > bool map__contains_symbol(const struct map *map, const struct symbol *sym)
> > {
> > u64 ip = map__unmap_ip(map, sym->start);
> > diff --git a/tools/perf/util/map.h b/tools/perf/util/map.h
> > index 49756716cb13..65e2609fa1b1 100644
> > --- a/tools/perf/util/map.h
> > +++ b/tools/perf/util/map.h
> > @@ -132,6 +132,9 @@ u64 map__rip_2objdump(struct map *map, u64 rip);
> > /* objdump address -> memory address */
> > u64 map__objdump_2mem(struct map *map, u64 ip);
> >
> > +/* objdump address -> rip */
> > +u64 map__objdump_2rip(struct map *map, u64 ip);
> > +
> > struct symbol;
> > struct thread;
> >
> > --
> > 2.43.0.594.gd9cf4e227d-goog
> >
On Tue, Feb 6, 2024 at 3:04 PM Namhyung Kim <namhyung@kernel.org> wrote:
>
> Hi Ian,
>
> On Fri, Feb 2, 2024 at 5:42 PM Ian Rogers <irogers@google.com> wrote:
> >
> > On Fri, Feb 2, 2024 at 2:05 PM Namhyung Kim <namhyung@kernel.org> wrote:
> > >
> > > Sometimes we want to convert an address in objdump output to
> > > map-relative address to match with a sample data. Let's add
> > > map__objdump_2rip() for that.
> >
> > Hi Namhyung,
> >
> > I think the naming can be better here. Aren't the objdump addresses
> > DSO relative offsets? Is the relative IP relative to the map or the
> > DSO?
>
> AFAIK the objdump addresses are DSO-relative and rip is to map.
> They are mostly the same but sometimes different due to kASLR
> for the kernel.
Perhaps we need to use names like map_rip for mapping relative and
dso_rip to clean this up, or to add a different mapping_type to the
enum. For non-kernel maps addresses for map are either the whole
virtual address space (identity) or relative to a dso:
https://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/tree/tools/perf/util/map.h?h=perf-tools-next#n115
https://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/tree/tools/perf/util/map.h?h=perf-tools-next#n20
The dso addresses should work for objdump so perhaps the kernel
addresses need map__pgoff fixing?
Thanks,
Ian
> >
> > > Cc: Adrian Hunter <adrian.hunter@intel.com>
> > > Signed-off-by: Namhyung Kim <namhyung@kernel.org>
> > > ---
> > > tools/perf/util/map.c | 20 ++++++++++++++++++++
> > > tools/perf/util/map.h | 3 +++
> > > 2 files changed, 23 insertions(+)
> > >
> > > diff --git a/tools/perf/util/map.c b/tools/perf/util/map.c
> > > index 54c67cb7ecef..66542864b7b5 100644
> > > --- a/tools/perf/util/map.c
> > > +++ b/tools/perf/util/map.c
> > > @@ -594,6 +594,26 @@ u64 map__objdump_2mem(struct map *map, u64 ip)
> > > return ip + map__reloc(map);
> > > }
> > >
> > > +u64 map__objdump_2rip(struct map *map, u64 ip)
> > > +{
> > > + const struct dso *dso = map__dso(map);
> > > +
> > > + if (!dso->adjust_symbols)
> > > + return ip;
> > > +
> > > + if (dso->rel)
> > > + return ip + map__pgoff(map);
> > > +
> > > + /*
> > > + * kernel modules also have DSO_TYPE_USER in dso->kernel,
> > > + * but all kernel modules are ET_REL, so won't get here.
> > > + */
>
> Hmm.. This comment is not true anymore. Will remove
> in other places too.
>
> Thanks,
> Namhyung
>
>
> > > + if (dso->kernel == DSO_SPACE__USER)
> > > + return ip - dso->text_offset;
> > > +
> > > + return map__map_ip(map, ip + map__reloc(map));
> > > +}
> > > +
> > > bool map__contains_symbol(const struct map *map, const struct symbol *sym)
> > > {
> > > u64 ip = map__unmap_ip(map, sym->start);
> > > diff --git a/tools/perf/util/map.h b/tools/perf/util/map.h
> > > index 49756716cb13..65e2609fa1b1 100644
> > > --- a/tools/perf/util/map.h
> > > +++ b/tools/perf/util/map.h
> > > @@ -132,6 +132,9 @@ u64 map__rip_2objdump(struct map *map, u64 rip);
> > > /* objdump address -> memory address */
> > > u64 map__objdump_2mem(struct map *map, u64 ip);
> > >
> > > +/* objdump address -> rip */
> > > +u64 map__objdump_2rip(struct map *map, u64 ip);
> > > +
> > > struct symbol;
> > > struct thread;
> > >
> > > --
> > > 2.43.0.594.gd9cf4e227d-goog
> > >
On Tue, Feb 6, 2024 at 3:34 PM Ian Rogers <irogers@google.com> wrote: > > On Tue, Feb 6, 2024 at 3:04 PM Namhyung Kim <namhyung@kernel.org> wrote: > > > > Hi Ian, > > > > On Fri, Feb 2, 2024 at 5:42 PM Ian Rogers <irogers@google.com> wrote: > > > > > > On Fri, Feb 2, 2024 at 2:05 PM Namhyung Kim <namhyung@kernel.org> wrote: > > > > > > > > Sometimes we want to convert an address in objdump output to > > > > map-relative address to match with a sample data. Let's add > > > > map__objdump_2rip() for that. > > > > > > Hi Namhyung, > > > > > > I think the naming can be better here. Aren't the objdump addresses > > > DSO relative offsets? Is the relative IP relative to the map or the > > > DSO? > > > > AFAIK the objdump addresses are DSO-relative and rip is to map. > > They are mostly the same but sometimes different due to kASLR > > for the kernel. > > Perhaps we need to use names like map_rip for mapping relative and > dso_rip to clean this up, or to add a different mapping_type to the > enum. For non-kernel maps addresses for map are either the whole > virtual address space (identity) or relative to a dso: > https://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/tree/tools/perf/util/map.h?h=perf-tools-next#n115 > https://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/tree/tools/perf/util/map.h?h=perf-tools-next#n20 > The dso addresses should work for objdump so perhaps the kernel > addresses need map__pgoff fixing? I'm not sure about the vDSO case. By the way, I need to take a look if we can make this objdump-rip thing simpler as you mentioned. My feeling is that it can be done but I'd like to do it in a separate work and to move this forward. Thanks, Namhyung
On Wed, Feb 7, 2024 at 11:04 AM Namhyung Kim <namhyung@kernel.org> wrote: > > On Tue, Feb 6, 2024 at 3:34 PM Ian Rogers <irogers@google.com> wrote: > > > > On Tue, Feb 6, 2024 at 3:04 PM Namhyung Kim <namhyung@kernel.org> wrote: > > > > > > Hi Ian, > > > > > > On Fri, Feb 2, 2024 at 5:42 PM Ian Rogers <irogers@google.com> wrote: > > > > > > > > On Fri, Feb 2, 2024 at 2:05 PM Namhyung Kim <namhyung@kernel.org> wrote: > > > > > > > > > > Sometimes we want to convert an address in objdump output to > > > > > map-relative address to match with a sample data. Let's add > > > > > map__objdump_2rip() for that. > > > > > > > > Hi Namhyung, > > > > > > > > I think the naming can be better here. Aren't the objdump addresses > > > > DSO relative offsets? Is the relative IP relative to the map or the > > > > DSO? > > > > > > AFAIK the objdump addresses are DSO-relative and rip is to map. > > > They are mostly the same but sometimes different due to kASLR > > > for the kernel. > > > > Perhaps we need to use names like map_rip for mapping relative and > > dso_rip to clean this up, or to add a different mapping_type to the > > enum. For non-kernel maps addresses for map are either the whole > > virtual address space (identity) or relative to a dso: > > https://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/tree/tools/perf/util/map.h?h=perf-tools-next#n115 > > https://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/tree/tools/perf/util/map.h?h=perf-tools-next#n20 > > The dso addresses should work for objdump so perhaps the kernel > > addresses need map__pgoff fixing? > > I'm not sure about the vDSO case. > > By the way, I need to take a look if we can make this objdump-rip > thing simpler as you mentioned. My feeling is that it can be done > but I'd like to do it in a separate work and to move this forward. Makes sense. Could we add a comment to the header file definition to capture some of this? Perhaps a "to be removed" to avoid later patches adding dependencies to the function. Thanks, Ian > Thanks, > Namhyung
On Wed, Feb 7, 2024 at 11:56 AM Ian Rogers <irogers@google.com> wrote: > > On Wed, Feb 7, 2024 at 11:04 AM Namhyung Kim <namhyung@kernel.org> wrote: > > > > On Tue, Feb 6, 2024 at 3:34 PM Ian Rogers <irogers@google.com> wrote: > > > > > > On Tue, Feb 6, 2024 at 3:04 PM Namhyung Kim <namhyung@kernel.org> wrote: > > > > > > > > Hi Ian, > > > > > > > > On Fri, Feb 2, 2024 at 5:42 PM Ian Rogers <irogers@google.com> wrote: > > > > > > > > > > On Fri, Feb 2, 2024 at 2:05 PM Namhyung Kim <namhyung@kernel.org> wrote: > > > > > > > > > > > > Sometimes we want to convert an address in objdump output to > > > > > > map-relative address to match with a sample data. Let's add > > > > > > map__objdump_2rip() for that. > > > > > > > > > > Hi Namhyung, > > > > > > > > > > I think the naming can be better here. Aren't the objdump addresses > > > > > DSO relative offsets? Is the relative IP relative to the map or the > > > > > DSO? > > > > > > > > AFAIK the objdump addresses are DSO-relative and rip is to map. > > > > They are mostly the same but sometimes different due to kASLR > > > > for the kernel. > > > > > > Perhaps we need to use names like map_rip for mapping relative and > > > dso_rip to clean this up, or to add a different mapping_type to the > > > enum. For non-kernel maps addresses for map are either the whole > > > virtual address space (identity) or relative to a dso: > > > https://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/tree/tools/perf/util/map.h?h=perf-tools-next#n115 > > > https://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/tree/tools/perf/util/map.h?h=perf-tools-next#n20 > > > The dso addresses should work for objdump so perhaps the kernel > > > addresses need map__pgoff fixing? > > > > I'm not sure about the vDSO case. > > > > By the way, I need to take a look if we can make this objdump-rip > > thing simpler as you mentioned. My feeling is that it can be done > > but I'd like to do it in a separate work and to move this forward. > > Makes sense. Could we add a comment to the header file definition to > capture some of this? Perhaps a "to be removed" to avoid later patches > adding dependencies to the function. Sure, will add that in v6. Thanks, Namhyung
© 2016 - 2026 Red Hat, Inc.