On Sat, Jan 25, 2020 at 10:53:31AM +, Sergei Trofimovich wrote:
> [ sending it to musl, glibc and gcc devel mailing list as we need
> to build a consensus across the projects ]
>
> To support smash stack protection gcc emits __stack_chk_fail
> calls on all targets. On top of that gcc emits _
On Thu, Jan 30, 2020 at 06:33:51AM -0600, Segher Boessenkool wrote:
> On Sat, Jan 25, 2020 at 10:54:24AM -0500, Rich Felker wrote:
> > > To support smash stack protection gcc emits __stack_chk_fail
> > > calls on all targets. On top of that gcc emits __stack_chk_fail_local
&g
On Mon, Sep 21, 2020 at 02:47:51PM +0200, Alejandro Colomar wrote:
> [[ CC += libc-coord at lists.openwall.com ]]
I missed the beginning of this so perhaps it's already been discussed,
but I don't see how cdefs.h is a remotely reasonable place for this.
cdefs.h is included by all glibc headers and
For background on the static PIE model I'm working with, see the
following post to the GCC list:
https://gcc.gnu.org/ml/gcc/2015-06/msg8.html
So far, I've been prototyping static PIE support by having GCC pass
the following options to ld instead of -static -pie:
-static -shared -Bsym
Ping.
On Wed, Jun 24, 2015 at 12:18:47AM -0400, Rich Felker wrote:
> For background on the static PIE model I'm working with, see the
> following post to the GCC list:
>
> https://gcc.gnu.org/ml/gcc/2015-06/msg8.html
>
> So far, I've been prototyping static PI
On Mon, Aug 17, 2015 at 02:19:34PM -0700, H.J. Lu wrote:
> On Tue, Jun 23, 2015 at 9:18 PM, Rich Felker wrote:
> > For background on the static PIE model I'm working with, see the
> > following post to the GCC list:
> >
> > https://gcc.gnu.org/ml/gcc/2015-06/ms
On Mon, Aug 17, 2015 at 02:19:34PM -0700, H.J. Lu wrote:
> On Tue, Jun 23, 2015 at 9:18 PM, Rich Felker wrote:
> > For background on the static PIE model I'm working with, see the
> > following post to the GCC list:
> >
> > https://gcc.gnu.org/ml/gcc/2015-06/ms
On Mon, Aug 17, 2015 at 10:42:56PM -0400, Rich Felker wrote:
> On Mon, Aug 17, 2015 at 02:19:34PM -0700, H.J. Lu wrote:
> > On Tue, Jun 23, 2015 at 9:18 PM, Rich Felker wrote:
> > > For background on the static PIE model I'm working with, see the
> > >
On Mon, Aug 17, 2015 at 10:29:41PM -0700, Cary Coutant wrote:
> > So far, I've been prototyping static PIE support by having GCC pass
> > the following options to ld instead of -static -pie:
> >
> > -static -shared -Bsymbolic
> >
> > This partly works, but since ld does not know it's produc
On Tue, Aug 18, 2015 at 08:56:00AM -0700, H.J. Lu wrote:
> On Mon, Aug 17, 2015 at 8:44 PM, Rich Felker wrote:
> > On Mon, Aug 17, 2015 at 10:42:56PM -0400, Rich Felker wrote:
> >> On Mon, Aug 17, 2015 at 02:19:34PM -0700, H.J. Lu wrote:
> >> > On Tue, Jun 23, 2015
On Tue, Aug 18, 2015 at 09:30:56AM -0700, H.J. Lu wrote:
> On Tue, Aug 18, 2015 at 9:08 AM, Rich Felker wrote:
> > On Tue, Aug 18, 2015 at 08:56:00AM -0700, H.J. Lu wrote:
> >> On Mon, Aug 17, 2015 at 8:44 PM, Rich Felker wrote:
> >> > On Mon, Aug 17, 2015 at 10:42
On Wed, Aug 19, 2015 at 01:30:12PM +0930, Alan Modra wrote:
> On Tue, Aug 18, 2015 at 08:58:43PM -0400, Rich Felker wrote:
> > I've updated the patch to cover the changes needed for all the
> > elf??-*.c target files (lots of code duplication already there), skip
On Tue, Aug 18, 2015 at 09:34:45PM -0700, Cary Coutant wrote:
> > This is OK to commit with a suitable ChangeLog. I think a separate ld
> > option is best too, because historically -static and its aliases
> > -Bstatic, -dn, -non_shared really are about what type of libraries are
> > accepted rathe
On Wed, Aug 19, 2015 at 03:01:20PM +, Joseph Myers wrote:
> If a new option is added, of course it needs documenting in the ld manual
> (ld.texinfo).
I can do that and resubmit the patch, but is there consensus that
adding a new option is appropriate? Like I said before I mildly lean
that way
On Tue, Sep 01, 2015 at 05:51:44PM -0700, Andy Lutomirski wrote:
> Hi all-
>
> Linux has a handful of weird features that are only supported for
> backwards compatibility. The big one is the x86_64 vsyscall page, but
> uselib probably belongs on the list, too, and we might end up with
> more at s
On Tue, Sep 01, 2015 at 08:39:27PM -0700, Andy Lutomirski wrote:
> On Tue, Sep 1, 2015 at 7:54 PM, Rich Felker wrote:
> > On Tue, Sep 01, 2015 at 05:51:44PM -0700, Andy Lutomirski wrote:
> >> Hi all-
> >>
> >> Linux has a handful of weird features that a
On Tue, Sep 01, 2015 at 09:32:22PM -0700, Andy Lutomirski wrote:
> On Tue, Sep 1, 2015 at 9:18 PM, Rich Felker wrote:
> > On Tue, Sep 01, 2015 at 08:39:27PM -0700, Andy Lutomirski wrote:
> >> On Tue, Sep 1, 2015 at 7:54 PM, Rich Felker wrote:
> >> > On Tue, Sep 01,
On Tue, Sep 01, 2015 at 10:03:27PM -0700, Andy Lutomirski wrote:
> On Tue, Sep 1, 2015 at 9:55 PM, Rich Felker wrote:
> > On Tue, Sep 01, 2015 at 09:32:22PM -0700, Andy Lutomirski wrote:
> >> On Tue, Sep 1, 2015 at 9:18 PM, Rich Felker wrote:
> >> > On Tue, Sep 01,
On Wed, Sep 09, 2015 at 12:36:01PM -0400, Zack Weinberg wrote:
> The first, simpler problem is strictly optimization. explicit_bzero
> can be optimized to memset followed by a vacuous use of the memory
> region (generating no machine instructions, but preventing the stores
> from being deleted as
On Wed, Sep 09, 2015 at 12:47:10PM -0400, Zack Weinberg wrote:
> On Wed, Sep 9, 2015 at 12:42 PM, Rich Felker wrote:
> > You're making this harder than it needs to be. The "m" constraint is
> > the wrong thing to use here. Simply use:
> >
> > _
On Wed, Sep 09, 2015 at 12:58:36PM -0400, Zack Weinberg wrote:
> On 09/09/2015 12:52 PM, paul_kon...@dell.com wrote:
> > Then again, suppose all you had is explicit_bzero, and an annotation
> > on the data saying it's sensitive. Can static code analyzers take
> > care of the rest? If so, this sor
On Wed, Sep 09, 2015 at 02:48:22PM -0400, Zack Weinberg wrote:
> On 09/09/2015 01:13 PM, Rich Felker wrote:
> > On Wed, Sep 09, 2015 at 12:47:10PM -0400, Zack Weinberg wrote:
> >> On Wed, Sep 9, 2015 at 12:42 PM, Rich Felker wrote:
> >>> You're making this
I've been working on the new version of runtime-selected SH atomics
for musl, and I think what I've got might be appropriate for GCC's
generated atomics too. I know Oleg was not very excited about doing
this on the gcc side from a cost/benefit perspective, but I think my
approach is actually prefer
On Tue, Jan 19, 2016 at 03:28:52PM -0500, Rich Felker wrote:
> I've been working on the new version of runtime-selected SH atomics
> for musl, and I think what I've got might be appropriate for GCC's
> generated atomics too. I know Oleg was not very excited about doing
>
On Thu, Jan 21, 2016 at 08:08:18AM +0900, Oleg Endo wrote:
> On Tue, 2016-01-19 at 15:28 -0500, Rich Felker wrote:
> > I've been working on the new version of runtime-selected SH atomics
> > for musl, and I think what I've got might be appropriate for GCC's
> >
On Tue, Apr 19, 2016 at 12:10:58PM -0700, H.J. Lu wrote:
> On Tue, Apr 19, 2016 at 7:06 AM, Michael Matz wrote:
> > Hi,
> >
> > On Tue, 19 Apr 2016, Richard Biener wrote:
> >
> >> So with all this it sounds that current protected visibility is just
> >> broken and we should forgo with it, making i
On Wed, Apr 20, 2016 at 06:09:54PM +0200, Volodymyr Kuznetsov wrote:
> On Wed, Apr 20, 2016 at 4:54 PM, Szabolcs Nagy wrote:
> > On 13/04/16 14:01, Cristina Georgiana Opriceana wrote:
> >> I bring to your attention SafeStack, part of a bigger research project
> >> - CPI/CPS [1], which offers compl
On Mon, May 09, 2016 at 09:02:33PM +0200, Michael Matz wrote:
> Hi,
>
> On Sat, 7 May 2016, Rich Felker wrote:
>
> > > > * sigaltstack and swapcontext are broken too.
> > >
> > > We have prototype that supports swapcontext that we're happy to
&
On Mon, May 09, 2016 at 10:03:02PM +0200, Michael Matz wrote:
> Hi,
>
> On Mon, 9 May 2016, Rich Felker wrote:
>
> > > > The *context APIs are deprecated and I'm not sure they're worth
> > > > supporting with this. It would be a good ex
On Thu, Feb 12, 2015 at 04:18:57PM +0100, Ulrich Weigand wrote:
> Hello,
>
> we're running into a problem related to use of initial-exec access to
> TLS variables in dynamically-loaded libraries. Now, in general, this
> is actually not supported. However, there seems to an "inofficial"
> extensi
On Thu, Feb 12, 2015 at 05:11:45PM +0100, Jakub Jelinek wrote:
> On Thu, Feb 12, 2015 at 11:09:59AM -0500, Rich Felker wrote:
> > On Thu, Feb 12, 2015 at 04:18:57PM +0100, Ulrich Weigand wrote:
> > > Hello,
> > >
> > > we're running into a problem
On Thu, Feb 12, 2015 at 08:56:26AM -0800, H.J. Lu wrote:
> On Thu, Feb 12, 2015 at 8:11 AM, Jakub Jelinek wrote:
> > On Thu, Feb 12, 2015 at 11:09:59AM -0500, Rich Felker wrote:
> >> On Thu, Feb 12, 2015 at 04:18:57PM +0100, Ulrich Weigand wrote:
> >> > Hello,
>
On Thu, Feb 12, 2015 at 06:23:12PM +, Andrew Haley wrote:
> On 02/12/2015 04:16 PM, Rich Felker wrote:
> > On Thu, Feb 12, 2015 at 05:11:45PM +0100, Jakub Jelinek wrote:
> >> On Thu, Feb 12, 2015 at 11:09:59AM -0500, Rich Felker wrote:
> >>>
> >>> Th
On Fri, Feb 13, 2015 at 10:12:11AM +1030, Alan Modra wrote:
> On Thu, Feb 12, 2015 at 12:07:24PM -0500, Rich Felker wrote:
> > On Thu, Feb 12, 2015 at 08:56:26AM -0800, H.J. Lu wrote:
> > > On Thu, Feb 12, 2015 at 8:11 AM, Jakub Jelinek wrote:
> > > > On Thu, Fe
On Fri, Feb 13, 2015 at 09:12:41AM +, Andrew Haley wrote:
> On 12/02/15 23:27, Rich Felker wrote:
> > On Thu, Feb 12, 2015 at 06:23:12PM +, Andrew Haley wrote:
> >> On 02/12/2015 04:16 PM, Rich Felker wrote:
> >>> On Thu, Feb 12, 2015 at 05:11:45PM +0100, Jaku
On Thu, May 28, 2015 at 08:29:31AM -0700, Richard Henderson wrote:
> On 05/28/2015 04:27 AM, H.J. Lu wrote:
> > You get consecutive jmpq's because x86 PLT entry is used as the
> > canonical function address. If you compile main with -fno-plt -fPIE, you
> > get:
>
> Well, duh. If the main executa
On Thu, May 28, 2015 at 11:41:10AM -0700, Richard Henderson wrote:
> On 05/28/2015 10:59 AM, Rich Felker wrote:
> >Am I missing something?
>
> You're not missing anything. But do you want the performance of a
> library to depend on how the main executable is compiled?
On Thu, May 28, 2015 at 09:40:57PM +0200, Jakub Jelinek wrote:
> On Thu, May 28, 2015 at 03:29:02PM -0400, Rich Felker wrote:
> > > You're not missing anything. But do you want the performance of a
> > > library to depend on how the main executable is compiled?
>
A feature I've been interested in getting upstream in GCC for a while
now is support for producing static-linked PIE executables for Linux.
In the model I'm working with, static PIE executables are ET_DYN
format with no PT_INTERP, and are intended to contain only relative
type relocations (no symbo
It's recently come up in musl libc development that the tlsdesc asm
functions, at least for some archs, are potentially not future-proof,
in that, for a given fixed version of the asm in the dynamic linker,
it seems possible for a future ISA level and compiler supporting that
ISA level to produce c
On Thu, Oct 11, 2018 at 12:53:04AM -0300, Alexandre Oliva wrote:
> On Oct 10, 2018, Rich Felker wrote:
>
> > It's recently come up in musl libc development that the tlsdesc asm
> > functions, at least for some archs, are potentially not future-proof,
> > in that, for
On Thu, Oct 11, 2018 at 08:18:37PM -0300, Alexandre Oliva wrote:
> On Oct 11, 2018, Rich Felker wrote:
>
> > This is indeed the big risk for glibc right now (with lazy,
> > non-fail-safe allocation of dynamic TLS)
>
> Yeah, dynamic TLS was a can of works in that reg
On Sat, Oct 13, 2018 at 04:00:32AM -0300, Alexandre Oliva wrote:
> On Oct 11, 2018, Rich Felker wrote:
>
> > However the only way to omit this path from TLSDESC is
> > installing the new TLS to all live threads at dlopen time
>
> Well, one could just as easily dro
On Wed, Jul 05, 2017 at 08:38:50AM -0700, H.J. Lu wrote:
> On x86-64, __tls_get_addr has to realigns stack so that binaries compiled by
> GCCs older than GCC 4.9.4:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58066
>
> continue to work even if vector instructions are used by functions called
On Thu, Jul 06, 2017 at 04:06:55AM -0700, H.J. Lu wrote:
> > or there are cases when libraries built against
> > one libc is used with another (e.g. musl can
> > mostly use a libstdc++ compiled against glibc
> > on x86_64)
>
> This happens every time when a new version of a function
> is added to
On Wed, Jan 31, 2018 at 07:58:31AM -0800, H.J. Lu wrote:
> On Wed, Jan 31, 2018 at 7:56 AM, H.J. Lu wrote:
> > On Wed, Jan 31, 2018 at 7:44 AM, Cory Fields wrote:
> >> After looking at this for quite a while, I'm afraid I'm unsure how to
> >> proceed.
> >>
> >> As of now, static and static-pie a
On Fri, Feb 02, 2018 at 11:33:22AM +, Szabolcs Nagy wrote:
> On 31/01/18 15:44, Cory Fields wrote:
> >After looking at this for quite a while, I'm afraid I'm unsure how to
> >proceed.
> >
> >As of now, static and static-pie are mutually exclusive. So given the
> >GNU_USER_TARGET_STARTFILE_SPEC
On Tue, Feb 27, 2018 at 11:01:23AM +0100, Florian Weimer wrote:
> I think it would be a nice addition to the toolchain if it were
> possible to programatically initialize data in the RELRO section.
> We do this in glibc, but I don't think this is currently supported
> for general use.
>
> One impo
On Mon, Jun 11, 2018 at 07:50:32PM +0200, Florian Weimer wrote:
> On 06/11/2018 04:50 PM, Rich Felker wrote:
> >On Tue, Feb 27, 2018 at 11:01:23AM +0100, Florian Weimer wrote:
> >>I think it would be a nice addition to the toolchain if it were
> >>possible to programatic
On Thu, Nov 10, 2022 at 12:16:20PM -0500, Zack Weinberg wrote:
> I’m the closest thing Autoconf has to a lead maintainer at present.
>
> It’s come to my attention (via https://lwn.net/Articles/913505/ and
> https://fedoraproject.org/wiki/Changes/PortingToModernC) that GCC and
> Clang both plan to
On Fri, Jan 20, 2023 at 12:06:50PM +0200, Stefan Puiu via Libc-alpha wrote:
> Hi Alex,
>
> On Thu, Jan 19, 2023 at 4:14 PM Alejandro Colomar
> wrote:
> >
> > Hi!
> >
> > I just received a report about struct sockaddr_storage in the man pages. It
> > reminded me of some concern I've always had ab
On Sun, Feb 05, 2023 at 04:28:36PM +0100, Alejandro Colomar wrote:
> As discussed before, and Bastien and I seem to agree, ideally we should
> define the following types:
>
> struct sockaddr_storage {
> union {
> struct {
> sa_family_t ss_family;
>
On Mon, Feb 06, 2023 at 12:59:48AM +0100, Alejandro Colomar wrote:
> Hi Rich,
>
> On 2/6/23 00:43, Rich Felker wrote:
> >On Sun, Feb 05, 2023 at 04:28:36PM +0100, Alejandro Colomar wrote:
> >>As discussed before, and Bastien and I seem to agree, ideally we should
> &
On Mon, Feb 06, 2023 at 02:02:23PM +0800, Xi Ruoyao wrote:
> On Sun, 2023-02-05 at 16:31 +0100, Alejandro Colomar via Libc-alpha wrote:
>
> > The only correct way to use different types in an API is
> > through a union.
>
> I don't think this statement is true (in general). Technically w
On Mon, Feb 06, 2023 at 12:55:12PM +0100, Alejandro Colomar wrote:
> Hi Xi,
>
> On 2/6/23 07:02, Xi Ruoyao wrote:
> >On Sun, 2023-02-05 at 16:31 +0100, Alejandro Colomar via Libc-alpha wrote:
> >
> >>The only correct way to use different types in an API is
> >>through a union.
> >
> >I don
On Mon, Feb 06, 2023 at 03:11:10PM +0100, Alejandro Colomar wrote:
> Hi Rich,
>
> On 2/6/23 14:38, Rich Felker wrote:
> >There is absolutely not any need to declare the union for application
> >code calling the socket APIs. You declare whatever type you will be
> >using
On Sun, Mar 24, 2024 at 01:20:36PM -0500, Dave Blanchard wrote:
> To whom it may concern--e.g. users of GCC who naively assume GCC is
> maintained by professionals who care about correct code generation:
It does not concern us, so please remove the musl list from CC here
and please do not CC this
On Thu, Jul 25, 2013 at 08:55:38AM +0200, Ondřej Bílka wrote:
> On Thu, Jul 25, 2013 at 05:06:55AM +0200, Jakub Jelinek wrote:
> > On Wed, Jul 24, 2013 at 07:36:31PM +0200, Richard Biener wrote:
> > > >Make them callee saved means we need to change ld.so to
> > > >preserve them and we need to chang
On Sat, Jul 27, 2013 at 05:44:05PM +0200, Ondřej Bílka wrote:
> On Thu, Jul 25, 2013 at 12:50:53PM -0400, Rich Felker wrote:
> > On Thu, Jul 25, 2013 at 08:55:38AM +0200, Ondřej Bílka wrote:
> > > On Thu, Jul 25, 2013 at 05:06:55AM +0200, Jakub Jelinek wrote:
> > > >
On Sat, Jul 27, 2013 at 12:12:57PM -0400, Rich Felker wrote:
> By the way, I do have another horrible idea for how you could do it.
> glibc's jmp_buf is actually a sigjmp_buf and contains 120 wasted bytes
> of sigset_t for nonexistant HURD signals. So you could store a few
> re
On Sat, Jul 27, 2013 at 08:27:07PM +0200, Ondřej Bílka wrote:
> On Sat, Jul 27, 2013 at 12:12:57PM -0400, Rich Felker wrote:
> > On Sat, Jul 27, 2013 at 05:44:05PM +0200, Ondřej Bílka wrote:
> > > On Thu, Jul 25, 2013 at 12:50:53PM -0400, Rich Felker wrote:
> > > >
62 matches
Mail list logo
