[PATCH v3] covoar: Handle periods in symbols from objdump

[Alex White]

I’m not sure if I have seen an example of method split into more than one piece. It has been a while since I made this fix.

A specific test executable that shows the suffixes is testsuites/libtests/block08.exe, but most (if not all) of them should have symbols like this from what I can tell.

I found a good explanation of this directly in the GCC source here:
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/ipa-split.c;h=5e918ee3fbf6a86bd7fbfab6293f90c146b74977;hb=HEAD

Alex

From: Joel Sherrill <joel at rtems.org>
Sent: Tuesday, March 16, 2021 9:53 AM
To: Alex White <alex.white at oarcorp.com>
Cc: rtems-devel at rtems.org <devel at rtems.org>
Subject: Re: [PATCH v3] covoar: Handle periods in symbols from objdump



On Tue, Mar 16, 2021 at 9:25 AM Alex White <alex.white at oarcorp.com<mailto:alex.white at oarcorp.com>> wrote:
Occasionally the compiler will generate symbols that look similar to
symbols defined in RTEMS code except that they contain some suffix.
These symbol suffixes are only found in the ELF symbol table; the
symbols appear to be normal in the DWARF info. This appears to be
happening on all architectures.

For example, the function _Message_queue_Create from rtems appears as
"_Message_queue_Create.part.0". Other suffixes include ".isra.0",
".constprop.0", and ".0".

This looks to be related to compiler optimizations. Symbols with
suffixes were being treated as unique. For our purposes, they should be
mapped to the equivalent symbols in the DWARF info. This has been
fixed.

Everything Alex said is correct. It appears to be related to the compiler
optimizing and moving a section of a method "out of line". I suspect it could
be that it is moving an alternate path ahead of the code generated for the
entry point to improve some straight execution path through the method.

Perhaps Alex can point to a BSP and test exe for an example.
But they definitely were there and looked like GCC had split the method
into different pieces and at least one had an address before the method
entry point. He never showed me a method split into more than one piece
but given they ended with a number, that seems likely.

--joel

---
 tester/covoar/ExecutableInfo.cc   | 22 +++++++++++++++++++---
 tester/covoar/ObjdumpProcessor.cc |  6 ++++++
 tester/covoar/SymbolTable.cc      | 12 +++++++++---
 3 files changed, 34 insertions(+), 6 deletions(-)

diff --git a/tester/covoar/ExecutableInfo.cc b/tester/covoar/ExecutableInfo.cc
index c996d75..9384973 100644
--- a/tester/covoar/ExecutableInfo.cc
+++ b/tester/covoar/ExecutableInfo.cc
@@ -118,8 +118,7 @@ namespace Coverage {
     // Obtain the coverage map containing the specified address.
     itsSymbol = theSymbolTable.getSymbol( address );
     if (itsSymbol != "") {
-      it = coverageMaps.find( itsSymbol );
-      aCoverageMap = (*it).second;
+      aCoverageMap = &findCoverageMap(itsSymbol);
     }

     return aCoverageMap;
@@ -150,8 +149,25 @@ namespace Coverage {
   )
   {
     CoverageMaps::iterator cmi = coverageMaps.find( symbolName );
-    if ( cmi == coverageMaps.end() )
+    if ( cmi != coverageMaps.end() ) {
+      return *(cmi->second);
+    }
+
+    size_t periodIndex = symbolName.find(".");
+
+    if (periodIndex == std::string::npos) {
+      // Symbol name has no '.', can't do another lookup.
       throw CoverageMapNotFoundError(symbolName);
+    }
+
+    cmi = coverageMaps.find(
+      symbolName.substr(0, periodIndex)
+    );
+
+    if ( cmi == coverageMaps.end() ) {
+      throw CoverageMapNotFoundError(symbolName);
+    }
+
     return *(cmi->second);
   }

diff --git a/tester/covoar/ObjdumpProcessor.cc b/tester/covoar/ObjdumpProcessor.cc
index fa9894d..544bfa1 100644
--- a/tester/covoar/ObjdumpProcessor.cc
+++ b/tester/covoar/ObjdumpProcessor.cc
@@ -417,6 +417,12 @@ namespace Coverage {
         processSymbol = false;
         theInstructions.clear();

+        // Look for a '.' character and strip everything after it.
+        char *periodIndex = strstr(symbol, ".");
+        if (periodIndex != NULL) {
+          *periodIndex = 0;
+        }
+
         // See if the new symbol is one that we care about.
         if (SymbolsToAnalyze->isDesired( symbol )) {
           currentSymbol = symbol;
diff --git a/tester/covoar/SymbolTable.cc b/tester/covoar/SymbolTable.cc
index 53bc8af..00062cc 100644
--- a/tester/covoar/SymbolTable.cc
+++ b/tester/covoar/SymbolTable.cc
@@ -46,12 +46,18 @@ namespace Coverage {
     symbolData.startingAddress = start;
     symbolData.length = length;

-    if ( info[ symbol ].empty() == false ) {
-      if ( info[ symbol ].front().length != length ) {
+    for (auto& symData : info[ symbol ]) {
+      // The starting address could differ since we strip any suffixes beginning
+      // with a '.'
+      if (symData.startingAddress != start) {
+        continue;
+      }
+
+      if (symData.length != length) {
         std::ostringstream what;
         what << "Different lengths for the symbol "
              << symbol
-             << " (" << info[ symbol ].front().length
+             << " (" << symData.length
              << " and " << length
              << ")";
         throw rld::error( what, "SymbolTable::addSymbol" );
--
2.27.0

_______________________________________________
devel mailing list
devel at rtems.org<mailto:devel at rtems.org>
http://lists.rtems.org/mailman/listinfo/devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20210316/5f75b95d/attachment-0001.html>