On 04/27/18 03:55, Thomas-Mich Richter wrote:
On 04/26/2018 05:26 PM, Martin Vuille wrote:
On 04/26/18 04:09, Thomas-Mich Richter wrote:
was different. With you patch it changed from /usr/lib64/libc.so (old) to
/usr/lib/debug/lib64/libc-2.26.so.debug (new)
Thomas,
Can you tell me what
On 04/26/18 04:09, Thomas-Mich Richter wrote:
was different. With you patch it changed from /usr/lib64/libc.so (old) to
/usr/lib/debug/lib64/libc-2.26.so.debug (new)
Thomas,
Can you tell me what 'file' reports for the old and new files?
Regards,
MV
In verbose level 2, errors returned by libdw are reported in most cases,
but not when calling dwfl_attach_state.
Since elfutils v 0.160 (2014), dwfl_attach_state sets the error code to
report failure cause. On failure, log the reported error.
---
tools/perf/util/unwind-libdw.c | 3 ++-
1 file
build_id_filename already contains symfs path if applicable, so
don't prepend it a second time.
Signed-off-by: Martin Vuille <jpm...@aim.com>
---
tools/perf/util/annotate.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/perf/util/annotate.c b/tools/perf/util/anno
path if DSO is [kernel.kallsyms]
Signed-off-by: Martin Vuille <jpm...@aim.com>
---
tools/perf/util/annotate.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/tools/perf/util/annotate.c b/tools/perf/util/annotate.c
index 425b7f0760ec..0b78cc4fb155 100644
--- a/tool
This fix works for my use case of supplying both '--symfs' and '--vmlinux'
options, and should be harmless if '--symfs' is not specified, but I suspect
it could cause problems if '--symfs' is specified without '--vmlinux', as
the symfs path will no longer be prepended and vmlinux may no longer be
Path passed to libdw for unwinding doesn't include symfs path
if specified, so unwinding fails because ELF file is not found.
Similar to unwinding with libunwind, pass symsrc_filename instead
of long_name. If there is no symsrc_filename, fallback to long_name.
Signed-off-by: Martin Vuille <
Thanks.
I replied to your message with additional information.
I will update the commit message and resubmit the patch.
MV
On 03/09/18 14:29, Arnaldo Carvalho de Melo wrote:
Em Fri, Mar 09, 2018 at 01:49:50PM -0500, Martin Vuille escreveu:
Hi,
I made two other submissions that may also
.
MV
On 03/09/18 14:07, Arnaldo Carvalho de Melo wrote:
Em Sun, Feb 11, 2018 at 02:19:37PM -0500, Martin Vuille escreveu:
build_id_filename already contains symfs path if applicable, so
don't prepend it a second time.
Where is the analysis that shows that that is the case? I looked here
Yes, thought of doing that.
Unfortunately it was sent directly from git, so I do not have a copy of the
message that was sent.
MV
On 03/09/18 14:15, Kim Phillips wrote:
On Fri, 9 Mar 2018 13:49:50 -0500
Martin Vuille <jpm...@aim.com> wrote:
For https://patchwork.kernel.org/patch/10
Hi,
I made two other submissions that may also have been overlooked:
https://patchwork.kernel.org/patch/10211401/ -- This one has the S-o-B
https://patchwork.kernel.org/patch/10211473/ -- RFC, was looking for comments,
has the S-o-B
For https://patchwork.kernel.org/patch/10211483/, I'm not
directory
Signed-off-by: Martin Vuille <jpm...@aim.com>
---
tools/perf/util/annotate.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/perf/util/annotate.c b/tools/perf/util/annotate.c
index 007170efa014..0b78cc4fb155 100644
--- a/tools/perf/util/annotate.c
+++ b/tool
On 03/09/18 13:24, Arnaldo Carvalho de Melo wrote:
- "perf unwind: Report error from dwfl_attach_state"
https://patchwork.kernel.org/patch/10211483/
[Martin, I guess it would help if you replied-all that patch and
added your signed-off-by.]
Right, the S-o-B is needed
S-o-B has
On 03/09/18 14:07, Arnaldo Carvalho de Melo wrote:
Em Sun, Feb 11, 2018 at 02:19:37PM -0500, Martin Vuille escreveu:
build_id_filename already contains symfs path if applicable, so
don't prepend it a second time.
Where is the analysis that shows that that is the case? I looked here
Apologies for any problems my patch may be causing.
I'm unclear on what is the proposed fix, other than reverting the commit.
In the problem scenario, is a --symfs option used? Is the debug info being
obtained from the symfs directory?
Unfortunately, I've had to change my focus for the time
In verbose level 2, errors returned by libdw are reported in most cases,
but not when calling dwfl_attach_state.
Since elfutils v 0.160 (2014), dwfl_attach_state sets the error code to
report failure cause. On failure, log the reported error.
Signed-off-by: Martin Vuille <jpm...@aim.
Ping?
On 03/13/18 09:56, Martin Vuille wrote:
build_id_filename already contains symfs path if applicable, so
don't prepend it a second time.
- dso__build_id_filename calls build_id_cache__linkname
- build_id_cache__linkname uses buildid_dir
- when symfs option is specified
On 04/26/18 04:09, Thomas-Mich Richter wrote:
Martin,
there is no need to revert the patch. I have adopted the test case for s390 and
it
now stops at main, which is identical to x86.
The --symfs option was not used, however the debug file selected for dwarf
examination
was different. With
directory
Signed-off-by: Martin Vuille
---
tools/perf/util/annotate.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/perf/util/annotate.c b/tools/perf/util/annotate.c
index 007170efa014..0b78cc4fb155 100644
--- a/tools/perf/util/annotate.c
+++ b/tools/perf/util/annotate.c
On 03/09/18 13:24, Arnaldo Carvalho de Melo wrote:
- "perf unwind: Report error from dwfl_attach_state"
https://patchwork.kernel.org/patch/10211483/
[Martin, I guess it would help if you replied-all that patch and
added your signed-off-by.]
Right, the S-o-B is needed
S-o-B has
On 03/09/18 14:07, Arnaldo Carvalho de Melo wrote:
Em Sun, Feb 11, 2018 at 02:19:37PM -0500, Martin Vuille escreveu:
build_id_filename already contains symfs path if applicable, so
don't prepend it a second time.
Where is the analysis that shows that that is the case? I looked here
Ping?
On 03/13/18 09:56, Martin Vuille wrote:
build_id_filename already contains symfs path if applicable, so
don't prepend it a second time.
- dso__build_id_filename calls build_id_cache__linkname
- build_id_cache__linkname uses buildid_dir
- when symfs option is specified
Hi,
I made two other submissions that may also have been overlooked:
https://patchwork.kernel.org/patch/10211401/ -- This one has the S-o-B
https://patchwork.kernel.org/patch/10211473/ -- RFC, was looking for comments,
has the S-o-B
For https://patchwork.kernel.org/patch/10211483/, I'm not
Yes, thought of doing that.
Unfortunately it was sent directly from git, so I do not have a copy of the
message that was sent.
MV
On 03/09/18 14:15, Kim Phillips wrote:
On Fri, 9 Mar 2018 13:49:50 -0500
Martin Vuille wrote:
For https://patchwork.kernel.org/patch/10211483/, I'm not sure
.
MV
On 03/09/18 14:07, Arnaldo Carvalho de Melo wrote:
Em Sun, Feb 11, 2018 at 02:19:37PM -0500, Martin Vuille escreveu:
build_id_filename already contains symfs path if applicable, so
don't prepend it a second time.
Where is the analysis that shows that that is the case? I looked here
Thanks.
I replied to your message with additional information.
I will update the commit message and resubmit the patch.
MV
On 03/09/18 14:29, Arnaldo Carvalho de Melo wrote:
Em Fri, Mar 09, 2018 at 01:49:50PM -0500, Martin Vuille escreveu:
Hi,
I made two other submissions that may also
Apologies for any problems my patch may be causing.
I'm unclear on what is the proposed fix, other than reverting the commit.
In the problem scenario, is a --symfs option used? Is the debug info being
obtained from the symfs directory?
Unfortunately, I've had to change my focus for the time
On 04/26/18 04:09, Thomas-Mich Richter wrote:
Martin,
there is no need to revert the patch. I have adopted the test case for s390 and
it
now stops at main, which is identical to x86.
The --symfs option was not used, however the debug file selected for dwarf
examination
was different. With
On 04/26/18 04:09, Thomas-Mich Richter wrote:
was different. With you patch it changed from /usr/lib64/libc.so (old) to
/usr/lib/debug/lib64/libc-2.26.so.debug (new)
Thomas,
Can you tell me what 'file' reports for the old and new files?
Regards,
MV
On 04/27/18 03:55, Thomas-Mich Richter wrote:
On 04/26/2018 05:26 PM, Martin Vuille wrote:
On 04/26/18 04:09, Thomas-Mich Richter wrote:
was different. With you patch it changed from /usr/lib64/libc.so (old) to
/usr/lib/debug/lib64/libc-2.26.so.debug (new)
Thomas,
Can you tell me what
In verbose level 2, errors returned by libdw are reported in most cases,
but not when calling dwfl_attach_state.
Since elfutils v 0.160 (2014), dwfl_attach_state sets the error code to
report failure cause. On failure, log the reported error.
Signed-off-by: Martin Vuille
---
tools/perf/util
build_id_filename already contains symfs path if applicable, so
don't prepend it a second time.
Signed-off-by: Martin Vuille
---
tools/perf/util/annotate.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/perf/util/annotate.c b/tools/perf/util/annotate.c
index
path if DSO is [kernel.kallsyms]
Signed-off-by: Martin Vuille
---
tools/perf/util/annotate.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/tools/perf/util/annotate.c b/tools/perf/util/annotate.c
index 425b7f0760ec..0b78cc4fb155 100644
--- a/tools/perf/util/annotate.c
This fix works for my use case of supplying both '--symfs' and '--vmlinux'
options, and should be harmless if '--symfs' is not specified, but I suspect
it could cause problems if '--symfs' is specified without '--vmlinux', as
the symfs path will no longer be prepended and vmlinux may no longer be
In verbose level 2, errors returned by libdw are reported in most cases,
but not when calling dwfl_attach_state.
Since elfutils v 0.160 (2014), dwfl_attach_state sets the error code to
report failure cause. On failure, log the reported error.
---
tools/perf/util/unwind-libdw.c | 3 ++-
1 file
Path passed to libdw for unwinding doesn't include symfs path
if specified, so unwinding fails because ELF file is not found.
Similar to unwinding with libunwind, pass symsrc_filename instead
of long_name. If there is no symsrc_filename, fallback to long_name.
Signed-off-by: Martin Vuille
Commit-ID: 555fc3b1ef4c850c635be333024dcf67bc1e7cb8
Gitweb: https://git.kernel.org/tip/555fc3b1ef4c850c635be333024dcf67bc1e7cb8
Author: Martin Vuille <jpm...@aim.com>
AuthorDate: Sun, 18 Mar 2018 13:50:53 -0400
Committer: Arnaldo Carvalho de Melo <a...@redhat.com>
CommitDate:
Commit-ID: 3d20c6246690219881786de10d2dda93f616d0ac
Gitweb: https://git.kernel.org/tip/3d20c6246690219881786de10d2dda93f616d0ac
Author: Martin Vuille <jpm...@aim.com>
AuthorDate: Sun, 11 Feb 2018 16:24:20 -0500
Committer: Arnaldo Carvalho de Melo <a...@redhat.com>
CommitDate:
Commit-ID: 555fc3b1ef4c850c635be333024dcf67bc1e7cb8
Gitweb: https://git.kernel.org/tip/555fc3b1ef4c850c635be333024dcf67bc1e7cb8
Author: Martin Vuille
AuthorDate: Sun, 18 Mar 2018 13:50:53 -0400
Committer: Arnaldo Carvalho de Melo
CommitDate: Tue, 20 Mar 2018 13:16:09 -0300
perf unwind
Commit-ID: 3d20c6246690219881786de10d2dda93f616d0ac
Gitweb: https://git.kernel.org/tip/3d20c6246690219881786de10d2dda93f616d0ac
Author: Martin Vuille
AuthorDate: Sun, 11 Feb 2018 16:24:20 -0500
Committer: Arnaldo Carvalho de Melo
CommitDate: Fri, 16 Mar 2018 13:55:51 -0300
perf unwind
40 matches
Mail list logo
