On 9/6/21 12:54 PM, Arnd Bergmann wrote:
On Sun, Sep 5, 2021 at 11:40 PM Helge Deller <deller@xxxxxx> wrote:
On 9/2/21 10:41 PM, Arnd Bergmann wrote:
The reason that the "output_len" access breaks is that gcc explicitly optimizes
the bytewise access into word accesses because it assumes that global variables
are correctly declared, and that they are aligned according to the requirements
of the ABI.
This may be surprising and even unfortunate, but I can see why they did
this optimization, and that it helps in other cases as well.
Arnd, you were absolutely correct and I was wrong.
It seems to work nicely now after I changed the output_len variable to
become an "extern char".
Ok, that's a relief, at least my patch wasn't the main cause then.
Yes, that's good!
Changing the declaration to 'extern char' of course is still incorrect, so
this might cause other problems in the future, the same way that the
old declaration caused the problem by decaring the wrong alignment.
Possibly. For the current use case it's enough.
I think declaring it as an array of four characters, or a struct with reduced
alignment would be the safer choice here.
Sure, I'll change that if it becomes necessary.
Ideally however you would
change the linker script to insert a
. = ALIGN(4);
before the output to make the variable properly aligned according to
the ABI. See 'git log arch/arm/kernel/vmlinux.lds.S' for a long history
of alignment changes we did there.
This here is a special case and it's not just parisc.
This happens when the linux kernel gets compressed, and at the end of
the compressed file bzip/gzip/lz4 and such gets added the size of the
compressed file.
See in generic Makefile scripts/Makefile.lib, line 392ff.
During make then this happens (for lz4 compression):
{ cat arch/parisc/boot/compressed/vmlinux.bin | lz4c -l -c1 stdin stdout; printf \\350\\044\\232\\000; } > arch/parisc/boot/compressed/vmlinux.bin.lz4
which is then later added as binary input to the linker to generate final file.
The printf() is the one which is then read afterwards.
Changing this isn't IMHO simply possible or useful, because gzip already does it that way
and it should be compatible independend which compression algorithm is used.
And if I'd change it I would need to change it for x86, sh and um arches too.
So, for now I don't think it's worth messing around here.
Helge
