Sergey Bugaev, le ven. 21 avril 2023 17:30:12 +0300, a ecrit:
> On Fri, Apr 21, 2023 at 12:24 PM Samuel Thibault
> wrote:
> > No, they don't :) otherwise they wouldn't respect the ABI. The AMD64
> > ABI indeed defaults to /lib/ld64.so.1, and says that Linux uses
> > /lib64/ld-linux-x86-64.so.2, an
On 2023-04-20 05:06, Cristian Rodríguez via Libc-alpha wrote:
Exactly, my understanding is that it is a futile exercise ..if one
sufficient privilege at that stage one can do whatever is desired.. why
even bother messing with the standard fds..
Making stdin unreadable is not meant to thwart a
On Fri, Apr 21, 2023 at 12:24 PM Samuel Thibault
wrote:
> No, they don't :) otherwise they wouldn't respect the ABI. The AMD64
> ABI indeed defaults to /lib/ld64.so.1, and says that Linux uses
> /lib64/ld-linux-x86-64.so.2, and that is cast in stone, we cannot change
> it any more.
>
> /lib/ld-x86
On 21/04/23 10:56, Sergey Bugaev wrote:
> On Fri, Apr 21, 2023 at 3:58 PM Adhemerval Zanella Netto
> wrote:
>>> Yes, sure, I wasn't really suggesting we do that change. My point is,
>>> I would like to make the same memcpy callsites both work during early
>>> startup and start calling the more
On Fri, Apr 21, 2023 at 3:58 PM Adhemerval Zanella Netto
wrote:
> > Yes, sure, I wasn't really suggesting we do that change. My point is,
> > I would like to make the same memcpy callsites both work during early
> > startup and start calling the more efficient implementation once early
> > startup
On 21/04/23 09:38, Sergey Bugaev wrote:
> On Fri, Apr 21, 2023 at 2:50 PM Adhemerval Zanella Netto
> wrote:
>> It might work if you don't care about a different architecture than x86,
>> and that's why I added the alias (so each architecture is free to name
>> its ifunc variant). And the patch
On 19/04/23 13:02, Sergey Bugaev wrote:
> When opening a temporary file without O_CLOEXEC we risk leaking the
> file descriptor if another thread calls (fork and then) exec while we
> have the fd open. Fix this by consistently passing O_CLOEXEC everywhere
> where we open a file for internal use
On 19/04/23 13:02, Sergey Bugaev wrote:
> Under certain conditions, SIGHUP will be sent to the child process when
> the parent process (the one calling daemon ()) terminates -- namely, if
> the parent process was the session leader and the child process was in
> the same session (which will be t
On Fri, Apr 21, 2023 at 2:50 PM Adhemerval Zanella Netto
wrote:
> It might work if you don't care about a different architecture than x86,
> and that's why I added the alias (so each architecture is free to name
> its ifunc variant). And the patch was exactly to handle the implicit
> created mem*
On 19/04/23 13:02, Sergey Bugaev wrote:
> This is nicer, and is going to be required for the following changes
> to reasonably stay within the 79 column limit.
>
> No functional change.
>
> Signed-off-by: Sergey Bugaev
LGTM, thanks. I can be installed independently.
Reviewed-by: Adhemerval
Hello,
On Thu, Apr 20, 2023 at 11:26 PM H.J. Lu wrote:
> Doesn't it disable IFUNC for memcpy and stpncpy?
I was hoping you'd tell me whether it does :|
I *think* on i386 it does indeed (so I'd need to rework that part of
the patch), but not on x86_64. This is based on the following
observations
On 21/04/23 06:27, Sergey Bugaev wrote:
> Hello,
>
> On Thu, Apr 20, 2023 at 11:38 PM Adhemerval Zanella Netto
> wrote:
>> Can't you use a similar strategy done by
>> 5355f9ca7b10183ce06e8a18003ba30f43774858 ?
>
> Do I understand it right that that is the moral equivalent of
>
> #define mem
Hello,
On Thu, Apr 20, 2023 at 11:38 PM Adhemerval Zanella Netto
wrote:
> Can't you use a similar strategy done by
> 5355f9ca7b10183ce06e8a18003ba30f43774858 ?
Do I understand it right that that is the moral equivalent of
#define memcpy __memcpy_sse2_unaligned
except that it works aat assembl
Sergey Bugaev, le ven. 21 avril 2023 12:17:54 +0300, a ecrit:
> Hello,
>
> On Fri, Apr 21, 2023 at 12:01 AM Samuel Thibault
> wrote:
> > BTW, which dynamic linker path do we have set for x86_64-gnu?
>
> It's in gcc/config/i386/gnu64.h in GCC tree:
>
> #define GNU_USER_DYNAMIC_LINKER64 "/lib/ld-
Hello,
On Fri, Apr 21, 2023 at 12:01 AM Samuel Thibault
wrote:
> BTW, which dynamic linker path do we have set for x86_64-gnu?
It's in gcc/config/i386/gnu64.h in GCC tree:
#define GNU_USER_DYNAMIC_LINKER64 "/lib/ld-x86-64.so.1"
It was added by Flavio.
So GCC passes -dynamic-linker /lib/ld-x86
15 matches
Mail list logo
