RTEMS C++ global constructor for Sparc
Joel Sherrill
joel.sherrill at OARcorp.com
Tue Apr 1 20:36:59 UTC 2014
On 4/1/2014 3:09 PM, Daniel Hellstrom wrote:
> Hi,
>
> The SPARC v7/v8 traps ends at 255, I dont have RTEMS code in front of
> me, perhaps there is a mask of 0x100 added to the trap number to
> indicate something.
>
OK. The 0x80 indicates synchronous trap:
/**
* This macro indicates that @a _trap as a synchronous trap.
*/
#define SPARC_SYNCHRONOUS_TRAP( _trap ) ((_trap) + 256 )
How about 137 or 0x87 which makes it a type of trap?
It is happening in classify_object_over_fdes if that helps.
--joel
> Daniel
>
> On 1 April 2014 17:44:38 CEST, Joel Sherrill
> <joel.sherrill at oarcorp.com> wrote:
>
> 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
>
>
> --
> Sent from my Android phone with K-9 Mail. Please excuse my brevity.
--
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/c371a7fb/attachment.html>
More information about the users
mailing list