This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On 21 Feb 2016 12:44, Nix wrote: > On 20 Feb 2016, Mike Frysinger outgrape: > > On 20 Feb 2016 12:06, Nix wrote: > >> Magnus Granberg has now pointed me at a much more recent version of this > >> change, which replaces __chk_fail() to the same end and reimplement > >> __stack_chk_fail() in terms of it. I'll incorporate that in the next > >> version. (The only concern is that this has received changes from lots > >> of people. Maybe I'll have to reimplement it entirely to avoid > >> copyright-assignment concerns. What a drag...) > > > > yes, you will. you (and Oracle) have CLA papers already signed for glibc > > right ? if not, there isn't much point in following up on this series if > > you don't plan to. > > Oracle has a disclaimer signed, of couse, but I'll need to start the > copyright papers dance for myself (I have signed papers for other GNU > projects, but not glibc yet). a disclaimer is not the same thing as a CLA. what exactly are you referring to here ? > > it needs a rewrite anyways to not use INLINE_SYSCALL but INTERNAL_SYSCALL. > > i had done this locally, stashed it, but then lost it when cleaning up the > > repo later :(. > > Frankly, I was rather hoping that someone could figure out what I > hadn't yet -- the right way to prevent the intermediate link failing > when the original __stack_chk_fail() is used. i haven't looked closely at the loop. i assumed the fail relied on more printf machinery. > > all that said, i don't think we want to import the Gentoo one anyways. > > it changes a lot of behavior that we shouldn't conflate here -- the > > crash/syslog handling is contentious. maybe something like (untested): > > > > void > > __attribute__ ((noreturn)) internal_function > > __fortify_fail (const char *msg) > > { > > #ifdef __SSP__ > > int fd = -1; > > > > const char *on_2 = __libc_secure_getenv ("LIBC_FATAL_STDERR_"); > > if (on_2 == NULL || *on_2 == '\0') > > fd = open_not_cancel_2 (_PATH_TTY, O_RDWR | O_NOCTTY | O_NDELAY); > > I fear this use of open_not_cancel_2() may bring back the same behaviour > we're trying to avoid :( if this triggers the loop, then you'll need INTERNAL_SYSCALL. if that fixes the loop, then we can probably not make it depend on __SSP__ at all. -mike
Attachment:
signature.asc
Description: Digital signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |