Re: Question about codes in libgcc/crtstuff.c
On Thu, Nov 3, 2016 at 7:20 PM, Lei Wang wrote:
> The brief structure of libgcc/crtstuff.c is as follows:
>
> #ifdef CRT_BEGIN
> …
> #elif defined(CRT_END)
> ...
> # ifdef OBJECT_FORMAT_ELF
> …
> # else
>
> static void
> __do_global_ctors_aux (void)/* prologue goes in .text section */
> {
> asm (__LIBGCC_INIT_SECTION_ASM_OP__);
> DO_GLOBAL_CTORS_BODY;
> atexit (__do_global_dtors);
> } /* epilogue and body go in .init section */
>
> FORCE_CODE_SECTION_ALIGN
> asm (__LIBGCC_TEXT_SECTION_ASM_OP__);
>
> #endif // OBJECT_FORMAT_ELF
>
> #else // !CRT_BEGIN && !CRT_END
> …
> #endif
>
> The __do_global_ctors_aux function shown above is static and without “used”
> attribute which result in optimizing out when compiled with optimization.
> This currently causes my port failed.
> My understanding is that this function is supposed to be split into two
> parts: a prologue in .text section and the rest part in .init section.
> Meanwhile there is another symmetric function with the same name which is
> also split into two parts: an prologue in .init section and the rest part in
> .text section, which result in two identical copies of this function, one in
> .init section and the other in .text section.
> Or is there any other purpose of this code?
This code is all ridiculously complicated. It's also not used on
modern ELF systems, which use a .init_array section instead. Tell us
more about your port, and why you need to worry about this.
Ian
Fwd: Question about codes in libgcc/crtstuff.c
In fact, I just want to find a practical way to make the crt work.
Currently, I did the following configure in my port:
include "elfos.h" in tm.h
define HAS_INIT_SECTION
undefine OBJECT_FORMAT_ELF
define INVOKE__main
use default INIT_SECTION_OP
My port is working on a bare metal machine with newlib support. Seems
I fall into an spurious configure for compiling crtstuff.c. Could you
give me some guide to lead me back to common configuration of this?
Thanks.
Lei
2016-11-04 10:33 GMT-04:00 Ian Lance Taylor :
> On Thu, Nov 3, 2016 at 7:20 PM, Lei Wang wrote:
>> The brief structure of libgcc/crtstuff.c is as follows:
>>
>> #ifdef CRT_BEGIN
>> …
>> #elif defined(CRT_END)
>> ...
>> # ifdef OBJECT_FORMAT_ELF
>> …
>> # else
>>
>> static void
>> __do_global_ctors_aux (void)/* prologue goes in .text section */
>> {
>> asm (__LIBGCC_INIT_SECTION_ASM_OP__);
>> DO_GLOBAL_CTORS_BODY;
>> atexit (__do_global_dtors);
>> } /* epilogue and body go in .init section */
>>
>> FORCE_CODE_SECTION_ALIGN
>> asm (__LIBGCC_TEXT_SECTION_ASM_OP__);
>>
>> #endif // OBJECT_FORMAT_ELF
>>
>> #else // !CRT_BEGIN && !CRT_END
>> …
>> #endif
>>
>> The __do_global_ctors_aux function shown above is static and without “used”
>> attribute which result in optimizing out when compiled with optimization.
>> This currently causes my port failed.
>> My understanding is that this function is supposed to be split into two
>> parts: a prologue in .text section and the rest part in .init section.
>> Meanwhile there is another symmetric function with the same name which is
>> also split into two parts: an prologue in .init section and the rest part in
>> .text section, which result in two identical copies of this function, one in
>> .init section and the other in .text section.
>> Or is there any other purpose of this code?
>
> This code is all ridiculously complicated. It's also not used on
> modern ELF systems, which use a .init_array section instead. Tell us
> more about your port, and why you need to worry about this.
>
> Ian
Re: Question about codes in libgcc/crtstuff.c
On Fri, Nov 4, 2016 at 7:55 AM, lei wang wrote: > > In fact, I just want to find a practical way to make the crt work. > Currently, I did the following configure in my port: > > include "elfos.h" in tm.h > define HAS_INIT_SECTION > undefine OBJECT_FORMAT_ELF > define INVOKE__main > use default INIT_SECTION_OP > > My port is working on a bare metal machine with newlib support. Seems > I fall into an spurious configure for compiling crtstuff.c. Could you > give me some guide to lead me back to common configuration of this? If you are using ELF, arrange for your startup code to execute the functions in the .init_array section. If necessary, modify your linker script to define symbols around .init_array that your startup code can use to find the section. Pass --enable-initfini-array when you run configure. Don't define INVOKE__main. Don't worry about HAS_INIT_SECTION or OBJECT_FORMAT_ELF or INIT_SECTION_OP. Ian
Re: Question about codes in libgcc/crtstuff.c
Thanks. One more question, my current entry point of the program is main, after which there is a call to __main to do the constructor stuffs and register destructors. Without INVOKE__main, which point should I define as the entry? Lei 2016-11-04 11:06 GMT-04:00 Ian Lance Taylor : > On Fri, Nov 4, 2016 at 7:55 AM, lei wang wrote: >> >> In fact, I just want to find a practical way to make the crt work. >> Currently, I did the following configure in my port: >> >> include "elfos.h" in tm.h >> define HAS_INIT_SECTION >> undefine OBJECT_FORMAT_ELF >> define INVOKE__main >> use default INIT_SECTION_OP >> >> My port is working on a bare metal machine with newlib support. Seems >> I fall into an spurious configure for compiling crtstuff.c. Could you >> give me some guide to lead me back to common configuration of this? > > If you are using ELF, arrange for your startup code to execute the > functions in the .init_array section. If necessary, modify your > linker script to define symbols around .init_array that your startup > code can use to find the section. Pass --enable-initfini-array when > you run configure. Don't define INVOKE__main. Don't worry about > HAS_INIT_SECTION or OBJECT_FORMAT_ELF or INIT_SECTION_OP. > > Ian
Re: Question about codes in libgcc/crtstuff.c
On Fri, Nov 4, 2016 at 8:12 AM, lei wang wrote: > > Thanks. One more question, my current entry point of the program is > main, after which there is a call to __main to do the constructor > stuffs and register destructors. Without INVOKE__main, which point > should I define as the entry? You should write some startup code that runs all the constructors in .init_array, does any other required initialization, and then jumps to main. The program's entry point should be that startup code. You can name it anything you like; typical favorites are _init and _start. You may want to look at libgloss, which is parallel to newlib, for various examples. Ian
