#9 Trouble for interpreting GPLINK warning

[Philippe Paternotte]

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

[Molnár Károly]

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.

[Molnár Károly]

This is a test archive.

[Philippe Paternotte]

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...

[Marko Kohtala]

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.

[Philippe Paternotte]

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).

[Marko Kohtala]

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.

[Philippe Paternotte]

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...

[Molnár Károly]

I made a minimal code that causes the error. Unfortunately, the code will actually be incorrect. See the instruction bra.

[Philippe Paternotte]

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.

[Molnár Károly]

I don't see the point about "see the instruction bra"? ;-) Training equipment for young ladies?

:-)
This is located in the list file (GPLINK_beavior.lst) at address 0x00000B. (This is the last code line.)

[Philippe Paternotte]

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.

[Molnár Károly]

Here is the solution:

svn [r1150]

gputils-src-20151108-1150.tar.gz
gputils-20151108-1150-setup.exe

Please try that.