On 2008-05-30, Sergey A. Borshch <[email protected]> wrote:
>> uninitialized variables are reserved in assembler using .comm.
>> the linker(?) then puts these in the .bss section but gcc does
>> not know that so it did not output the reference to
>> _do_clear_bss. i've now added the reference to the function
>> also for variables that are put into .comm
>>
>> the original code from you also works if -fno-common is used.
>> in that case is gcc directly emitting these variables to .bss,
>> where the reference to the function was correctly placed.
>>
>> anyways, doing the same for .bss and .comm seems reasonable to me.
>
> I got last sources from cvs today. Your solution works fine,
> but there is a problem in my code. If --gc-sections with
> --fdata-sections removes all variables from .data or .bss
> section,
Just to clarify: were all of the symbols in .data and .bss
sections unreference? IOW, is the --gc-sections and
--fdata-sections feature working properly?
> .global __do_clear_bss or __do_copy_data remains in source
> file and causes __do_clear_bss or __do_copy_data functions to
> be linked to output file with segmend size = 0, and it causes
> 64K block to be zeroed or copied. The only solution I see is
> to check segment size to 0 before cycle, so I removed .global
> __do_xxx from sections definitions and added it to
> _reset_vector__, so copy/clear cycles linked always together
> with library _reset_vector__. If user project have no .bss or
> .data variables, user can define empty copy|clear function:
>
> __attribute__((__naked__, __section__(".init4"))) void __do_clear_bss()
> {
> }
Too bad the elimination of the copy/clear code can't happen
automatically when size of .data or .bss is 0.
--
Grant Edwards grante Yow! I want my nose in
at lights!
visi.com
