Re: [QUESTION] Does or1k-elf-gcc handle OpenRISC 4B alignment requirement?

[Stafford Horne <shorne@gmail.com>]

Hi zgliu,

On Fri, Jul 11, 2025 at 02:20:42PM +0800, 48494605 wrote:
> Hi OpenRISC maintainers,
> 
> I encountered an alignment issue with `or1k-elf-gcc` and would like to confirm
> if it handles OpenRISC's 4B alignment requirement correctly. Here's the
> problem:
> 
> When using a recent version of `or1k-elf-gcc`, the following code triggers an alignment exception:
>           Alignment 0x600: Load/store access to unaligned location.
> 
> The issue occurs in a `memcpy()` operation within an ELF image loader (code
> snippet below). Interestingly, the same code works fine with the older
> `or32-elf-gcc 4.2.2`.

Interesting.  After 5.4.x we rewrote the GCC backend to get around issues with
copyright, none of the old code was used in the rewwrite.  I didn't even look at
the old implementation, so this feature was not carried forward.

> --- Code snippet ---
> static unsigned long load_elf_image_phdr(unsigned long addr)
> {
>       Elf32_Ehdr *ehdr;       /* Elf header structure pointer     */
>       Elf32_Phdr *phdr;       /* Program header structure pointer */
>       int i;
> 
> 
>       ehdr = (Elf32_Ehdr *) addr;
>       phdr = (Elf32_Phdr *) (addr + ehdr->e_phoff);
>       
>       printf("## phdr at 0x%08lx ...\n", phdr);
> 
> 
>       /* Load each program header */
>       for (i = 0; i < ehdr->e_phnum; ++i) {
>             void *dst = (void *)(uintptr_t) phdr->p_paddr;
>             void *src = (void *) addr + phdr->p_offset;
>             printf("Loading phdr %i to %p (%i bytes)\n",
>                   i, dst, phdr->p_filesz);
>             if (phdr->p_filesz)
>                   memcpy(dst, src, phdr->p_filesz);
>             if (phdr->p_filesz != phdr->p_memsz)
>                   memset(dst + phdr->p_filesz, 0x00,
>                         phdr->p_memsz - phdr->p_filesz);
>             //flush_cache((unsigned long)dst, phdr->p_filesz);
>             ++phdr;
>       }
> 
> 
>       return ehdr->e_entry;
> }
> ---

Do you have a more simple program that can reproduce the issue?  From the above
I cannot easily reproduce as I don't have hage the details of elf program
headers you are laoding.  At least can you share the output of `or1k-elf-readelf
-l ELF_FILE`? i.e.

    $ or1k-elf-readelf -l ~/work/linux/vmlinux

    Elf file type is EXEC (Executable file)
    Entry point 0xc0000000
    There are 4 program headers, starting at offset 52

    Program Headers:
      Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
      LOAD           0x002000 0xc0000000 0x00000000 0x511598 0x511598 R E 0x2000
      LOAD           0x514000 0xc0512000 0x00512000 0x5dffcc 0x5f1b4c RWE 0x2000
      NOTE           0x513544 0xc0511544 0x00511544 0x00054 0x00054 R   0x4
      GNU_STACK      0x000000 0x00000000 0x00000000 0x00000 0x00000 RW  0x10

Also, I see your program has some printf's what does it print before it crashes?
Note that the program headers have Alignment requirements.  It looks like your
program is not using those.

> Questions:
> 1. Should `or1k-elf-gcc` generate code that respects OpenRISC's 4B alignment by default?

It's posssible.  Getting a better test program and understand your ELF loader
inputs can help confirm where the exact issue is.

> 2. Is there a compiler flag (e.g., `-mstrict-align`) or workaround to enforce safe unaligned access?

We don't have it.

> 3. Could this be a regression compared to the older `or32-elf-gcc`?

  As its a rewrite with no shared code, its just a feature we didnt carry
forward, Doing memcpy with 4B reads is going to be faster.  Perhaps old code had
support for analigned memcpy reads.  This is something we can possibly fix.

But it has not been a problem that has come up until now and we have compiled
many programs with the toolchain.

> Any insights would be greatly appreciated!

You can read this?

   https://www.kernel.org/doc/Documentation/unaligned-memory-access.txt

In general we usually try to write code that works without performing unaligned
access.

-Stafford