Re: dejagnu version update?

[Siddhesh Poyarekar]

On 17/05/20 05:15, Maciej W. Rozycki wrote:
>  Siddhesh, would you care to tell us how much effort it would be to set up 
> fresh patchwork?  The patch traffic is surely much lower with DejaGnu than 
> it is with glibc, and there would be no data to migrate (but we might want 
> to feed a couple of months' back worth of mailing list traffic).
> 

Not much on my end, I only need to create a project on sourceware.
Dejagnu admins will have to add the patchwork email address to their
mailing list from the back end and then you'd have to point me or Carlos
to the email archive to seed the project.

That and nominate a maintainer or two for the project on patchwork to
carry out regular tasks.

Siddhesh

unnormal Intel 80-bit long doubles and isnanl

[Siddhesh Poyarekar]

Hi,

The Intel 80-bit long double format has a concept of "unnormal" numbers 
that have a non-zero exponent and zero integer bit (i.e. bit 63) in the 
mantissa; all valid long double numbers have their integer bit set to 1. 
 Unnormal numbers are mentioned in "8.2.2 Unsupported Double 
Extended-Precision Floating-Point Encodings and Pseudo-Denormals" and 
listed in Table 8-3 in the Intel 64 and IA-32 Architectures Software 
Developer’s Manual Volume 1:Basic Architecture.


As per the manual, these numbers are considered unsupported and generate 
an invalid-operation exception if they are used as operands to any 
floating point instructions.  The question of this email is how the 
toolchain (including glibc) should treat these numbers since as things 
stand today, glibc and gcc disagree when it comes to isnanl.


glibc evaluates the bit pattern of the 80-bit long double and in the 
process, ignores the integer bit, i.e. bit 63.  As a result, it 
considers the unnormal number as a valid long double and isnanl returns 0.


gcc on the other hand, simply uses the number in a floating point 
comparison and uses the parity flag (which indicates an unordered 
compare, signalling a NaN) to decide if the number is a NaN.  The 
unnormal numbers behave like NaNs in this respect, in that they set the 
parity flag and with -fsignalling-nans, would result in an 
invalid-operation exception.  As a result, __builtin_isnanl returns 1 
for an unnormal number.


So the question is, which behaviour should be considered correct? 
Strictly speaking, unnormal numbers are listed separately from NaNs in 
the document and as such are distinct from NaNs.  So on the question of 
"is nan?" the answer ought to be "No".


On the flip side, the behaviour described (and experienced through code) 
is exactly the same as a NaN, i.e. a floating point operation sets the 
parity flag and generates an invalid-operation exception.  So if it 
looks like a NaN, behaves like a NaN, then even if the document hints 
(and it is just a hint right, since it doesn't specifically state it?) 
that it's different, it likely is a NaN.  What's more, one of the fixes 
to glibc[1] assumes that __builtin_isnanl will do the right thing.


The third alternative (which seems like a step back to me, but will 
concede that it is a valid resolution) is to state that unnormal input 
to isnanl would result in undefined behaviour and hence it is the 
responsibility of the application to ensure that inputs to isnanl are 
never unnormal.


Thoughts?

Siddhesh

[1] 
https://sourceware.org/git/?p=glibc.git;h=0474cd5de60448f31d7b872805257092faa626e4

Re: unnormal Intel 80-bit long doubles and isnanl

[Siddhesh Poyarekar]

On 11/24/20 7:11 PM, Szabolcs Nagy wrote:

ideally fpclassify (and other classification macros) would
handle all representations.

architecturally invalid or trap representations can be a
non-standard class but i think classifying them as FP_NAN
would break the least amount of code.


That's my impression too.


glibc evaluates the bit pattern of the 80-bit long double and in the
process, ignores the integer bit, i.e. bit 63.  As a result, it considers
the unnormal number as a valid long double and isnanl returns 0.


i think m68k and x86 are different here.



gcc on the other hand, simply uses the number in a floating point comparison
and uses the parity flag (which indicates an unordered compare, signalling a
NaN) to decide if the number is a NaN.  The unnormal numbers behave like
NaNs in this respect, in that they set the parity flag and with
-fsignalling-nans, would result in an invalid-operation exception.  As a
result, __builtin_isnanl returns 1 for an unnormal number.


compiling isnanl to a quiet fp compare is wrong with
-fsignalling-nans: classification is not supposed to
signal exceptions for snan.


I agree, but I think that issue with __builtin_isnanl is orthogonal to 
the question about unnormals.  Once that is fixed in gcc, we could 
actually use __builtin_isnanl all the time in glibc for isnanl.


Siddhesh

Re: unnormal Intel 80-bit long doubles and isnanl

[Siddhesh Poyarekar]

On 11/24/20 7:46 PM, Adhemerval Zanella wrote:

Which is the currently take from gcc developers on this semantic change of
__builtin_isnanl? Are they considering current behavior of non classifying
the 'unnormal' as NAN the expected behavior and waiting glibc to follow
it or are they willing to align with glibc behavior?


The gcc ml is also in cc (apologies to those getting 2-3 copies of 
this!) so I'm hoping to get feedback from both communities to arrive and 
a consensus.


gcc currently considers unnormals as NaN.  I think that is the right 
behaviour and would like glibc to align with that but before making 
such a proposal for glibc, I wanted to make sure that this gcc behaviour 
is defined because currently there is nothing that makes that clear.


Siddhesh

Re: unnormal Intel 80-bit long doubles and isnanl

[Siddhesh Poyarekar]

On 11/24/20 8:13 PM, Richard Biener wrote:

compiling isnanl to a quiet fp compare is wrong with
-fsignalling-nans: classification is not supposed to
signal exceptions for snan.


Can you open a bugreport for this?  Note that the option is likely
to invoke isnanl from libm ...


I believe Szabolcs is talking about this:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66462

Siddhesh

Re: unnormal Intel 80-bit long doubles and isnanl

[Siddhesh Poyarekar]

On 11/25/20 2:58 AM, Joseph Myers wrote:

glibc effectively treats them as unspecified behavior - we don't expect
them to produce any particular meaningful function return value (this
includes the possibility that such an invalid encoding might be returned
by a function given such an encoding as input), but if they result in
buffer overflows, infinite loops or similar, that's fixed as a bug.


Knowing what to call these numbers would be the first step towards 
knowing what to do with them, which is why I considered classification 
the first thing to tackle.



Note that there are lots of libm function implementations, not just
isnanl, which work by looking at the encoding without considering the
possibility it might be one of the kinds of encodings (other than sNaN)
that cannot result from floating-point arithmetic.  This includes both
ldbl-96 implementations in C and implementations in assembly for i386 and
x86_64, and probably implementations for m68k and ia64 as well.
iscanonical is the only operation in glibc that deliberately tries to
detect and produce defined results for these encodings.


Once we have consensus on what unnormals are, it will be much easier for 
me to work through the toolchain and ensure that we consistently treat 
them as NaNs.


Would you agree to treating unnormals as NaNs and consequently have 
glibc provide that guarantee in the library instead of either declaring 
it undefined or maintaining the status quo, i.e. keeping it unspecified?


Siddhesh

Re: unnormal Intel 80-bit long doubles and isnanl

[Siddhesh Poyarekar]

On 11/26/20 12:57 AM, Joseph Myers wrote:

I think it would be a pain to maintain test coverage for unnormals (and
presumably all the other kinds of unsupported operands, and you'd need to
work out what semantics you want for pseudo-denormals as well since those
are the one kind of such representation the processor doesn't raise
"invalid" for) for all the functions with floating-point arguments - and
claiming to handle those consistently requires having such test coverage
(there are only a few tests for such format-specific representations in
sysdeps/ieee754/ldbl-96 at present).


pseudo-denormals are still considered valid, so I'm admittedly punting 
them for later since the processor manual still claims to handle them 
correctly.



But maybe you could set up some mechanism by which, when gen-libm-test.py
processes a test using snan_value or snan_value_ld (but not
snan_value_pl), and the relevant format is one of the format variants that
has these representations, it automatically generates tests for all those
variants (that the processor raises "invalid" for when handling as
operands, i.e. treats much like sNaN).  I'm not sure if it's actually
possible to generate a static initializer for a long double value with one
of those representations, or only for a union containing a long double
where another member is initialized; if a union type needs to be used in
the tables of test inputs, that further complicates things.
It would have to either be a union type with various bit patterns or a 
bit string copied into a long double; the CPU will never generate any of 
the pseudo numbers on its own.


Siddhesh

Re: unnormal Intel 80-bit long doubles and isnanl

[Siddhesh Poyarekar]

On 11/27/20 5:01 PM, Florian Weimer wrote:

I think the last part (the “bug”) is new.  I welcome a consensus along
those lines.  I just want to highlight this aspect.


Should we consider fixing behaviour if the bug manifests in a user 
application and not in glibc itself?  i.e. a crash because glibc either 
returned the unnormal or misclassified the unnormal number?


At the minimu ISTM that we should at least make the classification 
consistent with gcc.


Siddhesh

Re: Remove RMS from the GCC Steering Committee

[Siddhesh Poyarekar]

On 3/27/21 7:08 PM, Alexandre Oliva via Gcc wrote:

It may be very convenient to paint a boogey-man and expel it because
that became fashionable.  But sacrificing a goat or a lamb does not
expiate our own sins, and expelling someone who hasn't even been present
in the community can't be expected to make any real difference to that
matter; it would rather make us seem *less* welcoming and more
intolerant, and suggest other motivations for the move.


Except that it's not a boogeyman.  There is evidence for the documented 
instances of misconduct and have been corroborated by multiple people.



Let's be real and honest, when was the last time anyone in the GCC
community was called out for sexist behavior?  When was there even
conversation about it, and about how sexist behavior is not acceptable
and not to be accepted among participants in the GCC community?  What
was our latest collective action to promote e.g. gender equity within
the community?


The discussion is about RMS' damaging conduct (especially with 
non-privileged groups) over the years and the steering committees stand 
on it, not about steps we take to make the community more welcoming to 
non-privileged groups.  The latter definitely needs a discussion, but as 
far as this thread is concerned, it is a digression.



If we were to shift our collective blame over this very real and
undesirable problem to someone who has any direct authority over the
project, why not suggesting expelling e.g. the entire Steering Committee
for its evident failure to address the problem?  (I don't think it's a
good idea, but that would be the first thing to try if we were to blame
"management"/"leadership" rather than ourselves for it)


Nope, you're the one shifting blame for RMS' conduct on to the steering 
committee and the gcc community.



What could support any rational belief that having RMS one extra level
removed from our technical community would bring about anything
resembling a solution to the very undesirable and unjust gender
imbalance you've correctly identified?


No but it will make it clear that toxic behaviour has no place in the 
gcc community.  That's step zero.  The FSF still hasn't got its act 
together in that regard unfortunately.



How about we set out to take individual and collective actions that
actually address the problem *in* our community?  We don't need anyone's
approval to call out sexist acts, nor to invite and train people with an
interest in compiler technology, nor to maintain a welcoming atmosphere.


Sexist acts, discriminatory comments and inappropriate behaviour by RMS 
have been called out.  It is now the steering committee's responsibility 
to share their stand on it.


On 3/27/21 9:15 PM, Alexandre Oliva via Gcc wrote:
> It looks like statements of any position whatsoever are invitations
> for pressure and trouble right now.

On the flip side, not making a statement would be a statement in itself. 
 You know that though, which is why you advocate silence.


Siddhesh

Re: Remove RMS from the GCC Steering Committee

[Siddhesh Poyarekar]

On 3/28/21 8:20 PM, Alexandre Oliva wrote:

Thanks for clarifying your understanding of Nathan's goal.

I may indeed have misread and mistaken Nathan's goal and means.

I thought the goal was to improve the GCC community by addressing the
gender imbalance, and that the means (misguided, IMHO) was to distance
ourselves from RMS.


There's only one point of departure; you chose to interpret RMS' removal 
from the steering committee to be the solution while I (and others) have 
pointed out that it is a notable step in that direction.



Your assertiveness came across to me as a correction of my mistake, but
I didn't see any reason to prefer your understanding over mine, until
Nathan posted today's followup.


My reading of every gcc contributor that has participated in this 
discussion seems to reinforce my understanding over yours.  Not one of 
them has conveyed IMO that RMS' removal from the board will magically 
solve gender or diversity issues with the community.



Now it looks like you were right, but I still find that a little hard to
believe.  Are you really sure about your understanding?

Do you know for a fact that Nathan agrees with your understanding?

Do you know with certainty of anyone else who shares that understanding
with you and him?


In my opinion there is nothing to indicate from any of the contributors' 
statements that they see RMS' removal from the steering committee as a 
final solution to D&I issues in the GNU community.  I'm happy to be 
corrected by others if they think I've misinterpreted their comments and 
if they indeed think that RMS' removal from the steering committee will 
solve all diversity issues.


Siddhesh

Re: Remove RMS from the GCC Steering Committee

[Siddhesh Poyarekar]

On 4/6/21 3:57 PM, Richard Biener via Gcc wrote:

Seeing the word "dysfunction" I don't remember using I want to clarify
the non-openess which I intended to criticize.  The SC is not "open" because:
- it appoints itself (new members, that is) - in fact in theory it
should be appointed
   by the FSF because the SC is the GNU maintainer of GCC
- all requests and discussions are _private_ - the SC does not report to the
   GCC project (it might report to the FSF which it is formally a delegate of)
- you can reach the SC only indirectly (unless you know the secret mailing list
   it operates on) - CC an SC member and hope a request is forwarded

now I understand the SC sees itself as buffer between GCC and the FSF (RMS
in particular) and it thinks we need to be protected from direct engagement.  I
think this is wrong.  I can very well say NO to RMS myself.


FWIW, the glibc FSF stewards are analogous to the SC and pretty much all 
of those points apply to them.  My impression is that it's a symptom of 
governance style of GNU projects (or maybe GNU *toolchain* projects due 
to shared history) and not specifically anything to do with the steering 
committee or the glibc FSF stewards.  Perhaps (and I guess it's more 
hope than knowledge) dissociation from GNU/FSF will make it easier to 
change the nature of the SC/steward governance.


Siddhesh

Re: GCC association with the FSF

[Siddhesh Poyarekar]

On 4/12/21 7:13 AM, Alexandre Oliva via Gcc wrote:

On Apr 11, 2021, Adhemerval Zanella  wrote:


All the other active maintainers suggested you shouldn't have done that, but you
ignored it anyway.


How could I possibly have ignored something that hadn't happened yet?


There are irreconcilable differences in perceptions over the events that 
unfolded then and your comments and Adhemerval's (that, FWIW, I echo as 
glibc not-a-gnu-maintainer-just-a-contributor) are sufficient to signal 
that.  The discussion of the events itself is irrelevant to this thread 
and this mailing list so I suggest we stop this subthread.


Siddhesh

Re: GCC association with the FSF

[Siddhesh Poyarekar]

On 4/12/21 12:55 PM, John Darrington wrote:

In GNU, there are no "senior" (or junior) developers/maintainers.  Maintainers
have some specific responsibilities, with which developers are not emcumbered.
In almost all projects, the maintainers are also developers, but this need not
be the case.  But all maintainers are equal, and all developers are equal.


Those are terms we tend to use in the glibc developer community to 
loosely indicate the amount of time and resources individuals have spent 
in the glibc project as developers, testers, release managers, etc.  In 
fact, 'maintainer' in glibc is not the same as 'maintainer' in GNU 
because they're not GNU maintainers.  We call GNU maintainers "FSF 
stewards" in glibc to disambiguate that.


It doesn't matter what these roles are called in GNU because they're not 
the names we use in the glibc community on a day to day basis.  That 
said, we can have a conversation about glibc on the glibc mailing list. 
 The gcc mailing list is not the place for it.  In the interest of 
keeping the thread relevant, this is my last email on this topic on the 
gcc mailing list.


Siddhesh

Re: A suggestion for going forward from the RMS/FSF debate

[Siddhesh Poyarekar]

On 4/17/21 12:11 AM, NightStrike via Gcc wrote:

I was under the (likely incorrect, please enlighten me) impression
that the meteoric rise of LLVM had more to do with the license
allowing corporate contributors to ship derived works in binary form
without sharing proprietary code.  Intel, IBM, nVidia, etc. are


I think this is a blinkered view.  Sure, there are companies that build 
proprietary toolchains using llvm as the base but I would argue that it 
is the *result* of the rise of llvm and not the cause.


The cause IMO is accessibility to other projects, most notably compiler 
researchers and students who find it a lot easier to target llvm than 
gcc because compiler-as-a-library.  License may have been a factor for 
some of those uses (e.g. I know some who think copyleft is not free 
enough and BSD style licensing is the *real* freedom), but concluding 
that it is the major reason is to delude ourselves.


It is also the reason why gcc does not even figure in situations where a 
larger project would need AOT or JIT compilation; we had to concede that 
ground all because of the FSF/GNU fears that companies would make 
proprietary compilers out of a gcc compiler-as-a-library.


Of computer science graduates I have encountered over the last decade, I 
know few who started their journey with gcc and they were all in the 
initial part of the decade.  In recent years I don't think I encountered 
any student who works on gcc; many even start with the assumption that 
gcc is in maintenance mode.


So to summarize, the reasons why llvm is gaining traction *today* (I'm 
sure there are more):


- Compiler-as-a-library - llvm is the first choice in FOSS projects and 
use cases are exploding with gcc nowhere in sight


- Mindshare - most students and researchers are focused on it

- Funding - llvm has a much stronger funding ecosystem than gcc.  This 
includes direct funding from the foundation and development workforce 
from various organizations and universities.


- License - Companies are building proprietary solutions on top of llvm.

Siddhesh

Re: A suggestion for going forward from the RMS/FSF debate

[Siddhesh Poyarekar]

On 4/18/21 1:15 PM, Gabriel Ravier via Gcc wrote:
I'd like to see a source for that. It certainly seems like complete 
bullshit to me, unless you're trying to tell me that they simultaneously 
do not fund anything related to free software while also having policy 
that mandates at least 20 percent of custom-developed code (i.e. code 
they fund the production of) has to be released as OSS (see 
https://www.commerce.gov/about/policies/source-code)


You see Free != OSS...

Re: A suggestion for going forward from the RMS/FSF debate

[Siddhesh Poyarekar]

On 4/18/21 1:08 PM, Christopher Dimech wrote:

The cause IMO is accessibility to other projects, most notably compiler
researchers and students who find it a lot easier to target llvm than
gcc because compiler-as-a-library.  License may have been a factor for
some of those uses (e.g. I know some who think copyleft is not free
enough and BSD style licensing is the *real* freedom), but concluding
that it is the major reason is to delude ourselves.


Originally, the LLVM License was derived from the X11 License and the
3-Clause BSD License, both licenses conforming to the definition of
free software.  Apple officially hired Chris Lattner in 2005, giving
him a team to work on LLVM.


It is irrelevant to the point I'm making.  If you're trying to assert 
that Lattner's hiring by Apple was the driving force behind the current 
llvm adoption then like I said before, it's blinkered.  Read my response 
again for a deeper context.



It is also the reason why gcc does not even figure in situations where a
larger project would need AOT or JIT compilation; we had to concede that
ground all because of the FSF/GNU fears that companies would make
proprietary compilers out of a gcc compiler-as-a-library.


Listen very carefully - In the first quarter of 2011, Keith Chuvala
began discussing the need to drop all proprietary systems used to command
the ISS.  He specifically mentioned products from Microsoft and Red Hat.
This was communicated to General Paul Martin, who then reported everything
to the US House Subcommittee on Investigations and Oversight.


I can't parse what you're saying in response to my point about llvm 
being the default choice for all modern use cases of compiler technologies.


Siddhesh

Re: GCC Mission Statement

[Siddhesh Poyarekar]

On 6/9/21 10:13 AM, Valentino Giudice via Gcc wrote:

Hi.

The Mission Statement of the GCC project recently changed without any
announcement.


Well there was an announcement; the changes in the mission statement 
reflect the new reality introduced by that announcement:


https://gcc.gnu.org/pipermail/gcc/2021-June/236182.html

Siddhesh

Re: GCC Mission Statement

[Siddhesh Poyarekar]

On 6/9/21 10:39 AM, Valentino Giudice wrote:

I was aware of that announcement, but it doesn't mention the mission
statement at all.
It appears that the decision in question was, at the time, in contrast
with the mission statement (rather than guided by it).

If the Steering Committee updates the mission statement, it may appear
that the mission statement follows the decisions of the steering
committee (in place of the contrary). In that case, what would be the
purpose of a mission statement?

The mission statement was also updated beyond simply making it
consistent with the change: in "Supporting the goals of the GNU
project, as defined by the FSF" the reference to the FSF was removed.


Quite a few projects under the GNU project[1] have dissociated 
themselves from the FSF, so "as defined by the FSF" perhaps doesn't 
apply as consistently as it did before.  That is my understanding 
anyway; maybe there's more context that others may be able to add.


Siddhesh

[1] https://gnu.tools/en/software/

Re: GSoC: Getting started

[Siddhesh Poyarekar]

On 02/06/2022 00:20, David Malcolm wrote:

(2) find a list of system calls (e.g. those implemented on Linux), and
see which ones relate to file descriptors e.g. acquiring them, using
them, releasing them, and duplicating them.  Look for patterns of usage
that could be expressed using function attributes.  Probably ignore
"ioctl" for now.

(3) probably talk to glibc's developers about this, since glibc
provides headers that wrap system calls, which would want to use the
attributes if we provide them


There are a significant number of interfaces that use file descriptors, 
not just limited to syscall interfaces. Another area I can think of is 
stdio, i.e. FILE interfaces.  There are interfaces (e.g. fdopen) that 
interact with file descriptors and they may require some special handling.



(4) implement the attributes, so that the analyzer doesn't have
hardcoded function names, and can instead rely on function attributes.
GCC's attributes are implemented in gcc/c-family/c-attribs.cc; see the
big c_common_attribute_table array, which associates the string names
of the attrbutes with properties, including a handler callback.  These
either set flags of a decl, or the attribute itself is appended to a
singly-linked list on that decl (for those things that don't directly
relate to fields of a decl).

I believe Siddhesh Poyarekar has been looking at attributes from the
glibc side of things, so I'm CCing him in case he has input on this.

I'm wondering if other people on this list have ideas for projects that
make heavy use of syscalls/file-descriptors that would benefit from
having this analyzer feature.  Maybe systemd?


Systemd AFAIK doesn't bypass glibc's syscall interfaces, so annotating 
glibc headers ought to be good start for a GSoC project.  If this is 
done before time we can explore server software, e.g. sshd, httpd, etc. 
to see if there's scope for additional annotations there.  I'll be happy 
to help on the glibc and interfaces front.


Siddhesh

Patchwork may go down for maintenance today

[Siddhesh Poyarekar]

Hello,

FYI, I'm working on a django and patchwork upgrade on sourceware today 
so you might see some downtime in the morning and afternoon EDT.


Sid

Re: The GNU Toolchain Infrastructure Project

[Siddhesh Poyarekar]

On 2022-10-02 16:47, Mark Wielaard via Overseers wrote:

I've published the current GTI TAC meeting minutes to the glibc website:
https://www.gnu.org/software/libc/gti-tac/index.html

The slides from the LF IT are a good overview:
https://www.gnu.org/software/libc/gti-tac/LF%20IT%20Core%20Projects%20Services.pdf


I assume www.gnu.org was the easiest way for you to quickly make these
things public. But it now does look like it is an official FSF/GNU
proposal. Which I assume wasn't your intention. Note that it contains
a copyright notice "© 2022, GTI TAC." but doesn't seem to have a
(free) license. Which is kind of necessary if you host it on
www.gnu.org.


Minutes moved here:

https://gti.gotplt.org/tac/
https://gti.gotplt.org/tac/LF%20IT%20Core%20Projects%20Services.pdf

I own gotplt.org and am happy to lend the subdomain for now to help 
coordinate this because I think the LF proposal is the best long term 
way forward for the GNU toolchain projects to remain competitive *and* Free.


To be clear, I don't think there are any qualms about adding a license 
notice here but we'd have to agree on one.  I made and shared this copy 
to dispel any further false speculation of scope creep of the GTI 
proposal.  For any content attributable to me in the meeting minutes, 
I'm happy to release it under any free license the TAC may agree on.


Sid

Re: The GNU Toolchain Infrastructure Project

[Siddhesh Poyarekar]

On 2022-10-04 10:01, Frank Ch. Eigler wrote:

Hi -


[...] I think the LF proposal is the best long term way forward for
the GNU toolchain projects to remain competitive *and* Free. [...]


Can you elaborate what risks in terms of competitiveness or freedom
you foresee with the status quo?  This is the first I recall hearing
of this concern.


I don't see a risk to freedom.  The GNU toolchain is quite underfunded 
compared to llvm/clang and IMO it's a major risk to maintain status quo 
on that front.  The GTI opens new avenues for funding aspects of the GNU 
toolchain without affecting its core governance.


Sid

Re: The GNU Toolchain Infrastructure Project

[Siddhesh Poyarekar]

On 2022-10-04 10:19, Frank Ch. Eigler wrote:

I don't see a risk to freedom.  The GNU toolchain is quite underfunded
compared to llvm/clang and IMO it's a major risk to maintain status quo on
that front.  The GTI opens new avenues for funding aspects of the GNU
toolchain without affecting its core governance.


What aspects of the gnu toolchain are open to being funded via the
LF/GTI proposal, -other than- the vast majority of the funds being
redirected to its own managed services infrastructure?


This current proposal is limited to infrastructure, which has 
ever-growing needs.  Do you think the current proposal is not an upgrade 
to what we currently have?


Sid

Re: The GNU Toolchain Infrastructure Project

[Siddhesh Poyarekar]

On 2022-10-04 10:41, Frank Ch. Eigler wrote:

I'm afraid I don't understand then what the point of comparing to LLVM
with respect to competitiveness or freedom was.  AIUI, infrastructure
is an enabler, not really a competitive differentiator.


I suppose that's a difference in our perception then.  I think of 
infrastructure as an accelerator and not just an enabler, which makes it 
a serious competitive differentiator.



Do you think the current proposal is not an upgrade to what we
currently have?


I don't know.  I am not under the impression that infrastructure is
holding back development on any of these projects.  Further, I suspect
that if the communities were given a choice to direct the sponsors'
generous donations toward new development type work, they may well
prefer that.  Is that possibility on offer?


Not in this proposal AFAICT (I have exactly the same information as you 
do) but IMO it would be great if it happens and the project communities 
accept it.


Sid

Re: The GNU Toolchain Infrastructure Project

[Siddhesh Poyarekar]

On 2022-10-04 13:10, Christopher Faylor wrote:

On Tue, Oct 04, 2022 at 09:46:08AM -0400, Siddhesh Poyarekar wrote:

I made and shared this copy to dispel any further false speculation of
scope creep of the GTI proposal.


Who is doing the false speculation?  Do you have a mailing list link?
It would be interesting to know who's got it wrong.



Mark asked upthread if content on gnu.org is also going to be migrated 
over based on sharing of meeting minutes on the gnu.org domain.


Sid

Re: The GNU Toolchain Infrastructure Project

[Siddhesh Poyarekar]

On 2022-10-04 15:05, Mark Wielaard wrote:

I did indeed. Both the proposal and these minutes mention migrating
websites without mentioning any specifics. Knowing which websites are
meant and why they need migration is useful information.

The FSF tech team is helping us coordinating things on overseers to
help with release archives, mirroring, backups and sourceware
continuity. If this is about migrating websites currently on
www.gnu.org then talking to the FSF tech team does make sense. If it
isn't about that, then we will simply note that and move one.

We do take this proposal, and all other suggestions people make about
the sourceware infrastructure, seriously, but a lot of details of this
proposal are still unclear. We are trying to get as much details as
possible so we can see how this fits into the current sourceware
roadmap, get a better understanding of the budgetary needs, file
sourceware infrastructure bugs with those details. All to get a better
understanding what the real needs are and document the necessary steps
forward.


I had in fact missed the websites mention, sorry I overreacted to your 
comment.  In that case, I don't know if the GNU websites are actually 
part of this proposal.


Sid

Re: The GNU Toolchain Infrastructure Project

[Siddhesh Poyarekar]

On 2022-10-06 16:02, Mark Wielaard wrote:

I had in fact missed the websites mention, sorry I overreacted to your
comment.  In that case, I don't know if the GNU websites are actually part
of this proposal.


No worries. It seems everybody is somewhat unclear on the details of
this proposal. Making it hard for people not to speculate a
little. And it seems the scope changed between when various "key
stakeholders" were informed, the LF/IT presentation, the Cauldron talk
and what eventually got posted.


I had not noticed the mention of websites in the proposal, which is why 
I was taken aback by its mention here.  That oversight is my fault, 
nothing to do with the proposal itself.


Could you clarify in what way you think the *scope* got changed between 
the private communications and the proposal that actually got posted? 
The technical details (which is different from scope) were never meant 
to be baked in, that's for the TAC to agree upon.  In that sense, the 
proposal details being open-ended is by design.



That is why we are trying to collect all details and file sourceware
infrastructure bugs to track the various technical needs from a


Fair enough.


community perspective. But it would be really nice to hear directly
from the Linux Foundation and the OpenSSF about what exactly they are
proposing, which parts of the proposal are mandatory, which can be
mixed and matched, and how they see this working together with
Sourceware becoming a Software Freedom Conservancy member
project.


You and others have been repeating "sourceware as a project" in a 
community owned sense as a truth for a while now but it really isn't. 
It is Red Hat owned infrastructure that is maintained by volunteers.  It 
is unquestioningly a community (and I'm proud part of it as someone who 
maintains the patchwork instance), but that's not the same thing as 
being an independent project that can do agreements and sign up for 
memberships.


Maybe Red Hat could spin off a sourceware project in some form that is 
actually capable of becoming a SFC member?  Or alternatively, 
"sourceware overseers" could become a body that maintains sourceware and 
is able to get funding through SFC for its activities?


Thanks,
Sid

Re: The GNU Toolchain Infrastructure Project

[Siddhesh Poyarekar]

On 2022-10-06 16:12, Christopher Faylor via Overseers wrote:

The silence from the proponents of this project is puzzling.  I wonder
if this means there are more non-public negotiations going on somewhere,
leaving the community out of the loop.


The proponents of this project are members of the GNU toolchain 
communities.  We approached the LF with the permission of the FSF to 
explore infrastructure funding solutions that would work for our 
communities.  The proposal has been made in response to our request, so 
we need to tell them what we need and not the other way around.


Also as I responded to Mark, the technical details of the transition are 
the responsibility of the GTI TAC (which you were invited to be member 
of and you declined) and not the LF IT, although they'd be the ones 
implementing and maintaining it.


We're at that stage at the moment where we look for consensus from the 
project communities so that we understand if we can move all of 
sourceware to LF IT or if we need both to coexist somehow.


Once we have a direction, we talk about what that transition would look 
like and ask questions accordingly.  Are there services that you 
absolutely cannot move to LF IT and why?  Why would you support (or 
oppose) porting the wiki to something like readthedocs backed by a git repo?


I respect your outright rejection of the proposal because at least it is 
clear that you don't have any stake in its fine tuning.


For everyone else, it's a proposal.  If there are changes you'd like to 
see in it, which will result in it being acceptable for you, please feel 
free to convey that.  If you think it is unnecessary for your project 
and that sourceware in its current state and vision is sufficient for 
your needs, please state that clearly too.


Sid

Re: The GNU Toolchain Infrastructure Project

[Siddhesh Poyarekar]

On 2022-10-06 17:36, Frank Ch. Eigler wrote:

[...] Or alternatively, "sourceware overseers" could become a body
that maintains sourceware and is able to get funding through SFC for
its activities?


Great idea -- and this is roughly what's happening.  This "body"
consisting of key individuals has invited other folks interested in
helping with or helping guide the upkeep of shared sourceware
infrastructure to join us.


Here's another crazy idea on those lines then: how about having SFC fund 
sourceware overseers' time on TAC (in addition to, perhaps consulting 
tasks like independent security audits so that we have more eyes on the 
infrastructure) so that we continue to have them involved in the 
technical direction of GNU toolchain infrastructure?  That is of course 
for overseers who are actually able to accept payments from the SFC for 
such involvement.


Sid

Re: The GNU Toolchain Infrastructure Project

[Siddhesh Poyarekar]

On 2022-10-06 18:57, Frank Ch. Eigler wrote:

[...] so that we continue to have them involved in the technical
direction of GNU toolchain infrastructure?  [...]


"continue"?  If the nature & degree of involvement we had so far in
the LF/GTI process is representative of the future, I'm not sure I can
in good faith ask anyone to fund our time on that.  Given that you are
listed as a TAC member, yet admitted being unclear on some details of
the proposal itself, perhaps we're in the same boat.


Yes we are, in the sense that this is a proposal and the details are 
upon us (you're a listed member of TAC too) to help finalize.


Sid

Re: Toolchain Infrastructure project statement of support

[Siddhesh Poyarekar]

On 2022-10-13 14:25, Christopher Faylor via Overseers wrote:

Also, the FSF, being the existing fiscal sponsor to these projects,
surely needs to review the formal agreements before we sunset our
infrastructural offerings to glibc, gcc, binutils, and gdb and hand
control of the projects' infrastructure over to a different entity.


I believe Nick at least has said that for binutils they would like to 
use both, i.e. mirror some of the LF offerings with sourceware (or vice 
versa, I suppose it's Nick's call to take) and that'll probably be the 
case for glibc and gcc as well over the years.  So sunset, whenever that 
will be and whatever it'll look like, will likely be a while.


Sid

Re: Toolchain Infrastructure project statement of support

[Siddhesh Poyarekar]

On 2022-10-17 11:10, Mark Wielaard via Overseers wrote:


In the last year we did some really nice work for the sourceware
infrastructure. We setup the shared buildbot, got various companies and


I feel like you're taking this personally as an overseer; the proposal 
to transition to LF IT is not a value judgment on your work.  It is a 
proposal to scale far beyond what our current resources can afford.  I 
personally am grateful for all that work and have participated in some 
of it too but I don't think that it's a scalable approach for gcc or to 
a lesser extent, glibc.



organisations to provide compute resources, workers for various
architectures. We now have CI, Try and Full builders for various
projects and doing 10.000+ builds a month. With a bunsen analysis
database with all those test-results. Did a resource analysis and wrote
up this public roadmap to make the email/git based workflow that
sourceware projects rely on more fun, secure and productive by
automating contribution tracking and testing. We now also have the
sourcehut mirror and the public-inbox instance to make the email
workflow nicer and support things like patch attestation. We are
working on better integration between patchwork and buildbot for pre-
commit checking. And we got the Software Freedom Conservancy to accept
sourceware as a member project to act as a fiscal sponsor. They are now


Fiscal sponsor for the *sourceware overseers*.  There's no way for SFC 
to be a fiscal sponsor for sourceware, which is infrastructure owned by 
Red Hat.



helping us with the future roadmap, setting up a organization,
budgeting, etc. And the FSF also is supportive of this.


The FSF has little stake in sourceware beyond the GNU toolchain, so FSF 
being supportive of sourceware overseers seeking funding has about the 
same relevance as the FSF being supportive of my decision to move to a 
different country.


They do have a significant stake in infrastructure for the GNU toolchain 
project and they've been part of discussions since the idea for GTI 
germinated.



And now you again seem to not want to discuss any details on how to
work together. After Cauldron I thought we agreed we would discuss
goals on overseers and create sourceware infrastructure bugs. So we
could see what the community priorities were, write an updated
sourceware roadmap, setup a budget, etc.


On multiple occasions I've been told on this list that sourceware 
administration being transitioned to LF IT is out of question, so I 
don't see the point of having these discussions.  I don't see a 
retention plan that's viable for the next 5, 10 or 20 years.


I personally do not think the current sourceware infrastructure, even 
with the roadmap it promises is a viable alternative to what LF IT can 
provide.  There is a significant resource gap (e.g. service isolation to 
different machines and/or containers, full time administrators with 
global presence for FTS support, established security and administration 
practices, traffic acceleration, to name a few) that we seem to disagree 
about.


There seems to be little to discuss from the GNU toolchain perspective 
IMO; the overseers think that the LF IT proposal and the additional 
funding and infrastructure it brings in are not necessary and we think 
it is.



I was really happy to see the discussions about setting up a video chat
system for projects, the FSF tech-team offering to setup mirrors,
backups and help coordinate secure release uploads. And I had hoped to
see some discussion on how the LF and potential sponsors could help,
working together with the sourceware community and the SFC.

We really would love for gdb, glibc, binutils and gcc to keep being
part of sourceware.


IMO the best way to make this happen is for us to transition sourceware 
administration to LF IT.  However since all projects hosted on 
sourceware don't seem to agree on this and the overseers also do not 
desire to give up control over the infrastructure, I don't see another 
way out of this.


Of course, like I said to Chris, it's likely going to be a while before 
we fully transition away from sourceware (it'll likely happen one 
service at a time, or something like that, we need to figure that out at 
some point) and we'll need continued help from the overseers to help 
manage the infrastructure in the near future.


Sid

Re: Toolchain Infrastructure project statement of support

[Siddhesh Poyarekar]

On 2022-10-18 05:50, Mark Wielaard wrote:

Hi Siddhesh,

On Mon, Oct 17, 2022 at 12:11:53PM -0400, Siddhesh Poyarekar wrote:

There seems to be little to discuss from the GNU toolchain perspective IMO;


Yes, it is clear you don't want any discussion or answer any questions
about the proposals, 


That is not true, Mark.  Your objections and questions have been 
answered at every stage, privately as well as publicly.  What *is* clear 
is that we have been talking past each other because despite our common 
high level intentions, we appear to have little common ground for our 
goals.  You want to retain the current sourceware infrastructure and try 
and see what we can do within that framework and I want us to migrate 
services to infrastructure with better funding (that's not just limited 
to services), dedicated ops management and an actually scalable future.



how funds can be used,
Let me turn that around: how *would* you like funds to be used beyond 
what is currently proposed in the LF IT proposal?


what the budget is, 


Around $400,000.


what
the requirements are, 


Your lack of clarity about requirements IMO have more to do with you 
wanting to fulfill those requirements within sourceware and not with 
their existence.  I and others have repeated them here and the overseers 
have either questioned their validity or noted them in bugzilla as 
possible things to explore in the current sourceware context.  With 
sourceware migration to LF IT off the table, there's little incentive 
for me personally to explore them.


how the governance structure works, 


I think you know how it works, maybe you meant to say that you don't 
like it?


The governance structure and their workings have been described in the 
GTI introduction.  There are two key bodies that govern the project: the 
Technical Advisory Council (comprised of project community members) 
manages the technical details of the infrastructure and the governing 
board (comprised of representatives from funding companies) manages the 
funding for those technical details.


The current TAC comprises of people from the initial community 
stakeholders who were contacted and subsequently accepted the invitation 
to be part of TAC.  You, along with other overseers, were invited too 
but most of you declined.



what
alternatives we have, etc.

For projects the alternatives they have are:

1. Migrate to LF IT infrastructure
2. Have a presence on sourceware as well as LF IT, contingent to Red 
Hat's decision on the hardware infrastructure

3. Stay fully on sourceware

For sourceware as infrastructure the alternatives are:

1. Migrate to LF IT infrastructure
2. Stay as it currently is

For sourceware overseers, the choices are contingent on what projects 
decide and what Red Hat decides w.r.t. sourceware.


All of the above has been clear all along.  Maybe the problem here is 
that you're not happy with the alternatives?



But personally I think it is healthy to have real discussions, doing
resource analysis, creating public roadmaps, collecting infrastructure
enahancement requests, discuss how to organize, argue about the needed
budget and how to use funding most efficiently, etc. To make sure that
sourceware keeps being a healthy and viable free software
infrastructure project for the next 24 years, hopefully including the
various GNU toolchain projects.


You want to talk about sourceware without including the LF IT proposal 
whereas I'd love to talk about sourceware as an LF IT maintained 
infrastructure.  There's a real disconnect that precludes any real 
discussions.


Sid

Re: Toolchain Infrastructure project statement of support

[Siddhesh Poyarekar]

On 2022-10-18 12:42, Christopher Faylor wrote:

On Tue, Oct 18, 2022 at 11:17:15AM -0400, Siddhesh Poyarekar wrote:

That is not true, Mark.  Your objections and questions have been answered at
every stage, privately as well as publicly.


Actually, going back through this thread, I see outstanding
questions/issues raised by Mark, Frank, Alexandre Oliva, Jon Corbet, and
Andrew Pinski.


As far as actual questions regarding the proposal is concerned, I think 
only Job Corbet's questions to Carlos/David are pending an answer; I 
deferred them to Carlos or David because I think they're better placed 
to answer them in their entirety.  The rest, AFAICT, are either fear of 
some kind of corporate takeover, discussions about current sourceware 
infrastructure, or just rhetoric, none of which I'm interested in 
engaging with.


The corporate takeover fear especially is amusing to me given how much 
of GNU toolchain development and infrastructure is sponsored by 
corporations right now but that's just my personal opinion.


Maybe the FSF hosted call next week[1] would be a suitable forum to 
discuss fears of corporate control of the GNU toolchain project 
infrastructure due to the LF IT migration, or for that matter any other 
questions you or others think may have gone unanswered.  Since 
sourceware is neither a GNU nor an FSF project, it probably does not 
make sense to discuss current sourceware infrastructure there.


Sid

[1] https://sourceware.org/pipermail/overseers/2022q4/018997.html

Re: Toolchain Infrastructure project statement of support

[Siddhesh Poyarekar]

On 2022-10-18 14:13, Siddhesh Poyarekar wrote:
only Job Corbet's questions to Carlos/David are pending an answer; I 


s/Job/Jon/ sorry about misspelling your name.

Sid

Re: Toolchain Infrastructure project statement of support

[Siddhesh Poyarekar]

On 2022-10-23 04:59, Ian Kelling wrote:

No, I don't think that was ever clear. I've just read this message, but
I've been keeping up with everything public since Cauldron.  All your
options assume that any specific service is 100% managed by LF IT, or
100% managed by sourceware. That is a bad assumption. They could do it
together, or another group could help.  So, you said you wanted
"dedicated ops management", and I assume sourceware is not currently
equipped for that. But there is no reason that an ops team from LF IT or
FSF could not provide dedicated ops management for existing sourceware
services in collaboration with sourceware. Another notable ops team is
OSU, https://osuosl.org/.


Hybrid administration isn't part of the GTI proposal, why would that be 
considered an option?  Is this something you'd like to propose to the 
TAC, i.e. give named members from the community access to infrastructure 
administration?  We can bring that up in our discussion with the LF IT.



Anyways, basically, having a dedicated ops team does not imply removing
the sourceware's role, it could simply mean: adding a dedicated ops team
to sourceware.


Given that the current sourceware admins have decided to block migration 
of all sourceware assets to the LF IT, I don't have a stake on how 
they'd like to handle this for sourceware.  I could however, as a member 
of TAC (and as member of projects that have agreed to migrate to LF IT, 
i.e. gcc and glibc), discuss with others the possibility of specific 
community volunteers being given some amount of access to manage 
infrastructure.



To provide dedicated ops for the physical servers would require moving
the servers or into servers in a data center near the ops team, or
outsourcing the hardware management to one of many companies (usually by
renting a physical server), but that is all totally feasible and not a
big cost.


Siddhesh Poyarekar via Overseers  writes:


I want us to migrate
services to infrastructure with better funding (that's not just limited
to services),


What do you want to fund specifically? "Infrastructure" and "not limited
to services" is not specific enough to understand.


and an actually scalable future.


What does "an actually scalable future" mean? That is very vague.


Both of those point to scaling hardware in addition to services, having 
things like physical isolation of services.  Scaling volunteers (which 
hasn't happened in the last 20-soemthing years; it has scaled *down*, if 
anything) and money to pay for dedicated ops isn't going to mostly 
pointless if we can't pay for hardware, which is owned by Red Hat. 
That, and FSF not being able to add resources for the GNU toolchain was 
in fact why we had to look elsewhere for funding.


I suggest you wait a day for the FSF hosted call so that the background 
is clearer.


Sid

Re: Toolchain Infrastructure project statement of support

[Siddhesh Poyarekar]

On 2022-10-23 11:16, Frank Ch. Eigler wrote:

Hi -


[...]  Given that the current sourceware admins have decided to
block migration of all sourceware assets to the LF IT [...]


If you're trying to say that projects have not unanimously shown
interest in moving infrastructure to LF IT, just say that.  Don't
blame overseers.


I did not say that, although no project (barring maybe elfutils and 
systemtap, assuming that your and Mark's objection as overseers implies 
that you do not want to move to LF IT) has specifically *opposed* moving 
infrastructure to LF IT either.


To be specific, gcc steering committee and glibc FSF stewards have 
announced the decision for their projects, Nick announced for binutils 
that he supports moving to LF IT (with the caveat that he won't abandon 
sourceware, I assume that means he'd like to use sourceware as a mirror 
or something similar) but gdb folks have been silent so far.  Given how 
gdb and binutils are coupled, the gdb conversation really needs to 
happen at some point.  From private conversations with folks from the 
gdb community, it seems to me that they're primarily avoiding getting 
into this public spat.


I am not aware of any opposition from maintainers of libabigail or 
cygwin or any other active sourceware based project over moving either, 
but I haven't had any links to those projects, so I may be uninformed.



If you're trying to suggest that overseers, contrary to our repeated
public statements, wish to block all migration, that is untrue and you
will need to retract this.


Here's a more precise statement: Two of the overseers are leaders of 
projects hosted on sourceware and three overseers (including those two) 
have stated clearly on multiple occasions that transitioning to LF IT is 
off the table, effectively announcing their decision on behalf of 
projects they lead.  It is hence clear that the overseers have 
effectively blocked full migration of sourceware to LF IT.


Sid

Re: Toolchain Infrastructure project statement of support

[Siddhesh Poyarekar]

On 2022-10-23 07:33, Ian Kelling wrote:

Siddhesh Poyarekar via Overseers  writes:


I personally do not think the current sourceware infrastructure, even
with the roadmap it promises is a viable alternative to what LF IT can
provide.  There is a significant resource gap (e.g.



established security and administration practices,

...

that we seem to disagree about.



Let's consider some "established security and administration practices"

curl -v http://vger.kernel.org | head
...
< Server: Apache/2.0.52 (Red Hat)
< X-Powered-By: PHP/4.3.9

This is RHEL 3, released in 2003, according to
https://people.redhat.com/crunge/RHEL3-package-lists.pdf,

The final end of support for this distro was on 2014-01-30.

There are CVE's for that version of Apache. I assume their apache is not
running in a configuration that makes them actually exploitable, but it
is still better security practice upgrade.

The kernel is likely from RHEL 3 too. I'm reminded of Greg KH beating the
drum that old kernels need upgrades for security, especially because the
kernel devs don't always check if a bug is a security issue and
especially not for really old kernels (
https://thenewstack.io/design-system-can-update-greg-kroah-hartman-linux-security/
)

Notice that link is http because https is not supported by the apache
from 2003. Linux kernel development works through patches on mailing
lists, and how do you find the patches if you aren't already subscribed
to a list? You'd naturally go to the lists main webpage,
http://vger.kernel.org, and click "LIST INFO",
http://vger.kernel.org/vger-lists.html, and then click one of the list
archive links, or maybe the subscribe link. So, those vger.kerne.org
pages are an essential part of retrieving upstream kernel patches and
security information for some people. And being http only, my isp or
anyone in my network path could alter them to be malicious urls that
that appear to give the correct result, but actually give malicious
kernel patches, or hides away a security relevant patch. Obviously,
https for security sensitive pages like these is a basic 101 security
practice in 2022.


+Konstantin from LF IT since he's better equipped to speak to this, 
although ISTM that they started migrating off vger last year[1].


Sid

[1] https://www.kernel.org/lists-linux-dev.html

Sid

Re: Toolchain Infrastructure project statement of support

[Siddhesh Poyarekar]

On 2022-10-23 12:07, Siddhesh Poyarekar via Overseers wrote:
sourceware, I assume that means he'd like to use sourceware as a mirror 
or something similar) but gdb folks have been silent so far.  Given how 
gdb and binutils are coupled, the gdb conversation really needs to 
happen at some point.  From private conversations with folks from the 
gdb community, it seems to me that they're primarily avoiding getting 
into this public spat.


... and I've been corrected offline that a gdb GNU maintainer (Joel 
Brobecker) has indeed signed on to support the LF IT proposal and there 
have been no objections so far that I'm aware of, either publicly or 
privately.


Sid

Re: Toolchain Infrastructure project statement of support

[Siddhesh Poyarekar]

On 2022-10-23 16:57, Christopher Faylor wrote:

On Thu, Oct 13, 2022 at 02:25:29PM -0400, Christopher Faylor wrote:

Re: https://sourceware.org/pipermail/overseers/2022q4/018981.html

On Wed, Oct 12, 2022 at 12:43:09PM -0400, Carlos O'Donell wrote:

The GNU Toolchain project leadership supports the proposal[1] to move the
services for the GNU Toolchain to the Linux Foundation IT under the auspices of
the Toolchain Infrastructure project (GTI) with fiscal sponsorship from the
OpenSSF and other major donors.


Noted, however, a list of signatories does not automatically confer
authority over any particular project.  Any participation from
overseers in moving projects to different infrastructure will require
clear approval from the individual projects themselves.

Also, the FSF, being the existing fiscal sponsor to these projects,
surely needs to review the formal agreements before we sunset our
infrastructural offerings to glibc, gcc, binutils, and gdb and hand
control of the projects' infrastructure over to a different entity.

We'd like to assure the communities that, when and if any individual
project formally expresses the decision of their developers to transfer
their services, we'll endeavor to make the move as smooth as possible.
Those projects that wish to stay will continue to receive the best
services that the overseers can offer, with the ongoing assistance of
Red Hat, the SFC, and, when relevant, the FSF tech team.


On Sun, Oct 23, 2022 at 09:27:26AM -0400, Siddhesh Poyarekar wrote:

Given that the current sourceware admins have decided to block migration of
all sourceware assets to the LF IT, I don't have a stake on how they'd like
to handle this for sourceware.  I could however, as a member of TAC (and as
member of projects that have agreed to migrate to LF IT, i.e. gcc and glibc),
discuss with others the possibility of specific community volunteers being
given some amount of access to manage infrastructure.


Stop spreading FUD.  The "we" in my statement above, from October 13,
included fche, mjw, and myself.  You have no reason to be confused on
this subject.



Nope, I'm not spreading FUD, in fact that statement of yours is 
perfectly consistent with what I've said: the blocker at the moment is 
that the sourceware overseers have refused to hand over the server *in 
its entirety* to LF IT, not that any projects themselves have refused to 
move their services to LF IT.  I don't doubt that the overseers will 
help in smooth migration for projects that eventually state that they 
wish to move over.


Sid

Re: Toolchain Infrastructure project statement of support

[Siddhesh Poyarekar]

On 2022-10-23 17:59, Christopher Faylor wrote:

On Sun, Oct 23, 2022 at 05:17:40PM -0400, Siddhesh Poyarekar wrote:

On 2022-10-23 16:57, Christopher Faylor wrote:

On Thu, Oct 13, 2022 at 02:25:29PM -0400, Christopher Faylor wrote:

Re: https://sourceware.org/pipermail/overseers/2022q4/018981.html

On Wed, Oct 12, 2022 at 12:43:09PM -0400, Carlos O'Donell wrote:

The GNU Toolchain project leadership supports the proposal[1] to move the
services for the GNU Toolchain to the Linux Foundation IT under the auspices of
the Toolchain Infrastructure project (GTI) with fiscal sponsorship from the
OpenSSF and other major donors.


Noted, however, a list of signatories does not automatically confer
authority over any particular project.  Any participation from
overseers in moving projects to different infrastructure will require
clear approval from the individual projects themselves.

Also, the FSF, being the existing fiscal sponsor to these projects,
surely needs to review the formal agreements before we sunset our
infrastructural offerings to glibc, gcc, binutils, and gdb and hand
control of the projects' infrastructure over to a different entity.

We'd like to assure the communities that, when and if any individual
project formally expresses the decision of their developers to transfer
their services, we'll endeavor to make the move as smooth as possible.
Those projects that wish to stay will continue to receive the best
services that the overseers can offer, with the ongoing assistance of
Red Hat, the SFC, and, when relevant, the FSF tech team.


On Sun, Oct 23, 2022 at 09:27:26AM -0400, Siddhesh Poyarekar wrote:

Given that the current sourceware admins have decided to block migration of
all sourceware assets to the LF IT, I don't have a stake on how they'd like
to handle this for sourceware.  I could however, as a member of TAC (and as
member of projects that have agreed to migrate to LF IT, i.e. gcc and glibc),
discuss with others the possibility of specific community volunteers being
given some amount of access to manage infrastructure.


Stop spreading FUD.  The "we" in my statement above, from October 13,
included fche, mjw, and myself.  You have no reason to be confused on
this subject.



Nope, I'm not spreading FUD, in fact that statement of yours is perfectly
consistent with what I've said: the blocker at the moment is that the
sourceware overseers have refused to hand over the server *in its entirety*
to LF IT, not that any projects themselves have refused to move their
services to LF IT.  I don't doubt that the overseers will help in smooth
migration for projects that eventually state that they wish to move over.


Your initial implication was that the unreasonable overseers would hold
all projects hostage on our current infrastructure.   


Absolutely not, you and I have had multiple exchanges on this list so 
far and I'd have trusted you to take my statement above in the correct 
context.  I did not even negate your statement when you stated that the 
overseers would support seamless migration of services over to LF IT and 
in fact supplemented[1] by saying that the transition would likely take 
years.



Now you've "clarified"
that point by implying that we've been approached to transfer the server
"in its entirety" to the LF and have unreasonably refused.


You literally have an email on the list with the subject like "Moving 
sourceware to the Linux Foundation? no thanks".



Both of those are FUD.  You're either intentionally trying to muddy the
waters or you're just confused.  I'd submit that in either case you should
just think about shutting up.  You have no special authority to speak for
the GTI TAC and your increasingly hostile messages are not helping anyone.


It's funny that you're asking me to shut up and also implying that my 
messages are hostile.


Sid

[1] https://sourceware.org/pipermail/overseers/2022q4/018987.html

Re: Toolchain Infrastructure project statement of support

[Siddhesh Poyarekar]

On 2022-10-23 13:09, Frank Ch. Eigler wrote:

[...]  To be specific, gcc steering committee and glibc FSF stewards
have announced the decision for their projects [...]


I may be missing something.  All I've seen so far were some of the
leaders of some of the projects being joint signatories to a letter on
overseers@.  As far as I'm aware, that is not how any of these
projects make or announce **project decisions** with/to their
respective constituencies.


Fair enough.


I am not aware of any opposition from maintainers of libabigail or
cygwin or any other active sourceware based project over moving
either, but I haven't had any links to those projects, so I may be
uninformed.


Indeed.  The onus is obviously on the shoulders of the proponents of
this proposal to convince each sourceware guest project to consent to
move.  If you wish to frame any dissent as "blocking full migration",
then I'd say the job of convincing everyone just has not been up to
par.  Perhaps it was the wrong goal all along.


Are you saying then that your dissent so far is as maintainer for 
systemtap and not as an overseer?


Sid

Re: Missed warning (-Wuse-after-free)

[Siddhesh Poyarekar]

On 2023-02-16 10:15, David Malcolm via Gcc wrote:

I'm not convinced that it's useful to the end-user to warn about the
"use of q itself" case.


FWIW, -Wuse-after-free=3 already should do this:

At level 3, the warning also diagnoses uses of indeterminate pointers in 
equality expressions.  All uses of indeterminate pointers are undefined 
but equality tests sometimes appear after
calls to "realloc" as an attempt to determine whether the call resulted 
in relocating the object to a different address.  They are diagnosed at 
a separate level to aid legacy code gradually
transition to safe alternatives.  For example, the equality test in the 
function below is diagnosed at this level:


Jakub and I had discussed this in the context of _FORTIFY_SOURCE=3 
(which is anal about this and can break things) and we got pr#105217, 
but that is also a best-effort thing, not really a guarantee.


IMO the analyzer should go that extra mile and warn for the use of q 
itself and maybe deprecate -Wuse-after-free=3 in its favour.


Sid

Re: Missed warning (-Wuse-after-free)

[Siddhesh Poyarekar]

On 2023-02-17 06:24, Jonathan Wakely wrote:

Please be aware that in C++ it's implementation-defined, not undefined.

That means that an implementation without trap representations for 
pointers can choose to make it behave just like using (uintptr_t)p.


https://cplusplus.github.io/CWG/issues/1438.html 

https://cplusplus.github.io/CWG/issues/623.html 

https://cplusplus.github.io/CWG/issues/616.html 

https://cplusplus.github.io/CWG/issues/312.html 



We could still warn in C++ (because the code isn't portable) but I would 
strongly suggest we don't influence C++ codegen based on deallocated 
pointers being undefined. I don't think gcc supports any targets with 
trapping pointers, and there are quite enough sources of UB already. We 
don't need to create traps for users where there are no traps for 
pointers :-)


The codegen problem is a pointer provenance issue and AFAICT, 
-Wuse-after-free=3 is also framed in that context and not as a problem 
with simply taking the numeric value of the pointer to, e.g. log it 
somewhere.


More concretely, something like this is what causes problems:

Foo *old = malloc (sz);
...
Foo *new = realloc (old, newsz);

if (new != old)
  {
old = new;
/* Adjust references.  */
  }

/* Otherwise continue using old unchanged */
...

The problem is the assumption that the old pointer continues to be valid 
because it has the same numeric value as the new one.  This is not an 
uncommon code pattern in C, what about C++?


On a fat pointer-like scheme such as the Arm Morello cpu, this won't 
work at all because even though old and new have the same numeric 
values, old will have been invalidated.


Sid

Re: Missed warning (-Wuse-after-free)

[Siddhesh Poyarekar]

On 2023-02-17 06:22, Alejandro Colomar wrote:

Hi Siddhesh,

On 2/17/23 04:48, Siddhesh Poyarekar wrote:

On 2023-02-16 10:15, David Malcolm via Gcc wrote:

I'm not convinced that it's useful to the end-user to warn about the
"use of q itself" case.


FWIW, -Wuse-after-free=3 already should do this:


Thanks!  It works.  I would have expected such a warning to be included
in -Wextra.  Does it have any false positives (or maybe too many false
negatives?) that make it unsuitable for -Wextra?


I don't know why it isn't enabled in -Wextra, it seems like the right 
thing to do.


Sid

Re: Missed warning (-Wuse-after-free)

[Siddhesh Poyarekar]

On 2023-02-17 08:44, David Malcolm wrote:

This is possibly a silly question, but what *are* these safe
alternatives? [1] How does one test to see if an object has been
reallocated?


Oops sorry, I snipped off that part when pasting from the man page. 
Typically such conditionals are used to update pointers within structs 
(and in some overly adventurous cases, continue using the old pointer!) 
and the alternative is to save offsets in structs and not pointers.


The text I missed quoting here:

"""
void adjust_pointers (int**, int);

void grow (int **p, int n)
{
  int **q = (int**)realloc (p, n *= 2);
  if (q == p)
return;
  adjust_pointers ((int**)q, n);
}

To avoid the warning at this level, store offsets into allocated memory 
instead of pointers.  This approach obviates needing to adjust the 
stored pointers after reallocation.

"""

Sid


Dave
[1] Would suggesting "rust" here be too snarky? :-P


I think the equivalent American expression is "lets take this outside" ;)

Re: Missed warning (-Wuse-after-free)

[Siddhesh Poyarekar]

On 2023-02-17 09:01, Mark Wielaard wrote:

The reason people might not know about it, is that the documentation is
somewhat unclear. -Wall says it already includes -Wuse-after-free=3:
https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wall


Yeah I posted a patch to fix it only a few minutes ago:

https://sourceware.org/pipermail/gcc-patches/2023-February/612229.html

Sid

Re: [PATCH] Make -Wuse-after-free=3 the default one in -Wall

[Siddhesh Poyarekar]

On 2023-02-17 16:20, Alejandro Colomar wrote:

Link: 
<https://inbox.sourceware.org/gcc/3098fd18-9dbf-b4e9-bae5-62ec6fea7...@opteya.com/T/>
Link: <https://github.com/shadow-maint/shadow/pull/649#discussion_r1108350066>
Cc: Andreas Schwab 
Cc: David Malcolm 
Cc: Florian Weimer 
Cc: Iker Pedrosa 
Cc: Jens Gustedt 
Cc: Jonathan Wakely 
Cc: Mark Wielaard 
Cc: Martin Uecker 
Cc: Michael Kerrisk 
Cc: Paul Eggert 
Cc: Sam James 
Cc: Siddhesh Poyarekar 
Cc: Yann Droneaud 
Signed-off-by: Alejandro Colomar 
---

Hi Siddhesh,

Here's a patch for it.  It is untested yet.  Please have a look at it.
I'm not used to GCC customs, so corrections are welcome :)

Cheers,

Alex


You've got the customs right as far as submission is concerned; gcc 
accepts patches under DCO.  I'm not a maintainer though, so I can't 
approve the change, I can only comment on it in the hope of influencing 
maintainers' opinions.  In any case it's probably suitable as a proposal 
for gcc 14, given that 13 is in stage 4, regression fixes only.


I'm split about where -Wuse-after-free=3 should be enabled.  On the one 
hand, I'd like it to go into -Wall and alongside _FORTIFY_SOURCE=3, 
given that the latter already breaks the incorrect provenance 
assumptions in such code patterns.  However on the other hand, it may 
lead to annoyed developers, even though the usage is, strictly speaking, 
UB.  I don't know about the false positive rate of -Wuse-after-free=3 
either (specifically in the context of UB-ness of the code it warns 
about), maybe someone else may be able to chime in on that.


Maybe a good compromise here is -Wextra, but if there's consensus 
developing towards adding it to -Wall, I'll happily jump to that side.


Thanks,
Sid




  gcc/c-family/c.opt  | 4 ++--
  gcc/doc/invoke.texi | 2 +-
  2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
index c0fea56a8f5..1a3fc2c5d74 100644
--- a/gcc/c-family/c.opt
+++ b/gcc/c-family/c.opt
@@ -1411,11 +1411,11 @@ C ObjC C++ ObjC++ Joined RejectNegative UInteger 
Var(warn_unused_const_variable)
  Warn when a const variable is unused.
  
  ; Defining this option here in addition to common.opt is necessary

-; in order for the default -Wall setting of -Wuse-after-free=2 to take
+; in order for the default -Wall setting of -Wuse-after-free=3 to take
  ; effect.
  
  Wuse-after-free=

-LangEnabledBy(C ObjC C++ LTO ObjC++, Wall,2,0)
+LangEnabledBy(C ObjC C++ LTO ObjC++, Wall,3,0)
  ; in common.opt
  
  Wvariadic-macros

diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 7b308cd3c31..d910052ce0c 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -4720,7 +4720,7 @@ instead of pointers.  This approach obviates needing to 
adjust the stored
  pointers after reallocation.
  @end table
  
-@option{-Wuse-after-free=2} is included in @option{-Wall}.

+@option{-Wuse-after-free=3} is included in @option{-Wall}.
  
  @item -Wuseless-cast @r{(C++ and Objective-C++ only)}

  @opindex Wuseless-cast

Re: [PATCH] Make -Wuse-after-free=3 the default one in -Wall

[Siddhesh Poyarekar]

On 2023-02-17 16:39, Siddhesh Poyarekar wrote:
You've got the customs right as far as submission is concerned; gcc 


Oh, one correction: patches typically go to gcc-patches at gcc dot gnu 
dot org.


Thanks,
Sid

Re: [PATCH] Make -Wuse-after-free=3 the default one in -Wall

[Siddhesh Poyarekar]

On 2023-02-17 17:58, Alejandro Colomar wrote:

On 2/17/23 22:41, Siddhesh Poyarekar wrote:

On 2023-02-17 16:39, Siddhesh Poyarekar wrote:

You've got the customs right as far as submission is concerned; gcc


Oh, one correction: patches typically go to gcc-patches at gcc dot gnu
dot org.


Okay, I'll take that note for next time.  For this one, should I resend,
or is it okay as is?  Both are fine for me.


Probably makes sense to resend to gcc-patches.

Thanks,
Sid

Re: _Nullable and _Nonnull in GCC's analyzer (was: [PATCH v5] libio: Add nonnull attribute for most FILE * arguments in stdio.h)

[Siddhesh Poyarekar]

On 2023-08-08 20:14, enh wrote:

(bionic maintainer here, mostly by accident...)

yeah, we tried the GCC attributes once before with _disastrous_
results (because GCC saw it as an excuse to delete explicit null
checks, it broke all kinds of things). the clang attributes are


AFAICT based on earlier discussions around this patch, the NULL check 
deletion anomalies in gcc seem to have been fixed recently.



"better" in that they don't confuse two entirely separate notions ...
but they're not "good" because the analysis is so limited. i think we
were hoping for something more like the "used but not set" kind of
diagnostic, but afaict it really only catches _direct_ use of a
literal nullptr. so:

   foo(nullptr); // caught

   void* p = nullptr;
   foo(p); // not caught

without getting on to anything fancy like:

   void* p;
   if (a) p = bar();
   foo(p);

we've done all the annotations anyway, but we're not expecting to
actually catch many bugs with them, and in fact did not catch any real
bugs in AOSP while adding the annotations. (though we did find several
"you're not _wrong_, but ..." bits of code :-) )


I believe it did catch a few issues in the glibc test cases when we 
enabled fortification internally in addition to flagging several "you're 
not _wrong_, but..." bits.  In any case, it's only enabled with 
fortification since we use that as a hint for wanting safer code.



what i really want for christmas is the annotation that lets me say
"this size_t argument tells you the size of this array argument" and
actually does something usefully fortify-like with that. i've seen
proposals like 
https://discourse.llvm.org/t/rfc-enforcing-bounds-safety-in-c-fbounds-safety/70854/
but i haven't seen anything i can use yet, so you -- who do use GCC
which aiui has something along these lines already -- will find out
what's good/bad about it before i do...


I think a lot of this is covered by __access__, __alloc_size__ and the 
upcoming __counted_by__ attributes.  There are still gaps that something 
like -fbounds-safety would cover (I think -fsanitize=bounds and 
-fsanitize=object-size further cover some of those gaps but there's a 
general lack of confidence in using them in production due to 
performance concerns; fbounds-safety has those concerns too AFAICT) but 
that gap is getting narrower.


Thanks,
Sid

Re: Getting a build failure in glibc due to gcc changes on 32bit x86 glibc

[Siddhesh Poyarekar]

On Wed, Nov 26, 2014 at 02:59:34PM -0800, Andrew Pinski wrote:
> Hi all,
>   I am getting the following failure on the 32bit x86 glibc with the
> top of the trunk gcc 5.0 and glibc from the commit
> (e5e0d9a4f632735cf3bb440eecb5caee5eea44c1).  While building

Is that the right commit?

Siddhesh


pgpZ9Nj6Pu3IU.pgp
Description: PGP signature

[RFC] builtin functions and `-ffreestanding -nostartfies` with static binaries

[Siddhesh Poyarekar]

Hello,

Ref: https://bugs.linaro.org/show_bug.cgi?id=5479

Statically built independent programs that implement their own program
entry points (i.e. -ffreestanding -nostartfiles) and call __builtin_*
functions break when the builtin function in question is implemented as
an IFUNC in glibc and the builtin results in a glibc call instead of
some inline code.

This happens because the startup code where ifuncs are resolved never
gets executed (since glibc's startup code is never executed) and hence
the PLT jumps fail.  The bug report talks about this as an aarch64
problem but I've been able to reproduce the problem on x86_64 as well.
One just needs to make sure that the __builtin_foo call results in a
glibc call.

I spent some time thinking about this and while it's trivial to fix by
disabling ifuncs for static glibc, I wanted a solution that wasn't such
a big hammer.  The other alternative I could think of is to have an
exported alias (called __builtin_strlen for example instead of strlen)
of a default implementation of the builtin function in glibc that gcc
generates a call to if freestanding && nostartfiles && static.

Any thoughts or other ideas on how this could be implemented?

Thanks,
Siddhesh

Re: [RFC] builtin functions and `-ffreestanding -nostartfies` with static binaries

[Siddhesh Poyarekar]

On 10/01/20 10:25 pm, Alexander Monakov wrote:
> On Fri, 10 Jan 2020, Siddhesh Poyarekar wrote:
> 
>> I spent some time thinking about this and while it's trivial to fix by
>> disabling ifuncs for static glibc, I wanted a solution that wasn't such
>> a big hammer.  The other alternative I could think of is to have an
>> exported alias (called __builtin_strlen for example instead of strlen)
>> of a default implementation of the builtin function in glibc that gcc
>> generates a call to if freestanding && nostartfiles && static.
> 
> In the Linaro bugreport you mention,
> 
>> Basically, IFUNCs and freestanding don't mix.
> 
> but really any libc (Glibc included) and -nostartfiles don't mix: stdio
> won't be initialized, TLS won't be setup, and pretty much all other
> libc-internal datastructures won't be properly setup. Almost no libc functions
> are callable, because for example if they try to access 'errno', they crash.
> 
> Looking at the opening comment of the failing kselftest source:
> 
>  * This program tries to be as small as possible itself, to
>  * avoid perturbing the system memory utilization with its
>  * own execution.  It also attempts to have as few dependencies
>  * on kernel features as possible.
>  *
>  * It should be statically linked, with startup libs avoided.
>  * It uses no library calls, and only the following 3 syscalls:
>  *   sysinfo(), write(), and _exit()
> 
> so in fact allowing it to link with libc strlen would be contrary to its 
> intent.
> The fix is simple: add -nodefaultlibs next to -nostartfiles in its Makefile, 
> and
> write a trivial loop in place of __builtin_strlen.

That's a valid point.  I'll recommend dropping __builtin_strlen from
that test.

Thanks,
Siddhesh

Re: [RFC] builtin functions and `-ffreestanding -nostartfies` with static binaries

[Siddhesh Poyarekar]

On 11/01/20 6:55 pm, Segher Boessenkool wrote:
> -ffreestanding means you might not have any of the C standard library,
> and -nostartfiles means you do not do any of the standard initialisation.
> Why then would you expect any ifunc to work?
> 

Agreed, based on Alexander's feedback I have suggested changing the
tests instead.

Siddhesh

Re: Dropping ChangeLogs

[Siddhesh Poyarekar]

On Friday 22 December 2017 05:41 PM, Florian Weimer wrote:
> *However*, my main problem with getting rid of ChangeLogs is that
> without a pull-request-based contribution procedure or some tool support
> like Gerrit, it's impossible to tell which parts of a patch submission> make 
> it into a commit message.  For glibc, we regularly have commits
> where the commit message is not informative at all, and we don't really
> know what will be committed by a contributor before the fact.

IIUC the way the kernel community solves this is by ensuring that the
patch in the mailing list makes it in exactly as is so that the mbox for
the email can simply be git-am'd into the repo.  That is, subject line
and mail body become commit messages.  This could actually make tools
like patchwork effective too since patches on patchwork can then be
reliably auto-closed in the post-commit hook.

Siddhesh

Re: Dropping ChangeLogs

[Siddhesh Poyarekar]

On Friday 22 December 2017 05:57 PM, Florian Weimer wrote:
> The Linux community does not have a tool-based solution for that.  I
> think it mainly relies on lack of commit access for contributors.

Sure, but that's a minor detail to implement once we decide we don't
need ChangeLogs.  As far as glibc is concerned, I don't think we have
reached that conclusion yet.

Siddhesh

Re: Dropping ChangeLogs

[Siddhesh Poyarekar]

On Friday 22 December 2017 06:06 PM, Florian Weimer wrote:
> I cannot agree with that.  Full commit review is an absolute requirement
> before we can eliminate ChangeLogs because the review needs to cover the
> author attribution.

We have agreed on doing full commit reviews multiple times (at least the
last couple of Cauldrons, including this year's) but implementation has
been inconsistent.

So we have agreement in principle on everything needed get a proper git
workflow (with or without a tool) except dropping ChangeLogs, which is
why I mentioned that as the main blocker.

Siddhesh

RE: Copyright assignment form

[Siddhesh Poyarekar]

Hi Shahid,

You need a separate assignment for every GNU project you intend to
contribute to, so separate assignments for GCC, glibc, binutils, etc.

Siddhesh

On 17-Jan-2018 01:25, "Shahid Khan"  wrote:

Thanks for the info, Jim.

Siddhesh,

Is there a separate copyright assignment for glibc or the same form works
for both?

-Shahid

-Original Message-
From: Jim Wilson [mailto:j...@sifive.com]
Sent: Tuesday, January 16, 2018 1:01 PM
To: Shahid Khan ; gcc@gcc.gnu.org
Cc: siddh...@linaro.org
Subject: Re: Copyright assignment form

On 01/15/2018 03:11 PM, Shahid Khan wrote:
> Our team at Qualcomm Datacenter Technologies, Inc. is interested in
contributing patches to the upstream GCC compiler project. To get the
process started, we'd like to request a copyright assignment form as per
contribution guidelines outlined at https://gcc.gnu.org/contribute.html.
>
> Please let me know if there are additional steps we need to take to
become an effective contributor to the GCC community.

You should contact ass...@gnu.org directly.  The standard forms contain
language about patents that Qualcomm lawyers are unlikely to be comfortable
with, and may require negotiating a non-standard agreement.
As best as I can tell, the FSF has never received a copyright assignment or
disclaimer from Qualcomm.  If this is the first time Qualcomm lawyers are
talking to the FSF, this will take a while.  I would not be surprised if
this takes a year or two.  You will also need a VP level signature for the
forms once you get approval from Qualcomm lawyers.

You may want to consider getting a disclaimer from your employer, and then
filing personal assignments.  It is probably easier to get a disclaimer
from Qualcomm than an assignment, but this requires more paperwork, since
each individual contributing then needs their own personal assignment.  The
disclaimers also have language about patents that the Qualcomm lawyers may
not like, so while this should be easier, it is still likely a difficult
process.

Siddhesh can help you with this as the rules for gcc are the same as for
glibc.

Jim

Re: Copyright assignment form

[Siddhesh Poyarekar]

On 17-Jan-2018 02:02, "Jim Wilson"  wrote:

On Tue, Jan 16, 2018 at 12:01 PM, Siddhesh Poyarekar
 wrote:
> You need a separate assignment for every GNU project you intend to
> contribute to, so separate assignments for GCC, glibc, binutils, etc.

The form is the same for all GNU projects.


Right, the content is the same, but I remember signing separate papers for
each project.

Siddhesh

Re: Copyright assignment form

[Siddhesh Poyarekar]

On Wednesday 17 January 2018 05:52 PM, Nathan Sidwell wrote:
> That was a local decision between (I presume) linaro and the FSF.   A
> single assignment may cover multiple specific projects, or specify any.

I didn't sign my copyright papers through Linaro; I've had an individual
assignment on file since 2012 when I was at RH.

In any case that's just a procedural thing that shouldn't matter given
that the content is the same.

Siddhesh

Re: ChangeLog's: do we have to?

[Siddhesh Poyarekar]

On 07/05/2018 05:02 PM, Richard Biener wrote:

I assumed you just want to remove the ChangeLog files, not change contents.
Thus I assumed the commit message would simply contain the ChangeLog
entry as we requie it today?  In that case git log --grep would still provide
everything grepping ChangeLogs does - maybe apart from reducing noise
because you can automatically grep specific ChangeLogs only (like only in cp/).


We had discussed making addition of ChangeLog entries into the commit 
message mandatory but the issue there is that commit logs cannot be (or 
more precisely, should not be) modified after they're pushed so errors 
in ChangeLog entries will remain.  Carlos had suggested git notes, but I 
don't know off the top of my head how they work; I vaguely remember them 
being editable.


Siddhesh

Re: ChangeLog's: do we have to?

[Siddhesh Poyarekar]

On 07/10/2018 08:19 PM, Frank Ch. Eigler wrote:


siddhesh wrote:


[...]  We had discussed making addition of ChangeLog entries into the
commit message mandatory but the issue there is that commit logs
cannot be (or more precisely, should not be) modified after they're
pushed so errors in ChangeLog entries will remain.  [...]


In such a rare case, it would be possible to add a subsequent commit
that carries the corrected text, but no other changes (--allow-empty).
Or even revert the previous patch, then re-commit with a fixed text.
Watch out for "perfect is the enemy of the good" syndrome here (as in
the svn-git conversion).


I agree.

Siddhesh

Cauldron schedule: diagnostics and security features talks

[Siddhesh Poyarekar]

Hello,

I want to begin by apologizing because I know from first hand experience 
that scheduling can be an immensely painful job.


The Cauldron 2023 schedule[1] looks packed and I noticed that Qing and 
David's talks on security features and diagnostics respectively are in 
the same time slot.  Both those sessions are likely to have pretty big 
overlaps in audience IMO since the topics are thematically related.  Is 
there a way in which they could be put in different time slots?


IIRC they were in different time slots before and were probably moved 
around to cater for another conflict (hence maybe making it harder to 
move them again) but I figured I'd rather air my request and be turned 
down than have to make the difficult choice :)


Thanks!
Sid

[1] https://gcc.gnu.org/wiki/cauldron2023