VLIB - Connected Components (COFF and ELF format)

I'm experiencing the same issue with VLIB 2.2. Building and linking in COFF format works fine. When I switch over to ELF, my DSP app crashes at a call into the VLIB library. Exception dump from CCS:

[C674X_0] A0=0x0 A1=0x1
[C674X_0] A2=0x0 A3=0x2d
[C674X_0] A4=0x8002 A5=0x0
[C674X_0] A6=0x82 A7=0x0
[C674X_0] A8=0x95f03a00 A9=0x0
[C674X_0] A10=0x0 A11=0x0
[C674X_0] A12=0x0 A13=0x0
[C674X_0] A14=0x0 A15=0x0
[C674X_0] A16=0x0 A17=0x0
[C674X_0] A18=0x8bdba290 A19=0x0
[C674X_0] A20=0x1 A21=0x0
[C674X_0] A22=0x4c2ba463 A23=0xbd7a0008
[C674X_0] A24=0x4849960e A25=0x0
[C674X_0] A26=0x94d942ec A27=0x94d942ec
[C674X_0] A28=0x0 A29=0x190
[C674X_0] A30=0x4 A31=0x200
[C674X_0] B0=0x0 B1=0x8bdba888
[C674X_0] B2=0x1 B3=0x2d
[C674X_0] B4=0x596 B5=0x8bdba5c4
[C674X_0] B6=0x12c000 B7=0x95f0c5a8
[C674X_0] B8=0x73 B9=0x3a
[C674X_0] B10=0x0 B11=0x0
[C674X_0] B12=0x0 B13=0x0
[C674X_0] B14=0x95f0c460 B15=0x8bdba580
[C674X_0] B16=0x30 B17=0x8bdba50c
[C674X_0] B18=0x95f0a588 B19=0x80
[C674X_0] B20=0x3e8 B21=0xb87a0008
[C674X_0] B22=0x4724a978 B23=0xb87a0008
[C674X_0] B24=0xc9cfe6d0 B25=0x0
[C674X_0] B26=0x94d942ec B27=0x94d942ec
[C674X_0] B28=0x94d95b90 B29=0x0
[C674X_0] B30=0x0 B31=0xffffffff
[C674X_0] NTSR=0x1000f
[C674X_0] ITSR=0xf
[C674X_0] IRP=0x95efd8d6
[C674X_0] SSR=0x0
[C674X_0] AMR=0x0
[C674X_0] RILC=0x80
[C674X_0] ILC=0x0
[C674X_0] Exception at 0x2c
[C674X_0] EFR=0x2 NRP=0x2c
[C674X_0] Internal exception: IERR=0x1
[C674X_0] Instruction fetch exception
[C674X_0] ti.sysbios.family.c64p.Exception: line 248: E_exceptionMin: pc = 0x95efd8d6, sp = 0x8bdba580.
[C674X_0] To see more exception detail, use ROV or set 'ti.sysbios.family.c64p.Exception.enablePrint = true;'
[C674X_0] xdc.runtime.Error.raise: terminating execution

So I either found a workaround, or the stars have aligned. Either way, the original problem seems to stem from stack corruption on return from VLIB_getCCFeatures. What seems to work is explicitly casting the arguments to VLIB_getCCFeatures. Instead of:

VLIB_getCCFeatures(handle, &ccElem, id);

try:

VLIB_getCCFeatures(handle, (VLIB_CC*)&ccElem, id);

This doesn't seem to be the most robust solution, so any feedback with a better solution is appreciated. Seems like an issue with the calling convention between my code and the VLIB library.

i'm still struggling with this problem. thank you for your hint. i'll try with this way~~~.

I've tried with this way, it failed.

but if i define my loop variable in global data section. it works! 

like this way:

for (jj=0; jj < numCCs; jj++)
{
//int h,w;
i = jj;
VLIB_getCCFeatures(handle, (VLIB_CC*)&vlibBlob, i);

}

jj is global variable. if i define it inside the function, the program failed.

so you are right, the stack corrupts on return from VLIB_getCCFeatures.

is it a bug with TI VLIB?

Bumping this to try to get some visibility on this issue. Of course, switching to any sort of optimization breaks my kludge workaround, so this issue is definitely a show stopper for me. Could someone from TI at least provide a recompile of the VLIB with the latest Code Gen tools?

您好，能发一份vlib2.2给我吗，谢谢啦，471030698@qq.com

I don't know how much this is of any help after so many months but the issue is resolved in the VLIB 2.2 ELF module.

Please take into account the vlib functions seem to be optimized only for c64x+ IS and not for the better (mainly in FLOP usage) c67x+ which is widely used.

Regards,

Roei