Path: chuka.playstation.co.uk!news From: gil@snsys.com (Gil Jaysmith) Newsgroups: scee.yaroze.programming.gnu_compiler Subject: Re: Optimise Problem - trunced data Date: Wed, 06 Aug 1997 09:37:09 GMT Organization: SN Systems Lines: 74 Message-ID: <5s9g9e$oj8@chuka.playstation.co.uk> References: <333d7fd9.23907964@news.playstation.co.uk> <33424023.72C4@interactive.sony.com> <33D5B732.3AC9@dial.pipex.com> <01bc9c44$3fe961e0$ca2c9ac2@martin.snsys.com> <33E39782.6C3F@dial.pipex.com> <01bca0db$fb8dfdc0$ca2c9ac2@martin.snsys.com> <33E8377F.366F@dial.pipex.com> Reply-To: gil@snsys.com NNTP-Posting-Host: gil.snsys.com X-Newsreader: Forte Free Agent 1.0.82 Chris Chadwick wrote: >I've tried this method too and it seems to work fine ;) >You are obviously more clued about the workings of the >compiler than me (not difficult :) so I was wondering >if you could explain what the 4 program sections - that are >listed when dowloading a prog - actually contain: .text, .sdata, >.rdata and .data ... >I assume .text is the actual executable program code and, from your >above desciption, .sdata (s for session?) holds global data ? Wotcher Chris... (compiler slave butts in since boss isn't in office yet :=) .text holds the executable program code. .data holds initialised data. .rdata holds initialised read-only data. (Sometimes it takes a little effort to convince the compiler of the difference.) .sdata holds small items of initialised data which are accessed slightly faster. There are also sections called .bss (for uninitialised data) and .sbss (for small items of uninitialised data). The -G option for the compiler determines what 'small' means. I think it defaults to 8 bytes. So if you declare an int variable, the compiler will allocate it in .sbss if you declare it simply as "int a;", or in .sdata if you declare it as "int a = 1;". Anything bigger than that -G limit, which generally means most structs and arrays, goes into .data if you give an initialiser, or .bss if not. Why not set the -G limit to a huge number if access to it is faster? Because access is with a signed 16-bit offset from the GP register, which is set to point into the middle of the .sdata/.sbss combined section. So you have a limit of 64K of 'small' data. This limit is discovered, so to speak, at link time, which is why a project can compile perfectly well but crash out with linker errors because it can't fit the offset into 16 bits. There isn't a good heuristic for determining a good value for -G during compilation, other than to write your code in one C file, so if you get this problem, you just have to systematically reduce the -G value and remake until it links. The bss sections are flagged as having no contents, and it's the responsibility of the startup code to fill them with zeros. This is why you can declare something like "char a[1000000];" without getting a massive object file. You can also declare your own sections and place functions and variables within them using the GNU C extension "__attribute__", but you need to be canny with your linker script to place these where you want. The sections named above are just the standard ones you always get when compiling, and mostly you shouldn't need any others. Our linker has cool stuff to meddle with section names during linking so as to make it easy to generate code overlays, but you can probably do this with the GNU linker too and I seem to remember a previous thread somewhere talking about a Japanese demo which downloaded overlays from the host. In C++ there are also sections called .ctors and .dtors, which contain the addresses of routines which create any global class objects you might have lying around. These are cycled through by the startup and shutdown code so you generally needn't worry about them. And that's what we know about standard COFF sections... Gil Jaysmith SN Systems Software Ltd, makers of Psy-Q... http://www.snsys.com Disclaimer: What I say when I post here represents me, not my employers.