[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-gcc-list] Re: Avoiding copy_data in config/avr/avr.c

From: Ben Jackson
Subject: Re: [avr-gcc-list] Re: Avoiding copy_data in config/avr/avr.c
Date: Thu, 28 Jul 2005 14:26:27 -0700
User-agent: Mutt/1.5.6i

On Thu, Jul 28, 2005 at 10:43:45PM +0200, Bj??rn Haase wrote:
> IIUC, there should be an easy workaround that, however, could result in 
> slightly bloated assembler source files.

Ok, I took this idea and tried it out.  Here are some details:

The *_SECTION_ASM_OPs are already in avr.h, so you can just replace them.
The .bss section is slightly different than your suggestion:

#define DATA_SECTION_ASM_OP "\t.global __do_copy_data\n\t.data"
#define BSS_SECTION_ASM_OP "\t.global __do_clear_bss\n\t.section .bss"

However, most bss comes from .comm and .lcomm, so you have to change
two other macros as well:

Make the following change to each of ASM_OUTPUT_COMMON and ASM_OUTPUT_LOCAL:

#define ASM_OUTPUT_COMMON(STREAM, NAME, SIZE, ROUNDED)                     \
do {                                                                       \
     static char done;                                                     \
     if (!done) {                                                          \
        done = 1;                                                          \
        fputs("\t.global __do_clear_bss\n", (STREAM));                     \
     }                                                                     \

> it should be possible to remove the two lines
>   fputs ("\t.global __do_copy_data\n", asm_out_file);
>   fputs ("\t.global __do_clear_bss\n", asm_out_file);

With that it seems to work.  There are a few more issues that might crop up:

1)  You'll want to rebuild all of your libraries so they don't have
unnecessary .global in every C .o pulling in the copy/zero functions,

2)  People may have gotten lazy in asm libraries and declared data or bss
without the .global to bring them in.  That's a downside to doing it
this way instead of in the linker.  That would not prevent your application
from building but it would have odd behavior at runtime.

Ben Jackson

reply via email to

[Prev in Thread] Current Thread [Next in Thread]