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 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 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 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: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 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 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 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 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
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 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 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 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 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
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 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 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 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 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 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, 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 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 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 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 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 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, 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
>
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 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
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 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: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 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 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 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 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 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, 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 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: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 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 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 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 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
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
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
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
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?
>
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 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 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 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 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 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 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 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 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:
> > > >
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 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 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
62 matches
Mail list logo
