• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 98 subscribers
  • Views 385 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Undefined symbol error using the library created by c6runlib

Hongwei Mao
Prodigy 100 points
Other Parts Discussed in Thread: OMAP3530

Hi,

I got several errors saying that some functions were undefined during linking, but they should be in the myfxn.lib file which was created by c6runlib and passed to the linker. I don't know what was wrong, and hope I can get some help here.

I have a program which is currently running on the ARM core of the OMAP3530 processor. I'd like to use the DSP to share some of the computation load, so I took out one file, say myfxn.c, and compiled it with c6runlib (C6Run version 0.94.05.06, installed with DVSDK 4.01).

There was an error during compilation, saying that in the myfxn.pp.c file 'size_t' was redefined. This is really confusing, because, first of all, stdlib.h was the only header file being included so I don't know how size_t got redefined; and second, the myfxn.pp.c file was created by c6runlib-cc, and I'm not sure I can manually change it.

Anyway, using c6runlib, I got these files created in the source code folder (where myfxn.c locates),

    myfxn.fxn_list.txt (this file is totally empty)

    myfxn.gpp_stub.o

    myfxn.pp.c

And in the Makefile folder, I got

    myfxn.c.001t.tu

    myfxn.dsp_stub.o

    myfxn.o

    and the library file myfxn.lib.

Then I got the undefined symbol error when linking the library file with other object files.

Any idea?

Thank you,

Hongwei

  • 0
    TI__Genius 17355 points

    Hongwei Mao said:
    I have a program which is currently running on the ARM core of the OMAP3530 processor. I'd like to use the DSP to share some of the computation load, so I took out one file, say myfxn.c, and compiled it with c6runlib (C6Run version 0.94.05.06, installed with DVSDK 4.01).

    That's a pretty old version of the tool, so the first thing I would recommend would be trying to update to the latest released version (as of today, v0.98.03.03).  You can get the latest version from here. You can then follow these directions to try and integrate that download into the SDK.  Alternatively, you can try using the tool in a stand-alone setup.

    With an update we can be sure you aren't running into an issue that has already been fixed.  If you can do that and you still see the same issue, then running the c6runlib-cc tool with the --C6Run:Debug option and sending us the output could help.  If you can share the original source (or provide an example test source file that shows the same issue), that would also be useful.

    Regards, Daniel

  • 0 in reply to Daniel Allred
    Prodigy 100 points

    Daniel, thanks! I tried the latest release version of c6run, and have no problem compiling my code with c6runlib now.

    But when I run my program on the device, it terminated with this message,

    "terminate called after throwing an instance of 'std::bad_alloc'

        what(): std::bad_alloc

    Aborted "

    The same program runs fine when compiled with ARM compiler.

    I just took one C file to compile with c6runlib-cc. And I did use the "--C6Run:replace_malloc" option when calling c6runlib-ar.

    I configured 73MB for CMEM, from 0x83700000 to 0x88000000 (it's a 3730 with 512 MB RAM), which should be sufficient. And I can run the c6run-apps examples on my device.

     

    Any idea what was wrong?

     

    Thanks,

    Hongwei

  • 0 in reply to Hongwei Mao
    Prodigy 100 points

    Some updates.

    When I use the "C6Run: replace_malloc" option, my program terminated with the "bad_alloc" error (described in my last post). Seems that my c6runlib functions had not been called yet.

    Then I removed the replace malloc option, and rebuilt the program. This time I got this message,  "C6RUN_SHAREDMEM_lookupBuffer() failed for pointer 0x49B2CAAB", when the program called the c6runlib function. And 0x49B2CAAB turns out to be a pointer which is passed to the c6runlib function. It's pointing to a structure which has several other buffer pointers. And in the serial console, I see this message,

        Configuration error (B): Exceeded maximum number [31] of translation Look-aside Buffers.

        The configured entries are:

            Number of entries of size 4KB:    0

            Number of buffers of size 64KB:  0

            Number of buffers of size 1MB:   30

            Number of buffers of size 16MB: 2

     

  • 0 in reply to Hongwei Mao
    TI__Genius 17355 points

    Removing the replace_malloc option is the right move.  It seems to cause problems with other frameworks and libraries that have their own low-level memory management routines that sit on top of the standard malloc routines.

    But when you remove that option, then any buffers (pointer) which you wish to share between the ARM and DSP core will need to be allocated with the C6RUN_MEM_* APIs. Otherwise, the C6Run framework can't figure out what cache operations to perform on the buffer and returns the "lookupBuffer() failed" message.

    Regards, Daniel