- Ask a related questionWhat is a related question?A related question is a question created from another question. When the related question is created, it will be automatically linked to the original question.
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).
