C++ objects with virtual tables in eeprom

C++ objects with virtual tables in eeprom

[jon.busenkell]

Hello all:

I am wondering if anyone has ever implemented a __attribute__ or #pragma
statement for use with constructors to specify to the compiler that the
object does not exist in ram; therefore it can not just do a "MOV.L
<reg>,<memory>" with the register containing the virtual tables address.
The compiler I am presently using (from the chip vendor) does not take
into account that C++ objects that have virtual tables, might reside in
the eeprom. I am asking them to add this feature, and they are asking me
if there is a standard way of handling this. Any thoughts would be
greatly appreciated.

Thank you,
Jon

Re: C++ objects with virtual tables in eeprom

[Ian Lance Taylor]

jon.busenkell@rsa.com writes:

> I am wondering if anyone has ever implemented a __attribute__ or #pragma
> statement for use with constructors to specify to the compiler that the
> object does not exist in ram; therefore it can not just do a "MOV.L
> <reg>,<memory>" with the register containing the virtual tables address.
> The compiler I am presently using (from the chip vendor) does not take
> into account that C++ objects that have virtual tables, might reside in
> the eeprom. I am asking them to add this feature, and they are asking me
> if there is a standard way of handling this. Any thoughts would be
> greatly appreciated.

I don't really understand your question.  Is the EEPROM not
addressable?  That seems like a problem.

The usual gcc approach for handling these sorts of issues is to use a
variable attribute to put the variable in a specific section, and to
use the linker script to place that section appropriately, possibly
with different load and runtime addresses (see the GNU linker
documentation for details).  gcc's role is to support the variable
attribute and to ensure that the virtual table goes in the right
section.  That said, I don't know whether gcc actually does put the
virtual table in the right section.

Ian

RE: C++ objects with virtual tables in eeprom

[jon.busenkell]

Ian,

The EEPROM is not directly write addressable, executing and reading are
directly addressable. Either using gcc or other compiler's I can place
the object(variable) where I want it. But then all the compilers that I
have tried, use some sort of direct addressing to write the vtable's
address into the object. My thought was that if the compiler generated a
call to an out-of-line function like: 
void setVtableAddress( object* dest, vtable* value )
{
	*((uint32_t*)dest) = value;
}

Then in could right an overload for the function that would do the
correct operation, and place this function as the first module to link.
There-by replacing the compiler's library function. 

While I realize this adds a performance overhead, I suggested to the
vendor that this could be controlled by a command line switch. There
response was how about doing it with a pragma.

Just to summarize; getting object into the locations I want them in
memory, and writing to them is not a problem, because I can control all
that. My only problem is with the code that the compiler generates to
set the vtable's address in the object.

Thank you,
Jon

-----Original Message-----
From: Ian Lance Taylor [mailto:iant@google.com] 
Sent: Thursday, August 21, 2008 10:37 AM
To: Busenkell, Jon
Cc: gcc-help@gcc.gnu.org
Subject: Re: C++ objects with virtual tables in eeprom

jon.busenkell@rsa.com writes:

> I am wondering if anyone has ever implemented a __attribute__ or
#pragma
> statement for use with constructors to specify to the compiler that
the
> object does not exist in ram; therefore it can not just do a "MOV.L
> <reg>,<memory>" with the register containing the virtual tables
address.
> The compiler I am presently using (from the chip vendor) does not take
> into account that C++ objects that have virtual tables, might reside
in
> the eeprom. I am asking them to add this feature, and they are asking
me
> if there is a standard way of handling this. Any thoughts would be
> greatly appreciated.

I don't really understand your question.  Is the EEPROM not
addressable?  That seems like a problem.

The usual gcc approach for handling these sorts of issues is to use a
variable attribute to put the variable in a specific section, and to
use the linker script to place that section appropriately, possibly
with different load and runtime addresses (see the GNU linker
documentation for details).  gcc's role is to support the variable
attribute and to ensure that the virtual table goes in the right
section.  That said, I don't know whether gcc actually does put the
virtual table in the right section.

Ian

Re: C++ objects with virtual tables in eeprom

[Ian Lance Taylor]

jon.busenkell@rsa.com writes:

> The EEPROM is not directly write addressable, executing and reading are
> directly addressable. Either using gcc or other compiler's I can place
> the object(variable) where I want it. But then all the compilers that I
> have tried, use some sort of direct addressing to write the vtable's
> address into the object. My thought was that if the compiler generated a
> call to an out-of-line function like: 
> void setVtableAddress( object* dest, vtable* value )
> {
> 	*((uint32_t*)dest) = value;
> }
>
> Then in could right an overload for the function that would do the
> correct operation, and place this function as the first module to link.
> There-by replacing the compiler's library function. 
>
> While I realize this adds a performance overhead, I suggested to the
> vendor that this could be controlled by a command line switch. There
> response was how about doing it with a pragma.
>
> Just to summarize; getting object into the locations I want them in
> memory, and writing to them is not a problem, because I can control all
> that. My only problem is with the code that the compiler generates to
> set the vtable's address in the object.

I see.  Yeah, g++ doesn't have anything to help you here today.  I
think this is a special case of an old general bug:
http://gcc.gnu.org/PR4131 .  Your suggestion of an overridable
function is interesting, but I personally would prefer to see a fix
for the general case.

The new constexpr keyword in C++0x may help, but g++ does not yet
implement it.

Ian