Root FS image with debug info for DM 6467

Root filesystems are generally not built with debug information. If such an image exists, you will get pointers here.

I am assuming you are having problems in debugging an application and need help to do so. You can describe the problem in detail, you may find alternate ways to do the same - without requiring the debug version of libraries.

I am trying to run valgrind on the platform. I have cross compiled a version of the same, but when I try to use it on my application, I get the following error.

valgrind:  Fatal error at startup: a function redirection
valgrind:  which is mandatory for this platform-tool combination
valgrind:  cannot be set up.  Details of the redirection are:
valgrind:  
valgrind:  A must-be-redirected function
valgrind:  whose name matches the pattern:      memcpy
valgrind:  in an object with soname matching:   ld-linux.so.3
valgrind:  was not found whilst processing
valgrind:  symbols from the object with soname: ld-linux.so.3
valgrind:  
valgrind:  Possible fixes: (1, short term): install glibc's debuginfo
valgrind:  package on this machine.  (2, longer term): ask the packagers
valgrind:  for your Linux distribution to please in future ship a non-
valgrind:  stripped ld.so (or whatever the dynamic linker .so is called)
valgrind:  that exports the above-named function using the standard
valgrind:  calling conventions for this platform.
valgrind:  
valgrind:  Cannot continue -- exiting now.  Sorry.

Can you share the output of this command (assuming it is located in /lib):

$ file /lib/ld-linux.so.3

If this is a symbolic link, run the same command on the actual file pointed by the symbolic link.

Just want to be sure that the library is indeed stripped....

Hi Sanjeev,

Here is the output of file cmd and objdump for your reference.

$ file ld-linux.so.3
ld-linux.so.3: symbolic link to `ld-2.8.so'

$ objdump -t ld-2.8.so

ld-2.8.so:     file format elf32-little

SYMBOL TABLE:
no symbols

$ file ld-2.8.so
ld-2.8.so: ELF 32-bit LSB shared object, ARM, version 1 (SYSV), dynamically linked, stripped <<<<<<<<< It is stripped.

Thanks & Regards,

Manu

Hi Sanjeev,

Do you have any updates for us on this issue. We need the rootfs with debuginfo to be able to proceed with our debugging.

Thanks & Regards,

Manu

Manu,

You will need to re-build the filesystem keeping the symbols intact.

~sanjeev

Thanks for your reply Sanjeev.

Could you give me any pointers on how to do that?

Regards,

Manu

I am not sure what is the contained in the filesystem you are using and what specific content you are expecting in your filesystem. Building filesystems can be quite simple/complex based upon the content.

You can refer the Arago Project (http://arago-project.org/wiki/index.php/Main_Page).

We are using the standard filesystem that TI recommended.

arago-demo-image-dm6467t-evm.tar.gz

Could you plz let us know if you can provide the same rootFS with debug info.

I have checked arago project and I feel there is lack on documentation on how to proceed creating one ourselves. It will help if you can help me get to the right documentation page.

Regards,

Manu

Manu Batura said:

Could you plz let us know if you can provide the same rootFS with debug info.

Manu Batura said:

I have checked arago project and I feel there is lack on documentation on how to proceed creating one ourselves. It will help if you can help me get to the right documentation page.

Thanks Sanjeev, I have tried arago but was not able to successfully build the rootfs. I will check out the openembedded page you have referenced as well.

Thanks & Regards,

Manu

We have been able to build the rootfs with debug information from arago-project. However, when we tried to execute Valgrind using the same, it resulted in following error:

==2443== Memcheck, a memory error detector
==2443== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==2443== Using Valgrind-3.6.0 and LibVEX; rerun with -h for copyright info
==2443== Command: /home/root/RecvModApp
==2443==
==2443==
==2443== Process terminating with default action of signal 4 (SIGILL)
==2443==  Illegal opcode at address 0x380A8AE0
==2443==    at 0x40007A0: ??? (in /lib/ld-2.11.1.so)
==2443==
==2443== HEAP SUMMARY:
==2443==     in use at exit: 0 bytes in 0 blocks
==2443==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==2443==
==2443== All heap blocks were freed -- no leaks are possible
==2443==
==2443== For counts of detected and suppressed errors, rerun with: -v
==2443== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Illegal instruction

What debugging techniques do TI engineers use/suggest for memory profiling?

Manu,

Illegal opcode means either valgrind/ the application are not built for the processor you are running them on.

You may want to check your build options for both.

Sanjeev,

Our application is definitely not a problem since it runs without Valgrind just fine. Also we have build for ARM configured for Valgrind so I don't think that is also an issue.

Has TI run Valgrind on Davinci processors?

Also can you plz answer the other part of my query regarding what memory profiling tool does TI use/suggest?

Regards,

Manu

Manu,

Glad to know that your application runs fine. I thought you are using Valgrind to debug the application.

I assume, you know that ARM is not yet fully supported by Valgrind [see: http://valgrind.org/info/platforms.html] ...though development is in progress.

If you are having trouble running Valgrind you should follow-up with the Valgrind developers list [valgrind-developers@lists.sourceforge.net].

Also can you plz answer the other part of my query regarding what memory profiling tool does TI use/suggest?

I can't speak for each developer/group working on Linux within TI. I haven't had need to use any such tool as part of my work.

I know this is an old message ... but I would really like to bump this.

As far as I can tell, Valgrind SVN code supports ARMv7, while the dm6467 is ARMv5. I'm confused as to how to manage the cross compiling.

please help.