Module Name:src
Committed By: tsutsui
Date: Sun Jul 3 16:16:50 UTC 2022
Modified Files:
src/sys/arch/atari/stand/installboot: Makefile installboot.c
Log Message:
Fix inverted logic. My fault back in 2015..
To generate a diff of this commit:
cvs rdiff -u -r1.10 -r1.11 s
Module Name:src
Committed By: tsutsui
Date: Sun Jul 3 16:16:50 UTC 2022
Modified Files:
src/sys/arch/atari/stand/installboot: Makefile installboot.c
Log Message:
Fix inverted logic. My fault back in 2015..
To generate a diff of this commit:
cvs rdiff -u -r1.10 -r1.11 s
Module Name:src
Committed By: rin
Date: Wed May 11 10:31:12 UTC 2022
Modified Files:
src/sys/arch/atari/stand/installboot: installboot.c
Log Message:
Make FD support optional (intended for install media).
To generate a diff of this commit:
cvs rdiff -u -r1.37 -r1.38 src/
Module Name:src
Committed By: rin
Date: Wed May 11 10:31:12 UTC 2022
Modified Files:
src/sys/arch/atari/stand/installboot: installboot.c
Log Message:
Make FD support optional (intended for install media).
To generate a diff of this commit:
cvs rdiff -u -r1.37 -r1.38 src/
Module Name:src
Committed By: rin
Date: Wed May 11 10:27:45 UTC 2022
Modified Files:
src/sys/arch/atari/stand/installboot: installboot.c
Log Message:
Refactor install_[sw]d() into install_hd().
Shave off ~0.5KB from install floppy, and dedup codes a lot.
Thanks tsutsui@
Module Name:src
Committed By: rin
Date: Wed May 11 10:27:45 UTC 2022
Modified Files:
src/sys/arch/atari/stand/installboot: installboot.c
Log Message:
Refactor install_[sw]d() into install_hd().
Shave off ~0.5KB from install floppy, and dedup codes a lot.
Thanks tsutsui@
On Mon, Nov 24, 2014 at 02:36:51PM +, Taylor R Campbell wrote:
>
> In the case of abcksum, if you have
>
> uint8_t p[512];
> ...
> *((uint16_t *)p + 255) = 0;
> *((uint16_t *)p + 255) = abcksum(p);
>
> GCC may choose to evaluate abcksum before the zero assignment, because
> no uint16_t is al
On Fri, Nov 14, 2014 at 02:43:39AM +0900, Izumi Tsutsui wrote:
> christos@ wrote:
>
> > Module Name:src
> > Committed By: christos
> > Date: Thu Nov 13 17:19:29 UTC 2014
> >
> > Modified Files:
> > src/sys/arch/atari/stand/installboot: installboot.c
> >
> > Log Me
>If you can confirm current netbsd-7 or netbsd-6 binaries are already
> broken,
>please let me know.
>
> I can't say without actually scrutinizing the generated code. It
> would be safer to just set -fno-strict-aliasing since the code does
> rely on violating the rules.
Again, this is a
Date: Mon, 24 Nov 2014 23:50:12 +0900
From: Izumi Tsutsui
If you can confirm current netbsd-7 or netbsd-6 binaries are already broken,
please let me know.
I can't say without actually scrutinizing the generated code. It
would be safer to just set -fno-strict-aliasing since the code
> GCC may choose
Ok, ok.
If you can confirm current netbsd-7 or netbsd-6 binaries are already broken,
please let me know.
---
Izumi Tsutsui
Date: Mon, 24 Nov 2014 22:39:24 +0900
From: Izumi Tsutsui
I don't think it's worth because binaries have worked without changes.
(if the compiler tries reorder optimization per strict-aliasing rule
I guess wrong implementation will be warned at that time)
No -- GCC will only warn
mrg@ wrote:
> Nick Hudson writes:
> > > Log Message:
> > > Specify -fno-strict-aliasing as a temporary workaround for gcc48.
:
> > > Should be pulled up to netbsd-7 if we switches m68k to using gcc48.
> > >
> > Why not pullup in anticipation?
Because it doesn't give any visible benefits (except
Nick Hudson writes:
> On 11/24/14 07:52, Izumi Tsutsui wrote:
> > Module Name:src
> > Committed By: tsutsui
> > Date: Mon Nov 24 07:52:04 UTC 2014
> >
> > Modified Files:
> > src/sys/arch/atari/stand/installboot: Makefile
> >
> > Log Message:
> > Specify -fno-strict
On 11/24/14 07:52, Izumi Tsutsui wrote:
Module Name:src
Committed By: tsutsui
Date: Mon Nov 24 07:52:04 UTC 2014
Modified Files:
src/sys/arch/atari/stand/installboot: Makefile
Log Message:
Specify -fno-strict-aliasing as a temporary workaround for gcc48.
The existing ab
> Module Name: src
> Committed By: tsutsui
> Date: Mon Nov 24 07:52:04 UTC 2014
>
> Modified Files:
> src/sys/arch/atari/stand/installboot: Makefile
>
> Log Message:
> Specify -fno-strict-aliasing as a temporary workaround for gcc48.
>
> The existing abcksum() also violates stric
christos@ wrote:
> On Nov 24, 7:18am, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote:
> | Then you don't have any patch for existing (and not warned) abcksum().
> | Are you also okay to specify -fno-strict-aliasing with the original code
> | as I and mrg (and now Taylor) suggest, rather than patch
On Nov 24, 7:18am, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote:
-- Subject: Re: CVS commit: src/sys/arch/atari/stand/installboot
| Then you don't have any patch for existing (and not warned) abcksum().
| Are you also okay to specify -fno-strict-aliasing with the original code
| as I an
christos@ wrote:
> | Taylor claims the existing abcksum() also violates aliasing rule.
> | http://mail-index.netbsd.org/source-changes-d/2014/11/23/msg007402.html
> |
> | If he is correct it's no sense to tweak only functions complained
> | by current gcc48.
>
> Yes, both solutions (your post a
On Nov 24, 4:55am, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote:
-- Subject: Re: CVS commit: src/sys/arch/atari/stand/installboot
| > Yes, taking this approach to the extreme we should never switch compilers.
|
| Please stop such "extreme or nothing" approach if you cannot maintai
Date: Mon, 24 Nov 2014 04:46:31 +0900
From: Izumi Tsutsui
Christos said "it is legally converting a void * pointer."
http://mail-index.netbsd.org/source-changes-d/2014/11/16/msg007356.html
You guys have different opinions. Which is correct?
Which C99 specification you think t
christos@ wrote:
> | > -static u_int abcksum(void *);
> | > +static void abcksum(void *);
> |
> | Changing existing functions requires more tests and
> | it's annoying for maintainers, especially for netbsd-7.
>
> Yes, taking this approach to the extreme we should never switch compilers
>I'd like to hear your answer of my dumb question:
>http://mail-index.netbsd.org/source-changes-d/2014/11/16/msg007354.html
>
> `Then why don't you guys also complain to fix existing abcksum()
> function which is called at the suggested memcpy?'
>
> I didn't see it before. The existing a
On Nov 24, 4:01am, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote:
-- Subject: Re: CVS commit: src/sys/arch/atari/stand/installboot
| > -static u_int abcksum(void *);
| > +static voidabcksum(void *);
|
| Changing existing functions requires more tests and
| it's a
Date: Mon, 24 Nov 2014 03:20:27 +0900
From: Izumi Tsutsui
riastradh@ wrote:
> As is, there are obviously violations, but we have papered over them
> enough that GCC isn't smart enough to warn about them: the void * cast
> through abcksum
I'd like to hear your answer of my d
christos@ wrote:
> How about this then,
:
> -static u_int abcksum(void *);
> +static void abcksum(void *);
Changing existing functions requires more tests and
it's annoying for maintainers, especially for netbsd-7.
Please don't assume we have unlimited resources and
remember that we need just
riastradh@ wrote:
> As is, there are obviously violations, but we have papered over them
> enough that GCC isn't smart enough to warn about them: the void * cast
> through abcksum
I'd like to hear your answer of my dumb question:
http://mail-index.netbsd.org/source-changes-d/2014/11/16/msg007354.
On Nov 24, 2:28am, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote:
-- Subject: Re: CVS commit: src/sys/arch/atari/stand/installboot
| christos@ wrote:
|
| > | http://mail-index.netbsd.org/source-changes-d/2014/11/15/msg007338.html
| >
| > I could not have tested; I asked you to tes
christos@ wrote:
> | http://mail-index.netbsd.org/source-changes-d/2014/11/15/msg007338.html
>
> I could not have tested; I asked you to test.
I didn't tested it either.
I noticed your obvious wrong pointer calculation by code inspection,
and it means memcpy() would confuse future maintainers "
On Nov 24, 12:06am, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote:
-- Subject: Re: CVS commit: src/sys/arch/atari/stand/installboot
| One major problem of the NetBSD Project is that we don't have any
| well defined procedure to get majority.
| (we don't have enough activities or a p
How about we take one of tsutsui@'s earlier suggestions and compile
the code in question with -fno-strict-aliasing, and revert to the
original code, until someone can go over the whole thing to clean up
the strict-aliasing violations? That way, the bad code will work as
originally intended and wil
christos@ wrote:
> Until that stops working, or being available. I think we should
> let the majority decide what's appropriate.
One major problem of the NetBSD Project is that we don't have any
well defined procedure to get majority.
(we don't have enough activities or a person like Linus unfort
> | -fno-strict-aliasing in MD is acceptable compromise for me.
>
> Until that stops working, or being available. I think we should
> let the majority decide what's appropriate.
if -fstrict-aliasing becomes the only option than we'll need a
few years to clean up the kernel.
ie, i don't think th
On Nov 19, 1:48am, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote:
-- Subject: Re: CVS commit: src/sys/arch/atari/stand/installboot
| christos@ wrote:
|
| > Best for me would have been MI installboot; compromise is make it compile
| > correctly without special handling.
|
| Well, it&#
christos@ wrote:
> Best for me would have been MI installboot; compromise is make it compile
> correctly without special handling.
Well, it's still your personalized opinion.
-fno-strict-aliasing in MD is acceptable compromise for me.
It's much worse to commit untested broken code.
If "responsib
On Nov 18, 11:27pm, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote:
-- Subject: Re: CVS commit: src/sys/arch/atari/stand/installboot
| christos@ wrote:
|
| > | I still don't understand why people don't want one additional
| > | -fno-strict-aliasing even for Tier-II port
christos@ wrote:
> | I still don't understand why people don't want one additional
> | -fno-strict-aliasing even for Tier-II ports...
> |
> http://nxr.netbsd.org/search?q=fno-strict-aliasing&project=src&defs=&refs=&path=%2Fsrc%2Fsys
>
> You evolve the code with the language, and you fix things a
On Nov 18, 12:05am, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote:
-- Subject: Re: CVS commit: src/sys/arch/atari/stand/installboot
| I still don't understand why people don't want one additional
| -fno-strict-aliasing even for Tier-II ports...
|
http://nxr.netbsd.org/search?q=
martin@ wrote:
> (and not paper over it by disabling some optimizations in the
> current compiler).
I still don't understand why people don't want one additional
-fno-strict-aliasing even for Tier-II ports...
http://nxr.netbsd.org/search?q=fno-strict-aliasing&project=src&defs=&refs=&path=%2Fsrc%2
Date: Mon, 17 Nov 2014 15:55:56 +0100
From: Martin Husemann
On Mon, Nov 17, 2014 at 11:48:49PM +0900, Izumi Tsutsui wrote:
> You don't think consistently using uint16_t assingments is not necessary.
> I think it's necessary to explicitly describe how cksum should be
> caluclated
On Mon, Nov 17, 2014 at 11:48:49PM +0900, Izumi Tsutsui wrote:
> You don't think consistently using uint16_t assingments is not necessary.
> I think it's necessary to explicitly describe how cksum should be
> caluclated and written. Both are personal opinions, and I don't think
> there is a "right
christos@ wrote:
> | So you are a person who are just interested in correctness
> | but ignoring readabilty (no one can see why one uses normal
> | assignments and others uses stream). Why don't you change
> | the cksum assignment to convert via void * pointer?
>
> Why does everything have to be
On Nov 17, 10:06pm, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote:
-- Subject: Re: CVS commit: src/sys/arch/atari/stand/installboot
| So you are a person who are just interested in correctness
| but ignoring readabilty (no one can see why one uses normal
| assignments and others uses stream
christos@ wrote:
> | > Yes be16enc() should work just fine, I think.
> |
> | Then why don't you guys also complain to fix existing abcksum() function
> | which is called at the suggested memcpy?
>
> Because it is legally converting a void * pointer.
So you are a person who are just interested i
On Nov 17, 5:50am, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote:
-- Subject: Re: CVS commit: src/sys/arch/atari/stand/installboot
| christos@ wrote:
|
| > Yes be16enc() should work just fine, I think.
|
| Then why don't you guys also complain to fix existing abcksum() function
|
christos@ wrote:
> Yes be16enc() should work just fine, I think.
Then why don't you guys also complain to fix existing abcksum() function
which is called at the suggested memcpy?
---
/* set AHDI checksum */
sum = 0;
memcpy(bb->bb_xxboot + 255 * sizeof(sum), &sum, sizeof(s
On Nov 16, 6:07pm, campbell+netbsd-source-change...@mumble.net (Taylor R
Campbell) wrote:
-- Subject: Re: CVS commit: src/sys/arch/atari/stand/installboot
|Date: Mon, 17 Nov 2014 01:37:37 +0900
|From: Izumi Tsutsui
|
|> Changing `*(uint16_t *)p = v' to `memcpy(p, &v,
Date: Mon, 17 Nov 2014 01:37:37 +0900
From: Izumi Tsutsui
> Changing `*(uint16_t *)p = v' to `memcpy(p, &v, 2)' doesn't change any
> of that.
The formar can be easily changed
*(uint16_t *)p = htobe16(v);
but the latter can't. You might be able to use functions like
host1
On Nov 17, 1:37am, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote:
-- Subject: Re: CVS commit: src/sys/arch/atari/stand/installboot
| Then what's your point?
| Should we always strictly use memcpy even in MD code you won't maintain?
|
| If you really don't like current code, I&
> It's access via two different pointers, which happen to have the same
> bits by virtue of being stored in a union -- the union doesn't
> actually do anything about aliasing of the pointed-to object, except
> probably confuse gcc.
>
> The point is that you can't get at one object in memory throug
Date: Sun, 16 Nov 2014 12:51:34 +0900
From: Izumi Tsutsui
My understanding is the strict aliasing rule is referred by compiler
for reorder optimization etc. If the access via union is still invalid,
why does the strict gcc48 no longer complain against it?
It's access via two diff
On Nov 16, 1:20pm, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote:
-- Subject: Re: CVS commit: src/sys/arch/atari/stand/installboot
| Christos, could you please at least compile before commit?
I compiled, but not with the right flags (obviously).
| http://mail-index.netbsd.org/source-changes
christos@ wrote:
> | Program received signal SIGSEGV, Segmentation fault.
> | 0x0007d662 in mbrtowc (ps=0x0, max_sz=1, str=0xffefdc27 "0123456789",
> wc=0x0)
> | at /r/work/netbsd-7/src/distrib/utils/libhack/multibyte.c:15
> | 15 return str == NULL || (*wc = (unsigned char)*str)
>- uint16_t sum;
>+ union {
>+ struct bootblock *bbp;
>+ uint16_t *word; /* to fill cksum word */
>+ } bbsec;
>...
>- sum = 0;
>- memcpy(bb->bb_xxboot + 255 * sizeof(sum), &sum, sizeof(sum));
>- sum = 0x1234 - abcksum(bb->b
Date: Sat, 15 Nov 2014 13:43:16 +0900
From: Izumi Tsutsui
-uint16_t sum;
+union {
+struct bootblock *bbp;
+uint16_t *word; /* to fill cksum word */
+} bbsec;
...
-sum = 0;
-memcpy(bb->bb_xxboot + 255 * sizeo
On Nov 15, 10:46pm, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote:
-- Subject: Re: CVS commit: src/sys/arch/atari/stand/installboot
| Program received signal SIGSEGV, Segmentation fault.
| 0x0007d662 in mbrtowc (ps=0x0, max_sz=1, str=0xffefdc27 "0123456789", wc=0x0)
| at /r/work/ne
On Nov 15, 1:43pm, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote:
-- Subject: Re: CVS commit: src/sys/arch/atari/stand/installboot
| How about this one? (cksum seems updated properly on the real machine)
That looks nicer, go for it!
christos
|
| --- installboot/installboot.c 2014-11-14 13:21
I wrote:
> With unstripped binary, it looks distrib/utils/libhack issue?
>
> ---
> (gdb) run y/0123456789/abcdefghij/
> Starting program:
> /r/work/netbsd-7/src/distrib/atari/floppies/install/obj.atari/sed/sed
> y/0123456789/abcdefghij/
>
> Program received signal SIGSEGV, Segmentation fault.
martin@ wrote:
> I still don't see the segmentation violation - what am I missing?
> Gdb is a bit confused about the stack:
>
> (gdb) bt
> #0 0x0008c2b8 in ?? ()
> #1 0xaba4 in ?? ()
> #2 0xbc34 in ?? ()
> #3 0x0006fce8 in ?? ()
> #4 0x in ?? ()
With unstripped binary, it lo
christos@ wrote:
> On Nov 14, 3:00am, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote:
> | "Test it (or call for testers) before commit"
> | because installboot could be fatal on install floppy and bootstrap.
> |
> | > but memcpy is the only way.
> |
> | - cast via (void *)
>
> That does not wo
On 14 Nov, 2014, at 14:18 , Martin Husemann wrote:
> I still don't see the segmentation violation - what am I missing?
> Gdb is a bit confused about the stack:
This
0x8c2b4: movel %d1,%a1@+
looks a little suspicious. %a1 seems to be 0x4.
Dennis Ferguson
On Fri, Nov 14, 2014 at 11:03:15PM +0100, Martin Husemann wrote:
> Core was generated by `sed'.
> Program terminated with signal SIGSEGV, Segmentation fault.
> ...
>0x8c2b4: movel %d1,%a1@+
>0x8c2b6: beqs 0x8c2be
> => 0x8c2b8: addql #1,%d0
>0x8c2ba: cmpl %d0,%d2
>0x8
> On Nov 15, 3:59am, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote:
> | You can test it on tme by copying crunched "/usr/bin/sed" binary
> | from netbsd-7 atari's sysinst.fs.gz:
> |
> ftp://nyftp.netbsd.org/pub/NetBSD-daily/netbsd-7/201411140020Z/atari/installation/miniroot/sysinst.fs.gz
> |
> |
On Nov 15, 3:59am, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote:
-- Subject: Re: CVS commit: src/sys/arch/atari/stand/installboot
| christos@ wrote:
|
| > Well, the code should be functionally equivalent
|
| There were many examples "readability is better" for ancient ports.
christos@ wrote:
> Well, the code should be functionally equivalent
There were many examples "readability is better" for ancient ports.
In most cases, geeks who knows the machines are not familiar
with NetBSD, and NetBSD geeks don't know the hardware behaivor.
> and I doubt that anyone
> has ev
On Nov 15, 2:29am, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote:
-- Subject: Re: CVS commit: src/sys/arch/atari/stand/installboot
| Hmm. How about -fno-strict-aliasing?
Hmm, no :-)
| >
| > That works...
| >
| > | - be16enc(9)
| >
| > I don't see how that helps...
|
christos@ wrote:
> | > but memcpy is the only way.
> |
> | - cast via (void *)
>
> That does not work.
Hmm. How about -fno-strict-aliasing?
> | - union {uint16_t w[256]; struct bootblock bbp;}
>
> That works...
>
> | - be16enc(9)
>
> I don't see how that helps...
There are two points:
- T
On Nov 14, 3:00am, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote:
-- Subject: Re: CVS commit: src/sys/arch/atari/stand/installboot
| "Test it (or call for testers) before commit"
| because installboot could be fatal on install floppy and bootstrap.
|
| > but memcpy is the only way
christos@ wrote:
> On Nov 14, 2:43am, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote:
> -- Subject: Re: CVS commit: src/sys/arch/atari/stand/installboot
>
> | christos@ wrote:
> |
> | > Module Name: src
> | > Committed By: christos
> | > Date:
On Nov 14, 2:43am, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote:
-- Subject: Re: CVS commit: src/sys/arch/atari/stand/installboot
| christos@ wrote:
|
| > Module Name:src
| > Committed By: christos
| > Date: Thu Nov 13 17:19:29 UTC 2014
| >
| >
christos@ wrote:
> Module Name: src
> Committed By: christos
> Date: Thu Nov 13 17:19:29 UTC 2014
>
> Modified Files:
> src/sys/arch/atari/stand/installboot: installboot.c
>
> Log Message:
> fix strict aliasing violations
> - *((u_int16_t *)bb->bb_xxboot + 255) = 0;
> - *
71 matches
Mail list logo
