jkmcnk / sx-gcc

The GNU Compiler Collection port to NEC SX CPU architecture.
GNU General Public License v2.0
0 stars 2 forks source link

strip breaks COFF/SX files #111

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
after stripping an executable, superux complains:

bash-2.05b$ ./simple-strip 
bash: ./simple-strip: cannot execute binary file

if stripping an object file containing main() and then linking it into an
executable, it coredumps immediately upon execution with:

bash-2.05b$ ./simple-prestrip 
Illegal instruction (core dumped)

most likely a problem with bfd.

Original issue reported on code.google.com by jmoc...@gmail.com on 17 Feb 2009 at 3:52

GoogleCodeExporter commented 8 years ago
A part of the problem (the copying of the a.out headers's "magic" and "stack 
size"
attributes) is solved in r190.

However, there is still one issue left: the copying of the section flags is 
still
wrong. Consider the following example:

{{

#include <stdio.h>

void function_in_use() {
    printf("Invoked function in use.\n");
}

void function_not_in_use() {
    printf("ERROR: this function should not be called!\n");
}

int main(int argc, char *argv[]) {

    printf("Testing the \"strip\" tool.\n");

    function_in_use();
    return 0;
}

}}

If we compile it into an "testStripSx" executable and execute the 
"sx8-nec-superux-objdump -h testStripSx" command on it, we get the following 
output:

************ OUTPUT BEGIN ******************
Sections:
Idx Name          Size      VMA               LMA               File off  Algn
  0 .text         00042c90  0000000400000000  0000000400000000  000001f8  2**3
                  CONTENTS, ALLOC, LOAD, CODE
  1 .data         00008c78  0000000404000000  0000000404000000  00042e88  2**3
                  CONTENTS, ALLOC, LOAD, DATA
  2 .bss          00002b60  0000000404008c80  0000000404008c80  00000000  2**3
                  ALLOC
  3 .comment      000075e0  0000000000000000  0000000000000000  0004bb00  2**3
                  CONTENTS
  4 .whoami       00000f88  00000000000075e0  00000000000075e0  000530e0  2**3
                  CONTENTS, ALLOC, LOAD
************ OUTPUT END ********************

Then, we execute the "sx8-nec-superux-objcump -h testStripSx -o 
testStripSxStripped
-N function_not_in_use" command and the "sx8-nec-superux-objdump -h
testStripSxStripped". We get the following output:

************ OUTPUT BEGIN ******************
Sections:
Idx Name          Size      VMA               LMA               File off  Algn
  0 .text         00042c90  0000000400000000  0000000400000000  000001f8  2**3
                  CONTENTS, ALLOC, LOAD, CODE
  1 .data         00008c78  0000000404000000  0000000404000000  00042e88  2**3
                  CONTENTS, ALLOC, LOAD, DATA
  2 .bss          00002b60  0000000404008c80  0000000404008c80  00000000  2**3
                  ALLOC
  3 .comment      000075e0  0000000000000000  0000000000000000  0004bb00  2**3
                  CONTENTS
  4 .whoami       00000f88  00000000000075e0  00000000000075e0  000530e0  2**3
                  CONTENTS, ALLOC, LOAD, CODE
************ OUTPUT END ********************

We can see that ".whoami" is now regarded as a code section, which is why the 
program
crashes (if we change the flag of the ".whoami" section to its previous value, 
the
"testStripSxStripped" executable works fine).

I did some research and found out that the section flag setting is done in the
following functions in "coffcode.h":
* the "styp_to_sec_flags" function"
* the "coff_write_object_contents" 

These two functions are not SX specific, so it is possible that we have found 
another
bug in binutils...

Original comment by nou...@gmail.com on 20 Feb 2009 at 12:57

GoogleCodeExporter commented 8 years ago
The stripping issue was fixed in r195. 

I still need to test the "coredump when stripping an object file containing 
main()
and then linking it into an executable", though.

Original comment by nou...@gmail.com on 13 Mar 2009 at 11:19

GoogleCodeExporter commented 8 years ago
test it ...

Original comment by jmoc...@gmail.com on 9 Oct 2009 at 9:32