false positive, but a workaround...

Ed Sutter ed.sutter at alcatel-lucent.com
Wed Jun 24 16:07:12 UTC 2015


On 6/24/2015 12:00 PM, Joel Sherrill wrote:
> On 6/24/2015 10:51 AM, Ed Sutter wrote:
>> On 6/24/2015 11:48 AM, Gedare Bloom wrote:
>>> On Wed, Jun 24, 2015 at 11:44 AM, Ed Sutter
>>> <ed.sutter at alcatel-lucent.com> wrote:
>>>> On 6/24/2015 10:57 AM, Joel Sherrill wrote:
>>>>>
>>>>> On 6/24/2015 9:40 AM, Ed Sutter wrote:
>>>>>> On 6/24/2015 10:41 AM, Jarielle Catbagan wrote:
>>>>>>> On Wed, Jun 24, 2015 at 6:10 AM, Ed Sutter
>>>>>>> <ed.sutter at alcatel-lucent.com> wrote:
>>>>>>>> Jarielle,
>>>>>>>> Well, it took almost 5 hours to build the tools last night. 
>>>>>>>> Obviously I
>>>>>>>> need
>>>>>>>> to upgrade the machine I have
>>>>>>>> this stuff running on at home!
>>>>>>>>
>>>>>>>> Anyway, this AM I was able to walk through what I thought I had 
>>>>>>>> done in
>>>>>>>> work
>>>>>>>> yesterday, and unfortunately due
>>>>>>>> to the fact that I am working in two different locations on two
>>>>>>>> different
>>>>>>>> machines (very very inefficient, but I'm
>>>>>>>> stuck in this mode at the moment); I fooled myself yesterday 
>>>>>>>> thinking I
>>>>>>>> had
>>>>>>>> stubbed out the __ctype_ptr__
>>>>>>>> declarations from docmd.c...  Unfortunately, I didn't :-(, so 
>>>>>>>> what I
>>>>>>>> thought
>>>>>>>> built clean didn't.
>>>>>>>>
>>>>>>>> Anyway, I want to get you over this hump quickly 'cause this 
>>>>>>>> isn't what
>>>>>>>> I'd
>>>>>>>> like you to be working on.  I really
>>>>>>>> want you to concentrate on beaglebone-specific stuff. That's the
>>>>>>>> important
>>>>>>>> stuff.  Today I brought my beaglebone
>>>>>>>> board to the office, and I've got it working clean now using a 
>>>>>>>> local
>>>>>>>> set of
>>>>>>>> ctype.h and ctypetbl.c files as I had in
>>>>>>>> umon1.19.  For now this is temporary, but it may turn out to be 
>>>>>>>> the
>>>>>>>> most
>>>>>>>> efficient way to get around this.
>>>>>>> These files would conflict with the licenses, am I right? Would a
>>>>>>> permanent solution be to implement a new local ctype.h?
>>>>>> Yep, that's exactly what I'm looking in to.  :-)
>>>>>> Just wanted to get you rolling meanwhile...
>>>>> All code in newlib has appropriate licenses. It would be easier to
>>>>> selectively pull in files from there. We just need to be careful
>>>>> to ensure we know versions so updates can occur. But that's true
>>>>> for every place you could grab from.
>>>>>
>>>>> New software has new bugs.
>>>>>
>>>>> Do you happen to have a master list of what methods you used
>>>>> in the original source base?
>>>> Back when I originally gave Amar the tarball, I stripped out all 
>>>> that I
>>>> thought was questionable for RTEMS.
>>>>
>>>> The two blocks of code that are not mine are zlib and glib.
>>>> zlib: I got this from Mark Adler decades ago (umon/main/zlib/README).
>>>> glib: subset of libc code i pulled in from a freebsd github
>>>> (umon/main/glib/getglib)
>>>>
>>> zlib is fine we include it's source in RTEMS too.
>>>
>>> I don't know about glib, but if it is in freebsd / has BSD headers it
>>> should be ok.
>> Regarding the current ctype problem, I was going to incorporate a
>> modified version of this file:
>> http://fxr.watson.org/fxr/source/sys/ctype.h
>> Is that legal for RTEMS?
> Sure. Just avoid any BSD license which requires author attribution.
So things like this:
http://www.menie.org/georges/embedded/crc16.c
and this:
http://read.pudn.com/downloads10/sourcecode/math/41641/EE.C__.htm
are not acceptable for RTEMS, correct?


>
> And try to get it all from a consistent version like FreeBSD 10.
>
> And I agree with keeping it all in simple portable C without cpu-specific
> versions is the way to go.
>
>
>
>>>
>>>> I have not updated them since original incorporation into uMon.
>>>> If necessary, I suppose I could update the glib files to be sourced 
>>>> from
>>>> newlib (lemme know).
>>>>
>>>> Aside from a few other files that Cogent and a few other uMon users
>>>> contributed,
>>>> I wrote the rest.
>>>>
>>>>>>>> So, attached to this are three files:
>>>>>>>> ctypetbl.c:  put this under main/glib
>>>>>>>> ctype.h:      put this under main/common
>>>>>>>> mydiffs:     small list of diffs based on the tree after 
>>>>>>>> installing
>>>>>>>> your
>>>>>>>> initial set of 24 patches.
>>>>>>>>                        most of these changes you probably have, 
>>>>>>>> the
>>>>>>>> important
>>>>>>>> one is in main/make/common.make so that ctypetbl.c is built.
>>>>>>>>
>>>>>>>> If you can incorporate these changes into a tree that starts 
>>>>>>>> with the
>>>>>>>> master
>>>>>>>> and has your initial 24 patches applied,
>>>>>>>> you should be good to go.  I know I should be using git to 
>>>>>>>> email you
>>>>>>>> patches, but I'm still trying to figure out how to
>>>>>>>> do that and I don't want you to be delayed by that.
>>>>>>>>
>>>>>>>> Does this make sense to you?
>>>>>>> Yes.  Ok, I'll incorporate those files and I believe you are right
>>>>>>> that everything should be all set.
>>>>>>>
>>>>>>>> Ed
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> umon-devel mailing list
>>>>>>>> umon-devel at rtems.org
>>>>>>>> http://lists.rtems.org/mailman/listinfo/umon-devel
>>>>>>
>>>> _______________________________________________
>>>> umon-devel mailing list
>>>> umon-devel at rtems.org
>>>> http://lists.rtems.org/mailman/listinfo/umon-devel
>> _______________________________________________
>> umon-devel mailing list
>> umon-devel at rtems.org
>> http://lists.rtems.org/mailman/listinfo/umon-devel
>
>



More information about the umon-devel mailing list