Quote:
Originally Posted by pipper
In my case I was lucky, vlink had already produced an output file. I used objdump to get a disassembly of the whole thing which gave me the offset plus the corresponding assembly. The offending offset will not directly show up as “line number” as the relocation is part of an instruction, but you’ll get close. Use this as reference in the original sources to lookup the actual offending instruction. Maybe there’s a more elegant way. But this worked for me.
|
Thank you for your tip!
I tried to use objdump to disassemble and to find a generated code which can't be relocated, according to your description. However vasm/vlink package comes with vobjdump which can parse VOBJ format only. In my case, vlink produces a hunk executable from .o files which are not in VOBJ format (by taking a look at vobjdump source code, VOBJ file must begin with a series of magic numbers which my .o files do not...). So this is currently the dead end for me.
However your example led me to another way which was successful:
Step #1:
vlink can produce a mapping file ("-M" parameter). There I could see at which offsets all code sections start. By comparing offset from a vlink error message (e.g. ....at Program+0x636), I could find which code section the error is at and compute a relative offset to the instruction byte.
Step #2:
vasm can produce a listing file ("-L" parameter). In there, I could see what instruction is at previously computed offset. And voila -- that's my culprit!
Yes, it is tedious. Most probably I am missing something. Some obvious way how to find which instruction in my source code the linker can't relocate.
P.S.: Can debug info (in .o file) help somehow?