GCC generating symbols prefixed with "call_"

GCC generating symbols prefixed with "call_"

[William Tambe]

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

Re: GCC generating symbols prefixed with "call_"

[Jim Wilson]

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

Re: GCC generating symbols prefixed with "call_"

[William Tambe]

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

Re: GCC generating symbols prefixed with "call_"

[Jim Wilson]

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