On Friday 11 June 2010 23:31:57 Dag-Erling Smørgrav wrote:
> Tijl Coosemans writes:
>> Dag-Erling Smørgrav writes:
>>> #define FORCE_ASSIGN(type, var, value) \
>>> *(volatile type *)&(var) = (value)
>> memset can be optimised away as well. The only way is to declare
>> those variables vol
Bernd Walter writes:
> Dag-Erling Smørgrav writes:
> > Those are freestanding environments, where printf() and puts() don't
> > exist as far as the C standard is concerned.
> Most controller environments have some kind of libc.
They are still freestanding environments.
Can we agree not to discu
2010/6/14 Peter Jeremy :
> On 2010-Jun-13 10:07:15 +0200, Dag-Erling Smørgrav wrote:
>>You always overwrite passphrases, keys etc. as soon as you're done with
>>them so they don't end up in a crash dump or on a swap disk or
>>something.
>
> Which brings up an associated issue: By default, mlock(2)
On Sun, Jun 13, 2010 at 11:35 PM, Bernd Walter wrote:
> Crypto code wasn't aware of this problem and this is a way more
> obviuous optimization than function exchange.
> And I do believe that the programmers were clever people.
> Alarming, isn't it?
> Maybe paranoid users might consider compiling
On 2010-Jun-13 10:07:15 +0200, Dag-Erling Smørgrav wrote:
>You always overwrite passphrases, keys etc. as soon as you're done with
>them so they don't end up in a crash dump or on a swap disk or
>something.
Which brings up an associated issue: By default, mlock(2) can only be
used by root process
On Sun, Jun 13, 2010 at 11:41:03PM +0200, Dag-Erling Smørgrav wrote:
> Bernd Walter writes:
> > Dag-Erling Smørgrav writes:
> > > The only way you can tell that gcc did it is if you break the rules,
> > > such as by defining your own version of printf() or puts().
> > Our loader stages do this fo
Le Sun, 13 Jun 2010 23:35:12 +0200,
Bernd Walter a écrit :
> Go back to the originating mail.
> Crypto code wasn't aware of this problem and this is a way more
> obviuous optimization than function exchange.
> And I do believe that the programmers were clever people.
> Alarming, isn't it?
The re
Bernd Walter writes:
> Dag-Erling Smørgrav writes:
> > The only way you can tell that gcc did it is if you break the rules,
> > such as by defining your own version of printf() or puts().
> Our loader stages do this for good reasons. And in microcontroller
> programming (surely out of FreeBSD sc
On Mon, Jun 14, 2010 at 02:20:26AM +1000, Andrew Milton wrote:
> +---[ Bernd Walter ]--
> | On Sun, Jun 13, 2010 at 05:44:29PM +0200, Dag-Erling Smørgrav wrote:
> | > Bernd Walter writes:
> | > > Amazing - this is one of the things which can get nasty if you try some
> | >
On Sun, Jun 13, 2010 at 06:14:11PM +0200, Dag-Erling Smørgrav wrote:
> Bernd Walter writes:
> > Dag-Erling Smørgrav writes:
> > > Bernd Walter writes:
> > > > Amazing - this is one of the things which can get nasty if you try
> > > > some kind of microtuning.
> > > Only if you break the rules.
+---[ Bernd Walter ]--
| On Sun, Jun 13, 2010 at 05:44:29PM +0200, Dag-Erling Smørgrav wrote:
| > Bernd Walter writes:
| > > Amazing - this is one of the things which can get nasty if you try some
| > > kind of microtuning.
| >
| > Only if you break the rules. Bad code is
Bernd Walter writes:
> Dag-Erling Smørgrav writes:
> > Bernd Walter writes:
> > > Amazing - this is one of the things which can get nasty if you try
> > > some kind of microtuning.
> > Only if you break the rules. Bad code is always bad, even if it
> > sometimes works by accident.
> To expect t
On Sun, Jun 13, 2010 at 05:44:29PM +0200, Dag-Erling Smørgrav wrote:
> Bernd Walter writes:
> > Amazing - this is one of the things which can get nasty if you try some
> > kind of microtuning.
>
> Only if you break the rules. Bad code is always bad, even if it
> sometimes works by accident.
To
Bernd Walter writes:
> Amazing - this is one of the things which can get nasty if you try some
> kind of microtuning.
Only if you break the rules. Bad code is always bad, even if it
sometimes works by accident.
DES
--
Dag-Erling Smørgrav - d...@des.no
__
On Sun, Jun 13, 2010 at 12:44:03PM +0200, Matthias Andree wrote:
> Am 13.06.2010, 00:52 Uhr, schrieb Bernd Walter:
>
> >>In more general terms, the compiler is allowed to make any changes it
> >>likes to the program as long as the end result behaves exactly like it
> >>would if it hadn't been chan
Am 13.06.2010, 00:52 Uhr, schrieb Bernd Walter:
In more general terms, the compiler is allowed to make any changes it
likes to the program as long as the end result behaves exactly like it
would if it hadn't been changed. This is called the "as if" rule. For
instance, if you call printf() or f
On Sun, Jun 13, 2010 at 12:17:50AM +, Bruce Cran wrote:
> On Sun, Jun 13, 2010 at 12:52:16AM +0200, Bernd Walter wrote:
> > I'm at least sure that the compiler can't if it is linked from another
> > object file.
>
> Is that still true if LTO is enabled?
Good question - I wasn't aware of LTO.
Bernd Walter writes:
> Dag-Erling Smørgrav writes:
> > Bernd Walter writes:
> > > I'm not sure when removing a memset is allowed.
> > Always, if the compiler can determine that the data will not be used
> > later.
> I'm at least sure that the compiler can't if it is linked from another
> object
On Sun, Jun 13, 2010 at 12:52:16AM +0200, Bernd Walter wrote:
> I'm at least sure that the compiler can't if it is linked from another
> object file.
Is that still true if LTO is enabled?
--
Bruce Cran
___
freebsd-current@freebsd.org mailing list
http:
Bernd Walter wrote:
> But calling my_abolsutely_not_inlineable_memset should work IMHO.
Try gcc -fno-builtin-memset
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "f
On Sat, Jun 12, 2010 at 07:35:26PM +0200, Dag-Erling Smørgrav wrote:
> Bernd Walter writes:
> > I'm not sure when removing a memset is allowed.
>
> Always, if the compiler can determine that the data will not be used
> later.
I'm at least sure that the compiler can't if it is linked from another
Bernd Walter writes:
> I'm not sure when removing a memset is allowed.
Always, if the compiler can determine that the data will not be used
later.
In more general terms, the compiler is allowed to make any changes it
likes to the program as long as the end result behaves exactly like it
would if
On Sat, Jun 12, 2010 at 05:35:28PM +0200, Ulrich Spörlein wrote:
> On Fri, 11.06.2010 at 21:37:29 +0200, Dag-Erling Smørgrav wrote:
> > Ulrich Spörlein writes:
> > > optimizing compilers have a tendency to remove assignments that have
> > > no side effects. The code in sys/crypto/sha2/sha2.c is do
On Fri, 11.06.2010 at 21:37:29 +0200, Dag-Erling Smørgrav wrote:
> Ulrich Spörlein writes:
> > optimizing compilers have a tendency to remove assignments that have
> > no side effects. The code in sys/crypto/sha2/sha2.c is doing a lot of
> > zeroing variables, which is however optimized away. [..
Tijl Coosemans writes:
> Dag-Erling Smørgrav writes:
> > #define FORCE_ASSIGN(type, var, value) \
> > *(volatile type *)&(var) = (value)
> memset can be optimised away as well. The only way is to declare those
> variables volatile.
Assigning through a volatile pointer, as in FORCE_ASSIGN
On Friday 11 June 2010 21:37:29 Dag-Erling Smørgrav wrote:
> Ulrich Spörlein writes:
>> optimizing compilers have a tendency to remove assignments that have
>> no side effects. The code in sys/crypto/sha2/sha2.c is doing a lot
>> of zeroing variables, which is however optimized away. [...] Is
>>
Ulrich Spörlein writes:
> optimizing compilers have a tendency to remove assignments that have
> no side effects. The code in sys/crypto/sha2/sha2.c is doing a lot of
> zeroing variables, which is however optimized away. [...] Is there a
> canonical way to zero those variables and should we use
27 matches
Mail list logo
