Re: Symbol Size Variance

[Chris Johns]

On 23/5/18 11:06 am, Joel Sherrill wrote:
> On Tue, May 22, 2018 at 5:45 PM, Chris Johns  > wrote:
> On 22/5/18 11:14 pm, Joel Sherrill wrote:
> > On Mon, May 21, 2018, 7:44 PM Chris Johns  
> > >> wrote:
> >     On 22/5/18 9:12 am, Joel Sherrill wrote:
> >     >
> >     > Attached is a shell script (pokes Chris) which calculates the 
> size of 
> >     > the specified symbol across a set of .exe files. 
> >     >
> >     > [joel@rtbf64c samples]$ /tmp/cmp_sizes -a sparc -s
> >     > _Workspace_Allocate_or_fatal_error *.exe
> >     > Size report for _Workspace_Allocate_or_fatal_error
> >     >          base_sp.exe - 0x4000c5a0 - 0x4000c5e0 (64)
> >     >          capture.exe - 0x400162a0 - 0x400162dc (60)
> >     >           cdtest.exe - 0x4001e6c4 - 0x4001e700 (60)
> >     >     cxx_iostream.exe - 0x4005cbdc - 0x4005cc20 (68)
> >     >           fileio.exe - 0x40020720 - 0x4002075c (60)
> >     >            hello.exe - 0x4000ac50 - 0x4000aca0 (80)
> >     >          minimum.exe - 0x40006240 - 0x40006280 (64)
> >     >            nsecs.exe - 0x4000c668 - 0x4000c6c0 (88)
> >     >         paranoia.exe - 0x4001426c - 0x400142c0 (84)
> >     >           ticker.exe - 0x4000d328 - 0x4000d380 (88)
> >     >        unlimited.exe - 0x4000cc0c - 0x4000cc60 (84)
> >     >
> >     > NOTE: Each SPARC instruction is ALWAYS 4 bytes. That will be
> >     > important as we look at instruction addresses.
> >     >
> >     > I objdump'ed (sparc-rtems5-objdump -S) each exe as I got to it in
> >     > the analysis. ( sparc-rtems5-objdump -S XXX.exe >XXX.dmp)
> >
> >     The following is not something for the GSoC tasks and I report them
> here and now
> >     so we can keep them in mind.
> >
> >     Binutils' objdump like addr2line uses the DWARF information held in
> the ELF
> >     file. My close inspection of the DWARF data in the exe files we are
> creating
> >     leave me with some concerns.
> >
> > These are important to look into but should almost certainly not have 
> anything
> > to do with the bugs I described.
> 
> Sure this is probability correct but you or I cannot prove this. What 
> concerns
> me most is objdump says nothing so it is natural for us to consider what 
> it
> presents as accurate when it may not be, it may be an approximation. For a
> command line tool to investigate an ELF file this would seem reasonable 
> because
> the user is after some detail however this is not the case in our use.
> 
> Agreed. 
> 
> In this case, I think objdump just changed its format though when presented
> with >1 NOP at the end of a method for padding. Unfortunately, it doesn't
> do it for just 1 and the instruction we saw is not known in covaor as a 
> padding pattern from ld. Those are well-defined.
> 
> The output you are parsing is derived from the DWARF info and that needs 
> to be
> correct but I am suspicious it is not. For example the line details for 
> mutex.c
> in the hello.exe Cillian sent me is clearly wrong, the line program's 
> location
> opcode sets the address to 0x0 while mutex.c in cdtest.exe I built 
> locally is
> correctly setting the address. This points to the linker.
> 
> 
> I have never seen this but believe you. 
>

I believe this is a bug of some form in the linker where unused sections of code
in a CU are being remove but some of the debug info is being left and this
results in the address fields of that info not being updated after relocation
because there is no address in the .text section to map too.

I have coded around this for now. I think what I have is OK but it is hard to 
say.

> 
> You are attempting to correlate function lengths that do not match across
> different executable files looking for a pattern to match against and all 
> I am
> saying is there may not be one you can find because of a bug elsewhere. 
> As a
> result this issue will appear over and over and frustrate you.
> 
> I am hoping that the DWARF info contains the true length and eventually
> we can flag when the computed and claimed length don't match.

I have only been looking at the line info and with that you can see the
continuous address range the CU spans. The DWARF CU attributes of pc_low and
pc_high is not consistently present. With line information I can determine the
starting address of the highest line of code present but not the end.

> 
> NOTE: Unless we incorporate objdump capability somehow, we will
> be stuck with this part of the process.
>

Which capabilities are you referring too?

> 
> 
> There is also this recent thread on gcc's list:
> 
> https://gcc.gnu.org/ml/gcc/2018-05/msg00083.html
> 
> 
> which discusses i

Re: [GSOC] Error in trace buffer generation

[Chris Johns]

On 23/5/18 6:24 pm, Sebastian Huber wrote:
> On 23/05/18 08:19, Vidushi Vashishth wrote:
>> >>Who created this fileio-trace.ini?
>> The fileio-trace.ini file was a sample I downloaded from here :
>> https://devel.rtems.org/attachment/wiki/Developer/Tracing/Trace_Buffering/fileio-trace.ini
>>
>> I made the necessary rtems path and rtems-bsp changes according to my 
>> machine.
>>
> 
> This is exactly why I would like to have all the tracing documentation in the
> user manual under version control.

Agreed. Do we clear the wiki pages once committed with a link the user
documentation? It maybe linked and archived somewhere.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [GSOC] Error in trace buffer generation

[Joel Sherrill]

On Wed, May 23, 2018 at 3:36 AM, Chris Johns  wrote:

> On 23/5/18 6:24 pm, Sebastian Huber wrote:
> > On 23/05/18 08:19, Vidushi Vashishth wrote:
> >> >>Who created this fileio-trace.ini?
> >> The fileio-trace.ini file was a sample I downloaded from here :
> >> https://devel.rtems.org/attachment/wiki/Developer/
> Tracing/Trace_Buffering/fileio-trace.ini
> >>
> >> I made the necessary rtems path and rtems-bsp changes according to my
> machine.
> >>
> >
> > This is exactly why I would like to have all the tracing documentation
> in the
> > user manual under version control.
>
> Agreed. Do we clear the wiki pages once committed with a link the user
> documentation? It maybe linked and archived somewhere.
>

This sounds reasonable. We will have the same issue as we begin to populate
the RTEMS Software Engineering Handbook to help address verification
requirements. Content will move from the wiki,.etc. to a real manual.

We can fix links we own but perhaps a place holder with a redirect or
a message and link is a good idea.

We need to think this through since moving to Trac we broke a lot
of links and IMO didn't do a good job of redirects.

--joel


>
> Chris
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

gcov compiler and gcov options

[Joel Sherrill]

Hi

I created a simple native example to see what options work for gcov
and sub-expressions. Hopefully I got the simple method and
test main right.

"make clean all" will compile, execute, and run gcov.

Edit the Makefile to change arguments.

Edit program.c to change test cases.

Three test cases for 100% coverage. Comment some out to
see the impact.

Hopefully we can see what we need to do or the limits.

--joel


coverage-test.tar.bz2
Description: Binary data
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [GSOC] Weekly report

[Vidushi Vashishth]

Hey!

I did take note of some. I think it should not take too much time to
document these. I will surely do this after I am done with running my CTF
conversion formula on the linux system.

Best,
Vidushi

On Tue, May 22, 2018 at 3:23 PM, Chris Johns  wrote:

> On 22/5/18 1:48 am, Vidushi Vashishth wrote:
> >
> > I was facing a lot of problems trying to get everything running on MacOS.
> > Babeltrace in particular had a lot of dependencies and it became
> exceedingly
> > difficult to build it.
>
> Are you able to document the dependencies you found? A post to this list is
> fine. It would be nice to not to have start that work again.
>
> Chris
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

APA Scheduler Documentation Missing?

[Joel Sherrill]

Hi

Looking at the list of schedulers available in confdefs.h based on the
following comment block:

*  - CONFIGURE_SCHEDULER_PRIORITY - Deterministic Priority Scheduler
 *  - CONFIGURE_SCHEDULER_PRIORITY_SMP - Deterministic Priority SMP
Scheduler
 *  - CONFIGURE_SCHEDULER_PRIORITY_AFFINITY_SMP - Deterministic
 *Priority SMP Affinity Scheduler
 *  - CONFIGURE_SCHEDULER_STRONG_APA - Strong APA Scheduler
 *  - CONFIGURE_SCHEDULER_SIMPLE - Light-weight Priority Scheduler
 *  - CONFIGURE_SCHEDULER_SIMPLE_SMP - Simple SMP Priority Scheduler
 *  - CONFIGURE_SCHEDULER_EDF - EDF Scheduler
 *  - CONFIGURE_SCHEDULER_EDF_SMP - EDF SMP Scheduler
 *  - CONFIGURE_SCHEDULER_CBS - CBS Scheduler
 *  - CONFIGURE_SCHEDULER_USER  - user provided scheduler
 *

I don't think Strong APA is documented in configuring a system or
scheduler concepts. Arbitrary Priority is used as the name.

I suspect most of the information is here but there is some naming
inconsistency and APA as an acronym or the configure_xxx constant
is not documented.

--joel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: APA Scheduler Documentation Missing?

[Gedare Bloom]

I don't think it is fully functional, but maybe I'm mistaken.

On Wed, May 23, 2018 at 11:43 AM, Joel Sherrill  wrote:
> Hi
>
> Looking at the list of schedulers available in confdefs.h based on the
> following comment block:
>
> *  - CONFIGURE_SCHEDULER_PRIORITY - Deterministic Priority Scheduler
>  *  - CONFIGURE_SCHEDULER_PRIORITY_SMP - Deterministic Priority SMP
> Scheduler
>  *  - CONFIGURE_SCHEDULER_PRIORITY_AFFINITY_SMP - Deterministic
>  *Priority SMP Affinity Scheduler
>  *  - CONFIGURE_SCHEDULER_STRONG_APA - Strong APA Scheduler
>  *  - CONFIGURE_SCHEDULER_SIMPLE - Light-weight Priority Scheduler
>  *  - CONFIGURE_SCHEDULER_SIMPLE_SMP - Simple SMP Priority Scheduler
>  *  - CONFIGURE_SCHEDULER_EDF - EDF Scheduler
>  *  - CONFIGURE_SCHEDULER_EDF_SMP - EDF SMP Scheduler
>  *  - CONFIGURE_SCHEDULER_CBS - CBS Scheduler
>  *  - CONFIGURE_SCHEDULER_USER  - user provided scheduler
>  *
>
> I don't think Strong APA is documented in configuring a system or
> scheduler concepts. Arbitrary Priority is used as the name.
>
> I suspect most of the information is here but there is some naming
> inconsistency and APA as an acronym or the configure_xxx constant
> is not documented.
>
> --joel
>
>
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: APA Scheduler Documentation Missing?

[Joel Sherrill]

I think it is an update/rename of the SMP Deterministic Priority Scheduler
with Affinity.

For sure, the list of CONFIGURE_SCHEDULER_xxx constants in confdefs.h
does not match the list documented in Configuring a System or the list
of schedulers in Scheduling Concepts.

Sebastian should know the "truth" and be able to adjust the docs to match.

--joel

On Wed, May 23, 2018 at 2:23 PM, Gedare Bloom  wrote:

> I don't think it is fully functional, but maybe I'm mistaken.
>
> On Wed, May 23, 2018 at 11:43 AM, Joel Sherrill  wrote:
> > Hi
> >
> > Looking at the list of schedulers available in confdefs.h based on the
> > following comment block:
> >
> > *  - CONFIGURE_SCHEDULER_PRIORITY - Deterministic Priority Scheduler
> >  *  - CONFIGURE_SCHEDULER_PRIORITY_SMP - Deterministic Priority SMP
> > Scheduler
> >  *  - CONFIGURE_SCHEDULER_PRIORITY_AFFINITY_SMP - Deterministic
> >  *Priority SMP Affinity Scheduler
> >  *  - CONFIGURE_SCHEDULER_STRONG_APA - Strong APA Scheduler
> >  *  - CONFIGURE_SCHEDULER_SIMPLE - Light-weight Priority Scheduler
> >  *  - CONFIGURE_SCHEDULER_SIMPLE_SMP - Simple SMP Priority Scheduler
> >  *  - CONFIGURE_SCHEDULER_EDF - EDF Scheduler
> >  *  - CONFIGURE_SCHEDULER_EDF_SMP - EDF SMP Scheduler
> >  *  - CONFIGURE_SCHEDULER_CBS - CBS Scheduler
> >  *  - CONFIGURE_SCHEDULER_USER  - user provided scheduler
> >  *
> >
> > I don't think Strong APA is documented in configuring a system or
> > scheduler concepts. Arbitrary Priority is used as the name.
> >
> > I suspect most of the information is here but there is some naming
> > inconsistency and APA as an acronym or the configure_xxx constant
> > is not documented.
> >
> > --joel
> >
> >
> >
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH 2/2] covoar/Target_sparc.cc: Add unimpl as nop

[Joel Sherrill]

---
 tester/covoar/Target_sparc.cc | 4 
 1 file changed, 4 insertions(+)

diff --git a/tester/covoar/Target_sparc.cc b/tester/covoar/Target_sparc.cc
index 0e4ab2e..deeafef 100644
--- a/tester/covoar/Target_sparc.cc
+++ b/tester/covoar/Target_sparc.cc
@@ -64,6 +64,10 @@ namespace Target {
   size = 4;
   return true;
 }
+if (!strcmp( &line[strlen(line)-6], "unimpl")) {
+  size = 4;
+  return true;
+}
 
 if (!strcmp( &line[strlen(line)-7], "unknown")) {
   size = 4; 
-- 
1.8.3.1

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH 1/2] covoar/ObjdumpProcessor.cc: Add processing for ... padding notation w/hack

[Joel Sherrill]

---
 tester/covoar/ObjdumpProcessor.cc | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/tester/covoar/ObjdumpProcessor.cc 
b/tester/covoar/ObjdumpProcessor.cc
index d41906c..183722b 100644
--- a/tester/covoar/ObjdumpProcessor.cc
+++ b/tester/covoar/ObjdumpProcessor.cc
@@ -384,6 +384,28 @@ namespace Coverage {
 break;
   }
 
+  // This string indicates a block of padding at the end of a method
+  if (!strncmp(line.c_str(), "\t...", 4)) {
+// If we are currently processing a symbol, finalize it.
+if (processSymbol) {
+  endAddress = executableInformation->getLoadAddress() + offset - 1;
+  endAddress += 4; // XXX SPARC TMP HACK
+  finalizeSymbol(
+executableInformation,
+currentSymbol,
+startAddress,
+endAddress,
+theInstructions
+  );
+  // Clear out processing of this symbol.
+  startAddress = 0;
+  currentSymbol = "";
+  processSymbol = false;
+  theInstructions.clear();
+}
+continue;
+  }
+
   lineInfo.line  = line;
   lineInfo.address   = 0x;
   lineInfo.isInstruction = false;
-- 
1.8.3.1

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 1/2] covoar/ObjdumpProcessor.cc: Add processing for ... padding notation w/hack

[Chris Johns]

On 24/5/18 12:07 pm, Joel Sherrill wrote:
> ---
>  tester/covoar/ObjdumpProcessor.cc | 22 ++
>  1 file changed, 22 insertions(+)
> 
> diff --git a/tester/covoar/ObjdumpProcessor.cc 
> b/tester/covoar/ObjdumpProcessor.cc
> index d41906c..183722b 100644
> --- a/tester/covoar/ObjdumpProcessor.cc
> +++ b/tester/covoar/ObjdumpProcessor.cc
> @@ -384,6 +384,28 @@ namespace Coverage {
>  break;
>}
>  
> +  // This string indicates a block of padding at the end of a method
> +  if (!strncmp(line.c_str(), "\t...", 4)) {

You have an std::string so why no use C++ rather than resorting to C?

For example http://en.cppreference.com/w/cpp/string/basic_string/compare.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 2/2] covoar/Target_sparc.cc: Add unimpl as nop

[Chris Johns]

On 24/5/18 12:07 pm, Joel Sherrill wrote:
> ---
>  tester/covoar/Target_sparc.cc | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/tester/covoar/Target_sparc.cc b/tester/covoar/Target_sparc.cc
> index 0e4ab2e..deeafef 100644
> --- a/tester/covoar/Target_sparc.cc
> +++ b/tester/covoar/Target_sparc.cc
> @@ -64,6 +64,10 @@ namespace Target {
>size = 4;
>return true;
>  }
> +if (!strcmp( &line[strlen(line)-6], "unimpl")) {

I have not looked at the code around this for C++.

Also these calls should be "::strcmp()".

Chris

> +  size = 4;
> +  return true;
> +}
>  
>  if (!strcmp( &line[strlen(line)-7], "unknown")) {
>size = 4; 
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 1/2] covoar/ObjdumpProcessor.cc: Add processing for ... padding notation w/hack

[Joel Sherrill]

On Wed, May 23, 2018, 9:59 PM Chris Johns  wrote:

> On 24/5/18 12:07 pm, Joel Sherrill wrote:
> > ---
> >  tester/covoar/ObjdumpProcessor.cc | 22 ++
> >  1 file changed, 22 insertions(+)
> >
> > diff --git a/tester/covoar/ObjdumpProcessor.cc
> b/tester/covoar/ObjdumpProcessor.cc
> > index d41906c..183722b 100644
> > --- a/tester/covoar/ObjdumpProcessor.cc
> > +++ b/tester/covoar/ObjdumpProcessor.cc
> > @@ -384,6 +384,28 @@ namespace Coverage {
> >  break;
> >}
> >
> > +  // This string indicates a block of padding at the end of a method
> > +  if (!strncmp(line.c_str(), "\t...", 4)) {
>
> You have an std::string so why no use C++ rather than resorting to C?
>
> For example http://en.cppreference.com/w/cpp/string/basic_string/compare.
>

I was in a hurry and had trouble getting this logic to trip at all. I still
fix this. It does need to be like strncmp.

The +4 is awful though

>
> Chris
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 2/2] covoar/Target_sparc.cc: Add unimpl as nop

[Joel Sherrill]

On Wed, May 23, 2018, 10:01 PM Chris Johns  wrote:

> On 24/5/18 12:07 pm, Joel Sherrill wrote:
> > ---
> >  tester/covoar/Target_sparc.cc | 4 
> >  1 file changed, 4 insertions(+)
> >
> > diff --git a/tester/covoar/Target_sparc.cc
> b/tester/covoar/Target_sparc.cc
> > index 0e4ab2e..deeafef 100644
> > --- a/tester/covoar/Target_sparc.cc
> > +++ b/tester/covoar/Target_sparc.cc
> > @@ -64,6 +64,10 @@ namespace Target {
> >size = 4;
> >return true;
> >  }
> > +if (!strcmp( &line[strlen(line)-6], "unimpl")) {
>

It's matching the last N characters on the line. It should be backing off
one extra for a new line.


> I have not looked at the code around this for C++.
>
> Also these calls should be "::strcmp()".
>

Ok. The same pattern is every Target*.cc

>
> Chris
>
> > +  size = 4;
> > +  return true;
> > +}
> >
> >  if (!strcmp( &line[strlen(line)-7], "unknown")) {
> >size = 4;
> >
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Where does the content of release report come from?

[Danxue Huang]

Hi Dr. Joel and Chris,

How is this pdf file generated (see attacked link please)? Is it generated
by Trac automatically? Or should I generate it manually?

https://ftp.rtems.org/pub/rtems/releases/4.11/4.11.2/rtems-4.11.2-release-notes.pdf

Best,
Dannie
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Where does the content of release report come from?

[Chris Johns]

On 24/5/18 3:31 pm, Danxue Huang wrote:
> Hi Dr. Joel and Chris,
> 
> How is this pdf file generated (see attacked link please)? Is it generated by
> Trac automatically? Or should I generate it manually?
> 
> https://ftp.rtems.org/pub/rtems/releases/4.11/4.11.2/rtems-4.11.2-release-notes.pdf
> 

The release script I gave you invokes the command 'wkhtmltopdf'. This command
takes as an argument the Trac webpage, for example:

 https://devel.rtems.org/wiki/Release/4.11/4.11.2

The command 'wkhtmltopdf' is like a browser but it creates a PDF as output
rather than to a screen. The release scripts creates a coverpage and joins the
PDF from the Trac Release page to create the release notes.

Please note, the way the release notes are currently done is not what this GSoC
is about. The task for this GSoC is to write Python code to extract the needed
information from Trac's RSS feed. I will send you some details off list and we
can discuss this some more next week in our meeting, which I am looking forward 
too.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: APA Scheduler Documentation Missing?

[Sebastian Huber]

On 23/05/18 17:43, Joel Sherrill wrote:

Hi

Looking at the list of schedulers available in confdefs.h based on the
following comment block:

*  - CONFIGURE_SCHEDULER_PRIORITY - Deterministic Priority Scheduler
 *  - CONFIGURE_SCHEDULER_PRIORITY_SMP - Deterministic Priority SMP 
Scheduler

 *  - CONFIGURE_SCHEDULER_PRIORITY_AFFINITY_SMP - Deterministic
 *    Priority SMP Affinity Scheduler
 *  - CONFIGURE_SCHEDULER_STRONG_APA - Strong APA Scheduler
 *  - CONFIGURE_SCHEDULER_SIMPLE - Light-weight Priority Scheduler
 *  - CONFIGURE_SCHEDULER_SIMPLE_SMP - Simple SMP Priority Scheduler
 *  - CONFIGURE_SCHEDULER_EDF - EDF Scheduler
 *  - CONFIGURE_SCHEDULER_EDF_SMP - EDF SMP Scheduler
 *  - CONFIGURE_SCHEDULER_CBS - CBS Scheduler
 *  - CONFIGURE_SCHEDULER_USER  - user provided scheduler
 *

I don't think Strong APA is documented in configuring a system or
scheduler concepts. Arbitrary Priority is used as the name.

I suspect most of the information is here but there is some naming
inconsistency and APA as an acronym or the configure_xxx constant
is not documented.


The scheduler configured with CONFIGURE_SCHEDULER_STRONG_APA has only a 
stub implementation. It should not be used.


--
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

Covoar address to line to DWARF updates.

[Chris Johns]

Hi,

I have pushed my latest set of changes to my personal repo to remove covoar
exec'ing addr2line and to directly use the DWARF debug info.

I have not been able to fully test the results because I do not have a suitable
.exe and .cov pair with match source. The executable and coverage data I have
received has helped but objdump fails because I do not have the source in the
executable path so does not find the source.

I would like to get these changes on to master as soon as possible so if a
covoar built from my repo can be tested I can then push the changes to master.

I have added to RTEMS Tools an addr2line utility as I needed a tool to test the
DWARF support I have added to the rtemstoolkit.

The repo is https://git.rtems.org/chrisj/rtems-tools.git and the changes are on
the branch 'covoar-dwarf'.

Thanks
Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel