This is the mail archive of the
mailing list for the GCC project.
Re: gcc corrections for better pie support
- From: Zack Weinberg <zack at codesourcery dot com>
- To: "Peter S. Mazinger" <ps dot m at gmx dot net>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Mon, 08 Nov 2004 11:18:59 -0800
- Subject: Re: gcc corrections for better pie support
- References: <Pine.LNX.firstname.lastname@example.org>
"Peter S. Mazinger" <email@example.com> writes:
> On Sun, 7 Nov 2004, Zack Weinberg wrote:
>> These look like a good idea in principle. However, they will not be
>> accepted for the 3.4 branch, which is only open for fixes to
>> regressions from previous versions of the compiler.
> That's bad, because the ENDFILE sections are faulty for most of archs
There have already been three releases from the 3.4 branch. We are
very conservative about accepting patches to a release branch of that
age, and we are extra cautious about patches to the specs, since they
are fragile and hard to understand.
> if the generic one is in place, the others are only relevant for the
> specific archs and the "long taking" copyright requirements can be
> omitted (as FSF says, for small changes it's enough to declare that
> it is copyright free, not copied from anywhere, GPL/LGPL copyright
> may be applied)
I skimmed your patches and I confirm that they are not long enough to
require copyright assignment. However, please start the paperwork
process anyway, so that we don't have to go through this again the
next time you want to submit (perhaps more substantial) patches.
>> must submit each logically-distinct change separately, and you must
>> provide patches against CVS mainline, before anyone will bother to
>> look at them.
> Attached applies to CVS as of 20041108 and it is separated into
> pieces The earlier one can be used for all 3.4.x where 0<=x<=3.
I said "submit each logically distinct change separately". That means
sending each patch in a separate email. Furthermore, you broke up the
patch along structural lines, not logical lines. This is less
convenient to review. You listed six problems with the existing code;
ideally you would send six independent patches, each of which
completely solves exactly one of those problems.
Also, it is silly to send small patches like this in a .tar.bz2.
Please use uncompressed text/plain attachments, or (if you are certain
that your email client will not mangle whitespace) include the patch
in the body of the message. Please also read the patch-submission
guidelines at <http://gcc.gnu.org/contribute.html> and
<http://gcc.gnu.org/codingconventions.html>, with particular attention
to the ChangeLog requirement.
As a suggestion, I see that you moved definitions of __pic__ and/or
__PIC__ from specs strings to TARGET_CPP_OS_BUILTINS. This is the
right thing to do, but it is not the perfect thing. Those definitions
are, or should be, consistent across all systems, so they should be
handled by c-cppbuiltin.c in a generic manner. Please consider making
that change instead.
>> reports in GCC Bugzilla (http://gcc.gnu.org/bugzilla). File
>> separate bug reports for each logically distinct bug.
> Well, first I will wait to see what the reactions to these patches
> are, if I see any activity/comments, then I will do that, else it is
Our process does not work that way. You substantially increase the
odds of your patches being reviewed if you file bug reports now.
I also recommend that you bring your patches to the attention of Jakub
Jelinek <firstname.lastname@example.org>, as he is the original contributor of PIE
support. He is probably the only person with sufficient context to
determine whether your spec changes are correct.