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: unassig...@sources.redhat.com
ReportedBy: morgon.kan...@gmail.com
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.
_______________________________________________
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
