Re: GNU/Linker and Microsoft object code.

[Pascal Obry]

Hi Nick,

First of all thanks for your help.

 > Hmm, OK this would imply that the linker is placing the initialised
 > data section (.bss) in the same area as the initialised data section
 > (.data).

I'm not an expert in this area, but it seems that the initialize data are set
into the .data section. See below.

 > 
 > There are a couple of simple checks that you do:
 > 
 >   1. Add the --print-map option to the linker and examine the
 >      resulting map.  Do you see an overlapping .data and .bss section
 >      ?  Where is the 'C' symbol located ?


Ok, here is my analysis. If I compile the C code with Microsoft compiler and
set the initialize variable to something different than 0, I have this in the
map file:

 .data          0x0040a0a0        0x8 pck.o
                0x0040a0a4                pck__k
                0x0040a0a0                pck_E
 .data          0x0040a0a8       0x12 c_vsimple.obj
                0x0040a0a8                c
 *fill*         0x0040a0ba        0x2
 .data          0x0040a0bc       0xcc d:/usr/gnat/lib/gcc-lib/...

Here no problem, the variable c is defined. If I set the same variable to 0
then I have the following map file:

 .data          0x0040a0a0        0x8 pck.o
                0x0040a0a4                pck__k
                0x0040a0a0                pck_E
 .data          0x0040a0a8        0xe c_vsimple.obj
 *fill*         0x0040a0b6        0x2
 .data          0x0040a0b8       0xcc d:/usr/gnat/lib/gcc-lib/...

Here as you see there is no more variable c defined ! This is definitly the
problem. Any idea what could be wrong ?

 > 
 >   2. Add the --check-sections switch to the linker command line.  This
 >      is supposed to check for and warn about overlapping sections.

No problem found here.

 > 
 >   3. Print out the linker script and check to see what is happening to
 >      the .data and .bss sections.  (You can use 'ld --verbose' to see
 >      the default linker script, but it is possible that gcc is using a
 >      custom linker script so add '-v' to gcc's command line and check
 >      to see if -T is being passed to the linker).
 > 
 >   4. Another possibility is that the linker is confused about common
 >      symbols.  Does the problem go away of you compile with
 >      -fno-common ?

No. The bug is still there.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--|
--| "The best way to travel is by means of imagination"