I am working on a project that depends on Lauterbach JTAG debugger hardware and software, and the support on the target JTAG cable ended in July 2011. We using a Linux 2.6.33 kernel on an omap2 processor. We are using gcc 4.9.2 to build the kernel image (not sure what version of bintools).
For those unfamiliar with how Lauterbach licenses its software, the target cable (connects between the debug pod and the target) carries the support contract dates. Any version of the Lauterbach Trace-32 software before and up to the end of the support period may be used, however anything after the end of support for the cable may not except for a 30 minute per session demo period. We are working through our purchasing process to renew the support contract for the cables, but until that is done (may take months), we're stuck with what we have.
It appears that the debug information produced by the toolchain we are using is too new for the last version of the Trace-32 debugger software released before July, 2017. Attempts to load the symbols for the kernel image (vmlinux) using the command:
data.load.elf \\path\to\vmlinux /nocode
fail with a message similar to:
error: entry near offset 5432100. in file \\path\to\vmlinux (use DUMP)
The easiest solution, of course, is to update to the first version of Trace-32 software that supports whatever ELF/DWARF combination that our toolchain produces. We know the most recent release works, but our cable does not support that version and won't until our procurement folks work out whether this is test equipment or software (they come out of different budgets).
For the next few months, we need a work-around. I'm looking for one of the following:
I thank everyone in advance for any help.
Edit: I'm not 100% sure whether the toolchain is producing DWARF3 or DWARF4, so it may be that I need to make a ELF/DWARF2 "vmlinux"
To your three ideas:
-g -gdwarf-2 -gstrict-dwarf