Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Tue, 27 Oct 2020 21:50:57 -0400
From: Rich Felker <dalias@...c.org>
To: Patrick Oppenlander <patrick.oppenlander@...il.com>
Cc: musl@...ts.openwall.com, unicorn_wang <unicorn_wang@...look.com>
Subject: Re: [Question] about arch/riscv64/crt_arch.h

On Wed, Oct 28, 2020 at 12:48:02PM +1100, Patrick Oppenlander wrote:
> On Wed, Oct 28, 2020 at 12:40 PM Chen Wang <unicorn_wang@...look.com> wrote:
> >
> > hi,
> > I'm reading musl (1.2.1) code for riscv. In arch/riscv64/crt_arch.h,
> >
> > __asm__(
> > ......
> > "andi sp, sp, -16\n\t" // <--- why do we need this?
> > "tail " START "_c"
> > );
> >
> 
> I'm not familiar with RISC-V, but it's there to guarantee that the
> stack is 16-byte aligned which must be either an architectural or ABI
> requirement.
> 
> Perhaps the kernel can start the process with a more relaxed stack
> alignment. Otherwise it's there for safety (paranoia).

Regardless of whether the kernel can, the dynamic linker can, because
it peels off a possibly odd number of 8-byte arguments when executed
as a command:

	/lib/ld-musl-riscv64.so.1 [options] your_program [args]

The ELF entry point contract is just that SP point to the argument
vector, not that it be a valid stack pointer for entering a C
function. So the entry point has to align the stack before
transferring control to C.

Rich

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.