From: | George Neuner <gneuner2@comcast.net> |
Newsgroups: | comp.compilers |
Date: | Mon, 25 May 2009 21:49:30 -0400 |
Organization: | A noiseless patient Spider |
References: | 09-04-072 09-04-086 09-05-010 09-05-022 09-05-028 09-05-038 09-05-039 09-05-050 09-05-055 09-05-065 09-05-069 09-05-073 09-05-087 09-05-110 09-05-115 |
Keywords: | linker |
Posted-Date: | 28 May 2009 17:36:29 EDT |
On Mon, 25 May 2009 09:13:09 +0200, Hans-Peter Diettrich
<DrDiettrich1@aol.com> wrote:
>George Neuner schrieb:
>
>> A problem occurs when there are multiple definitions in separate
>> files. Technically, by the standards, there can be only 1 definition
>> of a name at top level ... all other references to the name, including
>> any forward references to the name in the same file, *must* be
>> "extern" declarations.
>[...]
>> Every compiler complained about multiple definitions of 'x' when all
>> the definitions were strong - ie. when 'x' was initialized in both
>> files.
>
>How does a compiler know about other files?
It doesn't.
>I assume that the definitions were in the same compilation unit, i.e. in
>the header files included by both source files. Otherwise it's a matter
>of object file formats and linkers, what will happen with multiple
>definitions of the same symbol in multiple object files.
No. The definitions were in separate source files. You snipped the
source with which I tested.
I tested 4 ways: with two weak definitions of 'x' (no initialization),
two strong definitions (with initialization), and with one strong and
one weak definition (both ways). The definition of the variable
'garbage' was left weak in all cases.
>> However, if either definition was weak, I was able to build an
>> executable. When both definitions were weak, however, some of the
>> compilers produced optimized executables with NO storage at all
>> allocated for the name 'x'.
>
>What's "NO" storage? A NULL address output by printf?
With two weak definitions of 'x' and a weak definition of 'garbage',
the compiler did not allocate any storage in the data segment. The
linker did not object to having no global data (why should it?) and
produced an executable that crashed with an illegal address reference
because the system loader didn't assign any pages to the empty data
segment. I checked the linker's map file to verify that no storage
had been allocated for variables.
This happened with 4 different compilers under high optimization.
George
Return to the
comp.compilers page.
Search the
comp.compilers archives again.