From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5801 invoked by alias); 12 Sep 2007 11:45:12 -0000 Received: (qmail 5791 invoked by uid 22791); 12 Sep 2007 11:45:11 -0000 X-Spam-Check-By: sourceware.org Received: from gum.itee.uq.edu.au (HELO gum.itee.uq.edu.au) (130.102.66.1) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 12 Sep 2007 11:45:01 +0000 Received: from filter2.itee.uq.edu.au (filter2.itee.uq.edu.au [130.102.66.22]) by gum.itee.uq.edu.au (8.13.1/8.13.1) with ESMTP id l8CBirTJ020232; Wed, 12 Sep 2007 21:44:54 +1000 Received: from g5099368 (g509-9368.itee.uq.edu.au [130.102.64.130]) by filter2.itee.uq.edu.au (8.13.1/8.13.1) with SMTP id l8CBirhK009962; Wed, 12 Sep 2007 21:44:53 +1000 Message-ID: <001101c7f532$554c6b70$82406682@itee.uq.edu.au> Reply-To: "Yi Tang" From: "Yi Tang" To: "Andrew Lunn" Cc: "eCos-discuss" Date: Wed, 12 Sep 2007 11:45:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-IsSubscribed: yes Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Subject: [ECOS] Fw: [ECOS] ecos kernel modification and kapidata X-SW-Source: 2007-09/txt/msg00067.txt.bz2 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" To: "Andrew Lunn" Cc: "eCos-discuss" 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 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" > To: "Yi Tang" > Cc: "eCos-discuss" > 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