This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: inlining failed
- From: "Carlos O'Donell" <carlos at systemhalted dot org>
- To: Nix <nix at esperi dot org dot uk>
- Cc: "Dominik Táborský" <bremby at seznam dot cz>, libc-help at sourceware dot org
- Date: Sat, 29 Nov 2008 16:57:00 -0500
- Subject: Re: inlining failed
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=U0LFAsg/smqgnP5LmSd4eOa7LIXcdS42Loz/YE4zLdg=; b=lH0vZEl0pKivk4agh2m9ck2vKJ+CGFWhM0CtewsWLcaBIJ7oDxcmWpNz09x0HRq7Hu ZjAcEm9DBO4lQSUGL5vTEQSq8TyGAgaI+MFSCy6oxW9OvEbmXptGd72wse8bhTatffqR 2LHdYoiy4jUQXL5RTcPBq7v6A5nPqNap2i6pU=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=wKinTfvdY3rPa8HQD4T+KSH9oYWLyrCnQonQUaPTp25AwrS86AikXUwmjHLTdga4CN MPP1x7nPwjCYBDTvo/3/FddZaCmf+PiAGe/DxVSavZf76/dH9YAn3ZBlzX4xdbG72Xgv zC+Dz4iaZb3R1FYFg0VR6exI61kTy28ZHZHss=
- References: <1227974019.24048.32.camel@eddy> <87wsemclqi.fsf@hades.wkstn.nix> <119aab440811291304o2c929d3bw9fb3c05c2a814a6b@mail.gmail.com> <87skpacjsb.fsf@hades.wkstn.nix>
On Sat, Nov 29, 2008 at 4:19 PM, Nix <nix@esperi.org.uk> wrote:
>> This looks like a nice patch, have you submitted it as an enhancement
>> in the bugzilla?
>
> Nope. I didn't know that was where enhancements were tracked (as opposed
> to bugfixes), and I didn't have any idea if the patch was any good at
> all, or even useful... I was sort of hoping for comments. 'Nice patch'
> counts :)
Your patch has a lot of problems, but I like the idea.
Issues:
1. There should be a configure switch to enable the use of libssp with glibc.
2. Conditionalize or use a variable to represent -lssp should be used.
3. Use lib_cv_ssp which is checked?
> (I also assumed that every distro out there had probably done something
> like this, until I checked and found that a lot of them just force off
> stack protection for all of libc. Since only ld.so is really allergic to
> it, this is excessive.)
Development gets done whenever and wherever a developer submits a patch :-)
> I also thought most of the work on new glibc features was done on
> libc-hacker, not bugzilla, and hence that not much work *was* being
> done, since libc-hacker seems to be pretty much dead. If bugzilla is the
> place to be these days, that puts a different light on things.
IMO the bugzilla is king.
>> Could you also submit this to eglibc? Embedded targets could make good
>> use of this.
>> (patches@eglibc.org http://www.eglibc.org/mailing_lists)
>
> I'll attach/submit once I've updated the patch to 2.9, probably
> tomorrow.
Thanks!
>>> Nobody commented, not even with regard to the apprarent stack corruption
>>> in strtol() spotted by running the testsuite with the stack protector on.
>>
>> If you think there is a bug in strtol() please open a bugzilla issue
>> along with your analysis. After all we are a volunteer project.
>
> I got lost inside the code tangle. All I really know is where the
> testcase crashes (in glibc 2.8, anyway) with -fstack-protector on, and
> with the patch applied anyone will be able to reproduce that, one hopes :)
>
> I'll open a bug once I've retested and verified that it still occurs,
> again, probably tomorrow.
Thanks again.
Cheers,
Carlos.