This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Extension compatibility policy

Joseph S. Myers wrote:
On Wed, 2 Mar 2005, Bernardo Innocenti wrote:

To move strings into program memory, there's a macro like this:

#define PSTR(s) ({ static const char __c[] PROGMEM = (s); &__c[0]; })

But this wouldn't work because __func__ does not work like a string literal:

#define TRACEMSG(msg,...) __tracemsg(PSTR(__func__), msg, ## __VA_ARGS__)

C99's __func__ is supposed to work as if a "const char __func__[]".
The __FUNCTION__ extension could instead be made to work like a
string literal.   We could live without string pasting capabilities
if it helps keeping the interface between cpp and the C frontend

How about calling decl_attributes from fname_decl so a target insert_attributes hook can add attributes to __func__? Would that suffice to solve your problem?

It would be an excellent solution for myself, but portable code might not expect __func__ to be stored in program memory. This isn't as transparent a a .rodata section.

Some compilers provide some sort of "fat" pointers, which of
course result in terrible code.  GCC's AVR target provides the
"progmem" attribute, but it requrires asm macros to fetch values.

The AVR is a Harvard processor, like many 8bit microcontrollers
and DSPs.  You need special opcodes to access data stored in
program address space, and this doesn't map well to C pointers.

Properly supporting this requires special variants of ANSI
string library functions such as memcpy_P(), strcmp_P(), etc.

A quick solution for the __func__ problem may be adding a
-mprogmem-func switch to the AVR backend.

 // Bernardo Innocenti - Develer S.r.l., R&D dept.

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