Team,
Could you please look at the following issue?
Compiler and CCS version will be added to the post.
Thanks and best regards,
Anthony
Loading symbols from the output of a relocatable link step crashes CCS 5:
This example is derived from a more complex one that doesn't actually attempt to load symbols from an unrelocated file but exhibits the same problem.
I have the following C file (hello.c):
c_int00() {
volatile int x = 0;
for (;;) x ++;
}
I compile it with: cl6x -c -mv6600 hello.c
I link it with: lnk6x -r -mv6600 hello.lnk
where hello.lnk contains:
hello.obj
-o hello.out
MEMORY {
MEM: origin = 0x800000 length = 0x01000
}
SECTIONS {
.text: > MEM
}
This gives me two relocatable outputs: hello.obj and hello.out.
In CCS5 connected to an EVM6678L, I connect to core #0 and select hello.obj with Run/Load/Load Symbols.
This is accepted and behaves as I would expect.
If I do exactly the same thing with hello.out, CCS is _immediately_ blown away (the process is terminated) without any error report.
This is the simplest example I can make of the problem which actually appears when the output from a link step generating relocatable output is relocated by a separate program (which generates applications that successfully execute when loaded over Ethernet). That program is not involved in the example above.
If I use the relocatable output from the linker as input to another link step that generates executable output, loading the symbols starts to work again.
I conclude that the linker is generating something wrong when creating relocatable output that gets corrected when it later generates executable output.
A further observation: after linking the relocatable linker output to form an executable, I note
that the section headers are misaligned (at offset 0xaca from the start of the file).
This appears to break the alignment rule from:
http://www.sco.com/developers/gabi/2003-12-17/ch4.intro.html#file_format
"All data structures that the object file format defines follow the ``natural'' size and alignment guidelines for the relevant class. If necessary, data structures contain explicit padding to ensure 8-byte alignment for 8-byte objects, 4-byte alignment for 4-byte objects, to force structure sizes to a multiple of 4 or 8, and so forth. Data also have suitable alignment from the beginning of the file. Thus, for example, a structure containing an Elf32_Addr member will be aligned on a 4-byte boundary within the file. "
Section headers contain Elf32_Addr members, and so should be aligned on a 4-byte boundary (which 0xaca isn't).
