On 22/5/18 11:14 pm, Joel Sherrill wrote: > On Mon, May 21, 2018, 7:44 PM Chris Johns <chr...@rtems.org > <mailto:chr...@rtems.org>> 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. 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. 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. There is also this recent thread on gcc's list: https://gcc.gnu.org/ml/gcc/2018-05/msg00083.html which discusses issues with -fdata-sections and -ffunction-sections. The thread is about LTO however the discussion also covers -fdata-sections and -ffunction-sections when not using LTO. Has adding these options changed something? There is discussion about a patch for binutils I have not tracked down and we should do this as well. FWIW the discussion also highlights that -fdata-sections and -ffunction-sections may not be the best options for some RISC architectures and LTO is better at reducing the overall executable size. I suspect LTO will cause covoar issues as well. > > Do they appear on other architectures? > I have not looked. The gcc thread is about the ARM architecture so it may. > We.need to.move these questions to the binutils list? Only they can answer > these. Yes. I would like to figure out what is a real issue and what is something I have to handle better or I need to understand better. Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
