N2X, GR740 and coverage: The impact of a linkcmds patch from 2014 to gcov_init calls
Thanassis.Tsiodras at esa.int
Thanassis.Tsiodras at esa.int
Wed Feb 28 11:50:06 UTC 2018
> However, I am not able to reproduce this problem.
Hi Sebastian.
Look at the reply I sent this morning to the mailing list - I uploaded the
code in a GitHub repository and provided instructions in the mailing list
with the exact invocations that reproduce the issue.
Hope this helps!
Thanassis.
Thanassis Tsiodras
Real-time Embedded Software Engineer
System, Software and Technology Department
ESTEC
Keplerlaan 1, PO Box 299
NL-2200 AG Noordwijk, The Netherlands
Thanassis.Tsiodras at esa.int | www.esa.int
T +31 71 565 5332
From: Sebastian Huber <sebastian.huber at embedded-brains.de>
To: Thanassis Tsiodras <Thanassis.Tsiodras at esa.int>
Cc: devel <devel at rtems.org>
Date: 28/02/2018 12:11
Subject: Re: N2X, GR740 and coverage: The impact of a linkcmds
patch from 2014 to gcov_init calls
----- Am 27. Feb 2018 um 17:30 schrieb Thanassis Tsiodras
Thanassis.Tsiodras at esa.int:
[...]
> After quite a lot of hunting, we traced this failure to a patch in the
> "linkcmds.base" - done back in 2014 ( commit 95cb09ed746 ) :
>
> This commit changed
"c/src/lib/libbsp/sparc/shared/startup/linkcmds.base"
> from this:
>
> KEEP (*(SORT(.ctors.*)))
> KEEP (*(.ctors))
> KEEP (*crtbegin.o(.dtors))
> KEEP (*crtbegin?.o(.dtors))
> KEEP (*(EXCLUDE_FILE (*crtend.o *crtend?.o ) .dtors))
> KEEP (*(SORT(.dtors.*)))
> KEEP (*(.dtors))
>
> ...to this:
>
> KEEP (*(EXCLUDE_FILE (*crtend.o *crtend?.o ) .ctors))
> KEEP (*(SORT(.ctors*)))
> KEEP (*crtbegin.o(.dtors))
> KEEP (*crtbegin?.o(.dtors))
> KEEP (*(EXCLUDE_FILE (*crtend.o *crtend?.o ) .dtors))
> KEEP (*(SORT(.dtors*)))
>
> Reverting this change, the gcov stubs revert back to their proper place,
> and __gcov_inits are called properly.
>
> The reason I tried this patch, was because I noticed that the coverage
> stubs are no longer placed in ".ctor" sections - they are instead placed
> by the newer compilers at ".ctor.NUMBER" sections (with NUMBER set to
> 65435 in my case - but I am guessing this will change from invocation to
> invocation).
>
> The comment provided by Joel back in 2014, only indicated that this
patch
> was done to address C++ concerns:
>
> commit 95cb09ed746e7daeca2158c7ecdf0249cfcbc5c8
> Author: Joel Sherrill <joel.sherrill at oarcorp.com>
> Date: Wed Apr 2 11:39:20 2014 -0500
>
> sparc/shared/.../linkcmds.base: Correct C++ support
> Add KEEP() for .eh_frame*, .ctor*, and .dtor*.
It could be a bug in the linker. The standard sections should be exactly
like the Binutils default:
sparc-rtems5-ld --verbose | grep ctor -C 3
*(.rela.data .rela.data.* .rela.gnu.linkonce.d.*)
*(.rela.tdata .rela.tdata.* .rela.gnu.linkonce.td.*)
*(.rela.tbss .rela.tbss.* .rela.gnu.linkonce.tb.*)
*(.rela.ctors)
*(.rela.dtors)
*(.rela.got)
*(.rela.bss .rela.bss.* .rela.gnu.linkonce.b.*)
--
.init_array :
{
PROVIDE_HIDDEN (__init_array_start = .);
KEEP (*(SORT_BY_INIT_PRIORITY(.init_array.*)
SORT_BY_INIT_PRIORITY(.ctors.*)))
KEEP (*(.init_array EXCLUDE_FILE (*crtbegin.o *crtbegin?.o *crtend.o
*crtend?.o ) .ctors))
PROVIDE_HIDDEN (__init_array_end = .);
}
.fini_array :
--
KEEP (*(.fini_array EXCLUDE_FILE (*crtbegin.o *crtbegin?.o *crtend.o
*crtend?.o ) .dtors))
PROVIDE_HIDDEN (__fini_array_end = .);
}
.ctors :
{
/* gcc uses crtbegin.o to find the start of
the constructors, so we make sure it is
first. Because this is a wildcard, it
doesn't matter if the user does not
actually link against crtbegin.o; the
linker won't look for a file to match a
wildcard. The wildcard also means that it
doesn't matter which directory crtbegin.o
is in. */
KEEP (*crtbegin.o(.ctors))
KEEP (*crtbegin?.o(.ctors))
/* We don't want to include the .ctor section from
the crtend.o file until after the sorted ctors.
The .ctor section from the crtend file contains the
end of ctors marker and it must be last */
KEEP (*(EXCLUDE_FILE (*crtend.o *crtend?.o ) .ctors))
KEEP (*(SORT(.ctors.*)))
KEEP (*(.ctors))
}
.dtors :
{
However, I am not able to reproduce this problem. For example in the
sptls04 linker map file (-Wl,-Map,map.txt) we have this:
*crtbegin.o(.ctors)
.ctors 0x0000000002011330 0x4
/opt/rtems/5/lib/gcc/sparc-rtems5/7.3.0/crtbegin.o
*crtbegin?.o(.ctors)
*(EXCLUDE_FILE(*crtend?.o *crtend.o) .ctors)
.ctors 0x0000000002011334 0x4 init.o
*(SORT_BY_NAME(.ctors*))
.ctors 0x0000000002011338 0x4
/opt/rtems/5/lib/gcc/sparc-rtems5/7.3.0/crtend.o
Who do the linker map files look in your test case?
This message and any attachments are intended for the use of the addressee or addressees only.
The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its
content is not permitted.
If you received this message in error, please notify the sender and delete it from your system.
Emails can be altered and their integrity cannot be guaranteed by the sender.
Please consider the environment before printing this email.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20180228/f7b45353/attachment-0002.html>
More information about the devel
mailing list