<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 22, 2018 at 5:45 PM, Chris Johns <span dir="ltr"><<a href="mailto:chrisj@rtems.org" target="_blank">chrisj@rtems.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 22/5/18 11:14 pm, Joel Sherrill wrote:<br>
> On Mon, May 21, 2018, 7:44 PM Chris Johns <<a href="mailto:chrisj@rtems.org">chrisj@rtems.org</a><br>
</span><div><div class="h5">> <mailto:<a href="mailto:chrisj@rtems.org">chrisj@rtems.org</a>>> wrote:<br>
> On 22/5/18 9:12 am, Joel Sherrill wrote:<br>
> ><br>
> > Attached is a shell script (pokes Chris) which calculates the size of <br>
> > the specified symbol across a set of .exe files. <br>
> ><br>
> > [joel@rtbf64c samples]$ /tmp/cmp_sizes -a sparc -s<br>
> > _Workspace_Allocate_or_fatal_<wbr>error *.exe<br>
> > Size report for _Workspace_Allocate_or_fatal_<wbr>error<br>
> > base_sp.exe - 0x4000c5a0 - 0x4000c5e0 (64)<br>
> > capture.exe - 0x400162a0 - 0x400162dc (60)<br>
> > cdtest.exe - 0x4001e6c4 - 0x4001e700 (60)<br>
> > cxx_iostream.exe - 0x4005cbdc - 0x4005cc20 (68)<br>
> > fileio.exe - 0x40020720 - 0x4002075c (60)<br>
> > hello.exe - 0x4000ac50 - 0x4000aca0 (80)<br>
> > minimum.exe - 0x40006240 - 0x40006280 (64)<br>
> > nsecs.exe - 0x4000c668 - 0x4000c6c0 (88)<br>
> > paranoia.exe - 0x4001426c - 0x400142c0 (84)<br>
> > ticker.exe - 0x4000d328 - 0x4000d380 (88)<br>
> > unlimited.exe - 0x4000cc0c - 0x4000cc60 (84)<br>
> ><br>
> > NOTE: Each SPARC instruction is ALWAYS 4 bytes. That will be<br>
> > important as we look at instruction addresses.<br>
> ><br>
> > I objdump'ed (sparc-rtems5-objdump -S) each exe as I got to it in<br>
> > the analysis. ( sparc-rtems5-objdump -S XXX.exe >XXX.dmp)<br>
> <br>
> The following is not something for the GSoC tasks and I report them here and now<br>
> so we can keep them in mind.<br>
> <br>
> Binutils' objdump like addr2line uses the DWARF information held in the ELF<br>
> file. My close inspection of the DWARF data in the exe files we are creating<br>
> leave me with some concerns.<br>
> <br>
> These are important to look into but should almost certainly not have anything<br>
> to do with the bugs I described.<br>
<br>
</div></div>Sure this is probability correct but you or I cannot prove this. What concerns<br>
me most is objdump says nothing so it is natural for us to consider what it<br>
presents as accurate when it may not be, it may be an approximation. For a<br>
command line tool to investigate an ELF file this would seem reasonable because<br>
the user is after some detail however this is not the case in our use.<br></blockquote><div><br></div><div>Agreed. </div><div><br></div><div>In this case, I think objdump just changed its format though when presented</div><div>with >1 NOP at the end of a method for padding. Unfortunately, it doesn't</div><div>do it for just 1 and the instruction we saw is not known in covaor as a </div><div>padding pattern from ld. Those are well-defined.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
The output you are parsing is derived from the DWARF info and that needs to be<br>
correct but I am suspicious it is not. For example the line details for mutex.c<br>
in the hello.exe Cillian sent me is clearly wrong, the line program's location<br>
opcode sets the address to 0x0 while mutex.c in cdtest.exe I built locally is<br>
correctly setting the address. This points to the linker.<br></blockquote><div><br></div><div>I have never seen this but believe you. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
You are attempting to correlate function lengths that do not match across<br>
different executable files looking for a pattern to match against and all I am<br>
saying is there may not be one you can find because of a bug elsewhere. As a<br>
result this issue will appear over and over and frustrate you.<br></blockquote><div><br></div><div>I am hoping that the DWARF info contains the true length and eventually</div><div>we can flag when the computed and claimed length don't match.</div><div><br></div><div>NOTE: Unless we incorporate objdump capability somehow, we will</div><div>be stuck with this part of the process.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
There is also this recent thread on gcc's list:<br>
<br>
<a href="https://gcc.gnu.org/ml/gcc/2018-05/msg00083.html" rel="noreferrer" target="_blank">https://gcc.gnu.org/ml/gcc/<wbr>2018-05/msg00083.html</a><br>
<br>
which discusses issues with -fdata-sections and -ffunction-sections. The thread<br>
is about LTO however the discussion also covers -fdata-sections and<br>
-ffunction-sections when not using LTO. Has adding these options changed<br>
something? There is discussion about a patch for binutils I have not tracked<br>
down and we should do this as well.<br></blockquote><div><br></div><div>I was reading that hoping Freddie would give us a hint on if LTO was worth</div><div>adopting after rtems5 and waf. No build changes until after that. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
FWIW the discussion also highlights that -fdata-sections and -ffunction-sections<br>
may not be the best options for some RISC architectures and LTO is better at<br>
reducing the overall executable size. I suspect LTO will cause covoar issues as<br>
well.<br></blockquote><div><br></div><div>It could if it results in the code being different in a method between two</div><div>executables.</div><div><br></div><div>OTOH we already use -Os for analysis purposes instead of -O2. This</div><div>may just be another option that hurts coverage analysis. </div><div><br></div><div>I would like our test coverage to be high and work for all gcc and link</div><div>options. Just saying there may be limitations. </div><div><br></div><div>Or we may need to limit ourselves to source line mapping on a per executable</div><div>basis. And generate reports using gcov output if we see methods change</div><div>between executables. I have shied away from gcov as the primary format</div><div>because I don't see how to do subexpression analysis.</div><div><br></div><div> if (a == 0 || b == 1)</div><div><br></div><div>That's one line of source but two sub-expressions. Unless it's changed</div><div>recently, the debug info is not at a level of granularity to generate </div><div>gcov data that can tell we always too the first sub-expression.</div><div><br></div><div>I'm not arguing -- just saying that doing the analysis at the asm level</div><div>gives us branch information I don't think we get via source line </div><div>analysis and gcov.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> <br>
> Do they appear on other architectures?<br>
> <br>
<br>
</span>I have not looked. The gcc thread is about the ARM architecture so it may.<br>
<span class=""><br>
> We.need to.move these questions to the binutils list? Only they can answer these.<br>
<br>
</span>Yes. I would like to figure out what is a real issue and what is something I<br>
have to handle better or I need to understand better.<br></blockquote><div><br></div><div>Sounds like bad info from GCC which needs to be fixed. I would suspect</div><div>it is common across architectures. </div><div><br></div><div>Needs to be tracked down but doesn't derail the GSoC project. Only that</div><div>we may hit another roadblock or hurdle. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
Chris<br>
</font></span></blockquote></div><br></div></div>