* [ECOS] Re: Some weirdnes with the tools
[not found] <000501bf195d$2c576080$56183a86@pc086-2.mech.kuleuven.ac.be>
@ 1999-10-18 5:14 ` Jesper Skov
[not found] ` <000601bf1963$2f158760$56183a86@pc086-2.mech.kuleuven.ac.be>
1999-10-18 5:38 ` [ECOS] " Gary Thomas
0 siblings, 2 replies; 3+ messages in thread
From: Jesper Skov @ 1999-10-18 5:14 UTC (permalink / raw)
To: bob.koninckx; +Cc: ecos-discuss
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
------------------------------------------------------------------------
^ permalink raw reply [flat|nested] 3+ messages in thread
* [ECOS] RE: Some weirdnes with the tools
[not found] ` <000601bf1963$2f158760$56183a86@pc086-2.mech.kuleuven.ac.be>
@ 1999-10-18 5:34 ` Jesper Skov
0 siblings, 0 replies; 3+ messages in thread
From: Jesper Skov @ 1999-10-18 5:34 UTC (permalink / raw)
To: bob.koninckx; +Cc: ecos-discuss
>>>>> "Bob" == Bob Koninckx <bob.koninckx@mail.mech.kuleuven.ac.be> writes:
Bob> No, That's certainly not the problem, memory allocation works
Bob> fine. It looks more like a problem that occured with the ARM
Bob> toolchain (The last one on the known problem list)
[please remember to CC the ecos-discuss list]
Come to think of it,we may have seen this, or a similar, problem
before. Try removing the -fvtable-gc option.
Jesper
^ permalink raw reply [flat|nested] 3+ messages in thread
* RE: [ECOS] Re: Some weirdnes with the tools
1999-10-18 5:14 ` [ECOS] Re: Some weirdnes with the tools Jesper Skov
[not found] ` <000601bf1963$2f158760$56183a86@pc086-2.mech.kuleuven.ac.be>
@ 1999-10-18 5:38 ` Gary Thomas
1 sibling, 0 replies; 3+ messages in thread
From: Gary Thomas @ 1999-10-18 5:38 UTC (permalink / raw)
To: Jesper Skov; +Cc: ecos-discuss, bob.koninckx
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
> ------------------------------------------------------------------------
>
>
>
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~1999-10-18 5:38 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <000501bf195d$2c576080$56183a86@pc086-2.mech.kuleuven.ac.be>
1999-10-18 5:14 ` [ECOS] Re: Some weirdnes with the tools Jesper Skov
[not found] ` <000601bf1963$2f158760$56183a86@pc086-2.mech.kuleuven.ac.be>
1999-10-18 5:34 ` [ECOS] " Jesper Skov
1999-10-18 5:38 ` [ECOS] " Gary Thomas
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).