Re: rtems-addr2line not working on ARM?
On 9/9/19 5:12 pm, Sebastian Huber wrote:
> On 09/09/2019 07:31, Sebastian Huber wrote:
>> On 07/09/2019 16:25, Sebastian Huber wrote:
>>> - Am 6. Sep 2019 um 18:06 schrieb Sebastian Huber
>>> sebastian.hu...@embedded-brains.de:
>>>
- Am 6. Sep 2019 um 11:09 schrieb Sebastian Huber
sebastian.hu...@embedded-brains.de:
> On 06/09/2019 09:26, Sebastian Huber wrote:
>> On 06/09/2019 09:01, Chris Johns wrote:
>>> On 6/9/19 4:20 pm, Sebastian Huber wrote:
Hello,
I tried the rtems-addr2line on ARM and SPARC. On SPARC it seems to
work fine,
however, on ARM I get this:
rtems-addr2line -e
build/arm-rtems5-xilinx_zynq_a9_qemu-everything/media01.exe
0x135a
/home/EB/sebastian_h/git-rtems-5/c/src/lib/libbsp/arm/xilinx-zynq/../../../../../../bsps/arm/shared/irq/irq-gic.c:264
addr2line -e
build/arm-rtems5-xilinx_zynq_a9_qemu-everything/media01.exe 135a
/scratch/git-rtems-libbsd/build/arm-rtems5-xilinx_zynq_a9_qemu-everything/../../testsuite/include/rtems/bsd/test/default-network-init.h:179
The GNU tool is right. It is also considerably faster.
>>> I would hope it is faster and exact. It has had many years of work on
>>> it,
>>> written in C and not a means to test a C++ framework so we can grow an
>>> ecosystem. I have stated its purpose before. I am perplexed by the
>>> intent of
>>> this statement.
>>>
>>> If you want to compare performance I suggest you try the elftools one?
>>> There is
>>> one. It is not built because GNU provides one and good one.
>>>
>>> Also be-careful as the exec call is not as fast as Linux on all the
>>> hosts we
>>> support.
>>
>> That the GNU tool is faster was just an observation.
>>
>> Do we have a working library solution to get from an address to the
>> source line/function? I don't have time to debug the DWARF support code
>> at the moment.
>>
>> I have a working solution using "addr2line" and rld::process::execute().
>
> Thanks for the hint to the elftoolchain:
>
> https://github.com/elftoolchain/elftoolchain/blob/trunk/addr2line/addr2line.c
>
> To me it looks pretty complicated. It should be possible to refactor
> this code to use it as a library, e.g. call translate() for each address
> you need the source information.
>
> I tried to debug the rld get_source() problem for more than two hours
> and the elftoolchain code looks similar. I am not sure what to do.
Another option is to use the LLVM infrastructure:
https://github.com/llvm-mirror/llvm/blob/master/tools/llvm-symbolizer/llvm-symbolizer.cpp
From a first glance, this looks like the way to go.
>>>
>>> Attached is a patch which uses the LLVM library to get an addr2line
>>> functionality. The code to resolve an address is very easy (item.data is the
>>> address):
>>>
>>> auto res_or_err = symbolizer_.symbolizeCode(elf_file_, item.data);
>>>
>>> if (res_or_err) {
>>> auto info = res_or_err.get();
>>> std::string fn = info.FunctionName;
>>> std::string str;
>>>
>>> if (fn != "") {
>>> str += fn;
>>> str += " at ";
>>> }
>>>
>>> str += llvm::sys::path::filename(info.FileName);
>>> str += ":";
>>> str += std::to_string(info.Line);
>>>
>>> LLVM has also support for command line arguments, file handling, etc.
>>
>> The LLVM solution is also the fastest so far:
>>
>> time ../build/trace/rtems-record-lttng -e media01.exe records.bin
>>
>> real 0m0.425s
>> user 0m0.293s
>> sys 0m0.132s
>>
>> addr2line based solution on Linux:
>>
>> real 0m11.944s
>> user 0m5.334s
>> sys 0m6.593s
>
> Compiling this on Windows using mingw64 was a bit difficult. I had to install:
>
> mingw-w64-x86_64-llvm
> mingw-w64-x86_64-clang
>
> I used clang to build the tool by hand. I had to remove the use of the POSIX
> open/connect/socket/etc. and replace it with fopen().
>
> The CTF stream files generated on Linux and Windows were identical using LLVM.
>
I think LLVM is a great idea for us moving forward but it has some hurdles we
need to overcome. I like the idea of a maintained code base that is fast and has
working 64bit support, something that is not tested or working in the
rtemstoolkit code.
Does LLVM as used in trace have support for all of the current RTEMS
architectures? If it does not what do we do?
We have been avoiding depending on packages on hosts because of our past
experiences ..
1. getting a stable consistent version across all hosts can be difficult and
with environments like cygwin and msys having a floating head and no release
things age and break which makes long term support harder.
2. A more complicated set up process for users.
Re: rtems-addr2line not working on ARM?
Hello, I checked in the variant using LLVM: https://git.rtems.org/rtems-tools/commit/?id=5d80d0b2e1de9decb24c2d7ef481e4b63525595e I hope that I got the waf configure stuff right to only use LLVM if it is installed. I tested on Linux, msys2 and mingw64. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: rtems-addr2line not working on ARM?
On 09/09/2019 07:31, Sebastian Huber wrote:
On 07/09/2019 16:25, Sebastian Huber wrote:
- Am 6. Sep 2019 um 18:06 schrieb Sebastian Huber
sebastian.hu...@embedded-brains.de:
- Am 6. Sep 2019 um 11:09 schrieb Sebastian Huber
sebastian.hu...@embedded-brains.de:
On 06/09/2019 09:26, Sebastian Huber wrote:
On 06/09/2019 09:01, Chris Johns wrote:
On 6/9/19 4:20 pm, Sebastian Huber wrote:
Hello,
I tried the rtems-addr2line on ARM and SPARC. On SPARC it seems to
work fine,
however, on ARM I get this:
rtems-addr2line -e
build/arm-rtems5-xilinx_zynq_a9_qemu-everything/media01.exe
0x135a
/home/EB/sebastian_h/git-rtems-5/c/src/lib/libbsp/arm/xilinx-zynq/../../../../../../bsps/arm/shared/irq/irq-gic.c:264
addr2line -e
build/arm-rtems5-xilinx_zynq_a9_qemu-everything/media01.exe 135a
/scratch/git-rtems-libbsd/build/arm-rtems5-xilinx_zynq_a9_qemu-everything/../../testsuite/include/rtems/bsd/test/default-network-init.h:179
The GNU tool is right. It is also considerably faster.
I would hope it is faster and exact. It has had many years of work
on it,
written in C and not a means to test a C++ framework so we can
grow an
ecosystem. I have stated its purpose before. I am perplexed by the
intent of
this statement.
If you want to compare performance I suggest you try the elftools
one?
There is
one. It is not built because GNU provides one and good one.
Also be-careful as the exec call is not as fast as Linux on all the
hosts we
support.
That the GNU tool is faster was just an observation.
Do we have a working library solution to get from an address to the
source line/function? I don't have time to debug the DWARF support
code
at the moment.
I have a working solution using "addr2line" and
rld::process::execute().
Thanks for the hint to the elftoolchain:
https://github.com/elftoolchain/elftoolchain/blob/trunk/addr2line/addr2line.c
To me it looks pretty complicated. It should be possible to refactor
this code to use it as a library, e.g. call translate() for each
address
you need the source information.
I tried to debug the rld get_source() problem for more than two hours
and the elftoolchain code looks similar. I am not sure what to do.
Another option is to use the LLVM infrastructure:
https://github.com/llvm-mirror/llvm/blob/master/tools/llvm-symbolizer/llvm-symbolizer.cpp
From a first glance, this looks like the way to go.
Attached is a patch which uses the LLVM library to get an addr2line
functionality. The code to resolve an address is very easy (item.data
is the address):
auto res_or_err = symbolizer_.symbolizeCode(elf_file_, item.data);
if (res_or_err) {
auto info = res_or_err.get();
std::string fn = info.FunctionName;
std::string str;
if (fn != "") {
str += fn;
str += " at ";
}
str += llvm::sys::path::filename(info.FileName);
str += ":";
str += std::to_string(info.Line);
LLVM has also support for command line arguments, file handling, etc.
The LLVM solution is also the fastest so far:
time ../build/trace/rtems-record-lttng -e media01.exe records.bin
real 0m0.425s
user 0m0.293s
sys 0m0.132s
addr2line based solution on Linux:
real 0m11.944s
user 0m5.334s
sys 0m6.593s
Compiling this on Windows using mingw64 was a bit difficult. I had to
install:
mingw-w64-x86_64-llvm
mingw-w64-x86_64-clang
I used clang to build the tool by hand. I had to remove the use of the
POSIX open/connect/socket/etc. and replace it with fopen().
The CTF stream files generated on Linux and Windows were identical using
LLVM.
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: rtems-addr2line not working on ARM?
On 07/09/2019 16:25, Sebastian Huber wrote:
- Am 6. Sep 2019 um 18:06 schrieb Sebastian Huber
sebastian.hu...@embedded-brains.de:
- Am 6. Sep 2019 um 11:09 schrieb Sebastian Huber
sebastian.hu...@embedded-brains.de:
On 06/09/2019 09:26, Sebastian Huber wrote:
On 06/09/2019 09:01, Chris Johns wrote:
On 6/9/19 4:20 pm, Sebastian Huber wrote:
Hello,
I tried the rtems-addr2line on ARM and SPARC. On SPARC it seems to
work fine,
however, on ARM I get this:
rtems-addr2line -e
build/arm-rtems5-xilinx_zynq_a9_qemu-everything/media01.exe
0x135a
/home/EB/sebastian_h/git-rtems-5/c/src/lib/libbsp/arm/xilinx-zynq/../../../../../../bsps/arm/shared/irq/irq-gic.c:264
addr2line -e
build/arm-rtems5-xilinx_zynq_a9_qemu-everything/media01.exe 135a
/scratch/git-rtems-libbsd/build/arm-rtems5-xilinx_zynq_a9_qemu-everything/../../testsuite/include/rtems/bsd/test/default-network-init.h:179
The GNU tool is right. It is also considerably faster.
I would hope it is faster and exact. It has had many years of work on it,
written in C and not a means to test a C++ framework so we can grow an
ecosystem. I have stated its purpose before. I am perplexed by the
intent of
this statement.
If you want to compare performance I suggest you try the elftools one?
There is
one. It is not built because GNU provides one and good one.
Also be-careful as the exec call is not as fast as Linux on all the
hosts we
support.
That the GNU tool is faster was just an observation.
Do we have a working library solution to get from an address to the
source line/function? I don't have time to debug the DWARF support code
at the moment.
I have a working solution using "addr2line" and rld::process::execute().
Thanks for the hint to the elftoolchain:
https://github.com/elftoolchain/elftoolchain/blob/trunk/addr2line/addr2line.c
To me it looks pretty complicated. It should be possible to refactor
this code to use it as a library, e.g. call translate() for each address
you need the source information.
I tried to debug the rld get_source() problem for more than two hours
and the elftoolchain code looks similar. I am not sure what to do.
Another option is to use the LLVM infrastructure:
https://github.com/llvm-mirror/llvm/blob/master/tools/llvm-symbolizer/llvm-symbolizer.cpp
From a first glance, this looks like the way to go.
Attached is a patch which uses the LLVM library to get an addr2line
functionality. The code to resolve an address is very easy (item.data is the
address):
auto res_or_err = symbolizer_.symbolizeCode(elf_file_, item.data);
if (res_or_err) {
auto info = res_or_err.get();
std::string fn = info.FunctionName;
std::string str;
if (fn != "") {
str += fn;
str += " at ";
}
str += llvm::sys::path::filename(info.FileName);
str += ":";
str += std::to_string(info.Line);
LLVM has also support for command line arguments, file handling, etc.
The LLVM solution is also the fastest so far:
time ../build/trace/rtems-record-lttng -e media01.exe records.bin
real0m0.425s
user0m0.293s
sys 0m0.132s
addr2line based solution on Linux:
real0m11.944s
user0m5.334s
sys 0m6.593s
LLVM has also an API to access the DWARF debug information:
https://github.com/llvm-mirror/llvm/blob/master/tools/llvm-dwarfdump/llvm-dwarfdump.cpp
llvm-dwarfdump media.exe | grep '\<_Workspace_Allocate\>' -B 10 -A 40
0x0163bea5: DW_TAG_subprogram
DW_AT_external (true)
DW_AT_name ("_Workspace_Allocate")
DW_AT_decl_file ("wkspace.c")
DW_AT_decl_line (232)
DW_AT_prototyped(true)
DW_AT_type (0x016388fd "*")
DW_AT_low_pc(0x00746092)
DW_AT_high_pc (0x007460b4)
DW_AT_frame_base(DW_OP_call_frame_cfa)
DW_AT_unknown_2116 (true)
DW_AT_sibling (0x0163bedb)
0x0163bebe: DW_TAG_formal_parameter
DW_AT_name("size")
DW_AT_decl_file ("wkspace.c")
DW_AT_decl_line (233)
DW_AT_type(0x01638817 "size_t")
DW_AT_location(DW_OP_fbreg -20)
This could be used to generate wrapper functions and generic record
function entry/exit consumers.
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: rtems-addr2line not working on ARM?
- Am 6. Sep 2019 um 18:06 schrieb Sebastian Huber
sebastian.hu...@embedded-brains.de:
> - Am 6. Sep 2019 um 11:09 schrieb Sebastian Huber
> sebastian.hu...@embedded-brains.de:
>
>> On 06/09/2019 09:26, Sebastian Huber wrote:
>>> On 06/09/2019 09:01, Chris Johns wrote:
On 6/9/19 4:20 pm, Sebastian Huber wrote:
> Hello,
>
> I tried the rtems-addr2line on ARM and SPARC. On SPARC it seems to
> work fine,
> however, on ARM I get this:
>
> rtems-addr2line -e
> build/arm-rtems5-xilinx_zynq_a9_qemu-everything/media01.exe
> 0x135a
> /home/EB/sebastian_h/git-rtems-5/c/src/lib/libbsp/arm/xilinx-zynq/../../../../../../bsps/arm/shared/irq/irq-gic.c:264
>
>
>
> addr2line -e
> build/arm-rtems5-xilinx_zynq_a9_qemu-everything/media01.exe 135a
> /scratch/git-rtems-libbsd/build/arm-rtems5-xilinx_zynq_a9_qemu-everything/../../testsuite/include/rtems/bsd/test/default-network-init.h:179
>
>
>
> The GNU tool is right. It is also considerably faster.
I would hope it is faster and exact. It has had many years of work on it,
written in C and not a means to test a C++ framework so we can grow an
ecosystem. I have stated its purpose before. I am perplexed by the
intent of
this statement.
If you want to compare performance I suggest you try the elftools one?
There is
one. It is not built because GNU provides one and good one.
Also be-careful as the exec call is not as fast as Linux on all the
hosts we
support.
>>>
>>> That the GNU tool is faster was just an observation.
>>>
>>> Do we have a working library solution to get from an address to the
>>> source line/function? I don't have time to debug the DWARF support code
>>> at the moment.
>>>
>>> I have a working solution using "addr2line" and rld::process::execute().
>>
>> Thanks for the hint to the elftoolchain:
>>
>> https://github.com/elftoolchain/elftoolchain/blob/trunk/addr2line/addr2line.c
>>
>> To me it looks pretty complicated. It should be possible to refactor
>> this code to use it as a library, e.g. call translate() for each address
>> you need the source information.
>>
>> I tried to debug the rld get_source() problem for more than two hours
>> and the elftoolchain code looks similar. I am not sure what to do.
>
> Another option is to use the LLVM infrastructure:
>
> https://github.com/llvm-mirror/llvm/blob/master/tools/llvm-symbolizer/llvm-symbolizer.cpp
>
> From a first glance, this looks like the way to go.
Attached is a patch which uses the LLVM library to get an addr2line
functionality. The code to resolve an address is very easy (item.data is the
address):
auto res_or_err = symbolizer_.symbolizeCode(elf_file_, item.data);
if (res_or_err) {
auto info = res_or_err.get();
std::string fn = info.FunctionName;
std::string str;
if (fn != "") {
str += fn;
str += " at ";
}
str += llvm::sys::path::filename(info.FileName);
str += ":";
str += std::to_string(info.Line);
LLVM has also support for command line arguments, file handling, etc.From 3245f52d5f1cf8496daf53acc921e8b7594b375c Mon Sep 17 00:00:00 2001
From: Sebastian Huber
Date: Fri, 6 Sep 2019 09:29:12 +0200
Subject: [PATCH] record: Use LLVM to link to the source code
Update #3665.
---
trace/record/record-main-lttng.cc | 213 ++
trace/wscript | 7 +-
2 files changed, 175 insertions(+), 45 deletions(-)
diff --git a/trace/record/record-main-lttng.cc b/trace/record/record-main-lttng.cc
index dda57ef..d921143 100644
--- a/trace/record/record-main-lttng.cc
+++ b/trace/record/record-main-lttng.cc
@@ -31,9 +31,16 @@
#include
#include
+#include
#include
#include
#include
+#include
+#include
+#include
+
+#include
+#include
#define CTF_MAGIC 0xC1FC1FC1
#define TASK_RUNNING 0x
@@ -83,6 +90,9 @@ struct EventHeaderCompact {
uint64_t ns;
} __attribute__((__packed__));
+static const size_t kEventHeaderBits =
+sizeof(EventHeaderCompact) * BITS_PER_CHAR;
+
struct EventRecordItem {
EventHeaderCompact header;
uint64_t data;
@@ -160,6 +170,8 @@ class LTTNGClient : public Client {
}
}
+ void OpenDebug(const char* elf_file);
+
void Destroy() {
Client::Destroy();
CloseStreamFiles();
@@ -180,6 +192,16 @@ class LTTNGClient : public Client {
size_t cpu_count_ = 0;
+ llvm::symbolize::LLVMSymbolizer symbolizer_;
+
+ std::string elf_file_;
+
+ bool resolve_address_ = false;
+
+ typedef std::map> AddressToLineMap;
+
+ AddressToLineMap address_to_line_;
+
static rtems_record_client_status HandlerCaller(uint64_t bt,
uint32_t cpu,
rtems_record_event event,
@@ -213,6 +235,10 @@ class LTTNGClient : public Client {
void OpenStreamFiles(uint64_t data);
Re: rtems-addr2line not working on ARM?
- Am 6. Sep 2019 um 11:09 schrieb Sebastian Huber sebastian.hu...@embedded-brains.de: > On 06/09/2019 09:26, Sebastian Huber wrote: >> On 06/09/2019 09:01, Chris Johns wrote: >>> On 6/9/19 4:20 pm, Sebastian Huber wrote: Hello, I tried the rtems-addr2line on ARM and SPARC. On SPARC it seems to work fine, however, on ARM I get this: rtems-addr2line -e build/arm-rtems5-xilinx_zynq_a9_qemu-everything/media01.exe 0x135a /home/EB/sebastian_h/git-rtems-5/c/src/lib/libbsp/arm/xilinx-zynq/../../../../../../bsps/arm/shared/irq/irq-gic.c:264 addr2line -e build/arm-rtems5-xilinx_zynq_a9_qemu-everything/media01.exe 135a /scratch/git-rtems-libbsd/build/arm-rtems5-xilinx_zynq_a9_qemu-everything/../../testsuite/include/rtems/bsd/test/default-network-init.h:179 The GNU tool is right. It is also considerably faster. >>> I would hope it is faster and exact. It has had many years of work on it, >>> written in C and not a means to test a C++ framework so we can grow an >>> ecosystem. I have stated its purpose before. I am perplexed by the >>> intent of >>> this statement. >>> >>> If you want to compare performance I suggest you try the elftools one? >>> There is >>> one. It is not built because GNU provides one and good one. >>> >>> Also be-careful as the exec call is not as fast as Linux on all the >>> hosts we >>> support. >> >> That the GNU tool is faster was just an observation. >> >> Do we have a working library solution to get from an address to the >> source line/function? I don't have time to debug the DWARF support code >> at the moment. >> >> I have a working solution using "addr2line" and rld::process::execute(). > > Thanks for the hint to the elftoolchain: > > https://github.com/elftoolchain/elftoolchain/blob/trunk/addr2line/addr2line.c > > To me it looks pretty complicated. It should be possible to refactor > this code to use it as a library, e.g. call translate() for each address > you need the source information. > > I tried to debug the rld get_source() problem for more than two hours > and the elftoolchain code looks similar. I am not sure what to do. Another option is to use the LLVM infrastructure: https://github.com/llvm-mirror/llvm/blob/master/tools/llvm-symbolizer/llvm-symbolizer.cpp >From a first glance, this looks like the way to go. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: rtems-addr2line not working on ARM?
On 06/09/2019 09:26, Sebastian Huber wrote: On 06/09/2019 09:01, Chris Johns wrote: On 6/9/19 4:20 pm, Sebastian Huber wrote: Hello, I tried the rtems-addr2line on ARM and SPARC. On SPARC it seems to work fine, however, on ARM I get this: rtems-addr2line -e build/arm-rtems5-xilinx_zynq_a9_qemu-everything/media01.exe 0x135a /home/EB/sebastian_h/git-rtems-5/c/src/lib/libbsp/arm/xilinx-zynq/../../../../../../bsps/arm/shared/irq/irq-gic.c:264 addr2line -e build/arm-rtems5-xilinx_zynq_a9_qemu-everything/media01.exe 135a /scratch/git-rtems-libbsd/build/arm-rtems5-xilinx_zynq_a9_qemu-everything/../../testsuite/include/rtems/bsd/test/default-network-init.h:179 The GNU tool is right. It is also considerably faster. I would hope it is faster and exact. It has had many years of work on it, written in C and not a means to test a C++ framework so we can grow an ecosystem. I have stated its purpose before. I am perplexed by the intent of this statement. If you want to compare performance I suggest you try the elftools one? There is one. It is not built because GNU provides one and good one. Also be-careful as the exec call is not as fast as Linux on all the hosts we support. That the GNU tool is faster was just an observation. Do we have a working library solution to get from an address to the source line/function? I don't have time to debug the DWARF support code at the moment. I have a working solution using "addr2line" and rld::process::execute(). Thanks for the hint to the elftoolchain: https://github.com/elftoolchain/elftoolchain/blob/trunk/addr2line/addr2line.c To me it looks pretty complicated. It should be possible to refactor this code to use it as a library, e.g. call translate() for each address you need the source information. I tried to debug the rld get_source() problem for more than two hours and the elftoolchain code looks similar. I am not sure what to do. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: rtems-addr2line not working on ARM?
On 06/09/2019 09:01, Chris Johns wrote: On 6/9/19 4:20 pm, Sebastian Huber wrote: Hello, I tried the rtems-addr2line on ARM and SPARC. On SPARC it seems to work fine, however, on ARM I get this: rtems-addr2line -e build/arm-rtems5-xilinx_zynq_a9_qemu-everything/media01.exe 0x135a /home/EB/sebastian_h/git-rtems-5/c/src/lib/libbsp/arm/xilinx-zynq/../../../../../../bsps/arm/shared/irq/irq-gic.c:264 addr2line -e build/arm-rtems5-xilinx_zynq_a9_qemu-everything/media01.exe 135a /scratch/git-rtems-libbsd/build/arm-rtems5-xilinx_zynq_a9_qemu-everything/../../testsuite/include/rtems/bsd/test/default-network-init.h:179 The GNU tool is right. It is also considerably faster. I would hope it is faster and exact. It has had many years of work on it, written in C and not a means to test a C++ framework so we can grow an ecosystem. I have stated its purpose before. I am perplexed by the intent of this statement. If you want to compare performance I suggest you try the elftools one? There is one. It is not built because GNU provides one and good one. Also be-careful as the exec call is not as fast as Linux on all the hosts we support. That the GNU tool is faster was just an observation. Do we have a working library solution to get from an address to the source line/function? I don't have time to debug the DWARF support code at the moment. I have a working solution using "addr2line" and rld::process::execute(). I know you don't like to use boost, but it has also a process support library: https://www.boost.org/doc/libs/1_71_0/doc/html/process.html -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: rtems-addr2line not working on ARM?
On 6/9/19 4:20 pm, Sebastian Huber wrote:
> Hello,
>
> I tried the rtems-addr2line on ARM and SPARC. On SPARC it seems to work fine,
> however, on ARM I get this:
>
> rtems-addr2line -e build/arm-rtems5-xilinx_zynq_a9_qemu-everything/media01.exe
> 0x135a
> /home/EB/sebastian_h/git-rtems-5/c/src/lib/libbsp/arm/xilinx-zynq/../../../../../../bsps/arm/shared/irq/irq-gic.c:264
>
>
> addr2line -e build/arm-rtems5-xilinx_zynq_a9_qemu-everything/media01.exe
> 135a
> /scratch/git-rtems-libbsd/build/arm-rtems5-xilinx_zynq_a9_qemu-everything/../../testsuite/include/rtems/bsd/test/default-network-init.h:179
>
>
> The GNU tool is right. It is also considerably faster.
I would hope it is faster and exact. It has had many years of work on it,
written in C and not a means to test a C++ framework so we can grow an
ecosystem. I have stated its purpose before. I am perplexed by the intent of
this statement.
If you want to compare performance I suggest you try the elftools one? There is
one. It is not built because GNU provides one and good one.
Also be-careful as the exec call is not as fast as Linux on all the hosts we
support.
> The mapping to the function (-f option) get both tools right.
Sorry I do not understand this sentence.
> I don't understand the logic here:
>
> bool
> file::get_source (const unsigned int addr,
> std::string& source_file,
> int& source_line)
> {
> [...]
> address match;
>
> for (auto& cu : cus)
> {
> address line;
> r = cu.get_source (addr, line);
> if (r)
> {
>
> <-- Why is there a "match = line" in both cases?
>
Looks like a bug and related to the comment not posted but present in the code
...
/*
* Search the CU's collecting the addresses. An address can appear in
* more than one CU. It may be the last address and the first.
*/
> if (match.valid () &&
> (match.is_an_end_sequence () || !!line.is_an_end_sequence ()))
> {
> match = line;
> }
> else
> {
I think this is suppose to happen if match is not valid ...
> match = line;
Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
