Values which should be aligned(4) in .scomm are not aligned (example attached)

[dshadoff]

The attached example is for the PC-FX machine, and requires liberis.

Many variables have been placed in the global area of this C program, some are char arrays, some int, etc. The Makefile builds bank.c into assembler source, which is then compiled into object, and linked with a few other object files.

The key variables at issue here are found in the map file as:

                0x000000000000c6d8                default_date
                0x000000000000c6e3                bram_free

default_date is 'char[11]', and bram_free is 'int'. bram_free should be aligned at a full word (4-byte) boundary, but clearly is not.

In the 'bank.source' file (and also in 'bank.lst'), bram_free is identified as: .scomm _bram_free,4,4 Which means, 4 bytes in size, align to 4-byte boundary

...So it would seem to be either the assembler step (bank.source -> bank.o), or the link step which fails to follow through on this definition.

Checking versions on my executables, I see:

GNU ld (GNU Binutils) 2.24
GNU assembler version 2.24 (v810) using BFD version (GNU Binutils) 2.24
gcc version 4.7.4 (GCC)

compile_err.zip

[dshadoff]

As a follow-up, it should be noted that "default_date" and "bram_free" in the above example are one after another in the sequence of allocation in the .scomm area, but based on their definitions, they should not be sequential.

Somehow, the sequence of variables as defined in the global area is not respected, causing the sequence of variables in the .scomm area to be arbitrary. Neither is variable type or alignment respected for sequencing (as might be useful for keeping alignment with minimum wastage).

This means that efforts to re-arrange the sequence of definition are irrelevant, or at least do not have lasting effect on working around the underlying issue of not respecting alignment of variables.

[jbrandwood]

Fixed by a recent check-in.