* GCC generating symbols prefixed with "call_"
@ 2020-03-26 1:41 William Tambe
2020-03-26 23:02 ` Jim Wilson
0 siblings, 1 reply; 4+ messages in thread
From: William Tambe @ 2020-03-26 1:41 UTC (permalink / raw)
To: gcc-help
Any idea what is causing GCC to generate the following symbols prefixed
with "call_" ?
call___do_global_ctors_aux
call___do_global_dtors_aux
call_frame_dummy
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: GCC generating symbols prefixed with "call_"
2020-03-26 1:41 GCC generating symbols prefixed with "call_" William Tambe
@ 2020-03-26 23:02 ` Jim Wilson
2020-03-27 0:03 ` William Tambe
0 siblings, 1 reply; 4+ messages in thread
From: Jim Wilson @ 2020-03-26 23:02 UTC (permalink / raw)
To: William Tambe; +Cc: gcc-help
On Wed, Mar 25, 2020 at 6:41 PM William Tambe via Gcc-help
<gcc-help@gcc.gnu.org> wrote:
> Any idea what is causing GCC to generate the following symbols prefixed
> with "call_" ?
>
> call___do_global_ctors_aux
> call___do_global_dtors_aux
> call_frame_dummy
find . -type f | xargs grep do_global_ctors_aux
on a linux machine in the gcc source tree will show you all uses of
do_global_ctors_aux, there are only about a hundred of them, and most
of them are obviously not relevant. You can ignore the ia64, pa, and
ChangeLog file hits. That gives a couple dozen, of which the most
interesting one is this one
./libgcc/crtstuff.c:CRT_CALL_STATIC_FUNCTION
(__LIBGCC_INIT_SECTION_ASM_OP__, __do_global_ctors_aux)
Jim
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: GCC generating symbols prefixed with "call_"
2020-03-26 23:02 ` Jim Wilson
@ 2020-03-27 0:03 ` William Tambe
2020-03-30 17:43 ` Jim Wilson
0 siblings, 1 reply; 4+ messages in thread
From: William Tambe @ 2020-03-27 0:03 UTC (permalink / raw)
To: Jim Wilson; +Cc: gcc-help
On Thu, Mar 26, 2020 at 7:03 PM Jim Wilson <jimw@sifive.com> wrote:
>
> On Wed, Mar 25, 2020 at 6:41 PM William Tambe via Gcc-help
> <gcc-help@gcc.gnu.org> wrote:
> > Any idea what is causing GCC to generate the following symbols prefixed
> > with "call_" ?
> >
> > call___do_global_ctors_aux
> > call___do_global_dtors_aux
> > call_frame_dummy
>
> find . -type f | xargs grep do_global_ctors_aux
> on a linux machine in the gcc source tree will show you all uses of
> do_global_ctors_aux, there are only about a hundred of them, and most
> of them are obviously not relevant. You can ignore the ia64, pa, and
> ChangeLog file hits. That gives a couple dozen, of which the most
> interesting one is this one
> ./libgcc/crtstuff.c:CRT_CALL_STATIC_FUNCTION
> (__LIBGCC_INIT_SECTION_ASM_OP__, __do_global_ctors_aux)
Thanks for shedding the light; essentially CRT_CALL_STATIC_FUNCTION()
inserts functions calls into the section given as argument.
But there is a weird behavior I am seeing; CRT_CALL_STATIC_FUNCTION()
is defined as follow:
# define CRT_CALL_STATIC_FUNCTION(SECTION_OP, FUNC) \
static void __attribute__((__used__)) \
call_ ## FUNC (void) \
{ \
asm (SECTION_OP); \
FUNC (); \
FORCE_CODE_SECTION_ALIGN \
asm (__LIBGCC_TEXT_SECTION_ASM_OP__); \
}
When asm (__LIBGCC_TEXT_SECTION_ASM_OP__) is used, it is not necessary
the same section as before the use of asm (SECTION_OP); hence the
prologue instructions end up not showing in the dis-assembly of "call_
## FUNC" .
Any idea why asm (__LIBGCC_TEXT_SECTION_ASM_OP__) is used instead of
asm (".previous") to restore the section before the use of asm
(SECTION_OP) ?
I tried above and it seems to work; I can see the prologue
instructions correctly showing in the dis-assembly of "call_ ## FUNC".
>
> Jim
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: GCC generating symbols prefixed with "call_"
2020-03-27 0:03 ` William Tambe
@ 2020-03-30 17:43 ` Jim Wilson
0 siblings, 0 replies; 4+ messages in thread
From: Jim Wilson @ 2020-03-30 17:43 UTC (permalink / raw)
To: William Tambe; +Cc: gcc-help
On Thu, Mar 26, 2020 at 5:03 PM William Tambe <tambewilliam@gmail.com> wrote:
> Any idea why asm (__LIBGCC_TEXT_SECTION_ASM_OP__) is used instead of
> asm (".previous") to restore the section before the use of asm
> (SECTION_OP) ?
Probably not all assemblers support previous. All GNU as ELF targets
do. But I think GNU as COFF targets don't, and there may be vendor
assemblers that don't.
But why are you worried about the call symbols anyways? I think that
this code is never run. The purpose here is to put a call in the fini
or init section, and the rest of the code is irrelevant. This is a
trick to support init/fini.
Most targets nowadays use init_array and fini_array instead of
init/fini. init/fini were obsoleted in the ELF standard about 20
years ago. This results in a much cleaner implementation, and allows
but better unwinding e.g. better C++ EH support. You should be using
the init_array/fini_array support here. I would suggest looking at
why this doesn't work. There should be a configure test to check for
assembler support for init_array/fini_array, and it should pass for
any elf gnu as port.
Jim
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2020-03-30 17:43 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-03-26 1:41 GCC generating symbols prefixed with "call_" William Tambe
2020-03-26 23:02 ` Jim Wilson
2020-03-27 0:03 ` William Tambe
2020-03-30 17:43 ` Jim Wilson
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).