[PATCH] Relocated compiler should not look in $prefix.

[Carlos O'Donell]

A relocated compiler should not look in $prefix.

A relocated compiler should never search the configured prefix for
programs, libraries or start files. A relocated compiler searching for
files in the configured prefix is troublesome. The configured prefix may
contain a conflicting toolchain, or a slow network path.

The old behaviour of searching the conifgured prefix is not what users
expect from a relocated toolchain.

Consider 3 types of paths:

1. Relocated paths.
2. Configured prefix paths.
3. Well known system paths.

The type 1 and type 3 paths are always added to our search lists. The
type 2 paths are only added if the compiler is installed at the
configured prefix.

This patch groups the 3 path types logically in gcc/gcc.c, and adds the
paths based on the wether the compiler is relocated or unrelocated.

The testing infrastructure also needs to be updated. Testing in the
object directory often uses libraries or start files from the configured
prefix. To enable testing from the object directory we export
GCC_EXEC_PREFIX with the value of the configured prefix. This gives the
old behaviour for the testsuite.

Comments?
OK for Stage1?

Tested without regression on i686-pc-linux-gnu (All languages),
arm-none-eabi, and arm-none-linux-gnueabi.

This is the first, of two, step to fixing pr17621.

Cheers,
Carlos.
-- 
Carlos O'Donell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x716

2006-10-13  Carlos O'Donell  <[EMAIL PROTECTED]>
Mark Mitchell  <[EMAIL PROTECTED]>
 
* gcc.c: Organize search path variables into $prefix relative,
and well-known native. Add comments.
(add_sysrooted_prefix): Add comment.
(process_command): If !gcc_exec_prefix add $prefix based paths.
If *cross_compile == '0', add native well-known paths.
Assert tooldir_base_prefix is always relative.
(main): If print_search_dirs, and if gcc_exec_prefix is set,
use this value for 'install:' path.
* Makefile.in: Add GCC_EXEC_PREFIX to generated site.exp.
 
Index: gcc/gcc.c
===
--- gcc/gcc.c   (revision 117699)
+++ gcc/gcc.c   (working copy)
@@ -1472,26 +1472,34 @@
 #define MD_STARTFILE_PREFIX_1 ""
 #endif
 
+/* These directories are locations set at configure-time based on the
+   --prefix option provided to configure.  Their initializers are
+   defined in Makefile.in.  These paths are not *directly* used when
+   gcc_exec_prefix is set because, in that case, we know where the
+   compiler has been installed, and use paths relative to that
+   location instead.  */
 static const char *const standard_exec_prefix = STANDARD_EXEC_PREFIX;
+static const char *const standard_libexec_prefix = STANDARD_LIBEXEC_PREFIX;
+static const char *const standard_bindir_prefix = STANDARD_BINDIR_PREFIX;
+static const char *const standard_startfile_prefix = STANDARD_STARTFILE_PREFIX;
+
+/* For native compilers, these are well-known paths containing
+   components that may be provided by the system.  For cross
+   compilers, these paths are not used.  */
 static const char *const standard_exec_prefix_1 = "/usr/libexec/gcc/";
 static const char *const standard_exec_prefix_2 = "/usr/lib/gcc/";
 static const char *md_exec_prefix = MD_EXEC_PREFIX;
-
 static const char *md_startfile_prefix = MD_STARTFILE_PREFIX;
 static const char *md_startfile_prefix_1 = MD_STARTFILE_PREFIX_1;
-static const char *const standard_startfile_prefix = STANDARD_STARTFILE_PREFIX;
-static const char *const standard_startfile_prefix_1
+static const char *const standard_startfile_prefix_1 
   = STANDARD_STARTFILE_PREFIX_1;
 static const char *const standard_startfile_prefix_2
   = STANDARD_STARTFILE_PREFIX_2;
 
+/* A relative path to be used in finding the location of tools
+   relative to the driver.  */
 static const char *const tooldir_base_prefix = TOOLDIR_BASE_PREFIX;
-static const char *tooldir_prefix;
 
-static const char *const standard_bindir_prefix = STANDARD_BINDIR_PREFIX;
-
-static const char *standard_libexec_prefix = STANDARD_LIBEXEC_PREFIX;
-
 /* Subdirectory to use for locating libraries.  Set by
set_multilib_dir based on the compilation options.  */
 
@@ -2749,6 +2757,7 @@
 }
 
 /* Same as add_prefix, but prepending target_system_root to prefix.  */
+/* The target_system_root prefix has been relocated by gcc_exec_prefix.  */
 static void
 add_sysrooted_prefix (struct path_prefix *pprefix, const char *prefix,
  const char *component,
@@ -3278,6 +3287,7 @@
   int is_modify_target_name;
   unsigned int j;
 #endif
+  const char *tooldir_prefix;
 
   GET_ENVIRONMENT (gcc_exec_prefix, "GCC_EXEC_PREFIX");
 
@@ -3383,10 +3393,18 @@
   gcc_libexec_prefix = make_relative_prefix (tmp_prefix,
 standard_exec_prefix,

Re: [PATCH] Relocated compiler should not look in $prefix.

[Carlos O'Donell]

On Mon, Oct 16, 2006 at 03:32:27PM -0700, Mark Mitchell wrote:
> Ian Lance Taylor wrote:
> >"Carlos O'Donell" <[EMAIL PROTECTED]> writes:
> >
> >>A relocated compiler should not look in $prefix.
> >
> >I agree.
> >
> >I can't approve your patches, though.
> 
> This patch is OK, once we reach Stage 1.
 
Checked into mainline.
Bootstrapped with no regressions on i686-pc-linux-gnu.

Cheers,
Carlos.
-- 
Carlos O'Donell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x716

Examples of callee returning struct, but caller allocating space?

[Carlos O'Donell]

The SPARC psABI defines that a caller must allocate the space for a
structure returned from the callee. If the callee sees the size marker
in the allocation matches the size of the return then it fills the slot.
If the size matches we return, if it doesn't match we return anyway but
add a fixed offset to the return (like a non-local goto).

There are some optimiations that can be done...

The caller, knowing that nobody uses the result can set the size marker
to zero. The callee should check for the size marker and write nothing
to the slot, returning to the normal location plus the offset.

The callee can assume the caller allocated the space and always write to
the slot (no size check) and return to the correct position in the
caller.

Is there any example of this type of behaviour in any other ports?
I'm just looking for implementation examples.

The root cause of this research is that code like this:

#include 

div_t
div(int num, int denom)
{
div_t r;

r.quot = num / denom;
r.rem = num % denom;
return (r);
}

Produces asm that doesn't check the callers size marker in the allocated
return slot. If the caller and callee are compiled separately then an
optimization in the caller could cause a problem. Rightly though the
caller can't optimize without breaking ABI. Rightly the callee can't
opimize away the size check without breaking ABI. Without coordination
we can't safely remove the checks.

Cheers,
Carlos.
-- 
Carlos O'Donell 
 
CodeSourcery, LLC   

[EMAIL PROTECTED] 

Feedback on the GNU Social contract and new wiki.gnu.tools.

[Carlos O'Donell]

Myself and several other GNU Maintainers have been publicly discussing
a GNU Social contract on gnu-misc-disc...@gnu.org and what it means to
be a GNU Project volunteer.

We are continuing that discussion by reaching out (by email) to all
GNU Maintainers. We look forward to your feedback! Please have a look
at the email you get since it has some important dates.

To assist in this discussion we have created a new wiki for use by GNU
Maintainers.

https://wiki.gnu.tools

The wiki is designed to meet the needs of GNU Maintainers who have
asked for a wiki.  Given the feedback it is git based with markdown
support, and is an actively maintained wiki that is free software with
good internationalization.

Thank you for your support in making a positive change in the GNU Project.

Cheers,
Carlos.

Re: RFC: Doc update for attribute

[Carlos O'Donell]

On 05/12/2014 11:13 PM, David Wohlferd wrote:
> After updating gcc's docs about inline asm, I'm trying to improve
> some of the related sections. One that I feel has problems with
> clarity is __attribute__ naked.
> 
> I have attached my proposed update. Comments/corrections are
> welcome.
> 
> In a related question:
> 
> To better understand how this attribute is used, I looked at the
> Linux kernel. While the existing docs say "only ... asm statements
> that do not have operands" can safely be used, Linux routinely uses
> asm WITH operands.

That's a bug. Period. You must not use naked with an asm that has
operands. Any kind of operand might inadvertently cause the compiler
to generate code and that would violate the requirements of the
attribute and potentially generate an ICE.

The correct solution, and we've talked about this in the past, is to
have the compiler generate a hard error if you use an asm statement
with operands and naked. I don't know what anyone ever got around to it.

> Some examples:
> 
> memory clobber operand:
> http://lxr.free-electrons.com/source/arch/arm/kernel/kprobes.c#L377 

Is this needed?

> Input arguments:
> http://lxr.free-electrons.com/source/arch/arm/mm/copypage-feroceon.c#L17

This is a bug and it's wrong. The naked asm can just assume the use of
first and second arguments as per AAPCS.

> Since I don't know why "asm with operands" was excluded from the
> existing docs, I'm not sure whether what Linux does here is supported
> or not (maybe with some limitations?). If someone can clarify, I'll
> add it to this text.

The "asm with operands" was excluded because to allow them in the
implementation would require gcc to potentially copy the argumnents
to temporary storage depending on their type. There is no prologue so
the compiler has no stack in which to place the arguments, therefore
the result is an impossible to satisfy constraint which usually results
in an ICE or compiler error.

Even if you said it was OK to use the incoming arguments with "r" type
operands the optimization level of the compile might inadvertently
try to force those values to the stack and that again is an impossible
to satisfy condition with a naked function.

> Even without discussing "asm with operands," I believe this text is 
> an improvement.
> Thanks in advance,
> dw
> 
> extend.texi.patch
> 
> 
> Index: extend.texi
> ===
> --- extend.texi   (revision 210349)
> +++ extend.texi   (working copy)
> @@ -3330,16 +3330,15 @@
>  
>  @item naked
>  @cindex function without a prologue/epilogue code
> -Use this attribute on the ARM, AVR, MCORE, MSP430, NDS32, RL78, RX and SPU
> -ports to indicate that the specified function does not need prologue/epilogue
> -sequences generated by the compiler.
> -It is up to the programmer to provide these sequences. The
> -only statements that can be safely included in naked functions are
> -@code{asm} statements that do not have operands.  All other statements,
> -including declarations of local variables, @code{if} statements, and so
> -forth, should be avoided.  Naked functions should be used to implement the
> -body of an assembly function, while allowing the compiler to construct
> -the requisite function declaration for the assembler.
> +This attribute is available on the ARM, AVR, MCORE, MSP430, NDS32, RL78, RX 
> +and SPU ports.  It allows the compiler to construct the requisite function 
> +declaration, while allowing the body of the function to be assembly code. 
> +The specified function will not have prologue/epilogue sequences generated 
> +by the compiler; it is up to the programmer to provide these sequences if 
> +the function requires them. The expectation is that only Basic @code{asm} 
> +statements will be included in naked functions (@pxref{Basic Asm}). While it 
> +is discouraged, it is possible to write your own prologue/epilogue code 
> +using asm and use ``C'' code in the middle.

I wouldn't remove the last sentence since IMO it's not the intent of the feature
to ever support that and the compiler doesn't guarantee it and may result
in wrong code given that `naked' is a fragile low-level feature.

>  
>  @item near
>  @cindex functions that do not handle memory bank switching on 68HC11/68HC12

Cheers,
Carlos.

Re: RFC: Doc update for attribute

[Carlos O'Donell]

On 05/20/2014 03:02 AM, David Wohlferd wrote:
> After thinking about this some more, I believe I have some better
> text. Previously I used the word "discouraged" to describe this
> practice. The existing docs use the term "avoid." I believe what you
> want is something more like the attached. Direct and clear, just like
> docs should be.

David, Thanks for the new patch.

> If you are ok with this, I'll send it to gcc-patches.

Looks good to me.

Cheers,
Carlos.

> Index: extend.texi
> ===
> --- extend.texi   (revision 210624)
> +++ extend.texi   (working copy)
> @@ -3332,16 +3332,15 @@
>  
>  @item naked
>  @cindex function without a prologue/epilogue code
> -Use this attribute on the ARM, AVR, MCORE, MSP430, NDS32, RL78, RX and SPU
> -ports to indicate that the specified function does not need prologue/epilogue
> -sequences generated by the compiler.
> -It is up to the programmer to provide these sequences. The
> -only statements that can be safely included in naked functions are
> -@code{asm} statements that do not have operands.  All other statements,
> -including declarations of local variables, @code{if} statements, and so
> -forth, should be avoided.  Naked functions should be used to implement the
> -body of an assembly function, while allowing the compiler to construct
> -the requisite function declaration for the assembler.
> +This attribute is available on the ARM, AVR, MCORE, MSP430, NDS32,
> +RL78, RX and SPU ports.  It allows the compiler to construct the
> +requisite function declaration, while allowing the body of the
> +function to be assembly code. The specified function will not have
> +prologue/epilogue sequences generated by the compiler. Only Basic
> +@code{asm} statements can safely be included in naked functions
> +(@pxref{Basic Asm}). While using Extended @code{asm} or a mixture of
> +Basic @code{asm} and ``C'' code may appear to work, they cannot be
> +depended upon to work reliably and are not supported.
>  
>  @item near
>  @cindex functions that do not handle memory bank switching on 68HC11/68HC12
> @@ -6269,6 +6268,8 @@
>  efficient code, and in most cases it is a better solution. When writing 
>  inline assembly language outside of C functions, however, you must use Basic 
>  @code{asm}. Extended @code{asm} statements have to be inside a C function.
> +Functions declared with the @code{naked} attribute also require Basic 
> +@code{asm} (@pxref{Function Attributes}).
>  
>  Under certain circumstances, GCC may duplicate (or remove duplicates of) 
> your 
>  assembly code when optimizing. This can lead to unexpected duplicate 
> @@ -6388,6 +6389,8 @@
>  
>  Note that Extended @code{asm} statements must be inside a function. Only 
>  Basic @code{asm} may be outside functions (@pxref{Basic Asm}).
> +Functions declared with the @code{naked} attribute also require Basic 
> +@code{asm} (@pxref{Function Attributes}).
>  
>  While the uses of @code{asm} are many and varied, it may help to think of an 
>  @code{asm} statement as a series of low-level instructions that convert 
> input 

Re: RFC: Doc update for attribute

[Carlos O'Donell]

On 05/20/2014 03:59 AM, Georg-Johann Lay wrote:
> Am 05/16/2014 07:16 PM, schrieb Carlos O'Donell:
>> On 05/12/2014 11:13 PM, David Wohlferd wrote:
>>> After updating gcc's docs about inline asm, I'm trying to
>>> improve some of the related sections. One that I feel has
>>> problems with clarity is __attribute__ naked.
>>> 
>>> I have attached my proposed update. Comments/corrections are 
>>> welcome.
>>> 
>>> In a related question:
>>> 
>>> To better understand how this attribute is used, I looked at the 
>>> Linux kernel. While the existing docs say "only ... asm
>>> statements that do not have operands" can safely be used, Linux
>>> routinely uses asm WITH operands.
>> 
>> That's a bug. Period. You must not use naked with an asm that has 
>> operands. Any kind of operand might inadvertently cause the
>> compiler to generate code and that would violate the requirements
>> of the attribute and potentially generate an ICE.
> 
> There is target hook TARGET_ALLOCATE_STACK_SLOTS_FOR_ARGS that is
> intended to cater that case.  For example, the documentation
> indicates it only works with optimization turned off.  But I don't
> know how reliable it is in general.  For avr target it works as
> expected.
> 
> https://gcc.gnu.org/onlinedocs/gccint/Misc.html#index-TARGET_005fALLOCATE_005fSTACK_005fSLOTS_005fFOR_005fARGS-4969

It's still a bug for now. That hook is there because we've allowed 
bad code to exist for so long that at this point we must for legacy
reasons allow some type of input arguments in the asm. However, that
doesn't mean we should actively promote this feature or let users
use it (until we fix it).

Ideally you do want to use the named input arguments as "r" types to
avoid needing to know the exact registers used in the call sequence.
Referencing the variables by name and letting gcc emit the right
register is useful, but only if it works consistently and today it
doesn't.

Features that fail to work depending on the optimization level should
not be promoted in the documentation. We should document what works
and file bugs or fix what doesn't work.

Cheers,
Carlos.

Re: glibc-2.2{8,9} multiarch build failure on x86_64 with gcc 9

[Carlos O'Donell]

On 5/1/19 2:24 PM, Arvind Sankar wrote:

gcc 9 when configured for fortran installs ISO_Fortran_Binding.h in
gfor_cdir = 
$(libdir)/gcc/$(target_alias)/$(gcc_version)$(MULTISUBDIR)/include
For x86_64's 32-bit architecture support, this creates a subdirectory named 
'include'
inside $(libsubdir)/32 which didn't use to exist in gcc 8.

This doesn't seem correct.

I would have expected the header to exist under the target name, for example:

/usr/lib/gcc/i686-redhat-linux/9/include/ISO_Fortran_binding.h

This way it doesn't conflict with other uses.

Perhaps there is enough variability in the way you build, package, and install 
this
that it can break in some configurations.

I think the gcc community needs to comment on this.

--
Cheers,
Carlos.

Public discussions on GNU Project governance.

[Carlos O'Donell]

GNU Maintainers, developers, volunteers, etc.,

This relates to all of our projects and how they operate. Please take
a minute and look over this email.

This is an invitation to a public discussion about GNU Project governance 
by GNU maintainers, developers, volunteers, etc.

Discussions will take place on a moderated mailing list gnu-misc-discuss:
https://lists.gnu.org/mailman/listinfo/gnu-misc-discuss

Mark Wielaard has kicked this off with a post about his ideas:
https://lists.gnu.org/archive/html/gnu-misc-discuss/2019-10/msg2.html

Please feel free to post your own ideas and opinions about governance
and how it relates to the GNU Project.

Please keep the conversations kind [1] and strictly about governance and
not about specific people and their respective abilities. If you need an 
example: "Carlos O'Donell is an aweful leader and speller" is off-topic,
but "I would like an autocratic model where we have one leader for life
who passes this on to the next leader" is on-topic.

If you have any questions please don't hesitate to ask me.

-- 
Cheers,
Carlos.

[1] https://www.gnu.org/philosophy/kind-communication.html

Setting up a wiki for GNU Project volunteers?

[Carlos O'Donell]

A wiki for GNU Project volunteers would provide a central place
for cross-project collaboration, including collaboration between
gcc, glibc, gdb, and binutils.

This is an invitation to discuss having a high-level wiki for
GNU Project volunteers.

The conversation is on gnu-misc-discuss:
https://lists.gnu.org/archive/html/gnu-misc-discuss/2019-12/msg2.html

Please feel free to send me your input directly if you like.

Thank you for your input.

-- 
Cheers,
Carlos.

Re: RFC: Add ___tls_get_addr

[Carlos O'Donell]

On 07/05/2017 11:38 AM, H.J. Lu wrote:
> On x86-64, __tls_get_addr has to realigns stack so that binaries compiled by
> GCCs older than GCC 4.9.4:
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58066
> 
> continue to work even if vector instructions are used by functions called
> from __tls_get_addr, which assumes 16-byte stack alignment as specified
> by x86-64 psABI.
> 
> We are considering to add an alternative interface, ___tls_get_addr, to
> glibc, which doesn't realign stack.  Compilers, which properly align stack
> for TLS, call generate call to ___tls_get_addr, instead of __tls_get_addr,
> if ___tls_get_addr is available.
> 
> Any comments?

Overall I agree with the idea.

However, the triple underscore will lead to eventual human error, can we
avoid that error by changing the name in an meaningful way? I don't care
what you choose really.

-- 
Cheers,
Carlos.

Re: RFC: Add ___tls_get_addr

[Carlos O'Donell]

On 07/05/2017 12:02 PM, Rich Felker wrote:
> Note that if you make the change and have gcc generate calls to the
> new ___tls_get_addr symbol, it's going to be problematic for people
> trying to link to older glibc versions that don't have it.

This is a normal problem to have, and there are solutions for this.

As you ask, the real question is: Is it necessary?

-- 
Cheers,
Carlos.

Re: GNU Tools Cauldron 2017 follow up: "Reviewed-by" etc.

[Carlos O'Donell]

On 09/21/2017 10:50 AM, Thomas Schwinge wrote:
> So my question is, if I've gotten a patch reviewed by someone who is not
> yet ;-) familiar with that new process, and I nevertheless want to
> acknowledge their time invested in review by putting "Reviewed-by" into
> the commit log, is it fine to do that if the reviewer just answered with
> "OK" (or similar) instead of an explicit "Reviewed-by: NAME "
> statement?
You should instead ask the author to give their "Reviewed-by:" and point
out what the Reviewed-by statement means.

> That is, is it fine to assume that our current patch review's standard
> "OK" (or similar) answer matches the more formal "Reviewer's statement of
> oversight"?

Not yet.

> Maybe in the future, reviewers will then switch over to explicitly
> stating "Reviewed-by: NAME " -- or maybe not, because "OK" is just
> so much easier to type...

All of this is nothing compared to the work of doing the review.

It will be your own personal comments, your reminder, your leading by 
example, that will change behaviours.

-- 
Cheers,
Carlos.

Re: GNU Tools Cauldron 2017 follow up: "Reviewed-by" etc.

[Carlos O'Donell]

On 09/21/2017 11:56 AM, Richard Biener wrote:
>> Not yet.
> 
> I think given an OK from an official reviewer entitles you to commit
> it indeed IS matching the formal statement. It better does...

Isn't it better to be explicit about this; rather than assuming?

>> All of this is nothing compared to the work of doing the review.
> 
> Depends on the complexity of the patch...  

... depends on your ability to create quick paste hot keys :}

-- 
Cheers,
Carlos.

Re: GNU Tools Cauldron 2017 follow up: "Reviewed-by" etc.

[Carlos O'Donell]

On 09/21/2017 12:38 PM, Richard Biener wrote:
> On September 21, 2017 8:18:39 PM GMT+02:00, Carlos O'Donell 
>  wrote:
>> On 09/21/2017 11:56 AM, Richard Biener wrote:
>>>> Not yet.
>>>
>>> I think given an OK from an official reviewer entitles you to commit
>>> it indeed IS matching the formal statement. It better does...
>>
>> Isn't it better to be explicit about this; rather than assuming?
>>
>>>> All of this is nothing compared to the work of doing the review.
>>>
>>> Depends on the complexity of the patch...  
>>
>> ... depends on your ability to create quick paste hot keys :}
> 
> Indeed. Any idea how to do that with K9 / SwiftKey? 

No idea. Right now I use Thunderbird+Clippings, and hotkey my responses
via ctrl+alt+v,r and ctrl+alt+v,s for Reviewed-by/Signed-off-by. Then
with mutt+vim I use recorded macros.

-- 
Cheers,
Carlos.

Re: GNU Tools Cauldron 2017 follow up: "Reviewed-by" etc.

[Carlos O'Donell]

On 10/19/2017 08:57 AM, Thomas Schwinge wrote:
> Hi!
> 
> Still waiting for any kind of reaction -- general process-change inertia,
> chicken-and-egg problem, I suppose.  ;-/
> 
> I have now put the proposed text onto a wiki page, so that those
> interested have a convenient handle to use,
> <https://gcc.gnu.org/wiki/Reviewed-by>.

I've started using Reviewed-by: Carlos O'Donell 
and Signed-off-by: Carlos O'Donell  in all my
glibc reviews.

Since then I've seen 5 such items go into the git commit messages.

Progress? :-)

-- 
Cheers,
Carlos.

Re: GNU Tools Cauldron 2017 follow up: "Reviewed-by" etc.

[Carlos O'Donell]

On 10/19/2017 09:45 AM, Joseph Myers wrote:
> On Thu, 19 Oct 2017, Thomas Schwinge wrote:
> 
>> Hi!
>>
>> Still waiting for any kind of reaction -- general process-change inertia,
>> chicken-and-egg problem, I suppose.  ;-/
>>
>> I have now put the proposed text onto a wiki page, so that those
>> interested have a convenient handle to use,
>> .
> 
> That wiki page refers to Reviewed-by as being about crediting reviewers.  
> But the specification appears to be oriented to something else entirely 
> (i.e. convincing a committer - in a Linux-kernel-like context with a very 
> limited set of committers to a particular tree, much smaller than the set 
> of reviewers - that a patch is worthy of commit).  It doesn't cover 
> reviews that request changes, or only relate to part of a patch, or relate 
> to a previous version of a patch - only the limited special case of a 
> review approving the entirety of a patch as posted.  If the aim is credit, 
> a substantially different specification is needed.
 
This is the purpose of Acked-by: ...

Which we could also include.

linux/Documentation/process/submitting-patches.rst
...

Acked-by: does not necessarily indicate acknowledgement of the entire patch.
For example, if a patch affects multiple subsystems and has an Acked-by: from
one subsystem maintainer then this usually indicates acknowledgement of just
the part which affects that maintainer's code.  Judgement should be used here.
When in doubt people should refer to the original discussion in the mailing
list archives.

...

-- 
Cheers,
Carlos.

Re: GNU Tools Cauldron 2017 follow up: "Reviewed-by" etc.

[Carlos O'Donell]

On 10/19/2017 09:45 AM, Joseph Myers wrote:
> On Thu, 19 Oct 2017, Thomas Schwinge wrote:
> 
>> Hi!
>>
>> Still waiting for any kind of reaction -- general process-change inertia,
>> chicken-and-egg problem, I suppose.  ;-/
>>
>> I have now put the proposed text onto a wiki page, so that those
>> interested have a convenient handle to use,
>> .
> 
> That wiki page refers to Reviewed-by as being about crediting reviewers.  
> But the specification appears to be oriented to something else entirely 
> (i.e. convincing a committer - in a Linux-kernel-like context with a very 
> limited set of committers to a particular tree, much smaller than the set 
> of reviewers - that a patch is worthy of commit).  It doesn't cover 
> reviews that request changes, or only relate to part of a patch, or relate 
> to a previous version of a patch - only the limited special case of a 
> review approving the entirety of a patch as posted.  If the aim is credit, 
> a substantially different specification is needed.
 
If a person is requesting changes, they should after accepting the changes,
submit a 'Reviewed-by:' tag or 'Acked-by:' tag to indicate they are happy
with the results?

-- 
Cheers,
Carlos.

Searching configured and relocated prefix.

[Carlos O'Donell]

GCC,

We currently search both the relocated compilers prefix and the
originally configured prefix. Should a relocated compiler be searching
both directories?

Does anyone see a need to search *both* the configured prefix and the
relocated prefix?  You can end up finding things you don't mean to find,
you can get NFS time-outs, etc.

However, the strategy above will break situations where people expect to
find some of their bits in a directory indicated by GCC_EXEC_PREFIX, and
the rest in the configured prefix.  

Cheers,
Carlos.
-- 
Carlos O'Donell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x716

Re: Bootstrap broken on ppc-darwin

[Carlos O'Donell]

On Sun, Jul 16, 2006 at 06:05:32PM -0700, Ian Lance Taylor wrote:
> Andrew Pinski <[EMAIL PROTECTED]> writes:
> 
> > Here we have the same scope_labelno.  The first dbxout_begin_prologue
> > comes from calling rs6000_output_mi_thunk.  The normal way
> > scope_labelno gets incremented is via the
> > call to debug_hooks->function_decl in rest_of_handle_final which is
> > not done for thunks.
> > I don't know if we should call debug_hooks->function_decl for thunks
> > or not.
> 
> We shouldn't.  It doesn't make sense, since there is no proper
> current_function_decl for a thunk.

OK.
 
> Previously, scope_labelno was referenced in dbxout_block and
> incremented in dbxout_function_end.  Both functions are called only by
> dbxout_function_decl (a debug hook).  So it was always consistent.

Yes, that's correct.

> Now scope_labelno is used by dbxout_begin_prologue and
> dbxout_source_line.  Those are both debug hooks themselves.  So this
> patch has introduced a dependency which was not previously there,
> which has led to a bug.

Sorry about that, I tried to make sure that scope_labelno was
consistent.

> There are several ways to fix this, of course.  I think the simplest
> is going to be to always preincrement scope_labelno in
> dbxout_begin_prologue, rather than postincrementing it in
> dbxout_function_end.  In cases where that fails, we are already in
> trouble.

I'm testing a patch for this right now.

> Note that scope_labelno is now used for two different things: for the
> LFBB symbol, and for the Lscope symbol.  It does not have to be used
> for both, although as far as I can see it does no harm.

Using scope_labelno for both cases made the patch clearer. I wanted the
patch to be as simple as possible.

Sorry I missed thinking about the thunks.

I'll get back ASAP when my current patch finishes testing.

Cheers,
Carlos.
-- 
Carlos O'Donell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x716

Re: Bootstrap broken on ppc-darwin

[Carlos O'Donell]

On Sun, Jul 16, 2006 at 06:05:32PM -0700, Ian Lance Taylor wrote:
> Previously, scope_labelno was referenced in dbxout_block and
> incremented in dbxout_function_end.  Both functions are called only by
> dbxout_function_decl (a debug hook).  So it was always consistent.
> 
> Now scope_labelno is used by dbxout_begin_prologue and
> dbxout_source_line.  Those are both debug hooks themselves.  So this
> patch has introduced a dependency which was not previously there,
> which has led to a bug.
> 
> There are several ways to fix this, of course.  I think the simplest
> is going to be to always preincrement scope_labelno in
> dbxout_begin_prologue, rather than postincrementing it in
> dbxout_function_end.  In cases where that fails, we are already in
> trouble.
> 
> Note that scope_labelno is now used for two different things: for the
> LFBB symbol, and for the Lscope symbol.  It does not have to be used
> for both, although as far as I can see it does no harm.

The following patch does a pre-increment of scope_labelno in
dbxout_begin_prologue.

No regressions on arm-none-eabi, and I verified the output stabs by
hand. The .Lscope and .LFBB labels start at 1, and increment for each
call to dbxout_begin_prologue.

Andrew, I built a powerpc-darwin cross compiler and manually verified
the output assembly from your testcase. It looks like it should fix your
problem. I don't see any repeated LFBB symbols, where previously I saw
repeated LFBB1 and LFBB4 due to the thunks.

OK to commit? 

Cheers,
Carlos.
-- 
Carlos O'Donell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x716

2006-07-17  Carlos O'Donell  <[EMAIL PROTECTED]>

* dbxout.c (dbxout_function_end): Do not increment scope_labelno.
(dbxout_begin_prologue): Increment scope_labelno.

Index: gcc/dbxout.c
===
--- gcc/dbxout.c(revision 115532)
+++ gcc/dbxout.c(working copy)
@@ -905,7 +905,6 @@ static void
 dbxout_function_end (tree decl)
 {
   char lscope_label_name[100];
-  int lscope_labelno = scope_labelno++;
 
   /* The Lscope label must be emitted even if we aren't doing anything
  else; dbxout_block needs it.  */
@@ -914,8 +913,8 @@ dbxout_function_end (tree decl)
   /* Convert Lscope into the appropriate format for local labels in case
  the system doesn't insert underscores in front of user generated
  labels.  */
-  ASM_GENERATE_INTERNAL_LABEL (lscope_label_name, "Lscope", lscope_labelno);
-  targetm.asm_out.internal_label (asm_out_file, "Lscope", lscope_labelno);
+  ASM_GENERATE_INTERNAL_LABEL (lscope_label_name, "Lscope", scope_labelno);
+  targetm.asm_out.internal_label (asm_out_file, "Lscope", scope_labelno);
 
   /* The N_FUN tag at the end of the function is a GNU extension,
  which may be undesirable, and is unnecessary if we do not have
@@ -941,7 +940,7 @@ dbxout_function_end (tree decl)
 {
   char begin_label[20];
   /* Reference current function start using LFBB.  */
-  ASM_GENERATE_INTERNAL_LABEL (begin_label, "LFBB", lscope_labelno);
+  ASM_GENERATE_INTERNAL_LABEL (begin_label, "LFBB", scope_labelno);
   dbxout_begin_empty_stabs (N_FUN);
   dbxout_stab_value_label_diff (lscope_label_name, begin_label);
 }
@@ -1249,6 +1248,9 @@ dbxout_begin_prologue (unsigned int line
   && !flag_debug_only_used_symbols)
 dbxout_stabd (N_BNSYM, 0);
 
+  /* pre-increment the scope counter */
+  scope_labelno++;
+
   dbxout_source_line (lineno, filename);
   /* Output function begin block at function scope, referenced 
  by dbxout_block, dbxout_source_line and dbxout_function_end.  */

Re: Imported GNU Classpath 0.92

[Carlos O'Donell]

On Tue, Aug 15, 2006 at 01:18:55AM +0200, Mark Wielaard wrote:
> GNU Classpath 0.92 was released last week. It contains a lot of new
> standard library classes and bug fixes. See
> http://savannah.gnu.org/forum/forum.php?forum_id=4573
> And the list of fixed bugs:
> http://gcc.gnu.org/bugzilla/buglist.cgi?product=classpath&target_milestone=0.92
> 
> This version has been imported now into the libjava directory on the
> trunk. It has been tested on a variety of platforms. But if we missed
> something please let us know ([EMAIL PROTECTED]).

Has the 'make html' target been fixed? I would like to enable this
target so that html support doesn't bitrot.

Cheers,
Carlos.
-- 
Carlos O'Donell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x716

Re: Imported GNU Classpath 0.92

[Carlos O'Donell]

On Wed, Aug 23, 2006 at 08:47:32AM +0200, Mark Wielaard wrote:
> On Tue, 2006-08-22 at 16:33 -0400, Carlos O'Donell wrote:
> > Has the 'make html' target been fixed? I would like to enable this
> > target so that html support doesn't bitrot.
> 
> No sorry. I didn't know it was broken. I see that it only works when
> configuring with --with-gjdoc. If there is already a bug report about
> this could you assign it to me?

There isn't a pr about this, I'll file one now. Thanks Mark.

Filed as pr28822.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28822

Cheers,
Carlos.
-- 
Carlos O'Donell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x716

pr27650 - dllimport of virtual methods broken.

[Carlos O'Donell]

Is any of you able to give some comments on pr27650

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27650

In particular I am interested in an opinion of Danny's fix.

http://gcc.gnu.org/ml/gcc-patches/2006-05/msg01504.html

I definately don't know enough about attributes and dllimport to
comment. The fix works, but is it correct?

Cheers,
Carlos.
-- 
Carlos O'Donell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x716

Re: pr27650 - dllimport of virtual methods broken.

[Carlos O'Donell]

On Tue, Sep 19, 2006 at 10:09:49AM +1200, Danny Smith wrote:
> Revised patch. 

Thanks Danny!
 
> Tested on i686-pc-mingw32
> 
> Danny
> 
> cp/ChangeLog
> 
>   PR target/27650
>   * class.c (check_for_override): Remove dllimport from virtual
>   methods.
> 
> testsuite/Changelog
>   PR target/27650
>   * g++.dg/ext/dllimport12.C: New file.

Mark,

What is your opinion on this patch?

Cheers,
Carlos.
-- 
Carlos O'Donell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x716

Re: [Patches] C++ linking problem when locale are disabled in eglic.

[Carlos O'Donell]

On Tue, Mar 13, 2012 at 6:43 AM, Jonathan Wakely  wrote:
>> This should have been CC'd to the libstdc++ list too.
>>
>>> C++ programs don't link anymore with gcc > 4.5.3 and eglibc 2.15 with 
>>> OPTION_EGLIBC_LOCALE_CODE=n.
>>>
>>> It seems that gcc/libstdc++-v3/acinclude.m4 doesn't check for bugs in early 
>>> glibc-2.2.x series anymore. So, it doesn't detect the lack of newlocale, 
>>> duplocale, freelocale, nl_langinfo_l and uselocale. On the other hand, 
>>> there is a new test for the presence of uclibc (!defined(__UCLIBC__)).
>>>
>>> I solved the problem with the '--enable-clocale=generic' option when 
>>> configuring gcc.
>>>
>>> So my question to the gcc team is : "should gcc detect the lack of these 
>>> functions with eglibc" , or using --enable-clocale=generic is the good 
>>> practice ?
>>
>> Ideally, yes.
>
> That wasn't very clear, sorry. I meant that ideally libstdc++ would
> detect the lack of the functions.  In the absence of that detection
> --enable-clocale=generic is a reasonable workaround.

As a glibc maintainer I agree with Jonathan's general statements.
We need the help of the developer community to test the various
configurations and patches are always welcome.

Cheers,
Carlos.

History of m68k ABI and `-malign-int'?

[Carlos O'Donell]

Andreas, Jeff,

The documentation for `-malign-int' on m68k hints that 16-bit int
alignment was the prominent alignment chosen by m68k ABI's of the era.

Why is 16-bit int alignment the default for m68k in gcc?

Which ABIs influenced this decision?

Should Coldfire targets default to 16 or 32-bit int alignment?

Cheers,
Carlos.
-- 
Carlos O'Donell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x716

Re: History of m68k ABI and `-malign-int'?

[Carlos O'Donell]

On Thu, Jan 17, 2008 at 01:08:16AM +0100, Andreas Schwab wrote:
> Carlos O'Donell <[EMAIL PROTECTED]> writes:
> 
> > Why is 16-bit int alignment the default for m68k in gcc?
> >
> > Which ABIs influenced this decision?
> 
> The original ABI was defined by Sun PCC.  Note that the SysV ABI
> actually uses natural alignment for all types, but that came only much
> later.
> 
> You can find much of the history in the change logs of gcc 1.42.

Excellent, that scratches my itch, thanks for providing a history lesson
and a good pointer.

Cheers,
Carlos.
-- 
Carlos O'Donell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x716

Re: Possible GCC 4.3 driver regression caused by your patch

[Carlos O'Donell]

Greg Schafer wrote:

Hi Carlos and Mark,

Your "Relocated compiler should not look in $prefix" patch here:

http://gcc.gnu.org/ml/gcc/2006-10/msg00280.html

appears to have caused a regression in my GCC 4.3 testing.

In summary, there is a small window *during the GCC build itself* where GCC
does not pick up the correct startfiles. For example, when GCC_FOR_TARGET is
called to build the target libraries, the startfiles in $prefix/lib are not
used. Instead, the startfiles from the host's /usr/lib are used which breaks
my build. Note that the problem seems to rectify itself once the just-built
GCC is installed into $prefix.

Here's the scenario:

 - Native build
 - i686-pc-linux-gnu
 - --prefix=/temptools
 - Glibc already installed in /temptools/lib


What options did you use to configure the compiler? Could you double 
check your host system is actually i686-pc-linux-gnu? When you say 
"breaks my build", what error are you seeing?


Cheers,
Carlos.
--
Carlos O'Donell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x716

[RFC] Implementation and documentation of -iwithprefix do not match?

[Carlos O'Donell]

The GCC option -iwithprefix does not match the documentation.

Is there any reason for this discrepancy?

The GCC option -iwithprefix is documented in gcc/doc/cppopts.texi

@item -iwithprefix @var{dir}
@itemx -iwithprefixbefore @var{dir}
@opindex iwithprefix
@opindex iwithprefixbefore
Append @var{dir} to the prefix specified previously with
@option{-iprefix}, and add the resulting directory to the include search
path.  @option{-iwithprefixbefore} puts it in the same place @option{-I}
would; @option{-iwithprefix} puts it where @option{-idirafter} would.

However, -iwithprefix does not put the search path where -idirafter 
would, instead it puts the search path at the top of the SYSTEM chain.


See gcc/c-opts.c:
...
case OPT_idirafter:
  add_path (xstrdup (arg), AFTER, 0, true);
  break;
...
case OPT_iwithprefix:
  add_prefixed_path (arg, SYSTEM);
  break;

The order of the compilers SYSTEM paths is important to the correct 
processing of C++ header #include_next macros.


If you use -iwithprefix to modify the compilers -iprefix path to define 
a header that matches a SYSTEM header, the compiler removes the 
redundant SYSTEM path definition and leaves the one generated by 
-iwithprefix (it's the same path just in a different search order). 
However, since -iwithprefix moved the header definition to the *top* of 
the search list, when #include_next is used, it may result in a missing 
header.


If -iwithprefix implemented what was documented, then it appears that 
there would be no issue.


Cheers,
Carlos.
--
Carlos O'Donell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x716

Re: Separate commit mailing lists for trunk/branches possible?

[Carlos O'Donell via Gcc]

On 7/17/20 2:11 PM, Frank Ch. Eigler via Overseers wrote:
> Hi -
> 
>> Would it be reasonable to have the mailing list split into more than
>> one, that is at least the original covering the trunk, and then one
>> or more for branches?  [...]
> 
> (This matter is for the gcc community to decide.  Overseers do not
> control git/mailing list traffic policy.)
> 
> 
> - FChE
> 

FYI, for glibc we use the AdaCore git commit hooks (like gdb).

There we use this configuration:

# Only send emails for master and release branches.
no-emails = refs/heads/(?!master|release.*)

This way you don't get vendor branch commit emails.

-- 
Cheers,
Carlos.

Re: Separate commit mailing lists for trunk/branches possible?

[Carlos O'Donell via Gcc]

On 7/17/20 3:41 PM, Florian Weimer wrote:
> * Carlos O'Donell via Gcc:
> 
>> FYI, for glibc we use the AdaCore git commit hooks (like gdb).
>>
>> There we use this configuration:
>>
>> # Only send emails for master and release branches.
>> no-emails = refs/heads/(?!master|release.*)
>>
>> This way you don't get vendor branch commit emails.
> 
> I think this only affects the Bugzilla gateway (which is broken anyway
> because it doesn't extract bug numbers from the commit subject).

I thought it was affecting everything. It sure looks like the infrastructure
intends it to be that way? See hooks/updates/__init__.py 
(send_email_notification)
which is used by post_receive.py driven by post-receive.

However you are right, even since April 15th 2020 when you and I switched
to the AdaCore git commit hooks it appears to have continued to allow
commits to vendor branches to get posted to glibc-cvs.

The IRC irker has a clear filter: refs/heads/master|refs/heads/release/*,
but the irker doesn't seem to be working either.
 
> Anyway, there are a ton of commit notifications for personal branches:
> 
>   <https://sourceware.org/pipermail/glibc-cvs/2020q3/thread.html>
 
Let me raise this on the list.

-- 
Cheers,
Carlos.

Re: New x86-64 micro-architecture levels

[Carlos O'Donell via Gcc]

On 7/22/20 5:26 AM, Richard Biener via Libc-alpha wrote:
> So for the bike-shedding I indeed think x86-10{0,1,2,3}
> or x86-{A,B,C,..}, eventually duplicating as x86_64- as
> suggested by Jan is better than x86-2014 or x86-avx2.

Agreed. If we really want to be clear, call it a "level"
or something else that has a direct English meaning
e.g. x86-level-101. This makes it unambiguously clear
that this is some kind of step at which some kind of
features are enabled.

-- 
Cheers,
Carlos.

Re: New x86-64 micro-architecture levels

[Carlos O'Donell via Gcc]

On 7/22/20 6:34 AM, Florian Weimer wrote:
> * Jan Beulich:
> 
>> On 21.07.2020 20:04, Florian Weimer wrote:
>>> * Premachandra Mallappa:
>>> 
 [AMD Public Use]
 
 Hi Floarian,
 
> I'm including a proposal for the levels below.  I use single
> letters for them, but I expect that the concrete
> implementation of this proposal will use names like
> “x86-100”, “x86-101”, like in the glibc patch referenced
> above.  (But we can discuss other approaches.)
 
 Personally I am not a big fan of this, for 2 reasons 1. uses
 just x86 in name on x86_64 as well
>>> 
>>> That's deliberate, so that we can use the same x86-* names for
>>> 32-bit library selection (once we define matching
>>> micro-architecture levels there).
>> 
>> While indeed I did understand it to be deliberate, in the light of 
>> 64-bit only ISA extensions (like AMX, and I suspect we're going to 
>> see more) I nevertheless think Premachandra has a point here.
> 
> Let me explain how I ended up there.  Maybe I'm wrong.

I did a review of your analysis, and it is my opinion that your
conclusion is correct.

> Previously, I observed that it is difficult to set LD_PRELOAD and 
> LD_LIBRARY_PATH on combined x86-64/i386 systems, so that the right 
> libraries are loaded for both variants, and users aren't confused by 
> dynamic linker warning messages.  On some systems, it is possible to
> use dynamic string tokens ($LIB), but not all.

The case of LD_PRELOAD is the most difficult because it is a direct request
to the dynamic loader to load a particular library. If the library to be
loaded is an absolute path then you'll always get warning messages if you
need to execute child processes that inherited LD_PRELOAD for an architecture
that doesn't match the architecture to be executed.

The case of LD_LIBRARY_PATH is generally less troublesome because you are
adding search paths, and the library loading can be suppressed by other
mechanisms that include search path pruning.

It is also possible that $LIB does not match what is actually required
for the system to operate correctly and it depends on /etc/ld.so.conf
(and included files) for correctness (despite it being a cache, see
glibc bug 22359). This is an ISV problem that the ISV can solve.

> Eventually, it will be possible to add and restrict glibc-hwcaps 
> subdirectories by setting an environment variable.  The original
> patch series only contains ld.so command line options because I
> wanted to avoid a discussion about the precise mechanism for setting
> the environment variable (current glibc has two approaches).  But the
> desire to provide this functionality is there: for adding additional 
> glibc-hwcaps subdirectories to be searched first, and for
> restricting selection to a subset of the built-in
> (automatically-selected) subdirectories.

If you allow the addition of subdirectories, those subdirectories
can then be processed as directories are normally processed and we
can indeed avoid emitting an error message. The addition of directories
is not a direct request to the loader to load a specific shared object.

> I was worried that we would run into the same problem as with 
> LD_PRELOAD, where x86-64 and i386 binaries may have different 
> requirements.  I wanted to minimize the conflict by sharing the
> names (eventually, once we have 32-bit variants).

Right, this would make it easier to deploy from the ISV side.

> But thinking about this again, I'm not sure if my worry is
> warranted. The main selection criteria is still the library load
> path, and that is already provided by some different means (e.g.
> $LIB).  Within the library path, there is the glibc-hwcaps
> subdirectory, but since it is nested under a specific library path
> subdirectory (determined by the architecture), adding subdirectories
> to be searched which do not exist on the file system, or surpressing
> directories which would not be searched in the first place, is not a
> problem.  The situation is completely benign and would not warrant
> any error message from the dynamic loader.

I agree completely.
 
> If this analysis is correct, there is no reason to share the 
> subdirectory names between x86-64 and i386 binaries, and we can put
> “64” somewhere in the x86-64 strings.

We can choose not to share the paths. In fact it may make it easier to
explain to users that they are distinct.

In summary:

The conclusion is that x86-64 and i386 shared objects can use different
directories because they are just search paths, and such search paths
have different semantics from explicit load requests like LD_PRELOAD,
therefore they can be suppressed at runtime without the need to issue
an error or warning diagnostic.

Notes:
- We may wish to have an LD_DEBUG settings that helps catch issues
  with various paths, but that's a diagnostic settings whose semantics
  we can iron out as we discover developers making bad choices.

-- 
Cheers,
Carlos.

The official glibc IRC channel is now on OFTC as #glibc.

[Carlos O'Donell via Gcc]

Community,

The official glibc IRC channel is now on OFTC as #glibc.

gcc developers, please feel free to visit #glibc :-)

We also have an unofficial IRC channel #glibc on Libera.Chat

-- 
Cheers,
Carlos.

Re: https://patchwork.sourceware.org/project/gcc/

[Carlos O'Donell via Gcc]

On 9/29/21 07:22, Jonathan Wakely wrote:
> On Wed, 29 Sept 2021 at 11:04, Thomas Schwinge  
> wrote:
>> Also, we'll need some user guide: web page, or wiki page, or,
>> preferably?, on  itself.
>> How are we using the different states, archived, bundles, etc.
> 
> Good idea ... care to write it? :-)
> 
>> I bet Carlos and team have all this sorted out for glibc already, so we
>> may "just" copy that for GCC?  ;-P
 
Quick reply.

1. Thomas now has gcc project permission.

2. See glibc's notes:
https://sourceware.org/glibc/wiki/Patch%20Review%20Workflow


-- 
Cheers,
Carlos.

RFP is open for the Toolchains and Kernel Track at LPC 2022

[Carlos O'Donell via Gcc]

The Linux Plumbers Conference 2022 (https://lpc.events) will be held
from 12 to 14 of September 2022 in Dublin.

As part of the conference we will be having a Toolchains and Kernel
track that will focus on topics of interest related to building the
Linux kernel, and kernel development in general. The goal is to get
kernel developers and toolchain developers together to discuss
outstanding or upcoming issues, feature requests, and further
collaboration.

Here we are calling for activity proposals for the track.

Note that LPC "activities" are not quite the same than regular talks as
they are found in most other free software events.  The activities shall
be related to the Linux kernel and should focus on some particular
toolchain problem, or issue, or proposed enhancement, that require or
would benefit from the input of kernel hackers.  The pursued outcome of
the activity shall not be some vague directions or promises of future
work and/or collaboration: you should aim to discuss and agree on the
spot using the fact the kernel hackers will be present.  The duration of
each activity depends on its nature and on how it actually develops:
some discussions will require just a few minutes, while others may
require more time.  However, it would be useful if you specify an
estimation of how much time you expect your activity will require; that
will help us in the scheduling. Slides are actually discouraged, so
please try to keep them at a minimum, the ideal is just one or two
slides to establish the context for the discussion.

As a reference, these are some of the topics that we would like to cover
this year:

Upstreaming Rust Support
Toolchain security feature requests
BPF/BTF support in the GNU Toolchain
Kernel Control Flow Integrity
PGO, AutoFDO, gprofng, perf
sysroots on kernel.org
hardware mitigation post mortems
Kernel debugging with drgn and poke+gdb
ABI analysis
GCC -fanalyzer
Fast Kernel Headers

If you are interested in proposing an activity, please use the online
form at the event website: https://lpc.events/event/16/abstracts/

Please make sure you use the submission form for the Toolchains track.

The CFP closes the 15th of August.  We will announce the approved
activities and publish the schedule of the track shortly after that.

[Thanks to Jose Marchesi and Nick Nick Desaulniers for organizing!]
-- 
Cheers,
Carlos.

Office Hours for the GNU Toolchain on October 17th at 11am EDT.

[Carlos O'Donell via Gcc]

Office Hours for the GNU Toolchain on October 17th at 11am EDT.

Agenda: 
 * First Office Hours and test of the meeting system.
 * No specific agenda will be presented, but feel free to attend.

Meeting Link:
 * https://bbb.linuxfoundation.org/room/adm-xcb-for-sk6

-- 
Cheers,
Carlos.

Re: Checks that autotools generated files were re-generated correctly

[Carlos O'Donell via Gcc]

On 11/7/23 02:38, Maxim Kuvyrkov wrote:
>> On Nov 6, 2023, at 21:19, Christophe Lyon
>>  wrote:
>> 
>> Hi!
>> 
>> On Mon, 6 Nov 2023 at 18:05, Martin Jambor 
>> wrote:
>>> 
>>> Hello,
>>> 
>>> I have inherited Martin Liška's buildbot script that checks that
>>> all sorts of autotools generated files, mainly configure scripts,
>>> were re-generated correctly when appropriate.  While the checks
>>> are hopefully useful, they report issues surprisingly often and
>>> reporting them feels especially unproductive.
>>> 
>>> Could such checks be added to our server side push hooks so that
>>> commits introducing these breakages would get refused
>>> automatically.  While the check might be a bit expensive, it only
>>> needs to be run on files touching the generated files and/or the
>>> files these are generated from.

$0.02.

We should move in a direction where all server side push hooks removed.

Removing the hooks allows for easy repo replication, and sharing load.

Such checks should all be moved IMO into pre-commit CI, or post-commit CI.

>>> Alternatively, Maxim, you seem to have an infrastructure that is
>>> capable of sending email.  Would you consider adding the check to
>>> your buildbot instance and report issues automatically?  The
>>> level of totally
>> 
>> After the discussions we had during Cauldron, I actually thought
>> we should add such a bot.
>> 
>> Initially I was thinking about adding this as a "precommit" check,
>> to make sure the autogenerated files were submitted correctly, but
>> I realized that the policy is actually not to send autogenerated
>> files as part of the patch (thus making pre-commit check
>> impracticable in such cases, unless we autogenerate those files
>> after applying the patch)
>> 
>> I understand you mean to run this as a post-commit bot, meaning we 
>> would continue to "accept" broken commits, but now automatically
>> send a notification, asking for a prompt fix?
>> 
>> We can probably implement that, indeed. Is that the general
>> agreement?
> 
> [CC: Siddhesh, Carlos]
> 
> Hi Martin,
> 
> I agree with Christophe, and we can add various source-level checks
> and wrap them up as a post-commit job.  The job will then send out
> email reports to developers whose patches failed it.

This is a great way to handle this until we have more consensus around other
kinds of worfklows.

> Where the current script is located?  These checks would be useful
> for all GNU Toolchain projects -- binutils/GDB, GCC, Glibc and,
> maybe, Newlib -- so it would be useful to put it in a separate
> "gnutools" repo.  I think Siddhesh and Carlos are looking into
> creating such a repo on gitlab?

I can make any repo we want here:

https://gitlab.com/gnutools

-- 
Cheers,
Carlos.

Office Hours for the GNU Toolchain on 2023-11-30 at 11am EST5EDT.

[Carlos O'Donell via Gcc]

Office Hours for the GNU Toolchain on 2023-11-30 at 11am EST5EDT.

Agenda: 
 * https://gcc.gnu.org/wiki/OfficeHours#Next

Meeting Link:
 * https://bbb.linuxfoundation.org/room/adm-xcb-for-sk6

-- 
Cheers,
Carlos.

Office Hours for the GNU Toolchain on 2024-01-25 at 11am EST5EDT.

[Carlos O'Donell via Gcc]

Office Hours for the GNU Toolchain on 2024-01-25 at 11am EST5EDT.

Agenda:
* https://gcc.gnu.org/wiki/OfficeHours#Next

Meeting Link:
* https://bbb.linuxfoundation.org/room/adm-xcb-for-sk6

-- 
Cheers,
Carlos.

Re: New TLS usage in libgcc_s.so.1, compatibility impact

[Carlos O'Donell via Gcc]

On 1/15/24 08:55, Adhemerval Zanella Netto wrote:
> 
> 
> On 15/01/24 09:46, Szabolcs Nagy wrote:
>> The 01/13/2024 13:49, Florian Weimer wrote:
>>> This commit
>>>
>>> commit 8abddb187b33480d8827f44ec655f45734a1749d
>>> Author: Andrew Burgess 
>>> Date:   Sat Aug 5 14:31:06 2023 +0200
>>>
>>> libgcc: support heap-based trampolines
>>> 
>>> Add support for heap-based trampolines on x86_64-linux, aarch64-linux,
>>> and x86_64-darwin. Implement the __builtin_nested_func_ptr_created and
>>> __builtin_nested_func_ptr_deleted functions for these targets.
>>> 
>>> Co-Authored-By: Maxim Blinov 
>>> Co-Authored-By: Iain Sandoe 
>>> Co-Authored-By: Francois-Xavier Coudert 
>>>
>>> added TLS usage to libgcc_s.so.1.  The way that libgcc_s is currently
>>> built, it ends up using a dynamic TLS variant on the Linux targets.
>>> This means that there is no up-front TLS allocation with glibc (but
>>> there would be one with musl).
>>>
>>> There is still a compatibility impact because glibc assigns a TLS module
>>> ID upfront.  This seems to be what causes the
>>> ust/libc-wrapper/test_libc-wrapper test in lttng-tools to fail.  We end
>>> up with an infinite regress during process termination because
>>> libgcc_s.so.1 has been loaded, resulting in a DTV update.  When this
>>> happens, the bottom of the stack looks like this:
>>>
>>> #4447 0x77f288f0 in free () from 
>>> /lib64/liblttng-ust-libc-wrapper.so.1
>>> #4448 0x77fdb142 in free (ptr=)
>>> at ../include/rtld-malloc.h:50
>>> #4449 _dl_update_slotinfo (req_modid=3, new_gen=2) at ../elf/dl-tls.c:822
>>> #4450 0x77fdb214 in update_get_addr (ti=0x77f2bfc0, 
>>> gen=) at ../elf/dl-tls.c:916
>>> #4451 0x77fddccc in __tls_get_addr ()
>>> at ../sysdeps/x86_64/tls_get_addr.S:55
>>> #4452 0x77f288f0 in free () from 
>>> /lib64/liblttng-ust-libc-wrapper.so.1
>>> #4453 0x77fdb142 in free (ptr=)
>>> at ../include/rtld-malloc.h:50
>>> #4454 _dl_update_slotinfo (req_modid=2, new_gen=2) at ../elf/dl-tls.c:822
>>> #4455 0x77fdb214 in update_get_addr (ti=0x77f39fa0, 
>>> gen=) at ../elf/dl-tls.c:916
>>> #4456 0x77fddccc in __tls_get_addr ()
>>> at ../sysdeps/x86_64/tls_get_addr.S:55
>>> #4457 0x77f36113 in lttng_ust_cancelstate_disable_push ()
>>>from /lib64/liblttng-ust-common.so.1
>>> #4458 0x77f4c2e8 in ust_lock_nocheck () from 
>>> /lib64/liblttng-ust.so.1
>>> #4459 0x77f5175a in lttng_ust_cleanup () from 
>>> /lib64/liblttng-ust.so.1
>>> #4460 0x77fca0f2 in _dl_call_fini (
>>> closure_map=closure_map@entry=0x77fbe000) at dl-call_fini.c:43
>>> #4461 0x77fce06e in _dl_fini () at dl-fini.c:114
>>> #4462 0x77d82fe6 in __run_exit_handlers () from /lib64/libc.so.6
>>>
>>> Cc:ing  for awareness.
>>>
>>> The issue also requires a recent glibc with changes to DTV management:
>>> commit d2123d68275acc0f061e73d5f86ca504e0d5a344 ("elf: Fix slow tls
>>> access after dlopen [BZ #19924]").  If I understand things correctly,
>>> before this glibc change, we didn't deallocate the old DTV, so there was
>>> no call to the free function.
>>
>> with 19924 fixed, after a dlopen or dlclose every thread updates
>> its dtv on the next dynamic tls access.
>>
>> before that, dtv was only updated up to the generation of the
>> module being accessed for a particular tls access.
>>
>> so hitting the free in the dtv update path is now more likely
>> but the free is not new, it was there before.
>>
>> also note that this is unlikely to happen on aarch64 since
>> tlsdesc only does dynamic tls access after a 512byte static
>> tls reservation runs out.
>>
>>>
>>> On the glibc side, we should recommend that intercepting mallocs and its
>>> dependencies use initial-exec TLS because that kind of TLS does not use
>>> malloc.  If intercepting mallocs using dynamic TLS work at all, that's
>>> totally by accident, and was in the past helped by glibc bug 19924.  (I
>>
>> right.
>>
>>> don't think there is anything special about libgcc_s.so.1 that triggers
>>> the test failure above, it is just an object with dynamic TLS that is
>>> implicitly loaded via dlopen at the right stage of the test.)  In this
>>> particular case, we can also paper over the test failure in glibc by not
>>> call free at all because the argument is a null pointer:
>>>
>>> diff --git a/elf/dl-tls.c b/elf/dl-tls.c
>>> index 7b3dd9ab60..14c71cbd06 100644
>>> --- a/elf/dl-tls.c
>>> +++ b/elf/dl-tls.c
>>> @@ -819,7 +819,8 @@ _dl_update_slotinfo (unsigned long int req_modid, 
>>> size_t new_gen)
>>>  dtv entry free it.  Note: this is not AS-safe.  */
>>>   /* XXX Ideally we will at some point create a memory
>>>  pool.  */
>>> - free (dtv[modid].pointer.to_free);
>>> + if (dtv[modid].pointer.to_free != NULL)
>>> +   free (dtv[modid].pointer.to_free);
>>>   dtv[modid].pointer.val = TLS_DTV_UNALLOCATED;
>

Office Hours for the GNU Toolchain on 2024-02-29 at 11am EST5EDT.

[Carlos O'Donell via Gcc]

Office Hours for the GNU Toolchain on 2024-02-29 at 11am EST5EDT.

Agenda:
* https://gcc.gnu.org/wiki/OfficeHours#Next

Meeting Link:
* https://bbb.linuxfoundation.org/room/adm-xcb-for-sk6

--
Cheers,
Carlos.

Office Hours for the GNU Toolchain on 2024-03-28 at 11am EST5EDT.

[Carlos O'Donell via Gcc]

Office Hours for the GNU Toolchain on 2024-03-28 at 11am EST5EDT.

Agenda:
* https://gcc.gnu.org/wiki/OfficeHours#Next

Meeting Link:
* https://bbb.linuxfoundation.org/room/adm-xcb-for-sk6

--
Cheers,
Carlos.

Office Hours for the GNU Toolchain on 2024-04-25 at 11am EST5EDT.

[Carlos O'Donell via Gcc]

Office Hours for the GNU Toolchain on 2024-04-25 at 11am EST5EDT.

Agenda:
* https://gcc.gnu.org/wiki/OfficeHours#Next

Meeting Link:
* https://bbb.linuxfoundation.org/room/adm-xcb-for-sk6

--
Cheers,
Carlos.

Invitation: Office Hours for the GNU Toolchain @ Monthly from 11am to 12pm on the last Thursday (EDT) (gcc@gcc.gnu.org)

[Carlos O'Donell via Gcc]

Office Hours for the GNU Toolchain
Monthly from 11am to 12pm on the last Thursday
Eastern Time - New York

Location
https://bbb.linuxfoundation.org/room/adm-xcb-for-sk6
https://www.google.com/url?q=https%3A%2F%2Fbbb.linuxfoundation.org%2Froom%2Fadm-xcb-for-sk6&sa=D&ust=17137887&usg=AOvVaw2V18NEONPlH-coE-TT_R5q



Office hours for the GNU  
Toolchain:https://gcc.gnu.org/wiki/OfficeHoursMeeting  
link:https://bbb.linuxfoundation.org/room/adm-xcb-for-sk6


Organizer
Carlos O'Donell
codon...@redhat.com

Guests
Carlos O'Donell - organizer
Nick Clifton
Jakub Jelinek
David Edelsohn
Siddhesh Poyarekar
Jason Merrill
j...@polyomino.org.uk
richard.earns...@arm.com
girish...@gmail.com
adhemerval.zane...@linaro.org
Florian Weimer
berg...@linux.ibm.com
Peter Bergner
libc-al...@sourceware.org
dilfri...@gentoo.org
binut...@sourceware.org
christophe.l...@linaro.org
gcc@gcc.gnu.org
g...@sourceware.org
View all guest info  
https://calendar.google.com/calendar/event?action=VIEW&eid=MjVqczBqZ2x2aWFkZ2QyczNzYTJoMmdwb2VfUjIwMjQwNDI1VDE1MDAwMCBnY2NAZ2NjLmdudS5vcmc&tok=MTkjY29kb25lbGxAcmVkaGF0LmNvbTc2YTJkODA5YmFjODAwMzBiZmVlYTZlYjRmMTkyODAyYmM1Yjk2M2E&ctz=America%2FNew_York&hl=en&es=0


Reply for gcc@gcc.gnu.org and view more details  
https://calendar.google.com/calendar/event?action=VIEW&eid=MjVqczBqZ2x2aWFkZ2QyczNzYTJoMmdwb2VfUjIwMjQwNDI1VDE1MDAwMCBnY2NAZ2NjLmdudS5vcmc&tok=MTkjY29kb25lbGxAcmVkaGF0LmNvbTc2YTJkODA5YmFjODAwMzBiZmVlYTZlYjRmMTkyODAyYmM1Yjk2M2E&ctz=America%2FNew_York&hl=en&es=0

Your attendance is optional.

~~//~~
Invitation from Google Calendar: https://calendar.google.com/calendar/

You are receiving this email because you are an attendee on the event. To  
stop receiving future updates for this event, decline this event.


Forwarding this invitation could allow any recipient to send a response to  
the organizer, be added to the guest list, invite others regardless of  
their own invitation status, or modify your RSVP.


Learn more https://support.google.com/calendar/answer/37135#forwarding


invite.ics
Description: application/ics

Invitation: Office Hours for the GNU Toolchain @ Thu May 30, 2024 11am - 12pm (EDT) (gcc@gcc.gnu.org)

[Carlos O'Donell via Gcc]

Office Hours for the GNU Toolchain
Thursday May 30, 2024 ⋅ 11am – 12pm
Eastern Time - New York

Location
https://bbb.linuxfoundation.org/room/adm-xcb-for-sk6
https://www.google.com/url?q=https%3A%2F%2Fbbb.linuxfoundation.org%2Froom%2Fadm-xcb-for-sk6&sa=D&ust=17137887&usg=AOvVaw2V18NEONPlH-coE-TT_R5q



Office hours for the GNU  
Toolchain:https://gcc.gnu.org/wiki/OfficeHoursMeeting  
link:https://bbb.linuxfoundation.org/room/adm-xcb-for-sk6


Organizer
Carlos O'Donell
codon...@redhat.com

Guests
Carlos O'Donell - organizer
Nick Clifton
Jakub Jelinek
David Edelsohn
Siddhesh Poyarekar
Jason Merrill
j...@polyomino.org.uk
richard.earns...@arm.com
girish...@gmail.com
adhemerval.zane...@linaro.org
Florian Weimer
christophe.l...@linaro.org
berg...@linux.ibm.com
Peter Bergner
libc-al...@sourceware.org
dilfri...@gentoo.org
binut...@sourceware.org
gcc@gcc.gnu.org
g...@sourceware.org
View all guest info  
https://calendar.google.com/calendar/event?action=VIEW&eid=MjVqczBqZ2x2aWFkZ2QyczNzYTJoMmdwb2VfMjAyNDA1MzBUMTUwMDAwWiBnY2NAZ2NjLmdudS5vcmc&tok=MTkjY29kb25lbGxAcmVkaGF0LmNvbTA1YWM1ODFlZjQwZjU1YjhkN2ZjMGJlMDZlYzkyNDFiMTkxNDQ1Yjc&ctz=America%2FNew_York&hl=en&es=0


Reply for gcc@gcc.gnu.org and view more details  
https://calendar.google.com/calendar/event?action=VIEW&eid=MjVqczBqZ2x2aWFkZ2QyczNzYTJoMmdwb2VfMjAyNDA1MzBUMTUwMDAwWiBnY2NAZ2NjLmdudS5vcmc&tok=MTkjY29kb25lbGxAcmVkaGF0LmNvbTA1YWM1ODFlZjQwZjU1YjhkN2ZjMGJlMDZlYzkyNDFiMTkxNDQ1Yjc&ctz=America%2FNew_York&hl=en&es=0

Your attendance is optional.

~~//~~
Invitation from Google Calendar: https://calendar.google.com/calendar/

You are receiving this email because you are an attendee on the event. To  
stop receiving future updates for this event, decline this event.


Forwarding this invitation could allow any recipient to send a response to  
the organizer, be added to the guest list, invite others regardless of  
their own invitation status, or modify your RSVP.


Learn more https://support.google.com/calendar/answer/37135#forwarding


invite.ics
Description: application/ics

Office Hours for the GNU Toolchain on 2024-05-30 at 11am EST5EDT.

[Carlos O'Donell via Gcc]

Office Hours for the GNU Toolchain on 2024-05-30 at 11am EST5EDT.

Agenda:
* https://gcc.gnu.org/wiki/OfficeHours#Next

Meeting Link:
* https://bbb.linuxfoundation.org/room/adm-xcb-for-sk6

--
Cheers,
Carlos.

Office Hours for the GNU Toolchain on 2024-06-27 at 11am EST5EDT.

[Carlos O'Donell via Gcc]

Office Hours for the GNU Toolchain on 2024-06-27 at 11am EST5EDT.

Agenda:
* https://gcc.gnu.org/wiki/OfficeHours#Next

Meeting Link:
* https://bbb.linuxfoundation.org/room/adm-xcb-for-sk6

--
Cheers,
Carlos.

Office Hours for the GNU Toolchain on 2024-07-25 at 11am EST5EDT.

[Carlos O'Donell via Gcc]

Office Hours for the GNU Toolchain on 2024-07-25 at 11am EST5EDT.

Agenda:
* https://gcc.gnu.org/wiki/OfficeHours#Next

Meeting Link:
* https://bbb.linuxfoundation.org/room/adm-xcb-for-sk6

--
Cheers,
Carlos.

Office Hours for the GNU Toolchain on 2024-08-29 at 11am EST5EDT.

[Carlos O'Donell via Gcc]

Office Hours for the GNU Toolchain on 2024-08-29 at 11am EST5EDT.

Agenda:
* https://gcc.gnu.org/wiki/OfficeHours#Next

Meeting Link:
* https://bbb.linuxfoundation.org/room/adm-xcb-for-sk6

--
Cheers,
Carlos.

Core Toolchain Infrastructure - October 2024 update

[Carlos O'Donell via Gcc]

Core Toolchain Infrastructure - October 2024 update

The Core Toolchain Infrastructure (CTI) Project’s mission is to support
the GNU Toolchain community with secure infrastructure and state of the
art services required to support the community’s development efforts to
be a trusted foundation in a secure supply chain.

We want to keep the GNU Toolchain development community updated with the
latest information on the CTI project and how it can support the GNU
Toolchain.

Since 2022 [1][2] the CTI project has been working to carry out a
detailed enumeration of the services required by the projects and how
those services may be provided in a secure and robust fashion.

We have completed a detailed service enumeration for the GNU Toolchain:
https://cti.coretoolchain.dev/projects/enum.html

In 2024 we published updated project documentation:
https://cti.coretoolchain.dev

Also in 2024 we've looked at the details of the services we provide, why
we provide them, and how we might provide them with with increased
security and robustness, including putting together a statement of work
with the Linux Foundation Core IT team (who provides similar services to
the Linux Kernel) [3].

The CTI Technical Advisory Committee (TAC) is made up of members of the
development community of the projects, and is working on behalf of the
GNU Toolchain to improve security and robustness of the infrastructure
used by the community. The CTI TAC meets monthly and the meetings are
open for anyone to attend.

There is still a lot of work ahead of us to find a way forward to state
of the art sustainable secure and robust services for the GNU Toolchain
projects. Recent discussions on the glibc mailing list make it clear
that we need to expand and discuss more about our "why" along with
the "what" and "how" of these changes.

We will be sending out one of these updates every 3 months to all the
projects to keep you updated on our progress and discussions with the
GNU Toolchain projects and the wider 

Sincerely,
Core Toolchain Infrastructure Technical Advisory Committee

[1] 
https://inbox.sourceware.org/overseers/ef140a6b-c72d-bd63-b94c-bceeb365b...@redhat.com/
[2] 
https://inbox.sourceware.org/overseers/2513b668-9ebd-9e78-7263-dc24f4a95...@redhat.com/
[3] 
https://inbox.sourceware.org/libc-alpha/eb0d5e7b-0280-4c5a-aff6-3418a4210...@redhat.com/

Re: Core Toolchain Infrastructure - October 2024 update

[Carlos O'Donell via Gcc]

On 10/30/24 11:45 AM, Mark Wielaard wrote:
> Hi Carlos,
> 
> On Wed, 2024-10-30 at 08:32 -0400, Carlos O'Donell wrote:
>> I can get down to specific requirements and possible solutions for them, 
>> including
>> things like securing logins with 2FA etc. Which *could* be solved by 
>> Sourceware
>> today possibly using Nitrokeys (open hardware and FOSS), for example.
> 
> Yes, a nitrokey distribution scheme is part of the Secure Sourceware
> Project Goals: https://sourceware.org/sourceware-security-vision.html

Have you broken down those project goals into actionable steps that could be 
taken?

For example filing Sourceware Infrastructure bugs for each service that needs 
to be
migrated into a VM and isolated (with a top level tracker for "Increased 
isolation")?

If you're going to ask for funding, having a list of concrete goals the funding
will solve, broken down to the level at which you can write an SOW, is very very
beneficial.
 
> We discussed this with OpenSSF and submitted a funding request to
> OpenSSF Alpha Omega for this particular part. OpenSSF initially was
> supportive to funding these kinds of security plans, but they have been
> silent for the last couple of months. If you have contacts to get this
> going forward again that would be great.

I do have contacts at the OpenSSF and I'd be glad to help. We just met with one 
of
their team members today as part of the CTI TAC meeting.

Do you have your funding request anywhere that I can read it?

>> Having all the details spelled out would allow Sourceware to make progress 
>> on the
>> same issues raised, and I can even file infrastructure bugs if that helps.
> 
> Yes, please file bugzilla reports against the Sourceware Infrastructure
> project:
> https://sourceware.org/bugzilla/buglist.cgi?product=sourceware&component=Infrastructure
> Or bring it up on the overseers list or during the Sourceware open
> office hours. https://sourceware.org/mission.html#organization

For tracking purposes I'll file them as Sourceware Infrastructure bugs and
we can go from there.

>> My deepest concerns here is that Sourceware PLC cannot convince larger 
>> sponsors
>> to provide the funding to do what needs to be done to scale out and improve 
>> our
>> services.
> 
> Thanks for your concern. The whole idea of setting up Sourceware as an
> organization with Conservancy as a fiscal sponsor is precisely to make
> these kind of sponsorships easy. And to expand funding to be able to
> accept community donations and grants:
> https://sourceware.org/donate.html

What you have done is make it *possible* for an organization to place money at 
the
fiscal sponsor for the mission you've set out, and while this is a measure of 
ease,
the hardest step is still to come. You need to convince sponsors to donate.

David, Joel and I have been the trustees of the GNU Toolchain Fund since we 
worked
with the FSF to set it up in 2017. Since then the hardest step is getting larger
sponsors to support.

How have your fund raising activities been going for the Sourceware fund at the 
SFC?

Have you allocated and spent any of that funding to move the project goals 
forward?
 
>> I'm excited that the GNU Toolchain community is looking at different 
>> workflows and
>> solutions, but if I'm honest the same question of funding and 
>> service/workload
>> isolation applies.
>>
>> I'm *more* excited to pay Codeberg directly to support the GNU Toolchain to 
>> support
>> the development of Forgejo, particularly given that larger groups like 
>> Fedora are
>> considering Forgejo.
> 
> Yes, we did already discuss this. But it is too early for that. Richard
> setup a wiki page for the Forge Experiment that includes a list of
> various bugs/issues in Forgejo that we would like to see resolved
> before we can call the experiment an success.
> https://gcc.gnu.org/wiki/ForgeExperiment
> When we are a bit further into the experiment to know which ones are
> real blockers, we could fund the work to get those done.

Yes, I agree we're too early.

Fedora has commented publicly that Codeberg's informal position was that they
probably did not have the capacity to host a project of Fedora's size.

https://discussion.fedoraproject.org/t/a-vote-in-favor-of-forgejo/112059/5

-- 
Cheers,
Carlos.

Re: Core Toolchain Infrastructure - October 2024 update

[Carlos O'Donell via Gcc]

On 10/30/24 6:39 AM, Mark Wielaard wrote:
> Hi Carlos,
> 
> On Tue, Oct 29, 2024 at 06:02:03PM -0400, Carlos O'Donell via Gcc wrote:
>> Recent discussions on the glibc mailing list make it clear
>> that we need to expand and discuss more about our "why" along with
>> the "what" and "how" of these changes.
> 
> Zoe wrote a good summary of that discussion back in July:
> https://inbox.sourceware.org/f20ce996-e9c6-4b6c-856d-eec6e14af...@fsf.org/
> Has anything changed since then to address the issues raised by her
> and others?

Yes, that the CTI TAC needs to expand the discussion of the "why" to the broader
list of the project, and that starts by writing up (something I'm in the 
progress
of doing) the detailed notes for glibc, particularly why we would want to meet
any of the requirements (and which specific ones) for a secure software 
development
framework. I'm writing these notes up for the community to continue our 
discussion.

Then once we have the full "why" written down, list the pros and the cons of an
LF IT-based solution and alternatives, including Sourceware, and again "why" the
TAC recommends one solution over the other.

I can get down to specific requirements and possible solutions for them, 
including
things like securing logins with 2FA etc. Which *could* be solved by Sourceware
today possibly using Nitrokeys (open hardware and FOSS), for example.

Having all the details spelled out would allow Sourceware to make progress on 
the
same issues raised, and I can even file infrastructure bugs if that helps.

> I don't believe the community is helped by trying to set up yet
> another, corporate controlled, organization or doing some highly
> disruptive move of some parts of the services our projects are using.

My position here is that the costs of running secure and robust infrastructure 
are
quite high, and engaging directly with corporate sponsors like we have done 
before
is the simplest way to pay for FOSS infrastructure. CTI is exactly the same 
model
we have today, but with broader corporate involvement, instead of just IBM 
paying
for the current services. This engagement happens in a place where the larger
contributors are already engaged at the Linux Foundation.

Have you discussed with IBM and other larger sponsors to pay Sourceware PLC to 
fund expanding the current services?

My deepest concerns here is that Sourceware PLC cannot convince larger sponsors
to provide the funding to do what needs to be done to scale out and improve our
services.
 
> I noticed you attended the Infrastructure BoF at the Cauldron and seem
> to be experimenting with the new Forge we setup. I hope you will be
> happy to work with the existing community and the existing
> organizations that support the GNU toolchain and the Sourceware
> infrastructure, instead of trying to setup yet another organization
> that would split our efforts.

I'm excited that the GNU Toolchain community is looking at different workflows 
and
solutions, but if I'm honest the same question of funding and service/workload
isolation applies.

I'm *more* excited to pay Codeberg directly to support the GNU Toolchain to 
support
the development of Forgejo, particularly given that larger groups like Fedora 
are
considering Forgejo.

Thanks for your feedback. We can continue the discussion once I post more to the
overseers list.

-- 
Cheers,
Carlos.

Office Hours for the GNU Toolchain on 2024-09-26 at 11am EST5EDT.

[Carlos O'Donell via Gcc]

Office Hours for the GNU Toolchain on 2024-09-26 at 11am EST5EDT.

Agenda:
* https://gcc.gnu.org/wiki/OfficeHours#Next

Meeting Link:
* https://bbb.linuxfoundation.org/room/adm-xcb-for-sk6

--
Cheers,
Carlos

Canceled event with note: Office Hours for the GNU Toolchain @ Thu Dec 26, 2024 11am - 12pm (EST) (gcc@gcc.gnu.org)

[Carlos O'Donell via Gcc]

This event has been canceled with a note:
"Removing due to Holidays!"

Office Hours for the GNU Toolchain
Thursday Dec 26, 2024 ⋅ 11am – 12pm
Eastern Time - New York

Location
https://bbb.linuxfoundation.org/room/adm-xcb-for-sk6
https://www.google.com/url?q=https%3A%2F%2Fbbb.linuxfoundation.org%2Froom%2Fadm-xcb-for-sk6&sa=D&ust=172762458000&usg=AOvVaw30AnuvSuJ6Oo5w1Df3_zh4



Office hours for the GNU  
Toolchain:https://gcc.gnu.org/wiki/OfficeHoursMeeting  
link:https://bbb.linuxfoundation.org/room/adm-xcb-for-sk6


Organizer
Carlos O'Donell
codon...@redhat.com

Guests
Carlos O'Donell - organizer
Nick Clifton
Jakub Jelinek
David Edelsohn
Siddhesh Poyarekar
Jason Merrill
j...@polyomino.org.uk
richard.earns...@arm.com
girish...@gmail.com
adhemerval.zane...@linaro.org
Florian Weimer
christophe.l...@linaro.org
berg...@linux.ibm.com
Peter Bergner
libc-al...@sourceware.org
dilfri...@gentoo.org
binut...@sourceware.org
gcc@gcc.gnu.org
g...@sourceware.org


~~//~~
Invitation from Google Calendar: https://calendar.google.com/calendar/

You are receiving this email because you are an attendee on the event. To  
stop receiving future updates for this event, decline this event.


Forwarding this invitation could allow any recipient to send a response to  
the organizer, be added to the guest list, invite others regardless of  
their own invitation status, or modify your RSVP.


Learn more https://support.google.com/calendar/answer/37135#forwarding


invite.ics
Description: application/ics

Re: On pull request workflows for the GNU toolchain

[Carlos O'Donell via Gcc]

On 9/19/24 11:51 AM, Joseph Myers wrote:
> 1. Introduction

Thanks for writing this up!

> This message expands on my remarks at the Cauldron (especially the
> patch review and maintenance BoF, and the Sourceware infrastructure
> BoF) regarding desired features for a system providing pull request
> functionality (patch submission via creating branches that are then
> proposed using some kind of web interface or API, with a central
> database then tracking the status of each pull request and review
> comments thereon automatically), for use by the GNU toolchain (or one
> or more components thereof - there is no need for each component to
> make the same decision about moving to such software and workflow, and
> indeed we have no mechanism to make such decisions for the toolchain
> as a whole).
> 
> This does not advocate a particular choice of software for such
> functionality (though much of the discussion seemed to suggest Forgejo
> as the most likely starting point), or a particular choice of where to
> host it.  Hosting would of course need to meet appropriate security
> requirements, and to achieve a passing grade on the GNU Ethical
> Repository Criteria, and the software would need to be entirely free
> software.  Where relevant features are not already supported, it's
> important that the software is receptive to the addition of such
> features (including cases where part of the functionality is provided
> by software specific to the GNU toolchain or parts thereof - such as
> for the custom checks currently implemented with git hooks - and the
> underlying software provides appropriate interfaces to allow
> integration of such external pieces).  The list of features here may
> be a good basis for reviewing what particular forge software supports
> and whether other features can be added, directly or through use of
> appropriate APIs.
> 
> Forge software may provide other pieces such as bug tracking or wikis
> that we currently handle separately from git hosting.  In such cases,
> we should be able to disable those pieces and keep using the existing
> bug tracking and wiki software (while having the option to decide
> independently to migrate those if desired).
> 
> I consider the overall benefits of such a move to be having more
> structured data about all changes proposed for inclusion and their
> status (needing review, needing changes from the author, under
> discussion, needing merge from mainline, etc.), to help all people
> involved in the patch submission and review process to track such
> information and to find patches needing review as applicable, along
> with providing a more familiar workflow for many people that avoids
> many of the problems with email (which affect experienced contributors
> working around corporate email systems, not just new contributors).
> It would not of course by itself turn people with no interest in or
> understanding of systems software development into contributors (for
> example, people without knowledge of directories and hierarchical file
> storage, or people who only understand software development as web
> development).  Nor would it prevent the accumulation of large backlogs
> of unreviewed patches, as is evident from many large and active
> projects using PR workflows with large numbers of open PRs.
> 
> As Richard noted in his BoF, email sucks.  As I noted in reply, so do
> the web and web browsers when trying to deal with large amounts of
> patch review state (when one wishes to apply one's own view, not the
> forge's, of what is resolved and what needs attention).  As I also
> noted, in the Sourceware infrastructure BoF, tools such as patchwork
> and b4 are the right answer to the wrong question: trying to get
> structured data about patch submissions when working from the axiom
> that emails on a mailing list should be the primary source of truth
> for everything needing review, rather than starting from more
> structured data and generating emails as one form of output.
> 
> Moving to a pull request system is not expected to change policies
> regarding who can approve a change for inclusion, or the technical
> limits on who can cause a change to enter mainline (e.g. all people
> with commit access would be expected to be able to use a button in a
> web interface to cause to PR to be merged, though policy might limit
> when they should do so).  We can of course choose to change policies,
> either as part of adopting a PR system or later.

Agreed.

> 
> 
> 2. Key features
> 
> (a) Some forges have a design that emphasises the tree you get after a
> proposed contribution, but not the sequence of commits to get there.

This has changed a lot in recent years in gitlab and github where per-commit 
reviews
were emerging as a needed property of the web UI, so the commits (rather than 
the
final state of the tree) were being exposed for review purposes. I see this as a
general maturing of the tooling towards what we already knew in systems design,
that the 

Re: Align the gcc, glibc, and binutils DCO text to match community usage.

[Carlos O'Donell via Gcc]

On 11/24/24 11:49 AM, Bradley M. Kuhn wrote:
> One size doesn't necessarily fit all.  Perhaps if you're changing the DCO
> text for the toolchain projects at this moment, it might be a good time to
> consider if the Linux DCO text suits your project perfectly.

This is not a change of the DCO text.

Nor am I suggesting a change in the DCO text.

-- 
Cheers,
Carlos.

Align the gcc, glibc, and binutils DCO text to match community usage.

[Carlos O'Donell via Gcc]

The DCO was introduced to gcc, glibc and binutils in 2021 and 2022
to expand and align the contribution process with other free and open
source software projects that had been effectively using DCO for
contributions.

To that end I'm aligning the glibc usage following the Linux kernel
changes from 2023-02-26 [1].

These changes clarify what was meant by "real name" and that it is
not required to be a "legal name" or any other stronger requirement
than a known identity that could be contacted to discuss the
contribution (and what was attested).

The same changes have been made to other projects including as noted
by Sam James in the Gentoo project [2], Mark Wielaard in elfutils [3],
and CNCF [4].

I have updated the glibc contribution checklist with matching language:
https://sourceware.org/glibc/wiki/Contribution%20checklist

I've submitted a patch for the gcc text[5]:
https://gcc.gnu.org/dco.html

The binutils contribution checklist DCO text did not need updating:
https://sourceware.org/binutils/wiki/HowToContribute

-- 
Cheers,
Carlos.

[1] Link: 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/Documentation/process/submitting-patches.rst?id=d4563201f33a022fc0353033d9dfeb1606a88330
[2] Link: 
https://sourceware.org/git/?p=elfutils.git;a=blob;f=CONTRIBUTING;h=27907652b388542c2213f94e8d679dab7b677f75;hb=HEAD#l48
[3] Link: 
https://gitweb.gentoo.org/data/glep.git/commit/?id=9733e2706ff46ebbc1c2b468f55006dd2921fca2
[4] Link: https://github.com/cncf/foundation/blob/659fd32c86dc/dco-guidelines.md
Link: https://github.com/cncf/foundation/issues/383
[5] Link: https://gcc.gnu.org/pipermail/gcc-patches/2024-November/669715.html

Updated invitation: Office Hours for the GNU Toolchain @ Monthly from 11am to 12pm on the last Thursday (EDT) (gcc@gcc.gnu.org)

[Carlos O'Donell via Gcc]

This event has been updated
Changed: description


Office Hours for the GNU Toolchain
Monthly from 11am to 12pm on the last Thursday
Eastern Time - New York

Location
https://bbb.linuxfoundation.org/room/adm-xcb-for-sk6
https://www.google.com/url?q=https%3A%2F%2Fbbb.linuxfoundation.org%2Froom%2Fadm-xcb-for-sk6&sa=D&ust=174594186000&usg=AOvVaw0JzrUZUhBD4gdqlyFRgyuQ



Office hours for the GNU Toolchain:
https://gcc.gnu.org/wiki/OfficeHours
Meeting link:
https://bbb.linuxfoundation.org/room/adm-xcb-for-sk6
 
Last updated 2025-04-24

Organizer
Carlos O'Donell
codon...@redhat.com

Guests
Carlos O'Donell - organizer
Nick Clifton
Jakub Jelinek
David Edelsohn
Siddhesh Poyarekar
Jason Merrill
j...@polyomino.org.uk
richard.earns...@arm.com
girish...@gmail.com
adhemerval.zane...@linaro.org
Florian Weimer
christophe.l...@linaro.org
berg...@linux.ibm.com
Peter Bergner
libc-al...@sourceware.org
dilfri...@gentoo.org
binut...@sourceware.org
gcc@gcc.gnu.org
g...@sourceware.org
View all guest info  
https://calendar.google.com/calendar/event?action=VIEW&eid=MjVqczBqZ2x2aWFkZ2QyczNzYTJoMmdwb2VfUjIwMjUwNTI5VDE1MDAwMCBnY2NAZ2NjLmdudS5vcmc&tok=MTkjY29kb25lbGxAcmVkaGF0LmNvbTFlZTA1MWM4NzQ0ZTJkNWU1NzNkZTVkMWYzZjExYzYzY2JjYTllYWY&ctz=America%2FNew_York&hl=en&es=0


Reply for gcc@gcc.gnu.org and view more details  
https://calendar.google.com/calendar/event?action=VIEW&eid=MjVqczBqZ2x2aWFkZ2QyczNzYTJoMmdwb2VfUjIwMjUwNTI5VDE1MDAwMCBnY2NAZ2NjLmdudS5vcmc&tok=MTkjY29kb25lbGxAcmVkaGF0LmNvbTFlZTA1MWM4NzQ0ZTJkNWU1NzNkZTVkMWYzZjExYzYzY2JjYTllYWY&ctz=America%2FNew_York&hl=en&es=0

Your attendance is optional.

~~//~~
Invitation from Google Calendar: https://calendar.google.com/calendar/

You are receiving this email because you are an attendee on the event.

Forwarding this invitation could allow any recipient to send a response to  
the organizer, be added to the guest list, invite others regardless of  
their own invitation status, or modify your RSVP.


Learn more https://support.google.com/calendar/answer/37135#forwarding


invite.ics
Description: application/ics

Synced invitation: Office Hours for the GNU Toolchain @ Monthly from 11am to 12pm on the last Thursday from Thu Apr 25, 2024 to Wed May 28 (EDT) (gcc@gcc.gnu.org)

[Carlos O'Donell via Gcc]

This email keeps the event up to date in your calendar.

Office Hours for the GNU Toolchain
Monthly from 11am to 12pm on the last Thursday from Thursday Apr 25, 2024  
to Wednesday May 28

Eastern Time - New York

Location
https://bbb.linuxfoundation.org/room/adm-xcb-for-sk6
https://www.google.com/url?q=https%3A%2F%2Fbbb.linuxfoundation.org%2Froom%2Fadm-xcb-for-sk6&sa=D&ust=174594186000&usg=AOvVaw0JzrUZUhBD4gdqlyFRgyuQ



Office hours for the GNU  
Toolchain:https://gcc.gnu.org/wiki/OfficeHoursMeeting  
link:https://bbb.linuxfoundation.org/room/adm-xcb-for-sk6


Organizer
Carlos O'Donell
codon...@redhat.com

Guests
Carlos O'Donell - organizer
Nick Clifton
Jakub Jelinek
David Edelsohn
Siddhesh Poyarekar
Jason Merrill
j...@polyomino.org.uk
richard.earns...@arm.com
girish...@gmail.com
adhemerval.zane...@linaro.org
Florian Weimer
christophe.l...@linaro.org
berg...@linux.ibm.com
Peter Bergner
libc-al...@sourceware.org
dilfri...@gentoo.org
binut...@sourceware.org
gcc@gcc.gnu.org
g...@sourceware.org


~~//~~
Invitation from Google Calendar: https://calendar.google.com/calendar/

You are receiving this email because you are an attendee on the event.

Forwarding this invitation could allow any recipient to send a response to  
the organizer, be added to the guest list, invite others regardless of  
their own invitation status, or modify your RSVP.


Learn more https://support.google.com/calendar/answer/37135#forwarding


invite.ics
Description: application/ics