<div dir="ltr"><div dir="ltr"><br><br><br><div class="gmail_quote"><div dir="ltr">On Mon, 1 Oct 2018 at 11:22, Sebastian Huber <<a href="mailto:sebastian.huber@embedded-brains.de">sebastian.huber@embedded-brains.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 25/09/2018 07:58, Chris Johns wrote:<br>
> On 25/09/2018 15:30, Sebastian Huber wrote:<br>
>> On 25/09/2018 00:27, Chris Johns wrote:<br>
>>>>>> We would have to go from the symbol to the ELF file to the DWARF info of the<br>
>>>>>> compilation unit.<br>
>>>>> All info should be directly via the ELF and DWARF format. I do not know if we<br>
>>>>> need to reference the ELF symbol table or we can just use the DWARF CU data.<br>
>>>>> The<br>
>>>>> use of objdump should be avoided.<br>
>>>> I only briefly look into this, but you have to go from the rld::symbols::symbol<br>
>>>> to the DWARF info somehow if DesiredSymbols.cc:95 is the right spot to add this<br>
>>>> stuff.<br>
>>>><br>
>>> You could be right. The DWARF info will contain all symbols and more.<br>
>>><br>
>>> Should these files move to the rtems.git repo?<br>
>> The *.ini files or which files?<br>
> Just the INI files, the files which describe the data.<br>
><br>
>> I would leave the files where they are and fix<br>
>> the issues first. Afterwards I would think about moving files around across<br>
>> repositories.<br>
> Oh of course, that is fine and it makes sense. I would like to understand the<br>
> tasks and agree on them.<br>
<br>
This stalled my background work on general RTEMS improvements (in this <br>
case the build system). I think the path is clear. We use source tree <br>
path regular expressions to assign source files to categories. The <br>
source tree path is determined for each symbol by the DWARF compilation <br>
unit information. The categories are defined in an INI file in <br>
rtems-tools for now. Maybe later it is places somewhere else.<br>
<br>
I would like to continue now with the build system changes. This will <br>
break the coverage tool categories for some time.<br>
<br>
Is there some documentation on how I can use the coverage tool? Which <br>
BSP is recommended for test runs?<br>
<br></blockquote><div>There isn't proper documentation of this, but the following wiki page</div><div>has the instruction of how to run the coverage tool.</div><div><a href="https://devel.rtems.org/wiki/GSoC/2018/coverage_analysis_toolset">https://devel.rtems.org/wiki/GSoC/2018/coverage_analysis_toolset</a> </div><div><br></div><div>The coverage tool worked properly with leon3.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
-- <br>
Sebastian Huber, embedded brains GmbH<br>
<br>
Address : Dornierstr. 4, D-82178 Puchheim, Germany<br>
Phone : +49 89 189 47 41-16<br>
Fax : +49 89 189 47 41-09<br>
E-Mail : <a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a><br>
PGP : Public key available on request.<br>
<br>
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.<br>
<br>
_______________________________________________<br>
devel mailing list<br>
<a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a></blockquote></div></div></div>