[PATCH v3] covoar: Handle periods in symbols from objdump
alex.white at oarcorp.com
Thu Mar 18 17:08:01 UTC 2021
> -----Original Message-----
> From: Chris Johns <chrisj at rtems.org>
> Sent: Tuesday, March 16, 2021 7:18 PM
> To: joel at rtems.org; 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 17/3/21 9:56 am, Joel Sherrill wrote:
> > On Tue, Mar 16, 2021, 4:47 PM Alex White <alex.white at oarcorp.com
> > <mailto:alex.white at 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
> > > 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.
More information about the devel