Re: CVS commit: src/include
On Fri, 17 Apr 2020, Kamil Rytarowski wrote: On 17.04.2020 22:22, Joerg Sonnenberger wrote: On Fri, Apr 17, 2020 at 03:22:35PM +, Kamil Rytarowski wrote: Module Name:src Committed By: kamil Date: Fri Apr 17 15:22:35 UTC 2020 Modified Files: src/include: assert.h Log Message: Remove the static_assert() fallback for pre-C11 and pre-C++11 C++ without real static_assert() can be incompatible with the C fallback as presented in openjdk. A pre-C11 compiler can be picky on the implementation. So did you actually test that the tree compiles with this? Just asking, since your own ptrace tests depend on static_assert... Joerg I will fix it! And please test... :) ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: CVS commit: src/include
On 17.04.2020 22:22, Joerg Sonnenberger wrote: > On Fri, Apr 17, 2020 at 03:22:35PM +, Kamil Rytarowski wrote: >> Module Name: src >> Committed By:kamil >> Date:Fri Apr 17 15:22:35 UTC 2020 >> >> Modified Files: >> src/include: assert.h >> >> Log Message: >> Remove the static_assert() fallback for pre-C11 and pre-C++11 >> >> C++ without real static_assert() can be incompatible with the C fallback >> as presented in openjdk. >> >> A pre-C11 compiler can be picky on the implementation. > > So did you actually test that the tree compiles with this? Just asking, > since your own ptrace tests depend on static_assert... > > Joerg > I will fix it! signature.asc Description: OpenPGP digital signature
Re: CVS commit: src/include
On Fri, 17 Apr 2020, Joerg Sonnenberger wrote: On Fri, Apr 17, 2020 at 03:22:35PM +, Kamil Rytarowski wrote: Module Name:src Committed By: kamil Date: Fri Apr 17 15:22:35 UTC 2020 Modified Files: src/include: assert.h Log Message: Remove the static_assert() fallback for pre-C11 and pre-C++11 C++ without real static_assert() can be incompatible with the C fallback as presented in openjdk. A pre-C11 compiler can be picky on the implementation. So did you actually test that the tree compiles with this? Just asking, since your own ptrace tests depend on static_assert... Obviousliy this change was not tested... dependall ===> tests/lib/libc/sys # compile sys/t_ptrace_wait.o /build/netbsd-local/tools/x86_64/amd64/bin/x86_64--netbsd-gcc -O2 -std=gnu99 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-sign-compare -Wsystem-headers -Wno-traditional -Wa,--fatal-warnings -Wreturn-type -Wswitch -Wshadow -Wcast-qual -Wwrite-strings -Wextra -Wno-unused-parameter -Wno-sign-compare -Wsign-compare -Wformat=2 -Wno-format-zero-length -Werror -Wno-missing-noreturn -fPIE -g --sysroot=/build/netbsd-local/dest/amd64 -I/build/netbsd-local/src_ro/tests/lib/libc/sys/../../.. -c -D_KERNTYPES -D__TEST_FENV -DENABLE_TESTS /build/netbsd-local/src_ro/tests/lib/libc/sys/t_ptrace_wait.c /build/netbsd-local/src_ro/tests/lib/libc/sys/t_ptrace_wait.c:77:15: error: expected declaration specifiers or '...' before 'sizeof' static_assert(sizeof(((struct ptrace_state *)0)->pe_report_event) == ^~ /build/netbsd-local/src_ro/tests/lib/libc/sys/t_ptrace_wait.c:79:5: error: expected declaration specifiers or '...' before string constant "pe_report_event and si_pe_report_event must be of the same size"); ^ /build/netbsd-local/src_ro/tests/lib/libc/sys/t_ptrace_wait.c:80:15: error: expected declaration specifiers or '...' before 'sizeof' static_assert(sizeof(((struct ptrace_state *)0)->pe_other_pid) == ^~ /build/netbsd-local/src_ro/tests/lib/libc/sys/t_ptrace_wait.c:82:5: error: expected declaration specifiers or '...' before string constant "pe_other_pid and si_pe_other_pid must be of the same size"); ^~~ /build/netbsd-local/src_ro/tests/lib/libc/sys/t_ptrace_wait.c:83:15: error: expected declaration specifiers or '...' before 'sizeof' static_assert(sizeof(((struct ptrace_state *)0)->pe_lwp) == ^~ /build/netbsd-local/src_ro/tests/lib/libc/sys/t_ptrace_wait.c:85:5: error: expected declaration specifiers or '...' before string constant "pe_lwp and si_pe_lwp must be of the same size"); ^~~ /build/netbsd-local/src_ro/tests/lib/libc/sys/t_ptrace_wait.c:86:15: error: expected declaration specifiers or '...' before 'sizeof' static_assert(sizeof(((struct ptrace_state *)0)->pe_other_pid) == ^~ /build/netbsd-local/src_ro/tests/lib/libc/sys/t_ptrace_wait.c:88:5: error: expected declaration specifiers or '...' before string constant "pe_other_pid and pe_lwp must be of the same size"); ^~ *** [t_ptrace_wait.o] Error code 1 nbmake: stopped in /build/netbsd-local/src_ro ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: CVS commit: src/include
On Fri, Apr 17, 2020 at 03:22:35PM +, Kamil Rytarowski wrote: > Module Name: src > Committed By: kamil > Date: Fri Apr 17 15:22:35 UTC 2020 > > Modified Files: > src/include: assert.h > > Log Message: > Remove the static_assert() fallback for pre-C11 and pre-C++11 > > C++ without real static_assert() can be incompatible with the C fallback > as presented in openjdk. > > A pre-C11 compiler can be picky on the implementation. So did you actually test that the tree compiles with this? Just asking, since your own ptrace tests depend on static_assert... Joerg
Re: CVS commit: src/sys
Date:Fri, 17 Apr 2020 07:52:53 -0700 From:Jason Thorpe Message-ID: <7e54033f-9f14-4db3-a11a-01d63cd92...@me.com> | The New Hotness (which isn't particularly new, at this point) | is to create branches and merge what you want into that branch. What I don't understand, is how this single commit-id works in practice (not how it is generated, I mean how it is used). Say you've got some local changes you're testing, maybe some ARM device driver (or related stuff), and I have local changes as well (maybe some new sh code - I actually have a lot of that, though most of it is no longer "new" and quite possibly none of it will appear in public) - so we're both working from different states of the overall tree. Hence different ID's right? Now imagine that while testing, some schedueller bug causes a panic, or the ATF tests detect some (unrelated to both of us) failure that shouldn't be happening (perhaps rump was neglected in someone's changes from elsewhere, yet again). If we both, along with someone running a pristine tree, all see this failure, perhaps manifesting in slightly different ways, how do we all determine that we're running the same versions of all of the relevant files, and hence are probably all seeing the same bug? Currently, with each file having its own version identfifier, it is easy, but if everything is to share one single "it is this version" ID, how can we know that we are all actually running the same version of whatever code broke and is affecting all of us? kre
Re: CVS commit: src/sys
On Fri, Apr 17, 2020 at 05:01:15PM +0200, Manuel Bouyer wrote: > On Fri, Apr 17, 2020 at 07:52:53AM -0700, Jason Thorpe wrote: > > > > > On Apr 17, 2020, at 7:46 AM, Robert Elz wrote: > > > > > >Date:Fri, 17 Apr 2020 15:37:33 +0200 > > >From:Manuel Bouyer > > >Message-ID: <20200417133733.ga5...@antioche.eu.org> > > > > > > | And that would be a problem for me. I regulary update a single file to > > > a > > > | specific revision in a source tree. > > > > > > Me too - I pull the current sh into NetBSD 8 (and I guess 9 now too, > > > though I haven't done that yet) and build it there for some people who > > > like to test and report bugs. > > > > The New Hotness (which isn't particularly new, at this point) is to create > > branches and merge what you want into that branch. > > Yes, but it's much more work than 'cvs up' in a single directory or against > a few files. > To checkout trunk in just the subdirectory bin/sh you can do: hg revert -r trunk bin/sh for git: git checkout trunk bin/sh Making a commit from this position is a little more awkward. But at least non-CVS repositories make it easier to switch between branches.
Re: CVS commit: src/distrib/utils/libhack
jdolecek@ wrote: > Module Name: src > Committed By: jdolecek > Date: Fri Apr 17 14:55:24 UTC 2020 > > Modified Files: > src/distrib/utils/libhack: Makefile.inc > > Log Message: > include aligned_alloc(3), now needed for newfs and fsck_ffs Could you consider to disable such extra futures in SMALL case, i.e. in src/distrib/utils/x_newfs and src/distrib/utils/x_fsck_ffs, to avoid another overflow on several install media? Thanks, --- Izumi Tsutsui
Re: CVS commit: src/sys
On Fri, Apr 17, 2020 at 07:52:53AM -0700, Jason Thorpe wrote: > > > On Apr 17, 2020, at 7:46 AM, Robert Elz wrote: > > > >Date:Fri, 17 Apr 2020 15:37:33 +0200 > >From:Manuel Bouyer > >Message-ID: <20200417133733.ga5...@antioche.eu.org> > > > > | And that would be a problem for me. I regulary update a single file to a > > | specific revision in a source tree. > > > > Me too - I pull the current sh into NetBSD 8 (and I guess 9 now too, > > though I haven't done that yet) and build it there for some people who > > like to test and report bugs. > > The New Hotness (which isn't particularly new, at this point) is to create > branches and merge what you want into that branch. Yes, but it's much more work than 'cvs up' in a single directory or against a few files. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: CVS commit: src/sys
> On Apr 17, 2020, at 7:46 AM, Robert Elz wrote: > >Date:Fri, 17 Apr 2020 15:37:33 +0200 >From:Manuel Bouyer >Message-ID: <20200417133733.ga5...@antioche.eu.org> > > | And that would be a problem for me. I regulary update a single file to a > | specific revision in a source tree. > > Me too - I pull the current sh into NetBSD 8 (and I guess 9 now too, > though I haven't done that yet) and build it there for some people who > like to test and report bugs. The New Hotness (which isn't particularly new, at this point) is to create branches and merge what you want into that branch. -- thorpej
Re: CVS commit: src/sys
Date:Fri, 17 Apr 2020 15:37:33 +0200 From:Manuel Bouyer Message-ID: <20200417133733.ga5...@antioche.eu.org> | And that would be a problem for me. I regulary update a single file to a | specific revision in a source tree. Me too - I pull the current sh into NetBSD 8 (and I guess 9 now too, though I haven't done that yet) and build it there for some people who like to test and report bugs. (Then I send them the binary to run on their system ... these tend to be bare bones "base only" type systems whose only purpose in existing is to test the shell.) Everything is -8 except the contents of src/bin/sh which is -HEAD. Not being able to easily do that kind of thing would be a nuisance. I could obviously still do it, just by cp -rp HEAD/src/bin/sh 8/src/bin but methods like that are kind of ugly ... and certainly don't comply with any assumption that the entire collection of files has a single commit ID. kre
Re: CVS commit: src/sys
> On Apr 17, 2020, at 6:28 AM, Rin Okuyama wrote: > > On 2020/04/17 22:14, Jason Thorpe wrote: >>> On Apr 17, 2020, at 12:24 AM, Robert Elz wrote: >>> >>> For this, RCS and RCS semantics are irrelevant aren't they? >> No, not really. With the modern systems, the "commit ID" identifies the >> state of the entire collection of files, not individual ones. Thus, you >> only need exactly one instance of the ID, not one ID per file. > > Exactly, but at the same time I think that RCSID is still useful till > we switch to a sane VCS with unique commit ID's. > > The attached patch adds SHF_MERGE|SHF_STRINGS flags as Joerg suggested. > I've confirmed that it works fine both for GCC/binutils and LLVM (for > kernel and userland). > > OK to commit, or objections? I'm fine with this change as a workaround for the current issue with the RCS-style IDs, but it will still be a huge mistake to embed a "commit ID" into every file when we (eventually, hopefully) switch to a modern revision control system because it would obviously require every file with such an embedded to change on each commit, which seems like a really really bad idea. > > Thanks, > rin > -- thorpej
Re: CVS commit: src/sys
On Fri, Apr 17, 2020 at 06:14:26AM -0700, Jason Thorpe wrote: > > > On Apr 17, 2020, at 12:24 AM, Robert Elz wrote: > > > > For this, RCS and RCS semantics are irrelevant aren't they? > > No, not really. With the modern systems, the "commit ID" identifies the > state of the entire collection of files, not individual ones. Thus, you only > need exactly one instance of the ID, not one ID per file. And that would be a problem for me. I regulary update a single file to a specific revision in a source tree. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: CVS commit: src/sys
On 2020/04/17 22:14, Jason Thorpe wrote:
On Apr 17, 2020, at 12:24 AM, Robert Elz wrote:
For this, RCS and RCS semantics are irrelevant aren't they?
No, not really. With the modern systems, the "commit ID" identifies the state
of the entire collection of files, not individual ones. Thus, you only need exactly one
instance of the ID, not one ID per file.
Exactly, but at the same time I think that RCSID is still useful till
we switch to a sane VCS with unique commit ID's.
The attached patch adds SHF_MERGE|SHF_STRINGS flags as Joerg suggested.
I've confirmed that it works fine both for GCC/binutils and LLVM (for
kernel and userland).
OK to commit, or objections?
Thanks,
rin
Index: sys/sys/cdefs_elf.h
===
RCS file: /home/netbsd/src/sys/sys/cdefs_elf.h,v
retrieving revision 1.55
diff -p -u -r1.55 cdefs_elf.h
--- sys/sys/cdefs_elf.h 22 Mar 2020 00:25:01 - 1.55
+++ sys/sys/cdefs_elf.h 17 Apr 2020 13:23:01 -
@@ -136,12 +136,12 @@
#if __STDC__
#define__SECTIONSTRING(_sec, _str)
\
- __asm(".pushsection " #_sec "\n"\
+ __asm(".pushsection " #_sec ", \"MS\", @progbits, 1\n" \
".asciz \"" _str "\"\n" \
".popsection")
#else
#define__SECTIONSTRING(_sec, _str)
\
- __asm(".pushsection _sec\n" \
+ __asm(".pushsection _sec, \"MS\", @progbits, 1\n" \
".asciz \"" _str "\"\n" \
".popsection")
#endif
Re: CVS commit: src/sys
> On Apr 17, 2020, at 12:24 AM, Robert Elz wrote: > > For this, RCS and RCS semantics are irrelevant aren't they? No, not really. With the modern systems, the "commit ID" identifies the state of the entire collection of files, not individual ones. Thus, you only need exactly one instance of the ID, not one ID per file. -- thorpej
Re: CVS commit: src/sys
Date:Thu, 16 Apr 2020 18:04:04 -0700 From:Jason Thorpe Message-ID: <432f538a-b863-441b-b4d0-0cd2e9d38...@me.com> | The sooner we get off of "things that use RCS semantics" the better. For this, RCS and RCS semantics are irrelevant aren't they? The only relevance of RCS to any of this is the name of the macro (and given that it is in almost every source file, I'd think it would need a very good reason to warrant a change - it is just a name after all) and that the contents of the string are currently (usually) automatically updated by RCS (aka CVS). The latter can easily change - the strings could contain any appropriate identification data (commit ID's from whatever system is in use). Using "RCS" in the name is also not really inappropriate, as while there is a revision control system called just "Revision Control System" that's also a generic name that applies to all of them (git, mercury, subversion, cvs, even sccs, all included, along with RCS itself). kre
