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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 1 May 2008 15:42:38 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Venki Pallipadi <venkatesh.pallipadi@...el.com>
Cc:	torvalds@...ux-foundation.org, bunk@...nel.org,
	venkatesh.pallipadi@...el.com, davem@...emloft.net,
	trini@...nel.crashing.org, mingo@...e.hu, tglx@...utronix.de,
	hpa@...or.com, linux-kernel@...r.kernel.org,
	suresh.b.siddha@...el.com
Subject: Re: huge gcc 4.1.{0,1} __weak problem

On Thu, 1 May 2008 15:35:15 -0700
Venki Pallipadi <venkatesh.pallipadi@...el.com> wrote:

> On Thu, May 01, 2008 at 03:27:26PM -0700, Linus Torvalds wrote:
> > 
> > 
> > On Thu, 1 May 2008, Andrew Morton wrote:
> > > > 
> > > > I see only the following choices:
> > > > - remove __weak and replace all current usages
> > > > - move all __weak functions into own files, and ensure that also happens
> > > >   for future usages
> > > > - #error for gcc 4.1.{0,1}
> > > 
> > > Can we detect the {0,1}?  __GNUC_EVEN_MORE_MINOR__?
> > 
> > It's __GNUC_PATCHLEVEL__, I believe.
> > 
> > So yes, we can distinguish 4.1.2 (good, and very common) from 4.1.{0,1} 
> > (bad, and rather uncommon).
> > 
> > And yes, considering that 4.1.1 (and even more so 4.1.0) should be rare to 
> > begin with, I think it's better to just not support it.
> > 
> 
> Not sure whether #error on gcc 4.1.{0.1} is the right thing as I found atleast
> one distro gcc which says itself as 4.1.1, do not exhibit the problem as it
> most likely has fix backported.
> 
> Putting all weak functions in one file is something Suresh and I considered
> before sending this patch. But, looking at various users of __weak, that
> single file did not look very appropriate.
> 

Is there some vaguely maintainable workaround we can do?  If the problem
only affects completely-empty weak functions then we could put something in
them to make them non-empty?

#if __GNUC__ == ...
#define weak_function_filler for ( ; ; );
#else
#define weak_function_filler()
#endif

because __weak and attribute((weak)) are pretty easy to grep for. Dunno.

--
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