This is the mail archive of the ecos-discuss@sourceware.cygnus.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

RE: Re: Some weirdnes with the tools


I think the problem here is that the 'm_cob->create()' function is declared 
"virtual". There is a known problem with this with our use of --gc-sections 
in the linker.  If the "create" function is only ever referenced as a virtual
function of the class, the linker can't tell that it is being used and
it will blissfully optimize it out of the resulting application.

For the time being a work-around is to remove '-fvtable-gc' from your
compile-time flags.  This will preserve your virtual functions.

On 18-Oct-99 Jesper Skov wrote:
> 
> If I'm not mistaken (and I may very well be) the problem is caused
> because you use a 'new' operator without defining it. I think it calls
> malloc() and throws an exception if the allocation fails. Remember
> that C++ exceptions are not handled when you use the default compiler
> arguments. 
> 
> Anyway, this is beyond me. I'm not the biggest C++ hacker there ever
> was, I must admit. You should have asked on the list directly where
> you would be more likely to get a correct answer.
> 
> 
> Jesper
> 
> --------------------
> Hi Jesper,
> This WE, I came accross something I really do not understand. I am working
> on a package implementing the CANopen protocol. I am writing this in C++.
> 
> It contains something like this :
> 
> class CommunicationObject
> { ...
>   public:
>     virtual      ~CommunicationObject();
>     virtual void create(void) = 0;
>     virtual void destroy(void) = 0;
> };
> 
> class TxCOB : public CommunicationObject
> { ...
>   public:
>     virtual      ~TxCOB();
>     virtual void create(void);
>     virtual void destroy(void);
> };
> 
> class RxCOB : public CommunicationObject
> { ...
>   public:
>     virtual      ~RxCOB();
>     virtual void create();
>     virtual void destroy(void);
> };
> 
> template <class Type>
> class CMS_Variable
> {
>   ....
> 
>   protected:
>     CommunicationObject * m_cob;
> };
> 
> template <class Type>
> class CMS_ServerVar : public CMS_Variable<Type>
> {
>   public:
>     CMS_ServerVar()
>     {
>       m_cob = new TxCOB();
>       m_cob->create();
>     }
> };
> 
> template <class Type>
> class CMS_ClientVar : public CMS_Variable<Type>
> {
>   public:
>     CMS_ServerVar()
>     {
>       m_cob = new RxCOB();
>       m_cob->create();
>     }
> };
> 
> typedef CMS_ServerVar<int> CMS_IntServerVar;
> typedef CMS_ClientVar<int> CMS_IntClientVar;
> 
> It compiles and links fine, no problem there.
> 
> 
> The strange thing is when I use it from the application that is linked
> against the ECOS library.
> 
> An application like
> 
> main()
> {
>   CMS_IntServerVar server();
>   CMS_IntClientVar client();
> 
>   return 0;
> }
> 
> Crashes on the call to m_cob->create(). When I look at the v-table of both
> TxCOB and RxCOB, it is partially filled with zeros. (the create function is
> a zero, the destroy is not)
> 
> If I rewrite the application as follows
> 
> main()
> {
>   TxCOB txcob();
>   CommunicationObject * cob = &txcob;
>   cob->create()
> 
>   CMS_IntServerVar server();
>   CMS_IntClientVar client();
> 
>   return 0;
> }
> 
> everything goes fine and the v-tables of both TxCOB and RxCOB are filled in
> correctly.
> It looks like only classes that are explicitly instantiated outside the ECOS
> library have correctly filled in v-tables (although that doesn't make much
> sense to me).
> 
> Have you ever come accross something like this ?? Or am I doing something
> wrong ?? What section are the v-tables stored in anyway (looks like they are
> in .rodata, I am not sure though) I use the EcosSWTools that I downloaded
> from the web (with the Redhat 6.0 patch)
> 
> If you don't know an answer, can you post this on the appropriate discussion
> forum please.
> 
> Regards,
> Bob
> 
> ------------------------------------------------------------------------
> ir. Bob Koninckx
> Katholieke Universiteit Leuven
> Division Production Engineering,                      tel. +32 16 322535
> Machine Design and Automation                         fax. +32 16 322987
> Celestijnenlaan 300B                 bob.koninckx@mech.kuleuven.ac.be
> B-3001 Leuven Belgium            http://www.mech.kuleuven.ac.be/pma.html
> ------------------------------------------------------------------------
> 
> 
> 

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]