public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Adhemerval Zanella <adhemerval.zanella@linaro.org>
To: Paul E Murphy <murphyp@linux.ibm.com>,
	"Paul E. Murphy" <murphyp@linux.vnet.ibm.com>,
	libc-alpha@sourceware.org
Subject: Re: [PATCHv2] powerpc64le/power9: guard power9 strcmp against rtld usage [BZ# 25905]
Date: Mon, 4 May 2020 15:26:22 -0300	[thread overview]
Message-ID: <e6b56813-9307-065b-e3cc-eef0bfe2daa6@linaro.org> (raw)
In-Reply-To: <915d6ad2-9ea4-793b-e6a6-03e884a3591c@linux.ibm.com>



On 04/05/2020 15:02, Paul E Murphy wrote:
> 
> 
> On 5/4/20 11:36 AM, Adhemerval Zanella wrote:
> 
>> As a side note, is strcmp the only string routine that used in lazy
>> resolution?
> 
> It was the only one I encountered while debugging this issue.  I won't claim it is the only one, I have limited experience with that corner of glibc.  Though, I am surprised only one test failed due to the vector register clobbering.

I am wondering which would be best way to avoid such issue to happen
with different string routines since some specific loader code need 
to adhere to more strict ABI requirements.

The powerpc Makefile already adds the expected compiler tools to
avoid this very issue:

---
sysdeps/powerpc/powerpc64/Makefile

 13 # These flags prevent FPU or Altivec registers from being used,
 14 # for code called in contexts that is not allowed to touch those registers.
 15 # Stupid GCC requires us to pass all these ridiculous switches.  We need to
 16 # pass the -mno-* switches as well to prevent the compiler from attempting
 17 # to emit altivec or vsx instructions, especially when the registers aren't
 18 # available.
 19 no-special-regs := $(sort $(foreach n,40 41 50 51 60 61 62 63 \
 20                                       $(foreach m,2 3 4 5 6 7 8 9, \
 21                                                   3$m 4$m 5$m),\
 22                                     -ffixed-$n)) \
 23                    $(sort $(foreach n,$(foreach m,0 1 2 3 4 5 6 7 8 9,\
 24                                                 $m 1$m 2$m) 30 31,\
 25                                     -ffixed-v$n)) \
 26                    -ffixed-vrsave -ffixed-vscr -mno-altivec -mno-vsx
[...]
 36 CFLAGS-dl-runtime.os = $(no-special-regs)
 37 CFLAGS-dl-lookup.os = $(no-special-regs)
 38 CFLAGS-dl-misc.os = $(no-special-regs)
 39 CFLAGS-rtld-mempcpy.os = $(no-special-regs)
 40 CFLAGS-rtld-memmove.os = $(no-special-regs)
 41 CFLAGS-rtld-memchr.os = $(no-special-regs)
 42 CFLAGS-rtld-strnlen.os = $(no-special-regs)
---

However it does not help when an arch-specific implementation might ended being
pulled in rtld build and thus making this ineffective (And it seems that 
the strcmp is missing as well for the powerpc case).

And using __builtin_strcmp not -ffreestanding does really help on dl-runtime,
since strcmp call might still being generated by compiler.  

Maybe one option could to enforce all rtld code to use generic C implementation
instead, not allowing sysdeps folder to override it.  It should scale better
than actually testing all possible permutation and require less hacky solutions
like overriding the loader object for an specific build option as this patch.

  reply	other threads:[~2020-05-04 18:26 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-01 20:32 [PATCH] " Paul E. Murphy
2020-05-04 12:26 ` Adhemerval Zanella
2020-05-04 15:25   ` [PATCHv2] " Paul E. Murphy
2020-05-04 16:36     ` Adhemerval Zanella
2020-05-04 18:02       ` Paul E Murphy
2020-05-04 18:26         ` Adhemerval Zanella [this message]
2020-05-04 21:16           ` Paul E Murphy
2020-05-05 21:01             ` Adhemerval Zanella

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e6b56813-9307-065b-e3cc-eef0bfe2daa6@linaro.org \
    --to=adhemerval.zanella@linaro.org \
    --cc=libc-alpha@sourceware.org \
    --cc=murphyp@linux.ibm.com \
    --cc=murphyp@linux.vnet.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).