lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sun, 13 Apr 2008 20:03:51 +0200
From:	"Alexander van Heukelum" <heukelum@...tmail.fm>
To:	"Andi Kleen" <andi@...stfloor.org>,
	"Alexander van Heukelum" <heukelum@...lshack.com>
Cc:	"Ingo Molnar" <mingo@...e.hu>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] x86: always_inline wrapper for x86's test_bit

On Sun, 13 Apr 2008 18:58:30 +0200, "Andi Kleen" <andi@...stfloor.org>
said:
> Alexander van Heukelum <heukelum@...lshack.com> writes:
> 
> > On x86, test_bit is currently implemented as a preprocessor macro. It
> > uses gcc's __builtin_constant_p to determine if the bit position is 
> > known at compile time and defers to one of two functions depending
> > on that. This changes the same logic to an __always_inline wrapper
> > instead.
> 
> Some old gccs didn't support __builtin_constant_p in inline properly,
> that is why it was always written in macros.
> 
> Please double check with the oldest still supported gcc (3.2) if it 
> really generates the expected code for the constant/non constant case.

Hi Andi,

I have googled, but the only problem I found was concerning dead code 
elimination, and in particular references to unavailable object from
code that was expected to be discarded. The worst that can happen in 
this case is that gcc might produce a strange construction where a
runtime check will choose between the two alternative implementations of
test_bit. Another is that it will select the 'wrong' implementation. 
Both will result is some code-bloat, but at least the code should work
properly.

I have not checked with 3.2. The oldest compiler I have available here
is 3.3. That version compiles the functions as expected: I have found
instances of either type in the objdump and I have not found strange
constructions with both types there.

If you were thinking of another/bigger problem with gcc-3.2, could you 
please give me a pointer?

Greetings,
        Alexander

> -Andi
-- 
  Alexander van Heukelum
  heukelum@...tmail.fm

-- 
http://www.fastmail.fm - Or how I learned to stop worrying and
                          love email again

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ