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

[Alex White]

> -Original Message-
> From: Chris Johns 
> Sent: Tuesday, March 16, 2021 7:18 PM
> To: j...@rtems.org; Alex White 
> Cc: rtems-de...@rtems.org 
> Subject: Re: [PATCH v3] covoar: Handle periods in symbols from objdump
> 
> On 17/3/21 9:56 am, Joel Sherrill wrote:
> > On Tue, Mar 16, 2021, 4:47 PM Alex White  > <mailto:alex.wh...@oarcorp.com>> wrote:
> >
> > > Do any non-compiler-generated symbols include "."?
> >
> > Yes, according to the output of nm:
> >
> > $ i386-rtems6-nm build/i386/pc686/testsuites/libtests/block08.exe | grep
> " \."
> > 0011bdd2 t .check_stack_switch
> >
> > I don't think there are any function symbols that include ".", though.
> >
> > I don't think including a dot is legal in any programming language we
> > are interested in. Holy qualified names in Ada use dot in fully
> > qualified names between the parts but that is mangled in the compiler.
> >
> > > Are there symbols that start with a "." that might be caught? I know 
> > we
> do
> > > this in assembly programming often, e.g., ".vectors", although 
> > probably
> it is
> > > unlikely to appear in C/asm I just want to be thorough.
> > >
> >
> > I didn't spot any when I looked:
> >
> > $ grep -r "PUBLIC\s*(\." --exclude-dir=build
> >
> > I guess it is possible, though. I'm not sure how I would properly 
> > handle it.
> > Currently, covoar would just chop off everything after the ".", fail to 
> > find
> > a coverage map, log an error, and move on.
> >
> > Do we think that is good enough?
> >
> > Until we find a language where a user written method can have a dot in
> > the generated name. :)
> 
> Do the asm symbols appear in the DWARF info? Could you search the DWARF
> and if it fails check for a . in the symbol and if it does remove the suffix 
> and
> try again?

As far as I can tell, no, the asm symbols do not appear in the DWARF info.

That method of having a fallback to search again for symbols containing a "." 
was my original method. I have removed that code from v4 of this patch because 
it was redundant given that I was already stripping the "." suffix from symbols 
as soon as I encountered them in the objdump.

> 
> Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Joel Sherrill]

On Tue, Mar 16, 2021, 7:15 PM Chris Johns  wrote:

> On 17/3/21 8:16 am, Alex White wrote:
> > Assuming I'm sending a v4 of this patch out, should I add the
> explanation of the compiler-generated suffixes to the commit message or
> perhaps as a comment in the code?
>
> Yes if you think it helps. In the end what you are doing makes the tool
> work and
> this doco help maintain the code because we now know why it is being done.
>

Comment in the code is better. Git commit will not be seen if someone is
questioning it.

>
> Chris
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Chris Johns]

On 17/3/21 9:56 am, Joel Sherrill wrote:
> On Tue, Mar 16, 2021, 4:47 PM Alex White  > wrote:
> 
> > Do any non-compiler-generated symbols include "."?
> 
> Yes, according to the output of nm:
> 
> $ i386-rtems6-nm build/i386/pc686/testsuites/libtests/block08.exe | grep 
> " \."
> 0011bdd2 t .check_stack_switch
> 
> I don't think there are any function symbols that include ".", though.
> 
> I don't think including a dot is legal in any programming language we are
> interested in. Holy qualified names in Ada use dot in fully qualified names
> between the parts but that is mangled in the compiler.
> 
> > Are there symbols that start with a "." that might be caught? I know we 
> do
> > this in assembly programming often, e.g., ".vectors", although probably 
> it is
> > unlikely to appear in C/asm I just want to be thorough.
> >
> 
> I didn't spot any when I looked:
> 
> $ grep -r "PUBLIC\s*(\." --exclude-dir=build
> 
> I guess it is possible, though. I'm not sure how I would properly handle 
> it.
> Currently, covoar would just chop off everything after the ".", fail to 
> find
> a coverage map, log an error, and move on.
> 
> Do we think that is good enough?
> 
> Until we find a language where a user written method can have a dot in the
> generated name. :)

Do the asm symbols appear in the DWARF info? Could you search the DWARF and if
it fails check for a . in the symbol and if it does remove the suffix and try 
again?

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Chris Johns]

On 17/3/21 8:16 am, Alex White wrote:
> Assuming I'm sending a v4 of this patch out, should I add the explanation of 
> the compiler-generated suffixes to the commit message or perhaps as a comment 
> in the code?

Yes if you think it helps. In the end what you are doing makes the tool work and
this doco help maintain the code because we now know why it is being done.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Joel Sherrill]

On Tue, Mar 16, 2021, 4:47 PM Alex White  wrote:

> > Do any non-compiler-generated symbols include "."?
>
> Yes, according to the output of nm:
>
> $ i386-rtems6-nm build/i386/pc686/testsuites/libtests/block08.exe | grep "
> \."
> 0011bdd2 t .check_stack_switch
>
> I don't think there are any function symbols that include ".", though.
>

I don't think including a dot is legal in any programming language we are
interested in. Holy qualified names in Ada use dot in fully qualified names
between the parts but that is mangled in the compiler.

>
> >
> > Are there symbols that start with a "." that might be caught? I know we
> do
> > this in assembly programming often, e.g., ".vectors", although probably
> it is
> > unlikely to appear in C/asm I just want to be thorough.
> >
>
> I didn't spot any when I looked:
>
> $ grep -r "PUBLIC\s*(\." --exclude-dir=build
>
> I guess it is possible, though. I'm not sure how I would properly handle
> it. Currently, covoar would just chop off everything after the ".", fail to
> find a coverage map, log an error, and move on.
>
> Do we think that is good enough?
>

Until we find a language where a user written method can have a dot in the
generated name. :)

>
> Alex
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Alex White]

> Do any non-compiler-generated symbols include "."?

Yes, according to the output of nm:

$ i386-rtems6-nm build/i386/pc686/testsuites/libtests/block08.exe | grep " \."
0011bdd2 t .check_stack_switch

I don't think there are any function symbols that include ".", though.

> 
> Are there symbols that start with a "." that might be caught? I know we do
> this in assembly programming often, e.g., ".vectors", although probably it is
> unlikely to appear in C/asm I just want to be thorough.
> 

I didn't spot any when I looked:

$ grep -r "PUBLIC\s*(\." --exclude-dir=build

I guess it is possible, though. I'm not sure how I would properly handle it. 
Currently, covoar would just chop off everything after the ".", fail to find a 
coverage map, log an error, and move on.

Do we think that is good enough?

Alex
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Alex White]

Assuming I'm sending a v4 of this patch out, should I add the explanation of 
the compiler-generated suffixes to the commit message or perhaps as a comment 
in the code?

Alex

> -Original Message-
> From: devel  On Behalf Of Alex White
> Sent: Tuesday, March 16, 2021 3:32 PM
> To: Chris Johns ; j...@rtems.org
> Cc: rtems-de...@rtems.org 
> Subject: RE: [PATCH v3] covoar: Handle periods in symbols from objdump
> 
> > I have lost of the context of why covoar would like to strip the
> > suffixes and use only the base symbol name. Could you please explain
> > why this is being done?
> 
> Sure. The symbol names in the DWARF info never contain these suffixes.
> 
> Covoar strips the suffixes while reading the objdump output so that the
> symbol names match those found in the DWARF info. This ensures that the
> proper coverage map is found when it looks up the symbol.
> 
> Your question prompted me to look back at my code and realize that my
> modification of ExecutableInfo::findCoverageMap() was unnecessary
> because I already modified ObjdumpProcessor::load() to always strip the
> symbol. The additional suffix handling code that I added to
> findCoverageMap() will never be run. If only I had done coverage analysis on
> the covoar tool itself...
> 
> Looks like I'll be sending a v4 of this patch. :)
> 
> Alex
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Alex White]

> I have lost of the context of why covoar would like to strip the suffixes and
> use only the base symbol name. Could you please explain why this is being
> done?

Sure. The symbol names in the DWARF info never contain these suffixes.

Covoar strips the suffixes while reading the objdump output so that the symbol 
names match those found in the DWARF info. This ensures that the proper 
coverage map is found when it looks up the symbol.

Your question prompted me to look back at my code and realize that my 
modification of ExecutableInfo::findCoverageMap() was unnecessary because I 
already modified ObjdumpProcessor::load() to always strip the symbol. The 
additional suffix handling code that I added to findCoverageMap() will never be 
run. If only I had done coverage analysis on the covoar tool itself...

Looks like I'll be sending a v4 of this patch. :)

Alex
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Chris Johns]

On 17/3/21 2:05 am, Alex White wrote:
> 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
> 
> 

Thanks Alex, this is a good explanation of what is going on.

I have lost of the context of why covoar would like to strip the suffixes and
use only the base symbol name. Could you please explain why this is being done?

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Gedare Bloom]

On Tue, Mar 16, 2021 at 8:25 AM Alex White  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".
>

Do any non-compiler-generated symbols include "."?

Are there symbols that start with a "." that might be caught? I know
we do this in assembly programming often, e.g., ".vectors", although
probably it is unlikely to appear in C/asm I just want to be thorough.

> 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.
> ---
>  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 = (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@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RE: [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 
Sent: Tuesday, March 16, 2021 9:53 AM
To: Alex White 
Cc: rtems-de...@rtems.org 
Subject: Re: [PATCH v3] covoar: Handle periods in symbols from objdump



On Tue, Mar 16, 2021 at 9:25 AM Alex White 
mailto:alex.wh...@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 = (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 "
   

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

[Joel Sherrill]

On Tue, Mar 16, 2021 at 9:25 AM Alex White  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 = (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@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Alex White]

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.
---
 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 = (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@rtems.org
http://lists.rtems.org/mailman/listinfo/devel