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

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

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 

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.

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-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-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.

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

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

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.

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-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.

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-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.

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.

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 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.

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.

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.

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: 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.

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: 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: 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.