RTEMS C++ global constructor for Sparc
Joel Sherrill
joel.sherrill at OARcorp.com
Tue Apr 1 15:44:38 UTC 2014
OK.. replying to self..
I made some changes locally and now have the examples-v2 sample
cxx_throw nearly running. I am down to the spurious exception handler
getting invoked on sis for exception 263 which I don't know what that
is. [1]
Does this run in gdb or exception mean anything to anyone?
(gdb) r
Starting program:
/home/joel/rtems-4.11-work/examples-v2/cxx/cxx_throw/o-optimize/cxx_throw.exe
Hey I'm in base class constructor number 1 for 0x2068384.
Hey I'm in base class constructor number 2 for 0x206837c.
Hey I'm in derived class constructor number 3 for 0x206837c.
*** CONSTRUCTOR/DESTRUCTOR TEST ***
Hey I'm in base class constructor number 4 for 0x20730f0.
Hey I'm in base class constructor number 5 for 0x20730f8.
Hey I'm in base class constructor number 6 for 0x2073100.
Hey I'm in base class constructor number 7 for 0x2073108.
Hey I'm in derived class constructor number 8 for 0x2073108.
Testing a C++ I/O stream
before try block
Breakpoint 1, _Terminate (
the_source=the_source at entry=RTEMS_FATAL_SOURCE_EXCEPTION,
is_internal=is_internal at entry=false, the_error=the_error at entry=34011320)
at ../../../../../../rtems/c/src/../../cpukit/score/src/interr.c:36
36 {
(gdb) bt
#0 _Terminate (the_source=the_source at entry=RTEMS_FATAL_SOURCE_EXCEPTION,
is_internal=is_internal at entry=false, the_error=the_error at entry=34011320)
at ../../../../../../rtems/c/src/../../cpukit/score/src/interr.c:36
#1 0x0203c454 in rtems_fatal (
source=source at entry=RTEMS_FATAL_SOURCE_EXCEPTION,
error=error at entry=34011320)
at ../../../../../../rtems/c/src/../../cpukit/sapi/src/fatal2.c:34
#2 0x02035f48 in bsp_spurious_handler (trap=263, isf=0x20721d8)
at
../../../../../../../../rtems/c/src/lib/libbsp/sparc/erc32/startup/spurious.c:131
#3 0x0205fda4 in dont_fix_pil2 ()
at
../../../../../../../../rtems/c/src/lib/libbsp/sparc/erc32/../../sparc/shared/irq_asm.S:476
#4 0x0205fda4 in dont_fix_pil2 ()
at
../../../../../../../../rtems/c/src/lib/libbsp/sparc/erc32/../../sparc/shared/irq_asm.S:476
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb)
#0 _Terminate (the_source=the_source at entry=RTEMS_FATAL_SOURCE_EXCEPTION,
is_internal=is_internal at entry=false, the_error=the_error at entry=34011320)
at ../../../../../../rtems/c/src/../../cpukit/score/src/interr.c:36
#1 0x0203c454 in rtems_fatal (
source=source at entry=RTEMS_FATAL_SOURCE_EXCEPTION,
error=error at entry=34011320)
at ../../../../../../rtems/c/src/../../cpukit/sapi/src/fatal2.c:34
#2 0x02035f48 in bsp_spurious_handler (trap=263, isf=0x20721d8)
at
../../../../../../../../rtems/c/src/lib/libbsp/sparc/erc32/startup/spurious.c:131
#3 0x0205fda4 in dont_fix_pil2 ()
at
../../../../../../../../rtems/c/src/lib/libbsp/sparc/erc32/../../sparc/shared/irq_asm.S:476
#4 0x0205fda4 in dont_fix_pil2 ()
at
../../../../../../../../rtems/c/src/lib/libbsp/sparc/erc32/../../sparc/shared/irq_asm.S:476
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb)
[1] I am not feeling 100% well and am at home today. So don't have
access to everything not inclination to hunt.
On 4/1/2014 10:21 AM, Joel Sherrill wrote:
> I am confused. Did you build RTEMS with --enable-cxx?
>
> Did you make the linkcmds changes discussed?
>
> In RTEMS, the C++ global constructors are called by the first thread
> that executes. Before that, almost anything a constructor is allowed
> to do that is not pure computation or memory initialization would
> not be valid because the OS and tasking are not running.
>
> There is a call in _Thread_Handler to the constructor execution method.
> The name varies by target so it is a macro named INIT. A few lines of code
> later the user init task is invoked.
>
> Let's keep this on rtems-users so others benefit from the discussion.
>
> --joel
> On 3/27/2014 9:00 PM, Thomas (Gmail) wrote:
>> On referencing, I misunderstood that _init() call not C++ constructor
>> function because there is not C++ constructor function in crti.o.
>>
>> Today, after I make object dump file about elf file(cxx_throw.exe), I
>> checked that below objdump information. It included ++ constructor as
>> like below;
>>
>> 02066130 <_init>:
>> 2066130:9d e3 bf a0 save %sp, -96, %sp
>> 2066134:7f fe 6c 60 call 20012b4 <frame_dummy>
>> 2066138:01 00 00 00 nop
>> 206613c:7f ff e8 99 call 20603a0 <__do_global_ctors_aux>
>> 2066140:01 00 00 00 nop
>> 2066144:81 e8 00 00 restore
>> 2066148:81 c3 e0 08 retl
>> 206614c:01 00 00 00 nop
>>
>> I am sorry for my misunderstanding.
>>
>> Best Regards
>>
>>
>> 2014-03-28 10:19 GMT+09:00 Thomas (Gmail) <thomas73.kim at gmail.com
>> <mailto:thomas73.kim at gmail.com>>:
>>
>> Please check that my modification is correct.
>>
>> I modified linkcmds.base according to your comment.
>>
>> (Before)
>> KEEP (*(EXCLUDE_FILE (*crtend.o *crtend?.o ) .ctors))
>> 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))
>>
>> (After)
>> KEEP (*(EXCLUDE_FILE (*crtend.o *crtend?.o ) .ctors))
>> 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*))
>>
>> Also, I compared map file.
>>
>> (Before)
>> *(.ctors)
>> .ctors 0x0206040c 0x4
>> /opt/rtems-4.11/lib/gcc/sparc-rtems4.11/4.8.2/crtend.o
>> *crtbegin.o(.dtors)
>> .dtors 0x02060410 0x4
>> /opt/rtems-4.11/lib/gcc/sparc-rtems4.11/4.8.2/crtbegin.o
>> *crtbegin?.o(.dtors)
>> *(EXCLUDE_FILE(*crtend?.o *crtend.o) .dtors)
>> *(SORT(.dtors.*))
>> *(.dtors)
>>
>> (After)
>> *(.ctors*)
>> .ctors 0x0206040c 0x4
>> /opt/rtems-4.11/lib/gcc/sparc-rtems4.11/4.8.2/crtend.o
>> *crtbegin.o(.dtors)
>> .dtors 0x02060410 0x4
>> /opt/rtems-4.11/lib/gcc/sparc-rtems4.11/4.8.2/crtbegin.o
>> *crtbegin?.o(.dtors)
>> *(EXCLUDE_FILE(*crtend?.o *crtend.o) .dtors)
>> *(SORT(.dtors.*))
>> *(.dtors*)
>>
>> Best Regards
>>
>>
>> 2014-03-28 2:00 GMT+09:00 Joel Sherrill
>> <joel.sherrill at oarcorp.com <mailto:joel.sherrill at oarcorp.com>>:
>>
>> I am out of the country and teaching this week. Trying adding an
>> "*" after ctors and before the parentheses. Ditto for dtors
>> so it wild
>> card matches.
>>
>> Look at how .text has a * on it
>> On 3/27/2014 10:25 AM, Thomas (Gmail) wrote:
>>> I am tring to compare linkcmd.base and toolchain's
>>> elf32_sparc.x.
>>> But, I am difficult to modify linkcmd.base for this.
>>>
>>> Please could you send to me the revised linkcmd.base file ?
>>>
>>>
>>>
>>> 2014-03-27 18:18 GMT+09:00 Joel Sherrill
>>> <joel.sherrill at oarcorp.com <mailto:joel.sherrill at oarcorp.com>>:
>>>
>>> libgcc2 is already in the toolset. This almost 100%
>>> certainly is a small
>>> bug in
>>> c/src/lib/libbsp/sparc/shared/startup/linkcmds.base. Look
>>> at how the .ctors are referenced in the files
>>> elf32_sparc.x* installed
>>> as part of the toolset in
>>> $prefix/sparc-rtems4.11/lib/ldscripts. They
>>> have "." and a "*" in the KEEP lines. I don't think we
>>> have that.
>>>
>>> The problem was almost certainly introduced with
>>> function sections
>>> being used and I missed a wildcard on the ctor/dtor lines.
>>>
>>> On 3/27/2014 3:04 AM, Thomas (Gmail) wrote:
>>>> On referencing, I am a beginner regarding this.
>>>>
>>>> As I know from googling information, name of the
>>>> section for constructor is in .ctors section in
>>>> linkcmds.base.
>>>> below reference code is from gcc-4.8.2/libgcc/libgcc2.c
>>>> because __do_global_ctors() function is in libgcc2.c, I
>>>> tried to add libgcc.a in rtems building environment.
>>>> but, I didn't complete.
>>>>
>>>> < libgcc2.c >
>>>> ----------------------------------------------------------------------------------------------------
>>>> /* Run all the global destructors on exit from the
>>>> program. */
>>>> void
>>>> __do_global_ctors (void)
>>>> {
>>>> #ifdef EH_FRAME_SECTION_NAME
>>>> {
>>>> static struct object object;
>>>> __register_frame_info (__EH_FRAME_BEGIN__, &object);
>>>> }
>>>> #endif
>>>> DO_GLOBAL_CTORS_BODY;
>>>> atexit (__do_global_dtors);
>>>> }
>>>> -------------------------------------------------------------------------------------
>>>>
>>>> < gbl-ctors.h>
>>>> -------------------------------------------------------------------------------------
>>>> /* Some systems use a different strategy for finding the ctors.
>>>> For example, svr3. */
>>>> #ifndef DO_GLOBAL_CTORS_BODY
>>>> #define DO_GLOBAL_CTORS_BODY \
>>>> do { \
>>>> unsigned long nptrs = (unsigned long) __CTOR_LIST__[0]; \
>>>> unsigned i; \
>>>> if (nptrs == (unsigned long)-1) \
>>>> for (nptrs = 0; __CTOR_LIST__[nptrs + 1] != 0; nptrs++); \
>>>> for (i = nptrs; i >= 1; i--) \
>>>> __CTOR_LIST__[i] (); \
>>>> } while (0)
>>>> #endif
>>>> -------------------------------------------------------------------------------------
>>>>
>>>>
>>>> 2014-03-27 16:33 GMT+09:00 Joel Sherrill
>>>> <joel.sherrill at oarcorp.com
>>>> <mailto:joel.sherrill at oarcorp.com>>:
>>>>
>>>>
>>>> On 3/27/2014 2:30 AM, Sebastian Huber wrote:
>>>> > On 2014-03-27 06:28, Thomas (Gmail) wrote:
>>>> >> I am tring to add libgcc.a in linking process
>>>> for calling __do_global_ctors().
>>>> > If you have to do this by hand, then your build
>>>> process is broken. How did you
>>>> > get the RTEMS tool chain? Which RTEMS version do
>>>> you use?
>>>> >
>>>> >> Please could you let me know how to add libgcc.a
>>>> in RTEMS building environment ?
>>>> >>
>>>> >> If this approach is not correct, please let me
>>>> know correct how-to-do for C++
>>>> >> global constructor for Sparc.
>>>> > It should work out of the box.
>>>> >
>>>> Just out of curiosity what is the name of the
>>>> section that the
>>>> constructor is in?
>>>>
>>>> When I turned on function sections, it may now be
>>>> in .initXXX instead of
>>>> just .init.
>>>> This would mean that an asterisk is needed in the
>>>> linkcmds.base for init
>>>> and fini
>>>> to pick up all the methods. There is a KEEP()
>>>> around them which I
>>>> thought might
>>>> be the issue.
>>>>
>>>> --
>>>> Joel Sherrill, Ph.D. Director of
>>>> Research & Development
>>>> joel.sherrill at OARcorp.com
>>>> <mailto:joel.sherrill at OARcorp.com> On-Line
>>>> Applications Research
>>>> Ask me about RTEMS: a free RTOS Huntsville AL 35805
>>>> Support Available (256) 722-9985
>>>>
>>>>
>>>
>>> --
>>> Joel Sherrill, Ph.D. Director of Research & Development
>>> joel.sherrill at OARcorp.com <mailto:joel.sherrill at OARcorp.com> On-Line Applications Research
>>> Ask me about RTEMS: a free RTOS Huntsville AL 35805
>>> Support Available (256) 722-9985
>>>
>>>
>>
>> --
>> Joel Sherrill, Ph.D. Director of Research & Development
>> joel.sherrill at OARcorp.com <mailto:joel.sherrill at OARcorp.com> On-Line Applications Research
>> Ask me about RTEMS: a free RTOS Huntsville AL 35805
>> Support Available (256) 722-9985
>>
>>
>>
>
> --
> Joel Sherrill, Ph.D. Director of Research & Development
> joel.sherrill at OARcorp.com On-Line Applications Research
> Ask me about RTEMS: a free RTOS Huntsville AL 35805
> Support Available (256) 722-9985
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherrill at OARcorp.com On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20140401/53a58be5/attachment.html>
More information about the users
mailing list