Hi,
Since a while (I don't know) I have warnings with [gplink-1.4.0 #1128 (Feb 1 2015)] of type "Destination address must be word aligned" and I can't figure out what's on.
I thought these messages was GPASM-related for this like "goto $-1"?
(this warning is listed in the GPASM section of gputils manual)
But there is no warning during assembly.
I have no warnings with MPLINK 5.08 when linking GPASM-generated object files.
Here is an example:
Processor: PIC18F13K22.
Assembler calls for the related files (no warnings):
"C:\Program Files\gputils\bin\gpasm.exe" -i -c -o "Serial.o" "Serial.asm" "C:\Program Files\gputils\bin\gpasm.exe" -i -c -o "TestProcVar2.o" "TestProcVar2.asm"
Linker call:
"C:\Program Files\gputils\bin\gplink.exe" -s "pmp.lkr" -c -o "TestProcVar.hex" warning: Destination address must be word aligned at 0x321 of section "__TestProcVar2.11". warning: Destination address must be word aligned at 0x315 of section "__Serial.1".
(The linker script is a pure copy of the standard one with "FILES" directives at the begining)
The problem is that the related sections does just contain this:
__TestProcVar2.11 code ; Subroutine section __FILLZ256: global __FILLZ256 __FILLZ256.0: clrf POSTINC0, ACCESS ; Clear byte decfsz WREG, F, ACCESS ; Loop on count bra __FILLZ256.0 return ; Return from subroutine
and this:
__Serial.1 code ; Proc / func section Serial.SerialPort_Output: global Serial.SerialPort_Output __SerialPort_Output.0: ; --- Loop target btfss PIR1, TXIF, ACCESS bra __SerialPort_Output.0 movff Serial.SerialPort_Output.Ch, TXREG ; Move byte return ; Return from subroutine
I installed this: gputils-20150924-1149-setup.exe
I tested with the contents of the archive test.zip. I launched the compile.bat. There was no warning or error message.
This is a test archive.
Hi again,
Thanks for the support.
I installed your gputils version, same problem with my files, no problem with your test.zip. So obviously the .asm snippets are not enough; the problem may be relative to the whole segments / cross-references between them, etc...
I attached the full object files and script (I cannot give the full .asm files), along with a simple .bat to start just the link, it should reproduce the problem.
I will try to make the simplest .asm file that reproduces the behavior so that you will have a full context.
Give me some time (tomorrow maybe), it's a bit late here...
Hi..
I can not verify, but I recall this error is related to having a code section with odd number of bytes. Perhaps you are defining data into flash and are missing a padding byte to make it an even number of bytes long.
Hi,
You are almost right: I have downsized the sources until the problem vanished.
There was one code_pack section of 15 bytes in TestProcVar2, none in Serial.
All other sections are instructions only.
If I reduce the code_pack section to an even nb of bytes: no more warnings.
Strange thing #1: If I have only one file with all the code, no warning at all!!!
Strange thing #2: The warnings refer to sections that are not related to the code_pack one.
I've attached simplified sources that reproduces the problem (only one warning).
Indeed, it required a code_pack section. Normal code sections pad each db to even number of bytes automatically and are therefore safer to use when the padding byte is not a risk.
It particularly affects the sections that are linked after the code_pack section. When they are linked after the odd sized code_pack section, the instruction addresses in them become odd. If there are two odd sized code_pack sections, the next section again starts at even address and all is well again.
And depending on how GPLINK sorts the sections, the next one to be fitted after the code_pack section gets the warning despite it is not guilty...
I made a minimal code that causes the error. Unfortunately, the code will actually be incorrect. See the instruction bra.
I don't see the point about "see the instruction bra"? ;-) Training equipment for young ladies?
As I said, the actual behaviour may strongly depend on the linker's sections sorting and fitting algorithm.
My point of view is that the linker should not emit the warning at the beginning of a section to be linked, but at the end of a normal "code" section when the final address is odd, giving the name of that section.
An odd number of bytes is perfectly legal in a "code_pack" section, this is what they are used for.
:-)
This is located in the list file (GPLINK_beavior.lst) at address 0x00000B. (This is the last code line.)
Ouch, I see!
I was trusting that the generated code was good, that after the warning a word alignment was automatically made...
OTOH the odd nb of bytes in the const section above main was automatically handled by a db 0 padding, without any warning.
"code_pack" sections cannot be word aligned because it is legal to have several "code_pack" sections to be consecutive and packed together. In my compiler, each text string / const array of bytes have their own "code_pack" section so that it's up to the linker to find the best fit.
The fix would be "just" to do a word align at the beginning of a normal "code" section.
Not so easy because of several cases; e.g.: to minimize bytes loss, do the linker has to find an even address fitting area before to try word alignment after odd ones? I wonder how does MPLINK?
Neat bug. Not trivial.
For now I will force an internal "code_pack" padding in the compiler to workarround this.
Here is the solution:
svn [r1150]
gputils-src-20151108-1150.tar.gz
gputils-20151108-1150-setup.exe
Please try that.
Related
Commit: [r1150]
Last edit: Molnár Károly 2016-02-15