[PATCH v2] RISC-V: Fix SIGSEGV of --static-pie binaries on riscv64 [BZ #33911]

[Jeffrey Law]

On 3/9/2026 6:33 AM, daichengrong wrote:
>
>
> On 3/7/26 00:42, Adhemerval Zanella Netto wrote:
>
> >
> > Sorry, but this kind of code duplication for arch-specific 
> workarounds are not
> > acceptable.
>
> I agree with this point. Using arch-specific code duplication as a 
> workaround
> is not a good long-term solution.
>
> In the v3 RFC reference implementation, I first tried to adjust the code
> structure to avoid giving the compiler the opportunity to generate a 
> memset
> libcall. The idea was to explore this from the perspective of compiler
> optimization behavior, i.e. trying to prevent certain patterns from being
> optimized into calls to more complex libc routines.
That's effectively coding to an implementation detail in the compiler.  
Yea, maybe you can obfuscate things today, but it opens up a maintenance 
burden as glibc is on the path to supporting multiple compilers and 
compilers are continually improving.

In general I recommend avoiding this path, it's proven too fragile in 
many contexts through the decades I've been involved in compiler work.
>
>
> Regarding the option you mentioned about using
> -ftree-loop-distribute-patterns to avoid libcalls,
>
> I am not entirely sure whether disabling this optimization for this TU
> might cause us to lose some optimizations that the compiler would
> otherwise perform, or lead to other unintended effects on the generated
> code.
Any impact would be minimal.  Essentially that option recognizes certain 
loops are just memcpy, memset, etc and converts the loops to call the 
relevant function.  Within this TU and in the context of early startup, 
you never want the compiler to make those kinds of optimizations as they 
introduce the precise behavior we're trying to avoid.

The biggest problem with using the flag is it's specific to a particular 
compiler, GCC in this case.


>
> For example, in the RFC v3 reference implementation, a memcpy was used 
> even
> though the number of bytes to copy is known at compile time:
The compiler has the choice to inline expand or make calls to memcpy, 
memset, etc.  Each target in the compiler has influence on that decision 
-- ie, one target might decide to inline expand (and thus would be safe) 
while another might call the library routine. Worse yet, those decisions 
could change from one release of the compiler to the next, etc.

That's why we want the dl-symbol-redir-ifunc approach.  It works 
irrespective of the compiler's decisions.

jeff