Union defined as .noinit fails to place in .noinit section

Go To Last Post
5 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A question was posted in this thread how to make a union variable noinit?

Johan had posted this:

larryvc wrote:
To answer your question completely, this
union tbyte               //Creates a triple byte union for transmitting
{		                   //24bit variables via Synapse engine.
	unsigned long int value;
	unsigned char bytes[3];
};

__attribute__((section (".noinit")))
union tbyte enc_pos;      //Triple Byte reserved for local encoder count

__attribute__((section (".noinit")))
union tbyte setPoint;     //Triple Byte reserved for incoming setpoint

or this

__attribute__((section (".noinit")))
union tbyte               //Creates a triple byte union for transmitting
{                         //24bit variables via Synapse engine.
	unsigned long int value;
	unsigned char bytes[3];
} enc_pos, setPoint;

will put both enc_pos and setPoint in the .noinit section.

This did not put enc_pos or setPoint in the .noinit section.

__attribute__((section (".noinit")))
union tbyte               //Creates a triple byte union for transmitting
{                         //24bit variables via Synapse engine.
	unsigned long int value;
	unsigned char bytes[3];
};

union tbyte enc_pos;      //Triple Byte reserved for local encoder count
union tbyte setPoint;     //Triple Byte reserved for incoming setpoint

Anyone know why?

Can some of you GCC gurus explain why that failed? If the union is defined with attribute .noinit what would be the difference between the last two examples? :?

=================================================================================

EDIT: Editing is now a real pain in the CAPTCHA. Sorry if this was fluid while you were reading it. Using AS6.

"I may make you feel but I can't make you think" - Jethro Tull - Thick As A Brick

"void transmigratus(void) {transmigratus();} // recursio infinitus" - larryvc

"It's much more practical to rely on the processing powers of the real debugger, i.e. the one between the keyboard and chair." - JW wek3

"When you arise in the morning think of what a privilege it is to be alive: to breathe, to think, to enjoy, to love." -  Marcus Aurelius

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Can some of you GCC gurus explain why that failed? If the union is defined with attribute .noinit what would be the difference between the last two examples?

In the first example the attribute is attached to the variables, in the second you try to attach it to the union type. There is no official support for decorating types with section attributes in GCC. It works in many cases (especially with older versions), but merely by accident.

BTW: For the same reason the prog_* types from are deprecated now.

Stefan Ernst

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for the answer, that makes perfect sense now.

"I may make you feel but I can't make you think" - Jethro Tull - Thick As A Brick

"void transmigratus(void) {transmigratus();} // recursio infinitus" - larryvc

"It's much more practical to rely on the processing powers of the real debugger, i.e. the one between the keyboard and chair." - JW wek3

"When you arise in the morning think of what a privilege it is to be alive: to breathe, to think, to enjoy, to love." -  Marcus Aurelius

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

larryvc wrote:
Can some of you GCC gurus explain why that failed?
The section attributes makes no sense with types. Please read again the GCC documentation on supported type attributes.

If you feel that GCC should issue a diagnostic with -Wattributes but fails to do so, please file a bug report after you ensured yourself that the problem is still present in oldest maintained release of GCC, which is 4.6.3 or any newer version.

sternst wrote:
For the same reason the prog_* types from are deprecated now.
It would have been possible to support PR38342 "progmem for types", but the decision was to not support it, thus the PR is closed "Won't fix".

One reason is the one you mentioned: progmem acts very much like section(), except that it is even more restrictive and requires read-only objects.

A second readon is the permanent shortage of guy that are contributing to avr-gcc: Better put effort into resonable stuff instead of into supporting syntax/semantics that nobody who reads the documentation will ever need...

avrfreaks does not support Opera. Profile inactive.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Johann,

My confusion was why the variables did not pick up the attribute in the failed example as they had when they were declared with the union definition and Stefan cleared that up for me.

SprinterSB wrote:
The section attributes makes no sense with types. Please read again the GCC documentation on supported type attributes.

If you feel that GCC should issue a diagnostic with -Wattributes but fails to do so, please file a bug report...


So this generates a diagnostic

union __attribute__((section (".noinit"))) tbyte
{
	...
};

while this does not

__attribute__((section (".noinit"))) 
union tbyte
{
	...
};

Is it worth posting a bug report? I think not. :)

"I may make you feel but I can't make you think" - Jethro Tull - Thick As A Brick

"void transmigratus(void) {transmigratus();} // recursio infinitus" - larryvc

"It's much more practical to rely on the processing powers of the real debugger, i.e. the one between the keyboard and chair." - JW wek3

"When you arise in the morning think of what a privilege it is to be alive: to breathe, to think, to enjoy, to love." -  Marcus Aurelius