AnsweredAssumed Answered

Debugging multiple executables

Question asked by SCOTT MILLER on Dec 18, 2018
Latest reply on Dec 19, 2018 by SCOTT MILLER

Just upgraded to MCUX 10.3.0.  Looks like some nice improvements but I've hit a snag and I'm not sure if it's related to the update or not.


I'm troubleshooting a bootloader problem and I need to be able to step through from my application code to the bootloader, but I'm not getting any source or symbols for the bootloader - which is a separate project with its own ELF output that's loaded on the target with a P&E Cyclone.


In CodeWarrior I can just select the ELF file as an additional executable to debug and it works great.  I'd swear I had this working before in MCUX, and I've tried using the instructions here, but nothing changes - the gdb command doesn't give an error, it just doesn't seem to have any effect.


I had to delete my existing launch configurations from the project when I imported the project into the new MCUX workspace.  Tomorrow I can try recovering them from backups (they might be in version control, too) and going back to the old version, but if someone can tell me how this is supposed to work, I would be most grateful.


With regards to Erich's gdb example in the link given above, I'm not clear what's going on with the offset and why gdb needs to be given one.  The offset is the offset within the ELF file of a particular section, right?  And in his example .text starts at 0x8200.  Shouldn't that be the actual .text contents?  I'd have expected the debug info to be in the .debug_* sections.  And if add-symbol-file always takes an ELF file as input and always needs the offset of .text, why can't it parse the ELF file itself to find the proper section?


In any case, using the same procedure with my executables doesn't give the desired result.