<div dir="ltr">Hi<div><br></div><div>Attached is a shell script (pokes Chris) which calculates the size of </div><div>the specified symbol across a set of .exe files. </div><div><br></div><div><div>[joel@rtbf64c samples]$ /tmp/cmp_sizes -a sparc -s _Workspace_Allocate_or_fatal_error *.exe</div><div>Size report for _Workspace_Allocate_or_fatal_error</div><div>         base_sp.exe - 0x4000c5a0 - 0x4000c5e0 (64)</div><div>         capture.exe - 0x400162a0 - 0x400162dc (60)</div><div>          cdtest.exe - 0x4001e6c4 - 0x4001e700 (60)</div><div>    cxx_iostream.exe - 0x4005cbdc - 0x4005cc20 (68)</div><div>          fileio.exe - 0x40020720 - 0x4002075c (60)</div><div>           hello.exe - 0x4000ac50 - 0x4000aca0 (80)</div><div>         minimum.exe - 0x40006240 - 0x40006280 (64)</div><div>           nsecs.exe - 0x4000c668 - 0x4000c6c0 (88)</div><div>        paranoia.exe - 0x4001426c - 0x400142c0 (84)</div><div>          ticker.exe - 0x4000d328 - 0x4000d380 (88)</div><div>       unlimited.exe - 0x4000cc0c - 0x4000cc60 (84)</div></div><div><br></div><div>NOTE: Each SPARC instruction is ALWAYS 4 bytes. That will be</div><div>important as we look at instruction addresses.</div><div><br></div><div>I objdump'ed (sparc-rtems5-objdump -S) each exe as I got to it in</div><div>the analysis. (

<span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">sparc-rtems5-objdump -S XXX.exe >XXX.dmp)</span></div><div><br></div><div>I started looking at the smallest one (capture.exe). It looks to </div><div>follow the pattern one expects when there is no padding needed</div><div>between it and the next method. [1]</div><div><br></div><div>Then I looked at ticker.dmp since it was one of the largest ones.</div><div>It puts a line with "..." at the end of the method and there was</div><div>a fairly large gap (0x360 - 0x380 - 4) which is 0x1c bytes of gap.</div><div><br></div><div>BUG 1: It looks like the output of objdump has changed its output</div><div>a bit and ObjdumpProcessor.cc is not recognizing the "..." line as</div><div>the end of a method. If you fix this issue, I suspect the ones ~80</div><div>bytes will be the right size.</div><div><br></div><div>Now let's move on to another one with a smaller size difference.</div><div>It is also an easier fix.  Look at base_sp.dmp. The last instruction is:</div><div><br></div><div><div>4000c5dc:<span style="white-space:pre">     </span>00 00 00 00 <span style="white-space:pre"> </span>unimp  0</div></div><div><br></div><div>Now look in Target_sparc.cc in IsNopLine(). That "instruction" is</div><div>not recognized as a nop.</div><div><br></div><div>BUG 2: Add logic to Target_sparc.cc to process that line as a nop.</div><div><br></div><div>As a final check, I looked at cxx_iostream.dmp which is 8 bytes</div><div>(e.g. 2 instructions) of padding. it uses the "..." line to indicate</div><div>padding.</div><div><br></div><div>So there's two bugs to fix which should address the situation. </div><div>The bugs are important but it is just as important that you understand</div><div>the process of how I tracked down what was going wrong. These</div><div>two are common problems.</div><div><br></div><div>  (a) issues processing the objdump</div><div>  (b) not understanding a nop</div><div><br></div><div>Once you get all the input into the C++ structures, life tends to</div><div>just be magically delicious. :)</div><div><br></div><div>[1] Padding is inserted by ld when linking the program to put</div><div>the first part of a function on a cache line boundary.</div><div><br></div><div>--joel</div></div>