Re: Align the gcc, glibc, and binutils DCO text to match community usage.
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.
gcc-13-20241129 is now available
Snapshot gcc-13-20241129 is now available on https://gcc.gnu.org/pub/gcc/snapshots/13-20241129/ and on various mirrors, see https://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 13 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-13 revision c535336028a0194148e73d40fbef0846da3e04a3 You'll find: gcc-13-20241129.tar.xz Complete GCC SHA256=4ad31723d45571621f67323602e3c30b90e25d8bf4ce9a75119d0fe5815e824e SHA1=b2d51aae878570e007a485759bb851aeaa3a0bce Diffs from 13-20241122 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-13 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Align the gcc, glibc, and binutils DCO text to match community usage.
> 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. Carlos O'Donell wrote: > This is not a change of the DCO text. > Nor am I suggesting a change in the DCO text. But of course you are. Specifically, you're tracking and implementing any changes to Linux's DCO done by the Linux project. That could be a good thing, but I'm just not sure. If everyone in all the toolchain projects are indeed sure they want the exact same DCO text as used by Linux, then of course you should track every change they make and mirror their text exactly. I'm just proposing that the toolchain projects take time to think for themselves on these matters, for reasons outlined in my earlier email (see below). There is no mandate by anyone, including Linux Foundation itself, that every implementation of a DCO be the same. In fact, LF has since the advent of the DCO encouraged folks to adapt the language for differing needs. I suggest that the toolchain projects may well have differing needs. >> While the DCO text used by the kernel named Linux is a fine text and >> serves many purposes, it is particularly aligned with the sub-maintainer >> model of Linux development — whereby submaintainers take cascading >> responsibility as patches work their way upstream, and are thus adding >> Signed-Off-By tags upon existing Signed-Off-By tags, and thus >> strengthening the DCO attestation with addition of more parties for the >> same patch. >> I am not aware that all of the toolchain projects have a similar model of >> development and thus the DCO text that Linux uses may not be ideal. >> Despite what the current marketing departments might tell you, the DCO is >> not a single document nor was it designed to be. There are many variants >> throughout the Free Software community to meet the needs of specific >> projects. (Indeed, the original DCO text was specifically released under >> CC-By-SA to encourage projects to adapt it to their needs [0].) >> 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. >> FWIW, my specific concern with the Linux DCO is, as Denver and I discussed >> in licensing BoF at Cauldron, the Linux DCO text is specifically designed >> to shift licensing liability from any *entity* who might be contributing >> or who might hold copyright (such as a company or a non-profit) *onto* the >> individual developer who submitted the patch. I suppose this structure >> works well for Linux, but, especially given that contributors to the >> toolchain projects have been used to all the liability shifting to the FSF >> through its historical copyright assignment system, developers might be >> surprised to learn that a DCO-based patch (as opposed to a copyright >> assigned one) puts additional liability onto the contributor. -- Bradley M. Kuhn - he/them Policy Fellow & Hacker-in-Residence at Software Freedom Conservancy Become a Conservancy Sustainer today: https://sfconservancy.org/sustainer
Help with setting the order of default system include directories of c,c++ preprocessor
Dear GCC Gurus, We are compiling a GCC using "pre-existing" GCC and we want to have control over the order of the system directories that are searched particularly we want /usr/include to be searched before others. We are not in a position to keep adding -I/usr/include to our build scripts. also -isystem /usr/include will anyway ignore it as its a part of the built-in list. Please refer to lines 15-21 in the information below: 1 $ ~/gcc/bin/cpp -v /dev/null -o /dev/null 2 Using built-in specs. 3 COLLECT_GCC=/home/builder/alpine-custom/mnt/builder/gcc/bin/cpp 4 Target: aarch64-unknown-linux-gnu 5 Configured with: ../configure --prefix=/mnt/builder/gcc --disable-bootstrap --enable-languages=c,c++ 6 Thread model: posix 7 Supported LTO compression algorithms: zlib 8 gcc version 13.2.1 20240309 (GCC) 9 COLLECT_GCC_OPTIONS='-E' '-v' '-o' '/dev/null' '-mlittle-endian' '-mabi=lp64' 10 /mnt/builder/gcc/bin/../libexec/gcc/aarch64-unknown-linux-gnu/13.2.1/cc1 -E -quiet -v -iprefix /mnt/builder/gcc/bin/../lib/gcc/aarch64-unknown-linux-gnu/13.2.1/ /dev/null -o /dev/null -mlittle-endian -mabi=lp64 -dumpbase null 11 ignoring nonexistent directory "/mnt/builder/gcc/bin/../lib/gcc/aarch64-unknown-linux-gnu/13.2.1/../../../../aarch64-unknown-linux-gnu/include" 12 ignoring duplicate directory "/mnt/builder/gcc/bin/../lib/gcc/../../lib/gcc/aarch64-unknown-linux-gnu/13.2.1/include" 13 ignoring duplicate directory "/mnt/builder/gcc/bin/../lib/gcc/../../lib/gcc/aarch64-unknown-linux-gnu/13.2.1/include-fixed" 14 ignoring nonexistent directory "/mnt/builder/gcc/bin/../lib/gcc/../../lib/gcc/aarch64-unknown-linux-gnu/13.2.1/../../../../aarch64-unknown-linux-gnu/include" 15 #include "..." search starts here: 16 #include <...> search starts here: 17 /mnt/builder/gcc/bin/../lib/gcc/aarch64-unknown-linux-gnu/13.2.1/include 18 /mnt/builder/gcc/bin/../lib/gcc/aarch64-unknown-linux-gnu/13.2.1/include-fixed 19 /usr/local/include 20 /mnt/builder/gcc/bin/../lib/gcc/../../include 21 /usr/include 22 End of search list. 23 COMPILER_PATH=/mnt/builder/gcc/bin/../libexec/gcc/aarch64-unknown-linux-gnu/13.2.1/:/mnt/builder/gcc/bin/../libexec/gcc/ 24 LIBRARY_PATH=/mnt/builder/gcc/bin/../lib/gcc/aarch64-unknown-linux-gnu/13.2.1/:/mnt/builder/gcc/bin/../lib/gcc/:/mnt/builder/gcc/bin/../lib/gcc/aarch64-unknown-linux-gnu/13.2.1/../../../../lib64/:/mnt/builder/gcc/bin/../lib/gcc/aarch64-unknown-linux-gnu/13.2.1/../../../:/lib/:/usr/lib/ 25 COLLECT_GCC_OPTIONS='-E' '-v' '-o' '/dev/null' '-mlittle-endian' '-mabi=lp64' [PS: this is my first post here , apologies in advance for anything awkward ] Regds Rajesh Kumar Mallah. Redgrape Technologies ( https://www.redgrape.tech ) Mobile: 09811255597, Land: 011-49044122 -- Opportunities are usually disguised as hard work, so most people don't recognize them Confidentiality Notice: The information that is transmitted in this message may contain confidential or proprietary material solely belonging to Redgrape Technologies. It is intended only for the person or entity to whom it is addressed, and is not for copying or further distribution. If you have received this message in error, please contact the sender immediately and remove it from your and any other computer. Thank you.
branch prediction not correctly applied to an if statement in an inline with multiple conditoins
Tested with gcc 14.2 and the Linux kernel compiling for amd64. This is
at Linux next-20241127. This was already the case on gcc 13 (no idea
about earlier versions), I tested 14 to see if the problem is gone.
In the particular case I ran into a prediction concerning the return
value of __access_ok is not correctly acted upon.
#define access_ok(addr, size) likely(__access_ok(addr, size))
then in __access_ok:
return valid_user_address(sum) && sum >= (__force unsigned long)ptr;
The expected asm contains 2 branches both with a jump towards the end
of the function in the failing case. Instead jumps are emitted if
everything works out.
Interestingly the issue fixes itself if I split the if statement like so:
- return valid_user_address(sum) && sum >= (__force
unsigned long)ptr;
+ if (!valid_user_address(sum))
+ return false;
+ return sum >= (__force unsigned long)ptr;
Routine at hand (trimmed):
static inline __must_check unsigned long
_inline_copy_to_user(void __user *to, const void *from, unsigned long n)
{
if (access_ok(to, n)) {
instrument_copy_to_user(to, from, n);
n = raw_copy_to_user(to, from, n);
}
return n;
}
Bad asm:
Dump of assembler code for function _copy_to_user:
0x819713c0 <+0>: endbr64
0x819713c4 <+4>: mov%rdx,%rcx
0x819713c7 <+7>: mov%rdx,%rax
0x819713ca <+10>:xor%edx,%edx
0x819713cc <+12>:add%rdi,%rcx
0x819713cf <+15>:setb %dl
0x819713d2 <+18>:movabs $0x123456789abcdef,%r8
0x819713dc <+28>:test %rdx,%rdx
0x819713df <+31>:jne0x819713e6 <_copy_to_user+38>
this jumps to the exit
0x819713e1 <+33>:cmp%rcx,%r8
0x819713e4 <+36>:jae0x819713eb <_copy_to_user+43>
this jumps over exiting the func to do the actual work, even though
doing the compiler is hinted this is the expected state
0x819713e6 <+38>:jmp0x8206b160 <__x86_return_thunk>
0x819713eb <+43>:nop
0x819713ec <+44>:nop
0x819713ed <+45>:nop
0x819713ee <+46>:mov%rax,%rcx
0x819713f1 <+49>:rep movsb %ds:(%rsi),%es:(%rdi)
0x819713f3 <+51>:nop
0x819713f4 <+52>:nop
0x819713f5 <+53>:nop
0x819713f6 <+54>:mov%rcx,%rax
0x819713f9 <+57>:nop
0x819713fa <+58>:nop
0x819713fb <+59>:nop
0x819713fc <+60>:jmp0x8206b160 <__x86_return_thunk>
Good asm:
Dump of assembler code for function _copy_to_user:
0x819713f0 <+0>: endbr64
0x819713f4 <+4>: xor%r8d,%r8d
0x819713f7 <+7>: mov%rdx,%rax
0x819713fa <+10>:add%rdi,%rdx
0x819713fd <+13>:setb %r8b
0x81971401 <+17>:movabs $0x123456789abcdef,%rcx
0x8197140b <+27>:cmp%rdx,%rcx
0x8197140e <+30>:jb 0x81971426 <_copy_to_user+54>
this only jumps if the condition failed (where the prediction is that it wont)
0x81971410 <+32>:test %r8,%r8
0x81971413 <+35>:jne0x81971426 <_copy_to_user+54>
ditto
0x81971415 <+37>:nop
0x81971416 <+38>:nop
0x81971417 <+39>:nop
0x81971418 <+40>:mov%rax,%rcx
0x8197141b <+43>:rep movsb %ds:(%rsi),%es:(%rdi)
0x8197141d <+45>:nop
0x8197141e <+46>:nop
0x8197141f <+47>:nop
0x81971420 <+48>:mov%rcx,%rax
0x81971423 <+51>:nop
0x81971424 <+52>:nop
0x81971425 <+53>:nop
0x81971426 <+54>:jmp0x8206b1a0 <__x86_return_thunk>
--
Mateusz Guzik
Re: libdiagnostics name clash
On Thu, 2024-11-28 at 03:56 +, Sam James wrote: > David Malcolm via Gcc writes: > > > I merged libdiagnostics to GCC trunk on Monday: > > https://gcc.gnu.org/wiki/libdiagnostics > > > > Unfortunately I've since discovered there's at least one > > libdiagnostics > > .so already in Debian: > > https://tracker.debian.org/pkg/diagnostics > > https://packages.debian.org/search?searchon=contents&keywords=libdiag&mode=filename&suite=unstable&arch=any > > FWIW, we don't have that packaged and at a glance, we never have. > > > > > so I've been asked to change the name. > > > > I'd prefer to avoid having "gcc" in the name. > > > > Some name ideas: > > > > * libdiag > > * libgdiagnostics (where we can be ambiguous about what the "g" > > stands > > for) > > * libgdiag (less typing) > > * libcomplain > > * libcomplaint > > * libwhining > > * libwhine (but sounds like the Windows compat software) > > I like libwhine > libgdiag > libdiag (libdiag feels too prone to > collision again, and whine has a bit of fun personality). > > I worry that complain gives the impression of like, libabrt/apport or > whatever (those crash reporting libraries/programs). > > But really, all of these sound fine and I'll go with whatever. > Thanks everyone for the suggestions. I've gone ahead with "libgdiagnostics", where I am being deliberately vague about what the "g" stands for: it could be "gnu", "gcc", or "gpl- licensed" as the reader desires. I've: * pushed the renaming to trunk as r15-5811-gbc3597635a708c: https://gcc.gnu.org/pipermail/gcc-patches/2024-November/670459.html * renamed the wiki page to https://gcc.gnu.org/wiki/libgdiagnostics * renamed the BZ component to libgdiagnostics Hopefully this doesn't clash with anything Dave >
