false positive, but a workaround...

Ed Sutter ed.sutter at alcatel-lucent.com
Wed Jun 24 15:47:41 UTC 2015

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?
Note, I never incorporated ANY cpu-specific code in these libc-type 
Optimizations are beautiful, but for a bootmonitor, simplicity (IMHO) 
overrides that.
>>>> 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

More information about the umon-devel mailing list