<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p dir="ltr">I think I have a real fix for this. I will confirm and commit it in the morning if I am right.</p>
<div class="quote">On Apr 3, 2014 5:04 PM, Joel Sherrill <joel.sherrill@oarcorp.com> wrote:<br type="attribution">
</div>
<div>The problem appears to be a missing "KEEP" directive in the<br>
linkcmds shared across the sparc BSPs.<br>
<br>
I proved this by reverting the patch to do per function/variable<br>
sections. <br>
<br>
The long term fix is to see what sections have KEEP() in <br>
$prefix/sparc-rtems4.11/lib/ldscripts and see which one was<br>
missed in the RTEMS version of this.<br>
<br>
But this patch is a short term fix<br>
<br>
diff --git a/c/src/lib/libbsp/sparc/erc32/make/custom/erc32.cfg b/c/src/lib/libb<br>
index 2859372..3ee9ca8 100644<br>
--- a/c/src/lib/libbsp/sparc/erc32/make/custom/erc32.cfg<br>
+++ b/c/src/lib/libbsp/sparc/erc32/make/custom/erc32.cfg<br>
@@ -13,6 +13,6 @@ CPU_CFLAGS = -mcpu=cypress<br>
<br>
# optimize flag: typically -O2<br>
CFLAGS_OPTIMIZE_V = -O2 -g<br>
-CFLAGS_OPTIMIZE_V += -ffunction-sections -fdata-sections<br>
+# CFLAGS_OPTIMIZE_V += -ffunction-sections -fdata-sections<br>
<br>
-LDFLAGS = -Wl,--gc-sections<br>
+# LDFLAGS = -Wl,--gc-sections<br>
<br>
<div class="moz-cite-prefix">On 4/2/2014 9:27 AM, Thomas Kim wrote:<br>
</div>
<blockquote cite="mid:CADY8aTBok1bHsL=qsXew_TT+hb2OmG-hNbc177Sz=T1ivgpEXQ@mail.gmail.com" type="cite">
<div dir="ltr">Hi,
<div><br>
</div>
<div>I didn't use --enable_cxx option because this option is C++ class API for rtems native c api.</div>
<div>Is it correct ?</div>
<div>Also, the reason about address unalignment is that the base address pointer for eh_frame is located on ctor_list. ctor_list is used for C++ global constructor.</div>
<div><br>
</div>
<div>After I modifed linkcmd.base for sis, eh_frame is generated. but, there is still a problem in classify_object_over_fdes() because CIE information is not correct.</div>
<div><br>
</div>
<div>If correct eh_frame section is generated, maybe, C++ throw handler will be worked.</div>
<div><br>
</div>
<div>If you have any idea for this, please let me know that.</div>
<div><br>
</div>
<div>Best Regards,</div>
<div>Thomas </div>
<div> </div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">2014-04-02 6:19 GMT+09:00 Joel Sherrill <span dir="ltr">
<<a moz-do-not-send="true" href="mailto:joel.sherrill@oarcorp.com" target="_blank">joel.sherrill@oarcorp.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
On 4/1/2014 4:10 PM, Cláudio Silva wrote:<br>
> If you are receiving trap 263 it should mean that you are receiving<br>
> trap 7 when subtracted with the synchronous bit. Trap 7 is memory<br>
> address not aligned in sis?<br>
It is and all SPARC BSPs use the same linkcmds.<br>
<br>
This may be dereferencing a special section which is not aligned<br>
enough. C++ has<br>
a number of them. The question is:<br>
<br>
What does the method classify_object_over_fdes() really do?<br>
<br>
Once we know the section(s) it uses, aligning it is easy.<br>
<br>
--joel<br>
> .<br>
> On Tue, Apr 1, 2014 at 9:36 PM, Joel Sherrill <<a moz-do-not-send="true" href="mailto:joel.sherrill@oarcorp.com">joel.sherrill@oarcorp.com</a>> wrote:<br>
>> On 4/1/2014 3:09 PM, Daniel Hellstrom wrote:<br>
>><br>
>> Hi,<br>
>><br>
>> The SPARC v7/v8 traps ends at 255, I dont have RTEMS code in front of me,<br>
>> perhaps there is a mask of 0x100 added to the trap number to indicate<br>
>> something.<br>
>><br>
>> OK. The 0x80 indicates synchronous trap:<br>
>><br>
>> /**<br>
>> * This macro indicates that @a _trap as a synchronous trap.<br>
>> */<br>
>> #define SPARC_SYNCHRONOUS_TRAP( _trap ) ((_trap) + 256 )<br>
>><br>
>> How about 137 or 0x87 which makes it a type of trap?<br>
>><br>
>> It is happening in classify_object_over_fdes if that helps.<br>
>><br>
>> --joel<br>
>><br>
>> Daniel<br>
>><br>
>> On 1 April 2014 17:44:38 CEST, Joel Sherrill <<a moz-do-not-send="true" href="mailto:joel.sherrill@oarcorp.com">joel.sherrill@oarcorp.com</a>><br>
>> wrote:<br>
>>> OK.. replying to self..<br>
>>><br>
>>> I made some changes locally and now have the examples-v2 sample<br>
>>> cxx_throw nearly running. I am down to the spurious exception handler<br>
>>> getting invoked on sis for exception 263 which I don't know what that<br>
>>> is. [1]<br>
>>><br>
>>> Does this run in gdb or exception mean anything to anyone?<br>
>>><br>
>>> (gdb) r<br>
>>> Starting program:<br>
>>> /home/joel/rtems-4.11-work/examples-v2/cxx/cxx_throw/o-optimize/cxx_throw.exe<br>
>>> Hey I'm in base class constructor number 1 for 0x2068384.<br>
>>> Hey I'm in base class constructor number 2 for 0x206837c.<br>
>>> Hey I'm in derived class constructor number 3 for 0x206837c.<br>
>>><br>
>>><br>
>>> *** CONSTRUCTOR/DESTRUCTOR TEST ***<br>
>>> Hey I'm in base class constructor number 4 for 0x20730f0.<br>
>>> Hey I'm in base class constructor number 5 for 0x20730f8.<br>
>>> Hey I'm in base class constructor number 6 for 0x2073100.<br>
>>> Hey I'm in base class constructor number 7 for 0x2073108.<br>
>>> Hey I'm in derived class constructor number 8 for 0x2073108.<br>
>>> Testing a C++ I/O stream<br>
>>> before try block<br>
>>><br>
>>> Breakpoint 1, _Terminate (<br>
>>> the_source=the_source@entry=RTEMS_FATAL_SOURCE_EXCEPTION,<br>
>>> is_internal=is_internal@entry=false,<br>
>>> the_error=the_error@entry=34011320)<br>
>>> at ../../../../../../rtems/c/src/../../cpukit/score/src/interr.c:36<br>
>>> 36 {<br>
>>> (gdb) bt<br>
>>> #0 _Terminate (the_source=the_source@entry=RTEMS_FATAL_SOURCE_EXCEPTION,<br>
>>> is_internal=is_internal@entry=false,<br>
>>> the_error=the_error@entry=34011320)<br>
>>> at ../../../../../../rtems/c/src/../../cpukit/score/src/interr.c:36<br>
>>> #1 0x0203c454 in rtems_fatal (<br>
>>> source=source@entry=RTEMS_FATAL_SOURCE_EXCEPTION,<br>
>>> error=error@entry=34011320)<br>
>>> at ../../../../../../rtems/c/src/../../cpukit/sapi/src/fatal2.c:34<br>
>>> #2 0x02035f48 in bsp_spurious_handler (trap=263, isf=0x20721d8)<br>
>>> at<br>
>>> ../../../../../../../../rtems/c/src/lib/libbsp/sparc/erc32/startup/spurious.c:131<br>
>>> #3 0x0205fda4 in dont_fix_pil2 ()<br>
>>> at<br>
>>> ../../../../../../../../rtems/c/src/lib/libbsp/sparc/erc32/../../sparc/shared/irq_asm.S:476<br>
>>> #4 0x0205fda4 in dont_fix_pil2 ()<br>
>>> at<br>
>>> ../../../../../../../../rtems/c/src/lib/libbsp/sparc/erc32/../../sparc/shared/irq_asm.S:476<br>
>>> Backtrace stopped: previous frame identical to this frame (corrupt stack?)<br>
>>> (gdb)<br>
>>> #0 _Terminate (the_source=the_source@entry=RTEMS_FATAL_SOURCE_EXCEPTION,<br>
>>> is_internal=is_internal@entry=false,<br>
>>> the_error=the_error@entry=34011320)<br>
>>> at ../../../../../../rtems/c/src/../../cpukit/score/src/interr.c:36<br>
>>> #1 0x0203c454 in rtems_fatal (<br>
>>> source=source@entry=RTEMS_FATAL_SOURCE_EXCEPTION,<br>
>>> error=error@entry=34011320)<br>
>>> at ../../../../../../rtems/c/src/../../cpukit/sapi/src/fatal2.c:34<br>
>>> #2 0x02035f48 in bsp_spurious_handler (trap=263, isf=0x20721d8)<br>
>>> at<br>
>>> ../../../../../../../../rtems/c/src/lib/libbsp/sparc/erc32/startup/spurious.c:131<br>
>>> #3 0x0205fda4 in dont_fix_pil2 ()<br>
>>> at<br>
>>> ../../../../../../../../rtems/c/src/lib/libbsp/sparc/erc32/../../sparc/shared/irq_asm.S:476<br>
>>> #4 0x0205fda4 in dont_fix_pil2 ()<br>
>>> at<br>
>>> ../../../../../../../../rtems/c/src/lib/libbsp/sparc/erc32/../../sparc/shared/irq_asm.S:476<br>
>>> Backtrace stopped: previous frame identical to this frame (corrupt stack?)<br>
>>> (gdb)<br>
>>><br>
>>><br>
>>> [1] I am not feeling 100% well and am at home today. So don't have<br>
>>> access to everything not inclination to hunt.<br>
>>><br>
>>><br>
>>> On 4/1/2014 10:21 AM, Joel Sherrill wrote:<br>
>>><br>
>>> I am confused. Did you build RTEMS with --enable-cxx?<br>
>>><br>
>>> Did you make the linkcmds changes discussed?<br>
>>><br>
>>> In RTEMS, the C++ global constructors are called by the first thread<br>
>>> that executes. Before that, almost anything a constructor is allowed<br>
>>> to do that is not pure computation or memory initialization would<br>
>>> not be valid because the OS and tasking are not running.<br>
>>><br>
>>> There is a call in _Thread_Handler to the constructor execution method.<br>
>>> The name varies by target so it is a macro named INIT. A few lines of code<br>
>>> later the user init task is invoked.<br>
>>><br>
>>> Let's keep this on rtems-users so others benefit from the discussion.<br>
>>><br>
>>> --joel<br>
>>> On 3/27/2014 9:00 PM, Thomas (Gmail) wrote:<br>
>>><br>
>>> On referencing, I misunderstood that _init() call not C++ constructor<br>
>>> function because there is not C++ constructor function in crti.o.<br>
>>><br>
>>> Today, after I make object dump file about elf file(cxx_throw.exe), I<br>
>>> checked that below objdump information. It included ++ constructor as like<br>
>>> below;<br>
>>><br>
>>> 02066130 <_init>:<br>
>>> 2066130: 9d e3 bf a0 save %sp, -96, %sp<br>
>>> 2066134: 7f fe 6c 60 call 20012b4 <frame_dummy><br>
>>> 2066138: 01 00 00 00 nop<br>
>>> 206613c: 7f ff e8 99 call 20603a0 <__do_global_ctors_aux><br>
>>> 2066140: 01 00 00 00 nop<br>
>>> 2066144: 81 e8 00 00 restore<br>
>>> 2066148: 81 c3 e0 08 retl<br>
>>> 206614c: 01 00 00 00 nop<br>
>>><br>
>>> I am sorry for my misunderstanding.<br>
>>><br>
>>> Best Regards<br>
>>><br>
>>><br>
>>> 2014-03-28 10:19 GMT+09:00 Thomas (Gmail) <<a moz-do-not-send="true" href="mailto:thomas73.kim@gmail.com">thomas73.kim@gmail.com</a>>:<br>
>>>> Please check that my modification is correct.<br>
>>>><br>
>>>> I modified linkcmds.base according to your comment.<br>
>>>><br>
>>>> (Before)<br>
>>>> KEEP (*(EXCLUDE_FILE (*crtend.o *crtend?.o ) .ctors))<br>
>>>> KEEP (*(SORT(.ctors.*)))<br>
>>>> KEEP (*(.ctors))<br>
>>>> KEEP (*crtbegin.o(.dtors))<br>
>>>> KEEP (*crtbegin?.o(.dtors))<br>
>>>> KEEP (*(EXCLUDE_FILE (*crtend.o *crtend?.o ) .dtors))<br>
>>>> KEEP (*(SORT(.dtors.*)))<br>
>>>> KEEP (*(.dtors))<br>
>>>><br>
>>>> (After)<br>
>>>> KEEP (*(EXCLUDE_FILE (*crtend.o *crtend?.o ) .ctors))<br>
>>>> KEEP (*(SORT(.ctors.*)))<br>
>>>> KEEP (*(.ctors*))<br>
>>>> KEEP (*crtbegin.o(.dtors))<br>
>>>> KEEP (*crtbegin?.o(.dtors))<br>
>>>> KEEP (*(EXCLUDE_FILE (*crtend.o *crtend?.o ) .dtors))<br>
>>>> KEEP (*(SORT(.dtors.*)))<br>
>>>> KEEP (*(.dtors*))<br>
>>>><br>
>>>> Also, I compared map file.<br>
>>>><br>
>>>> (Before)<br>
>>>> *(.ctors)<br>
>>>> .ctors 0x0206040c 0x4<br>
>>>> /opt/rtems-4.11/lib/gcc/sparc-rtems4.11/4.8.2/crtend.o<br>
>>>> *crtbegin.o(.dtors)<br>
>>>> .dtors 0x02060410 0x4<br>
>>>> /opt/rtems-4.11/lib/gcc/sparc-rtems4.11/4.8.2/crtbegin.o<br>
>>>> *crtbegin?.o(.dtors)<br>
>>>> *(EXCLUDE_FILE(*crtend?.o *crtend.o) .dtors)<br>
>>>> *(SORT(.dtors.*))<br>
>>>> *(.dtors)<br>
>>>><br>
>>>> (After)<br>
>>>> *(.ctors*)<br>
>>>> .ctors 0x0206040c 0x4<br>
>>>> /opt/rtems-4.11/lib/gcc/sparc-rtems4.11/4.8.2/crtend.o<br>
>>>> *crtbegin.o(.dtors)<br>
>>>> .dtors 0x02060410 0x4<br>
>>>> /opt/rtems-4.11/lib/gcc/sparc-rtems4.11/4.8.2/crtbegin.o<br>
>>>> *crtbegin?.o(.dtors)<br>
>>>> *(EXCLUDE_FILE(*crtend?.o *crtend.o) .dtors)<br>
>>>> *(SORT(.dtors.*))<br>
>>>> *(.dtors*)<br>
>>>><br>
>>>> Best Regards<br>
>>>><br>
>>>><br>
>>>> 2014-03-28 2:00 GMT+09:00 Joel Sherrill <<a moz-do-not-send="true" href="mailto:joel.sherrill@oarcorp.com">joel.sherrill@oarcorp.com</a>>:<br>
>>>>> I am out of the country and teaching this week. Trying adding an<br>
>>>>> "*" after ctors and before the parentheses. Ditto for dtors so it wild<br>
>>>>> card matches.<br>
>>>>><br>
>>>>> Look at how .text has a * on it<br>
>>>>> On 3/27/2014 10:25 AM, Thomas (Gmail) wrote:<br>
>>>>><br>
>>>>> I am tring to compare linkcmd.base and toolchain's elf32_sparc.x.<br>
>>>>> But, I am difficult to modify linkcmd.base for this.<br>
>>>>><br>
>>>>> Please could you send to me the revised linkcmd.base file ?<br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>> 2014-03-27 18:18 GMT+09:00 Joel Sherrill <<a moz-do-not-send="true" href="mailto:joel.sherrill@oarcorp.com">joel.sherrill@oarcorp.com</a>>:<br>
>>>>>> libgcc2 is already in the toolset. This almost 100% certainly is a<br>
>>>>>> small<br>
>>>>>> bug in c/src/lib/libbsp/sparc/shared/startup/linkcmds.base. Look<br>
>>>>>> at how the .ctors are referenced in the files elf32_sparc.x* installed<br>
>>>>>> as part of the toolset in $prefix/sparc-rtems4.11/lib/ldscripts. They<br>
>>>>>> have "." and a "*" in the KEEP lines. I don't think we have that.<br>
>>>>>><br>
>>>>>> The problem was almost certainly introduced with function sections<br>
>>>>>> being used and I missed a wildcard on the ctor/dtor lines.<br>
>>>>>><br>
>>>>>> On 3/27/2014 3:04 AM, Thomas (Gmail) wrote:<br>
>>>>>><br>
>>>>>> On referencing, I am a beginner regarding this.<br>
>>>>>><br>
>>>>>> As I know from googling information, name of the section for<br>
>>>>>> constructor is in .ctors section in linkcmds.base.<br>
>>>>>> below reference code is from gcc-4.8.2/libgcc/libgcc2.c<br>
>>>>>> because __do_global_ctors() function is in libgcc2.c, I tried to add<br>
>>>>>> libgcc.a in rtems building environment. but, I didn't complete.<br>
>>>>>><br>
>>>>>> < libgcc2.c ><br>
>>>>>><br>
>>>>>> ----------------------------------------------------------------------------------------------------<br>
>>>>>> /* Run all the global destructors on exit from the program. */<br>
>>>>>> void<br>
>>>>>> __do_global_ctors (void)<br>
>>>>>> {<br>
>>>>>> #ifdef EH_FRAME_SECTION_NAME<br>
>>>>>> {<br>
>>>>>> static struct object object;<br>
>>>>>> __register_frame_info (__EH_FRAME_BEGIN__, &object);<br>
>>>>>> }<br>
>>>>>> #endif<br>
>>>>>> DO_GLOBAL_CTORS_BODY;<br>
>>>>>> atexit (__do_global_dtors);<br>
>>>>>> }<br>
>>>>>><br>
>>>>>> -------------------------------------------------------------------------------------<br>
>>>>>><br>
>>>>>> < gbl-ctors.h><br>
>>>>>><br>
>>>>>> -------------------------------------------------------------------------------------<br>
>>>>>><br>
>>>>>> /* Some systems use a different strategy for finding the ctors.<br>
>>>>>> For example, svr3. */<br>
>>>>>> #ifndef DO_GLOBAL_CTORS_BODY<br>
>>>>>> #define DO_GLOBAL_CTORS_BODY \<br>
>>>>>> do { \<br>
>>>>>> unsigned long nptrs = (unsigned long) __CTOR_LIST__[0]; \<br>
>>>>>> unsigned i; \<br>
>>>>>> if (nptrs == (unsigned long)-1) \<br>
>>>>>> for (nptrs = 0; __CTOR_LIST__[nptrs + 1] != 0; nptrs++); \<br>
>>>>>> for (i = nptrs; i >= 1; i--) \<br>
>>>>>> __CTOR_LIST__[i] (); \<br>
>>>>>> } while (0)<br>
>>>>>> #endif<br>
>>>>>><br>
>>>>>><br>
>>>>>> -------------------------------------------------------------------------------------<br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>> 2014-03-27 16:33 GMT+09:00 Joel Sherrill <<a moz-do-not-send="true" href="mailto:joel.sherrill@oarcorp.com">joel.sherrill@oarcorp.com</a>>:<br>
>>>>>>><br>
>>>>>>> On 3/27/2014 2:30 AM, Sebastian Huber wrote:<br>
>>>>>>>> On 2014-03-27 06:28, Thomas (Gmail) wrote:<br>
>>>>>>>>> I am tring to add libgcc.a in linking process for calling<br>
>>>>>>>>> __do_global_ctors().<br>
>>>>>>>> If you have to do this by hand, then your build process is broken.<br>
>>>>>>>> How did you<br>
>>>>>>>> get the RTEMS tool chain? Which RTEMS version do you use?<br>
>>>>>>>><br>
>>>>>>>>> Please could you let me know how to add libgcc.a in RTEMS building<br>
>>>>>>>>> environment ?<br>
>>>>>>>>><br>
>>>>>>>>> If this approach is not correct, please let me know correct<br>
>>>>>>>>> how-to-do for C++<br>
>>>>>>>>> global constructor for Sparc.<br>
>>>>>>>> It should work out of the box.<br>
>>>>>>>><br>
>>>>>>> Just out of curiosity what is the name of the section that the<br>
>>>>>>> constructor is in?<br>
>>>>>>><br>
>>>>>>> When I turned on function sections, it may now be in .initXXX instead<br>
>>>>>>> of<br>
>>>>>>> just .init.<br>
>>>>>>> This would mean that an asterisk is needed in the linkcmds.base for<br>
>>>>>>> init<br>
>>>>>>> and fini<br>
>>>>>>> to pick up all the methods. There is a KEEP() around them which I<br>
>>>>>>> thought might<br>
>>>>>>> be the issue.<br>
>>>>>>><br>
>>>>>>> --<br>
>>>>>>> Joel Sherrill, Ph.D. Director of Research & Development<br>
>>>>>>> <a class="moz-txt-link-abbreviated" href="mailto:joel.sherrill@OARcorp.com">
joel.sherrill@OARcorp.com</a> On-Line Applications Research<br>
>>>>>>> Ask me about RTEMS: a free RTOS Huntsville AL 35805<br>
>>>>>>> Support Available (256) 722-9985<br>
>>>>>>><br>
>>>>>><br>
>>>>>> --<br>
>>>>>> Joel Sherrill, Ph.D. Director of Research & Development<br>
>>>>>> <a class="moz-txt-link-abbreviated" href="mailto:joel.sherrill@OARcorp.com">
joel.sherrill@OARcorp.com</a> On-Line Applications Research<br>
>>>>>> Ask me about RTEMS: a free RTOS Huntsville AL 35805<br>
>>>>>> Support Available (256) 722-9985<br>
>>>>><br>
>>>>><br>
>>>>> --<br>
>>>>> Joel Sherrill, Ph.D. Director of Research & Development<br>
>>>>> <a class="moz-txt-link-abbreviated" href="mailto:joel.sherrill@OARcorp.com">
joel.sherrill@OARcorp.com</a> On-Line Applications Research<br>
>>>>> Ask me about RTEMS: a free RTOS Huntsville AL 35805<br>
>>>>> Support Available (256) 722-9985<br>
>>>><br>
>>><br>
>>> --<br>
>>> Joel Sherrill, Ph.D. Director of Research & Development<br>
>>> <a class="moz-txt-link-abbreviated" href="mailto:joel.sherrill@OARcorp.com">joel.sherrill@OARcorp.com</a> On-Line Applications Research<br>
>>> Ask me about RTEMS: a free RTOS Huntsville AL 35805<br>
>>> Support Available (256) 722-9985<br>
>>><br>
>>><br>
>>> --<br>
>>> Joel Sherrill, Ph.D. Director of Research & Development<br>
>>> <a class="moz-txt-link-abbreviated" href="mailto:joel.sherrill@OARcorp.com">joel.sherrill@OARcorp.com</a> On-Line Applications Research<br>
>>> Ask me about RTEMS: a free RTOS Huntsville AL 35805<br>
>>> Support Available (256) 722-9985<br>
>><br>
>> --<br>
>> Sent from my Android phone with K-9 Mail. Please excuse my brevity.<br>
>><br>
<span class="HOEnZb"><font color="#888888">>><br>
>> --<br>
>> Joel Sherrill, Ph.D. Director of Research & Development<br>
>> <a class="moz-txt-link-abbreviated" href="mailto:joel.sherrill@OARcorp.com">joel.sherrill@OARcorp.com</a> On-Line Applications Research<br>
>> Ask me about RTEMS: a free RTOS Huntsville AL 35805<br>
>> Support Available (256) 722-9985<br>
>><br>
>><br>
>> _______________________________________________<br>
>> rtems-users mailing list<br>
>> <a moz-do-not-send="true" href="mailto:rtems-users@rtems.org">rtems-users@rtems.org</a><br>
>> <a moz-do-not-send="true" href="http://www.rtems.org/mailman/listinfo/rtems-users" target="_blank">
http://www.rtems.org/mailman/listinfo/rtems-users</a><br>
>><br>
<br>
--<br>
Joel Sherrill, Ph.D. Director of Research & Development<br>
<a class="moz-txt-link-abbreviated" href="mailto:joel.sherrill@OARcorp.com">joel.sherrill@OARcorp.com</a> On-Line Applications Research<br>
Ask me about RTEMS: a free RTOS Huntsville AL 35805<br>
Support Available (256) 722-9985<br>
<br>
</font></span></blockquote>
</div>
<br>
</div>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Joel Sherrill, Ph.D. Director of Research & Development
<a class="moz-txt-link-abbreviated" href="mailto:joel.sherrill@OARcorp.com">joel.sherrill@OARcorp.com</a> On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985</pre>
</div>
</body>
</html>