[Bug ld/12524] New: Linking with --format=binary discards non-static global variables

[morgon.kanter at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=12524

           Summary: Linking with --format=binary discards non-static
                    global variables
           Product: binutils
           Version: 2.21
            Status: NEW
          Severity: normal
          Priority: P2
         Component: ld
        AssignedTo: address@hidden
        ReportedBy: address@hidden


Take the following example piece of C code, call it test.c:

------------------
int global;
int main() { global = 1; global = 2; return 0; }
------------------

When this code is compiled, using the following command, which is executable:
$ gcc -o test test.c

The global variable gets put in the .bss section. In addition, if you compile
and link with the following commands, the end of which is not executable (as
the compiler never puts in the startup bits), the variable also ends up in the
.bss section in the end:

$ gcc -c test.c
$ ld -o test test.o -lc

However, if you link with a flat binary target instead of ELF, the variable
gets lost and, interestingly, the following code gets emitted where normally
the value would get moved to the variable's location:

movl $0x1,0x0(%rip)

...later...

movl $0x2,0x0(%rip)

This is very similar to a bug I at first thought was in Clang before
encountering it here, which can be found here:
http://llvm.org/bugs/show_bug.cgi?id=9297

If we explicitly define a section, ie have: 'int global __attribute__ ((section
(".bss")));', this will still fail. I tested it with clang as well, and it
fails in the same fashion. However -- I have a larger project that outputs to a
binary format and defines a global variable in this fashion; interestingly, gcc
fails similarly but clang works successfully in this case where I explicitly
define the section. I haven't been able to reproduce this behavior, though.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.