This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos 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: gcc3.3 everything in the data segment?


>>>>> "Nick" == Nick Garnett <nickg@ecoscentric.com> writes:

    Nick> Gary Thomas <gary@mlbassoc.com> writes:
    >> While I agree that these should probably be in something other than
    >> ".data.XXX", I do see this as an improvement since it gives the linker
    >> garbage collection a chance to removed unused data objects - better
    >> than before.

    Nick> Yep, but of course they should be in ".bss.XXX" sections.
    Nick> This looks like another of those places where the GCC
    Nick> maintainers haven't considered the needs of the embedded
    Nick> world.

    Nick> However, I have a very vague memory of an explanation of why
    Nick> it was not done this way from the start. Unfortunately I
    Nick> cannot remember what it was now, just that it was
    Nick> sufficiently plausible for us to stop complaining about it.
    Nick> Maybe somebody else can remember: Bart, Jifl?

It was a long time ago, and I don't remember the details.

I think it was related to the different semantics for .bss vs. .data,
when the same variable is defined in several different modules. For an
initialized variable in .data you'll get multiple definition errors.
For an uninitialized variable in .bss the linker will just combine the
definitions. Having .bss.XXX sections would have complicated all this.
A lot of existing Unix code depends on this behaviour, and they did
not want to risk breaking things.

Bart

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss


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