Unable to load GCC built executables from CCS 5.1

Sudhanand,

Does the table below summarize what you are seeing?

What error do you see when you try to load using CCSv5.1?  CCS should be doing a data verification test so it would give you data verification errors if it did not load properly.  During data verification we read back some of the locations that were written and verify them against what we were writing.  If it is not loading properly you should absolutely be getting errors.

Any chance that you have it set to load symbols only?

Can you provide the executable you are loading so that we can confirm this behavior.  If you don't want to attach it to a forum post you can send it via email if you want.

Regards,

John

Hi John,

   Yes, the table summarizes what I am seeing.

  The odd part is that CCS does not report any errors. I verified that I am loading the program not symbols. I also had a colleague test it on him PC and saw the same result. 

  I am attaching the executable (renamed to txt). It is a simple memory read-write test.

4118.ARMTest.txt

Thank you,

Regards,

Sudhanand.

    Forgot to mention, the code is built for a Cortex-A8

Regards,

Sudhanand.

Which device?

I was able to reproduce this on DM8168.  When I load in CCSv5.1 I only get symbols, when I load in CCSv5.0.3 the program loads and I end up at main().  I will file a defect for this.

I filed SDSCM00043927 to track this.

I tested it on TMS320TCI6614 simulator and Integra (DM816x) hardware.

Sudhanand

It looks like there is an issue with the program segment table generated by the linker.

 Program Segment Table

    id type                    load addr  run addr   file size mem size   flags align

    -- ----                    ---------  --------   --------- --------   ----- -----

    0  PT_UNKNOWN (0x70000001) 0x8000b0dc 0x8000b0dc 0x8       0x8        r--   4   

    1  PT_LOAD                 0x80000000 0x80000000 0xb9c8    0xba2c     rwx   32768

    2  PT_LOAD                 0x90000000 0x90000000 0x0       0x10000000 rw-   32768

The PT_LOAD segment (index 1) for the executable code has a p_offset ( file offset to the data ) set as 0x00000000; which is obviously incorrect because this is right at the beginning of the file where the ELF header is located.

Note: The there is slight difference in the behavior between older/newer versions of CCS. We used to load data from the offset regardless of weather it was incorrect or not; now we do not. Thus, in older versions you might actually see data getting loaded. However, it the loaded data is incorrect.

Hi Mandeep,

   I have attached the linker command file I used (renamed from gcc_a8.cmd) and the generated map file (armTest_map.txt). Can you tell me what needs to be changed to correct the error.

.

Thank you.

Regards,

Sudhanand.

The attachments did not come through.  I am not sure how familiar our team is with gcc link files.

 John,

 I am going to try sending the file once more.

  Can you tell me what the possible reasons that could cause the p_offset to be incorrect. I am new to GCC world and could not find anything on this in any of the Codesourcery or GCC documents.

6175.armTest_map.txt

OUTPUT_FORMAT ("elf32-littlearm","elf32-bigarm","elf32-littlearm")
ENTRY(_start)


MEMORY
{
  INTERRUPT	         (rwx) : ORIGIN = 0x80000000,    LENGTH = 1K
  DDR_cachedShared   (rwx) : ORIGIN = 0x80000400,  LENGTH = 64M
  DDR_region   (rwx) : ORIGIN = 0x84000400,  LENGTH = 64M
  DDR_reserved       (rwx) : ORIGIN = 0x90000000,  LENGTH = 256M
}

SECTIONS
{

/*
 .interrupt :
 {
	*interrupt.o (.text);
 } > INTERRUPT
 
 .tlb_table :
 {
	*mmu_tables.o (.data);
 } > DDR_cachedShared
*/
 
 .start :
 {
	 *startup.o (.text);
 } > DDR_cachedShared
 
 .text : ALIGN (8)
 {
	__pgm_load_start = LOADADDR (.text);
	__pgm_start = .;
	*(.text)
	*(.rodata)
	pgm_end = .;
	. = ALIGN (4); 
	__pgm_end = .; 
   } > DDR_cachedShared
  
 .data : ALIGN (8)
 {
	__data_load_start = LOADADDR (.data);
	__data_start = .;
	*(.data)
  data_end = .;
	. = ALIGN (4); 
    __data_end = .; 
 } > DDR_cachedShared
 
 .bss : ALIGN (8)
 {
  *(.bss)
  *(COMMON)	
 } > DDR_cachedShared


 .reserved :
 {
 . = ALIGN(0x8); /* aligned the heap on a 8 bytes boundary */
 heap_low = .; /* for _sbrk */
 . = . + 0x8000000; /* 128MB of heap memory */
 heap_top = .; /* for _sbrk */
 . = . + 0x8000000; /* 128MB of stack memory */
 . = ALIGN(0x8); /* aligned the stack on a 8 bytes boundary */
 stack_top = .; /* for startup.S */
 } > DDR_reserved

  .stab 0 (NOLOAD) : { *(.stab) }
  .stabstr 0 (NOLOAD) : { *(.stabstr) }
  /* DWARF debug sections.
   * Symbols in the DWARF debugging sections are relative to
   * the beginning of the section so we begin them at 0.
   */
  /* DWARF 1 */
  .debug          0 : { *(.debug) }
  .line           0 : { *(.line) }
  /* GNU DWARF 1 extensions */
  .debug_srcinfo  0 : { *(.debug_srcinfo) }
  .debug_sfnames  0 : { *(.debug_sfnames) }
  /* DWARF 1.1 and DWARF 2 */
  .debug_aranges  0 : { *(.debug_aranges) }
  .debug_pubnames 0 : { *(.debug_pubnames) }
  /* DWARF 2 */
  .debug_info     0 : { *(.debug_info .gnu.linkonce.wi.*) }
  .debug_abbrev   0 : { *(.debug_abbrev) }
  .debug_line     0 : { *(.debug_line) }
  .debug_frame    0 : { *(.debug_frame) }
  .debug_str      0 : { *(.debug_str) }
  .debug_loc      0 : { *(.debug_loc) }
  .debug_macinfo  0 : { *(.debug_macinfo) }
  /* DWARF 2.1 */
  .debug_ranges   0 : { *(.debug_ranges) }
  /* SGI/MIPS DWARF 2 extensions */
  .debug_weaknames 0 : { *(.debug_weaknames) }
  .debug_funcnames 0 : { *(.debug_funcnames) }
  .debug_typenames 0 : { *(.debug_typenames) }
  .debug_varnames  0 : { *(.debug_varnames) }

  .note.gnu.arm.ident 0 : { KEEP (*(.note.gnu.arm.ident)) }
.ARM.attributes 0 : { KEEP (*(.ARM.attributes)) }
}

Regards,

Sudhanand.

Sudhanand,

I took a look at the file but unfortunately I don't know what is wrong with it.  You could try Code Sourcery however I believe they now charge for support, might want to see if anyone on your team has a support contract.  Or you could try posting in one of the public gcc forums that are available.

Regards,

John