Re: Proposal: readable and writable attributes on variables

[Florian Weimer]

On 08/30/2016 02:22 PM, Jens Bauer wrote:

Hi all.

I know it's possible to declare a variable 'read-only' by using 'const'.

When working with microcontrollers (small ICs, which often requires you to 
write your code at driver-level), you need to be able to declare a structure 
member 'read-only', 'write-only' or 'read+write'.
In addition to that, it would definitely be handy to declare variables 'no 
access'

So I'd like to propose the following two attributes, which is 'off' by default 
(eg. read access + write access):
__attribute__((not_readable))
__attribute__((not_writable))

Any combination of those allowed.


You can already do this:

“
int my_register;

#define store_my_register(val) (my_register = (val))

#pragma GCC poison my_register
”

And GCC will reject any access to my_register.

Is this solution good enough?

Florian

Re: Proposal: readable and writable attributes on variables

[Jens Bauer]

Hi Florian.

On Thu, 1 Sep 2016 15:21:27 +0200, Florian Weimer wrote:
>> So I'd like to propose the following two attributes, which is 'off' 
>> by default (eg. read access + write access):
>> __attribute__((not_readable))
>> __attribute__((not_writable))
> 
> You can already do this:
> 
> “
> int my_register;
> 
> #define store_my_register(val) (my_register = (val))
> 
> #pragma GCC poison my_register
> ”
> 
> And GCC will reject any access to my_register.

I very much appreciate this enlightenment. Thank you. :)

> Is this solution good enough?

It is helpful, I'll try and play a little with it; I'm not thinking about my 
own needs in this case, though.

I have a few concerns about the above solution:
1: As far as I know, the CMSIS library is not allowed to make use of #pragma (I 
think this is for compatibility/portability reasons).
2: There are many people working with microcontrollers (ARM/PIC/AVR/others; 
especially after the Arduino-boom).
These people would want their C code to look like it usually does. ;)
3: There's also another party involved; the chip manufacturer. The chip 
manufacturer usually provides an IDE (based upon Eclipse with the GCC toolchain 
and OpenOCD). They build upon CMSIS and they would likely not want to change 
their library code.

If it was up to me, to decide how to solve it, I think I would want to use 
typedef and make a type for each of the modes on uint8_t, uint16_t, uint32_t 
and uint32_t *.
It's not a perfect solution either, because some people are already using __IO, 
__I and __O in their code. They would be able to quickly switch to a different 
type, though - but since it might be possible by adding attributes and changing 
the existing macro, I personally favour this approach.

It would also be easy for developers who write device drivers on platforms like 
Linux, Windows, Mac, etc. to just prefix their structure members with the macro 
and then click the "compile" button.

Note: Many copies of the core_cm4.h include files can be found on the net, 
including this one:

-It contains all the combinations of the permissions in the two structures 
NVIC_Type and SCB_Type.
The "blank" uint32_t should really be __NA (no access); eg. the reserved fields.

The structures are used in this way:

uint32_tcpuid;

cpuid = SCB->CPUID; /* this register is only readable, not 
writable. */
NVIC->STIR = (1 << 3);  /* this register is only writable, not 
readable. */

Some hardware registers behave "strange" compared to how RAM behaves.
Writing a set bit to a status register will clear the bit in the same register. 
(this does not apply to all status registers; this is just an example on how 
some status registers behave).


Love
Jens

Re: Proposal: readable and writable attributes on variables

[Martin Sebor]

On 08/31/2016 04:56 AM, Jens Bauer wrote:

Hi Martin (and everyone else on the gcc list).

I appreciate your input and kind reply to my proposal. :)

On Tue, 30 Aug 2016 20:44:35 -0600, Martin Sebor wrote:

This sounds reasonable and useful to me but to be fully integrated
into the language, attribute not_readable would need to be elevated
to the status of a type qualifier analogous to const.  Otherwise it
would (likely, if applied as most other attributes) be lost during
conversions such as in

   __attribute__ ((not_readable)) int write_only;
   int *preadwrite = &write_only;


Would it not be possible to bring a warning in such cases ?
-or would that actually require a kludge ?


I would expect it to be easier to issue a warning than to add support
for a whole new type qualifier to the two GCC front ends (C and C++).
The latter, of course, has the advantage of a more robust solution.


If it's not possible (or if it's too complicated to bring a warning or error), 
then I would still find it valuable to have __attribute__((not_writable)) and 
__attribute__((not_readable)).

They're intended to be used in structures, which in the CMSIS case would be 
something like this:

#define __I volatile __attribute__((not_writable))
#define __O volatile __attribute__((not_readable))
#define __IOvolatile
#define __NA__attribute__((not_readable,not_writable)) /* not available or 
no access */

typedef struct {
   __IO uint32_tSR
   union {
 __I  uint32_t  IDR;/* input data register */
 __O  uint32_t  ODR;/* output data register */
   };
   __NA uint32_treserved[2];/*  */


This could be implemented via unnamed bit-fields:

  uint32_t: 32;
  uint32_t: 32;


   /* .. more registers here .. */
};

USART3->ODR = byteToSend;
receivedByte = USART3->IDR;


I'm not sure I understand the purpose of using the union here but
that's probably not important for your proposal.


Normally, __I, __O and __IO are defined as follows in the CMSIS include files:
#ifdef __cplusplus
   #define __I   volatile  /*!< Defines 'read only' permissions */
#else
   #define __I   volatile const/*!< Defines 'read only' permissions */
#endif
#define __O volatile  /*!< Defines 'write only' permissions */
#define __IOvolatile  /*!< Defines 'read / write' permissions */

-That means for C++, __I does not work entirely as intended; it was probably 
done this way due to RTTI.
I believe that in this case an attribute would not have this problem ?


I can't imagine what impact RTTI might have on this. I'd expect
"__attribute__((not_writable))" to map to "const" with no need for
the attribute.


__O can not prohibit reading.
Some hardware registers react upon 'access'; eg. if read, it becomes zero, if 
written, only the set bits are changed.
__O currently cannot prevent reading such registers.


Understood.  I think a write-only attribute or type qualifier would
make sense.  Until/unless it's implemented I would recommend to work
around its absence by hiding access to the registers behind a read-
only and write-only functional API.

Martin

gcc-6-20160901 is now available

[gccadmin]

Snapshot gcc-6-20160901 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/6-20160901/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 6 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-6-branch 
revision 239948

You'll find:

 gcc-6-20160901.tar.bz2   Complete GCC

  MD5=33a383344359ef5913ceb7eb6679cfda
  SHA1=ce93852ee66b20f56ba005030fbd2b4ac2c6492b

Diffs from 6-20160825 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-6
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.