This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: objcopy problem with tic4x architecture


Aschwin Gopalan wrote:
I try to produce a binary file (to loaded into the dsp) using
objcopy from a coff2-c4x fully linked object file. As soon as I use
-O binary (or any of the Hex output formats) the following happens:
The Adresses in the coff file are addressing 32-bit wide memory. The adresses are put directly into the output file, but without multiplying them by four to address the correct *byte* in the file, resulting in overlapping sections. What should I do?



Hi,


Do you have a simple testcase to prove your point, please?

The problem with tic4x has always been that it is unaware of bytes. The host must use 4 native storeage elements (i.e. bytes) to store one of the target's native storeage element (i.e. a 32-bit word). This problem arises when you are working with the output formats, like you do. Should they apply to the host, i.e. multiply the addresses with four, or should they apply to the target, like they do today. Beacause if you are to flash this binary image (or ihex for that matter) into a 32-bits flash which is connected to the DSP, well, then the image is correct AFAICS.

The same applies to your question about gdb; getting a gdb patch up and running is simple enough - but the main gdb requres a lot of changes as the host is byte addressable, while the target is 32-bit addressable. As for your question; no I do not have any working source. I plan on make one, but I'm too busy at the moment.


Regards, Svein


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]