On Tue, Apr 7, 2015 at 8:44 PM, Matt Thomas wrote:
>
>> On Apr 7, 2015, at 1:27 AM, Ryota Ozaki wrote:
>>
>> On Tue, Apr 7, 2015 at 5:13 PM, Nick Hudson wrote:
>>> On 04/07/15 04:19, Ryota Ozaki wrote:
Module Name:src
Committed By: ozaki-r
Date: Tue Apr 7 03:
> On Apr 7, 2015, at 1:27 AM, Ryota Ozaki wrote:
>
> On Tue, Apr 7, 2015 at 5:13 PM, Nick Hudson wrote:
>> On 04/07/15 04:19, Ryota Ozaki wrote:
>>>
>>> Module Name:src
>>> Committed By: ozaki-r
>>> Date: Tue Apr 7 03:19:25 UTC 2015
>>>
>>> Modified Files:
>>> src/sys/a
On Tue, Apr 7, 2015 at 5:13 PM, Nick Hudson wrote:
> On 04/07/15 04:19, Ryota Ozaki wrote:
>>
>> Module Name:src
>> Committed By: ozaki-r
>> Date: Tue Apr 7 03:19:25 UTC 2015
>>
>> Modified Files:
>> src/sys/arch/arm/ep93xx: ep93xx_intr.c
>> src/sys/arch/arm/ixp12x
On 04/07/15 04:19, Ryota Ozaki wrote:
Module Name:src
Committed By: ozaki-r
Date: Tue Apr 7 03:19:25 UTC 2015
Modified Files:
src/sys/arch/arm/ep93xx: ep93xx_intr.c
src/sys/arch/arm/ixp12x0: ixp12x0_intr.c
Log Message:
Add missing #include
is preferred, I th
> On Mar 31, 2015, at 3:12 AM, Reinoud Zandijk wrote:
>
> Hi Matt,
>
> On Tue, Mar 31, 2015 at 01:30:50AM +, Matt Thomas wrote:
>> When the cpu gets an exception from kernel mode, the sscratch register will
>> be
>> 0 and curlwp will be in the "tp" register. When the cpu gets an exception
Hi Matt,
On Tue, Mar 31, 2015 at 01:30:50AM +, Matt Thomas wrote:
> When the cpu gets an exception from kernel mode, the sscratch register will be
> 0 and curlwp will be in the "tp" register. When the cpu gets an exception
> from
> user mode, the sscratch register will be a pointer to the cu
>On Wed, Feb 25, 2015 at 08:11:49AM +, Ryo Shimizu wrote:
>> Module Name: src
>> Committed By:ryo
>> Date:Wed Feb 25 08:11:49 UTC 2015
>>
>> Modified Files:
>> src/sys/arch/evbarm/conf: std.nitrogen6
>> src/sys/arch/evbarm/nitrogen6: nitrogen6_machdep.c
>>
>
On Wed, Feb 25, 2015 at 08:11:49AM +, Ryo Shimizu wrote:
> Module Name: src
> Committed By: ryo
> Date: Wed Feb 25 08:11:49 UTC 2015
>
> Modified Files:
> src/sys/arch/evbarm/conf: std.nitrogen6
> src/sys/arch/evbarm/nitrogen6: nitrogen6_machdep.c
>
> Log Message:
> on iM
On Wednesday 11 February 2015 18:12:17 Ryota Ozaki wrote:
> On Wed, Feb 11, 2015 at 5:35 PM, Nick Hudson wrote:
> > On 02/11/15 07:51, Ryota Ozaki wrote:
> >> Module Name:src
> >> Committed By: ozaki-r
> >> Date: Wed Feb 11 07:51:10 UTC 2015
> >>
> >> Modified Files:
> >>
On 02/11/15 08:35, Nick Hudson wrote:
On 02/11/15 07:51, Ryota Ozaki wrote:
Module Name:src
Committed By:ozaki-r
Date:Wed Feb 11 07:51:10 UTC 2015
Modified Files:
src/sys/arch/evbarm/conf: VEXPRESS_A15 files.vexpress std.vexpress
src/sys/arch/evbarm/vexpress: if_smsh_axi
On Wed, Feb 11, 2015 at 5:35 PM, Nick Hudson wrote:
> On 02/11/15 07:51, Ryota Ozaki wrote:
>>
>> Module Name:src
>> Committed By: ozaki-r
>> Date: Wed Feb 11 07:51:10 UTC 2015
>>
>> Modified Files:
>> src/sys/arch/evbarm/conf: VEXPRESS_A15 files.vexpress std.vexpress
>>
On 02/11/15 07:51, Ryota Ozaki wrote:
Module Name:src
Committed By: ozaki-r
Date: Wed Feb 11 07:51:10 UTC 2015
Modified Files:
src/sys/arch/evbarm/conf: VEXPRESS_A15 files.vexpress std.vexpress
src/sys/arch/evbarm/vexpress: if_smsh_axi.c platform.h vexpress_axi.c
On Jan 18, 8:18pm, "Jonathan A. Kollasch" wrote:
}
} This is a multi-part message in MIME format.
}
} --_--=_1421612287110410
} Content-Disposition: inline
} Content-Transfer-Encoding: 8bit
} Content-Type: text/plain; charset="US-ASCII"
}
} Module Name: src
} Committed By: jakllsch
} Da
"NONAKA Kimihiro" writes:
> Module Name: src
> Committed By: nonaka
> Date: Mon Jan 5 08:40:56 UTC 2015
>
> Modified Files:
> src/sys/arch/evbppc/mpc85xx: machdep.c
>
> Log Message:
> Initialize TLB for non cpu0.
this seems to be also done in e500_spinup_trampoline(), a few
inst
"Frank Wille" writes:
> Module Name: src
> Committed By: phx
> Date: Wed Dec 31 18:43:18 UTC 2014
>
> Modified Files:
> src/sys/arch/ofppc/ofppc: mainbus.c
>
> Log Message:
> Make it compile with GCC48.
thanks.
no idea how this didn't trigger for me. we might need
this on netbs
On Wed, Dec 31, 2014 at 11:15:24AM +0100, Martin Husemann wrote:
> On Wed, Dec 31, 2014 at 10:05:22AM +, David Laight wrote:
> > In this case I suspect removing __constfunc and making the
> > asm volatile will force correct sequencing.
>
> Check the commit history.
> Can we make only the hypve
On Wed, Dec 31, 2014 at 10:05:22AM +, David Laight wrote:
> In this case I suspect removing __constfunc and making the
> asm volatile will force correct sequencing.
Check the commit history.
Can we make only the hypverisor call __constfunc?
Martin
On Tue, Dec 30, 2014 at 04:34:42PM -0600, Dennis Ferguson wrote:
>
> On 30 Dec, 2014, at 12:52 , David Laight wrote:
> > Is that the correct fix?
> > Unless the rdpr actually accesses memory (don't think it does) then
> > then problem is probably a missing 'volatile' instead.
> >
> > Certainly t
On 30 Dec, 2014, at 12:52 , David Laight wrote:
> Is that the correct fix?
> Unless the rdpr actually accesses memory (don't think it does) then
> then problem is probably a missing 'volatile' instead.
>
> Certainly the way those asm functions are defined looks to be
> rather more obfuscated tha
On Thu, Dec 25, 2014 at 02:02:04PM +, Takeshi Nakayama wrote:
> Modified Files:
> src/sys/arch/sparc64/include: psl.h
>
> Log Message:
> Put "memory" to asm inline for reading privilege registers on sun4v
> to avoid issuing rdpr %ver before checking cputyp as a result of
> code moving by
> On Dec 20, 2014, at 5:13 AM, John Klos wrote:
>
> Module Name: src
> Committed By: jklos
> Date: Sat Dec 20 13:13:58 UTC 2014
>
> Added Files:
> src/sys/arch/vax/include: autoconf.h
>
> Log Message:
> Added as a placeholder so kernels compile until a better fix is found.
>
>
On Fri, Dec 19, 2014 at 1:44 PM, John Klos wrote:
> Module Name:src
> Committed By: jklos
> Date: Fri Dec 19 04:44:13 UTC 2014
>
> Modified Files:
> src/sys/arch/vax/conf: GENERIC files.vax majors.vax
> Added Files:
> src/sys/arch/vax/vsa: vsaudio.c
>
> Log Message:
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
On 11/28/14 15:37, Nick Hudson wrote:
Module Name:src
Committed By: skrll
Date: Fri Nov 28 15:37:02 UTC 2014
Modified Files:
src/sys/arch/arm/include: profile.h
Log Message:
Fix __mconunt in the !(__ARM_EABI__) case by opoing the right number of
registers on exit.
The
>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;
> - *
> On Nov 11, 2014, at 6:19 PM, Michael wrote:
>
> Hello,
>
> On Tue, 11 Nov 2014 23:14:18 +0100
> Martin Husemann wrote:
>
>> On Tue, Nov 11, 2014 at 02:10:08PM -0800, John Nemeth wrote:
>>> } >The latest import fixed m68k (but tsutsui-san asked for a bit more
>>> testing,
>>> } >which I did
Hello,
On Tue, 11 Nov 2014 23:14:18 +0100
Martin Husemann wrote:
> On Tue, Nov 11, 2014 at 02:10:08PM -0800, John Nemeth wrote:
> > } >The latest import fixed m68k (but tsutsui-san asked for a bit more
> > testing,
> > } >which I didn't manage to get around too yet).
> > }
> > } If you switch,
Hello,
On Tue, 11 Nov 2014 18:36:37 -0500
chris...@zoulas.com (Christos Zoulas) wrote:
> On Nov 11, 11:14pm, mar...@duskware.de (Martin Husemann) wrote:
> -- Subject: Re: CVS commit: src/sys/arch
>
> | The request for more testing before switching was not unreasonable, and
> | I
On Nov 11, 11:14pm, mar...@duskware.de (Martin Husemann) wrote:
-- Subject: Re: CVS commit: src/sys/arch
| The request for more testing before switching was not unreasonable, and
| I bet the amount of people testing -current on m68k is pretty limited anyway.
|
| However, I'm updating my m
On Tue, Nov 11, 2014 at 02:10:08PM -0800, John Nemeth wrote:
> } >The latest import fixed m68k (but tsutsui-san asked for a bit more testing,
> } >which I didn't manage to get around too yet).
> }
> } If you switch, more people will test :-)
>
> Or, tsutsui-san will back it out. :->
The re
On Nov 11, 6:59pm, Christos Zoulas wrote:
} In article <2014163355.gk8...@mail.duskware.de>,
} Martin Husemann wrote:
} >On Tue, Nov 11, 2014 at 04:29:44PM +, Christos Zoulas wrote:
} >> Can we move powerpc to gcc-4.8 then? What about m68k? It would be great
} >> if those could be done f
In article <2014163355.gk8...@mail.duskware.de>,
Martin Husemann wrote:
>On Tue, Nov 11, 2014 at 04:29:44PM +, Christos Zoulas wrote:
>> Can we move powerpc to gcc-4.8 then? What about m68k? It would be great
>> if those could be done for -7!
>
>The latest import fixed m68k (but tsutsui-s
On Tue, Nov 11, 2014 at 04:29:44PM +, Christos Zoulas wrote:
> Can we move powerpc to gcc-4.8 then? What about m68k? It would be great
> if those could be done for -7!
The latest import fixed m68k (but tsutsui-san asked for a bit more testing,
which I didn't manage to get around too yet).
Mar
In article <20141110234332.5411cead@blackbush>,
Michael wrote:
>
>And a clang-built kernel boots just fine now, at least on my beige G3.
>Going to torture it for a bit now.
Can we move powerpc to gcc-4.8 then? What about m68k? It would be great
if those could be done for -7!
christos
Hello,
On Mon, 10 Nov 2014 08:00:03 -0800
Chuck Silvers wrote:
> On Sun, Nov 09, 2014 at 08:34:38AM -0500, Michael wrote:
> > On Sun, 9 Nov 2014 00:05:06 +
> > "Chuck Silvers" wrote:
> >
> > > Module Name: src
> > > Committed By: chs
> > > Date: Sun Nov 9 00:05:06 UTC
Hello,
On Mon, 10 Nov 2014 08:00:03 -0800
Chuck Silvers wrote:
> On Sun, Nov 09, 2014 at 08:34:38AM -0500, Michael wrote:
> > On Sun, 9 Nov 2014 00:05:06 +
> > "Chuck Silvers" wrote:
> >
> > > Module Name: src
> > > Committed By: chs
> > > Date: Sun Nov 9 00:05:06 UTC
On Sun, Nov 09, 2014 at 08:34:38AM -0500, Michael wrote:
> On Sun, 9 Nov 2014 00:05:06 +
> "Chuck Silvers" wrote:
>
> > Module Name:src
> > Committed By: chs
> > Date: Sun Nov 9 00:05:06 UTC 2014
> >
> > Modified Files:
> > src/sys/arch/macppc/macppc: locore.
901 - 1000 of 1962 matches
Mail list logo
