[ECOS] Fw: [ECOS] ecos kernel modification and kapidata

[Yi Tang]

Hi,

It is been solved. I first disabled the thread linked list and debuged 
through my new scheduler. After that, I reenable the thread linked list and 
it works fine now. I think it is due to the stack overflow and memory 
corruption.

During the process, I found one bug related the thread prioirty option in 
thread.inl and thread.hxx. As my scheduler is priority free and thus I turn 
the option off and found one #ifdef bugs. Just wondering where to report 
that?

Regards,
Yi Tang

----- Original Message ----- 
From: "Yi Tang" <yitang@itee.uq.edu.au>
To: "Andrew Lunn" <andrew@lunn.ch>
Cc: "eCos-discuss" <ecos-discuss@ecos.sourceware.org>
Sent: Wednesday, September 12, 2007 12:22 AM
Subject: Re: [ECOS] ecos kernel modification and kapidata


> Hi Andrew and all,
>
> Thanks for your reply. I'm trying to build a custom scheduler which is 
> OSEKtime compliant (a first in last out (stack) queue based scheduler).
>
> I use the lottery scheduler as prototype and create the new scheduler. The 
> new kernel is complied successfully. The test is also built good.
>
> However, in the execution, some other part of the kernel behave strangely. 
> In the thread creation part, the <add to list> function went wrong 
> somehow. According to the code, the thread_list should be a circular 
> queue. During the execution, in the function (attach_stack) called at the 
> start of thread creation, the pointer "thread_list->list_next" is modified 
> into a new value and broke the circular queue.
>
> I don't quite understand why this will happen. I didn't touch anything in 
> kernel except change the scheduler implementation file. I guess it can be 
> the kernel's size is changed or the complier's problem.
>
> I have tried to use the bitmap to run the same code. That runs well.
>
> I totally have no idea about it and hope someone kind enough to help me.
>
> Thanks and regards,
> Yi Tang
>
>
> ----- Original Message ----- 
> From: "Andrew Lunn" <andrew@lunn.ch>
> To: "Yi Tang" <yitang@itee.uq.edu.au>
> Cc: "eCos-discuss" <ecos-discuss@ecos.sourceware.org>
> Sent: Friday, September 07, 2007 7:31 PM
> Subject: Re: [ECOS] ecos kernel modification and kapidata
>
>
>> On Fri, Sep 07, 2007 at 02:49:41PM +1000, Yi Tang wrote:
>>> Hi,
>>>
>>> I'm currently doing some modification to ecos kernel, mainly trying to 
>>> add
>>> a custom scheduler. I have created my own scheduler implementation file 
>>> and
>>> changed some to kapi.cxx (hxx).
>>>
>>> I thought that's all. After finished the cdl modification to add the new
>>> scheduler, I tried to build the library. But during the compiling, it 
>>> says
>>> I also need to do some modification to kapidata.hxx.
>>
>> Could you be more specific about this....
>>
>>> The thing is I don't understand the role this file takes in the whole
>>> kernel.
>>
>> There is a nice comment in kapidata.h
>>
>> Description: This file defines the structures used in the native API. The
>> //              sizes of these structures are dependent on the system
>> //              configuration and must be kept in step with their real
>> //              counterparts in the C++ headers.
>> //              IMPORTANT: It is NOT guaranteed that the fields of these
>> //              structures correspond to the equivalent fields in the
>> //              C++ classes they shadow.
>> //
>> //              One oddity with this file is that the way many of the 
>> "mirror"
>> //              classes are defined with macros. The resulting structures
>> //              then have a "flat" layout, rather than just declaring a
>> //              member structure directly in the structure. The reason 
>> for
>> //              this is that as of GCC 3.x, the C++ compiler will 
>> optimise
>> //              classes by removing padding and reusing it for subsequent
>> //              members defined in a derived class. This affects some 
>> targets
>> //              (including PowerPC and MIPS at least) when a C++ base 
>> class
>> //              includes a long long. By instead arranging for the C 
>> structure
>> //              to just list all the members directly, the compiler will 
>> then
>> //              behave the same for the C structures as the C++ classes.
>> //
>> //              This means that care has to be taken to follow the same
>> //              methodology if new stuff is added to this file. Even if
>> //              it doesn't contain long longs for your target, it may for
>> //              others, depending on HAL definitions.
>> //
>>
>> The memory for kernel data structures, like threads, mutexes, flags
>> etc are allocated in applications C code. However these structures are
>> actually used as classes in the C++ code. You need to ensure that the
>> C structure is the same size as the C++ class. If not, bad things will
>> happen. If you have added members to a class, you also need to add
>> extra members to the C structures. Otherwise too little memory will be
>> allocated.
>>
>>
>>> Also is there any other source file I need to modify?
>>
>> Hard to say. It sounds like you have made major changes to the API, so
>> without seeing your code it is impossible to say.
>>
>>        Andrew
>>
>> -- 
>> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
>> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
>>
>>
>
>
>
> -- 
> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
>
> 



-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss