All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Namhyung Kim <namhyung@kernel.org>
Cc: Adrian Hunter <adrian.hunter@intel.com>,
	Jiri Olsa <jolsa@kernel.org>, Ian Rogers <irogers@google.com>,
	linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org,
	tlipcon@google.com, eranian@google.com
Subject: Re: [PATCH] perf symbol: Do not use debug file as the binary type
Date: Sun, 30 Aug 2026 10:10:45 -0300	[thread overview]
Message-ID: <apQr1UOHdI9f0IqU@x2> (raw)
In-Reply-To: <apCR1kJMBbdDC8B3@google.com>

On Thu, Aug 27, 2026 at 12:36:54PM -0700, Namhyung Kim wrote:
> Hello,
> 
> On Tue, Aug 25, 2026 at 09:23:45AM +0300, Adrian Hunter wrote:
> > dso__load() sets the binary type of a DSO to the type of the first symbol
> > source found. For a DSO with a separate debug file linked via
> > .gnu-debuglink, that is DSO_BINARY_TYPE__DEBUGLINK, which makes
> > dso__get_filename() return the name of the debug file instead of the file
> > that was actually executed.
> > 
> > Consumers that need to read instruction bytes, such as Intel PT decoding
> > in 'perf script', then read from the debug file and produce wrong
> > instructions.
> > 
> > Prefer DSO_BINARY_TYPE__BUILD_ID_CACHE, and otherwise
> > DSO_BINARY_TYPE__SYSTEM_PATH_DSO, over debug-only types, which restores
> > the behaviour of using a file that contains the executed instructions.
> > 
> > This is a workaround. Properly separating the binary file used for
> > instructions from the file used for debug symbols is left for later.
> > 
> > Example:
> > 
> >  Create a shared object with a separate .gnu_debuglink debug file. Note
> >  that 'objcopy --only-keep-debug' leaves .text as NOBITS, so instructions
> >  read from the debug file are zeros:
> > 
> >   # cat > foo.c << EOF
> >   unsigned long foo_work(unsigned long n)
> >   {
> >         unsigned long s = 0;
> > 
> >         for (unsigned long i = 0; i < n; i++)
> >                 s = s * 31 + i;
> >         return s;
> >   }
> >   EOF
> >   # cat > main.c << EOF
> >   #include <stdio.h>
> >   unsigned long foo_work(unsigned long n);
> >   int main(void)
> >   {
> >         printf("%lu\n", foo_work(1000));
> >         return 0;
> >   }
> >   EOF
> >   # gcc -g -O2 -shared -fPIC -o libfoo.so foo.c
> >   # gcc -g -O2 -o main main.c -L. -lfoo -Wl,-rpath,'$ORIGIN'
> >   # objcopy --only-keep-debug libfoo.so libfoo.so.debug
> >   # objcopy --strip-debug libfoo.so
> >   # objcopy --add-gnu-debuglink=libfoo.so.debug libfoo.so
> >   # perf record -e intel_pt//u ./main
> > 
> >  Note that branch samples must be requested, because it is the resolving
> >  of the branch target symbol that causes dso__load() to be called, and
> >  hence the binary type to be set, before the decoder walks the code.
> >  With '--itrace=e' alone, nothing loads symbols for libfoo.so, the binary
> >  type is left as DSO_BINARY_TYPE__NOT_FOUND, the correct file is read
> >  anyway, and no errors are reported either way.
> > 
> >  Before:
> > 
> >   # perf.before script --itrace=be 2>&1 | grep "instruction trace error"
> >    instruction trace error type 1 time 2350.467489498 cpu 9 pid 75634 tid 75634 ip 0x77d48480718f code 6: Trace doesn't match instruction
> >    instruction trace error type 1 time 2350.467489832 cpu 9 pid 75634 tid 75634 ip 0x77d484807341 code 6: Trace doesn't match instruction
> >    instruction trace error type 1 time 2350.467496412 cpu 9 pid 75634 tid 75634 ip 0x5b4de37a8074 code 6: Trace doesn't match instruction
> >    instruction trace error type 1 time 2350.467593393 cpu 9 pid 75634 tid 75634 ip 0x77d4848070d0 code 6: Trace doesn't match instruction
> >    instruction trace error type 1 time 2350.467593954 cpu 9 pid 75634 tid 75634 ip 0x77d4848075a8 code 6: Trace doesn't match instruction
> >    instruction trace error type 1 time 2350.467595728 cpu 9 pid 75634 tid 75634 ip 0x77d4848324de code 6: Trace doesn't match instruction
> >   6 instruction trace errors
> > 
> >  After:
> > 
> >   # perf script --itrace=be 2>&1 | grep "instruction trace error"
> >   #
> > 
> > Fixes: 5363c306787c8 ("perf symbol: Set binary_type of dso when loading")
> > Reported-by: Todd Lipcon <tlipcon@google.com>
> > Closes: https://lore.kernel.org/all/CAGH6UiG=RJLqBU3kLu9XJciPyPO1HZkbAPERguVUMRuWQgqf=A@mail.gmail.com/
> > Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
> 
> Thanks for the patch and a test case.
> 
> Arnaldo, I can take this to the perf-tools tree for v7.3.

Ok!

- Arnaldo

  reply	other threads:[~2026-08-30 13:10 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-25  6:23 [PATCH] perf symbol: Do not use debug file as the binary type Adrian Hunter
2026-08-25  6:41 ` sashiko-bot
2026-08-25 18:13 ` Ian Rogers
2026-08-27 19:36 ` Namhyung Kim
2026-08-30 13:10   ` Arnaldo Carvalho de Melo [this message]
2026-09-01  4:14 ` Namhyung Kim

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=apQr1UOHdI9f0IqU@x2 \
    --to=acme@kernel.org \
    --cc=adrian.hunter@intel.com \
    --cc=eranian@google.com \
    --cc=irogers@google.com \
    --cc=jolsa@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=namhyung@kernel.org \
    --cc=tlipcon@google.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 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.