1. Home
  2. Embedded Programming
  3. How to line up source code with assembly code?

How to line up source code with assembly code?

My target board is running Freesacle MPC5500 based Microcontroller. I have Trace32 debugger connected to the target board and my desktop computer.

I built my application elf file and loaded in the internal flash memory of the MPC5500 Microcontroller. My application assembly code lines up with the source code in the debugger but the libraries source code that my application linked don't line up with the assembly code.

I am using the following Trace32 command to find out where the debugger is fetching source code from:

symbol.list.source

The reason library source code doesn't line up with the assembly source code is because debugger is not fetching library source code from the clearcase view that was used to build the application elf file. I build the elf file in H: directory. Application source code that lines up with the assembly code is being fetched from H: directory. That's because it was compiled in H: directory.

However, one library source code is being fetched from Y: drive. Another library source code is being fetched from F: drive.

I think library code is being fetched from drives that were used to compile the library. Since I didn't compile libraries in my H: drive, debugger is not fetching them from H: drive.

So, I know exactly what the problem is but I dont' know how to solve it.

How do I tell debugger to fetch library source code from H: drive?

--------------------------------------- Posted through

formatting link

Reply to
janii
Loading thread data ...

Do your libraries include debug information? If not there is the problem. Third party libaries usually don't, although just possibly there may be a "development" version available that does. If you have the source you can rebuild the libraries with debug info yourself.

--
Andrew Smallshaw
andrews@sdf.lonestar.org
Reply to
Andrew Smallshaw

It sounds like you have the actual source code for the library since you seem set on seeing it in the debugger. Sounds to me that you need to simply move the library source code to the H: drive and rebuild the libraries from there. This will replace any previously captured path information then ended up in the pre-built libraries that you are using now.

You know that it is quite normal to realize that standard library functions do their functions in a very predictable and reliable way. It could very well be of a minor value to be able to see the library source code in the debugging mode. Test to make sure that faulty code is setting the proper parameters for library calls and then just let the library function do its job. There is not normally a strong need to trace through the library functions.

You also have the possibility to consider taking the source code for the library functions and bringing that together as local sources in your project build. This would make the whole of the code used by your application be linked into the executable directly and all its source code would be directly visible to the debugger without further ado.

--

Michael Karas
Carousel Design Solutions
http://www.carousel-design.com
Reply to
Michael Karas

have

of

with

Thanks for the response. The libraries probably include debug information.

How do I find out for sure? These are not third party libraries. These libraries are already built by members of my team. My top level application links these libraries.

It won't make sense for me to rebuild all these libraries. They are responsibility of another group.

--------------------------------------- Posted through

formatting link

Reply to
janii

built by

Wow, the folks that built the library are part of your team and yet you cannot work with then to get the build environment and embedded debug information in these libraries to be compatible with the application development environment.

Some team!!

--

Michael Karas
Carousel Design Solutions
http://www.carousel-design.com
Reply to
Michael Karas

Well, either that, or it's one of those silly issues caused by ClearCase's somewhat harebrained idea of mounting a sandbox as a file system, and the rather spectacularly bad way that concept fits in with MS Windows' traditional understanding of what a file system actually is.

Reply to
Hans-Bernhard Bröker

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.