Fetch packet exception thrown from trampolined functions

NRP could be pointing after the exception occurred. What are the instructions in a couple of fetch packets above this instruction and the rest of the fetch packet after this instruction? In other words, please show the disassembler window for 0x8cc03d80-0x8cc03ddf.

The address in B3 is usually the return address of a function call, so you can look back to that address to see where this came from. That could help with tracking down the actual cause.

An exception like this should never occur in compiler-generated code. Causes can be stack overflow, memory corruption from invalid/incorrect pointers, and such.

Regards,
RandyP

Thank you very much for your comment Randy.

Below is the disassebler window for 0x8cc03d80-0x8cc03ddf that you requested.I've replaced some irrelevant symbol names with *****.

The area 0x8cc03ddc-0x8cc03d7 might not be a valid code, but it had not changed since the application was loaded to the memory.

          $Tramp$S$$__cxa_guard_release:
8cc03d70:   01231810            B.S1          __cxa_guard_release (PC+596160 = 0x8cc95620)
8cc03d74:   00008000            NOP           5
8cc03d78:   00000000            NOP           
8cc03d7c:   00000000            NOP           
          $Tramp$S$$_ZN10*******_:
8cc03d80:   01221810            B.S1          ***** (PC+594112 = 0x8cc94e40)
8cc03d84:   00008000            NOP           5
8cc03d88:   00000000            NOP           
8cc03d8c:   00000000            NOP           
          $Tramp$S$$_Znwj:
8cc03d90:   010C5C10            B.S1          operator new  (PC+549600 = 0x8cc8a060)
8cc03d94:   00008000            NOP           5
8cc03d98:   00000000            NOP           
8cc03d9c:   00000000            NOP           
          ~__class_type_info:
8cc03da0:   00100FD8            MV.L1         A4,A0
8cc03da4:   D0000290     [!A0]  B.S1          $C$L13 (PC+20 = 0x8cc03db4)
8cc03da8:   C122DC10     [ A0]  B.S1          operator delete  (PC+595680 = 0x8cc95480)
8cc03dac:   D08C6362     [!A0]  BNOP.S2       B3,3
8cc03db0:   00000000            NOP           
          $C$L13:
8cc03db4:   00002000            NOP           2
8cc03db8:   00000000            NOP           
8cc03dbc:   00000000            NOP           
          $Tramp$S$$_****************_:
8cc03dc0:   01174410            B.S1          ********** (PC+571936 = 0x8cc8f7e0)
8cc03dc4:   00008000            NOP           5
8cc03dc8:   00000000            NOP           
8cc03dcc:   00000000            NOP           
          $P$T0$2:
8cc03dd0:   00000001            NOP           
8cc03dd4:   00000001 ||         NOP           
8cc03dd8:   00000000 ||         NOP           
8cc03ddc:   FFFFFFFF            .word         0xffffffff
8cc03de0:   FFFFFFFF ||         .word         0xffffffff
8cc03de4:   FFFFFFFF ||         .word         0xffffffff
8cc03de8:   00000000 ||         NOP           
8cc03dec:   00000001            NOP           
          $Tramp$S$$_****************_:
8cc03df0:   01227010 ||         B.S1          ***** (PC+594816 = 0x8cc95160)
8cc03df4:   00008000            NOP           5

I also realized that the code that throws the internal exception was a part of a constructor, which was called from a C++ code like below. The code has been running fine on C64x+ compiled with CGTool v6.0.

const classA& classA::only ()

{

static classA instanceA(paramters);

return instanceA;

}

I really appreciate your help.

Thanks,

Hi Randy,

FYI, below is an excerpt from the map file. As you see below, the data between 8cc03dd0 and  8cc03dec was not corrupted, but actually coming from a .const.1 data section.

80000000    80000000    0c800000   00000000    rw-
  80000000    80000000    0c800000   00000000    rw- .sysmem
8c800000    8c800000    00403de0   00403de0    r-x
  8c800000    8c800000    00403de0   00403de0    r-x .text.1
8cc03dd0    8cc03dd0    00000070   00000070    r-x
 8cc03dd0 8cc03dd0 00000020 00000020 r-- .const.1
  8cc03df0    8cc03df0    00000010   00000010    r-x .text.2
  8cc03e00    8cc03e00    00000010   00000010    r-- .const.2

Thanks,

Since the yellow highlighting seems to have changed the indentation, it is not quite as easy to figure out what the relationships are with the lines. But I think I understand.

However, it looks like the .text.1 section should use the range from 8c800000-8cc03ddf while the .const.1 section overlaps with it by using 8cc03dd0-8cc03def. They overlap by 16 bytes, or am I misreading something here?

If that overlap is my mistake or does not really matter for some reason, and the area from the previous post that looked like corrupt code is really just constant data, then are we any closer to solving your problems?

Regards,
RandyP

I was also wondering why there was the 16 byte overlap of .text.1 and .const.1. An excerpt from the map file was copy-pasted and is not a mistake.

I understand that the exception was thrown because was a data from .const section got into fetch packet. The strange 16 byte overlap might be indicating that the linker is doing something wrong with laying out .code and .text sections. As a work around for now, we are trying to put .text and .const into one contiguous sections respectively and reduce the chance of const data getting into .text segment. But if this is an issue in the linker, can we expect a fix in the near future release?

Best regards,