linux-kernel - Re: Will's kernel compilation error

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]

Message-Id: <4AB85842-79DF-412F-833C-4B784353A1F5@orcon.net.nz>
Date:	Wed, 17 Mar 2010 11:05:34 +1300
From:	Michael Cree <mcree@...on.net.nz>
To:	Matt Turner <mattst88@...il.com>
Cc:	Will L Givens <wlgivens@...il.com>, dl8bcu@...bcu.de,
	linux-kernel@...r.kernel.org, linux-alpha@...r.kernel.org
Subject: Re: Will's kernel compilation error

On 17/03/2010, at 10:39 AM, Matt Turner wrote:
> On Tue, Mar 16, 2010 at 5:23 PM, Will L Givens <wlgivens@...il.com>  
> wrote:
>>
>>> when I hit the relocation overflow a couple of releases before, I
>>> locally
>>> applied this patch, which fixes it for me. I assume the kernel is
>>> slightly
>>> bigger this way, but I didn't measure it.
>>>
>>> diff --git a/arch/alpha/Makefile b/arch/alpha/Makefile
>>> index 4759fe7..2cc3cc5 100644
>>> --- a/arch/alpha/Makefile
>>> +++ b/arch/alpha/Makefile
>>> @@ -12,7 +12,7 @@ NM := $(NM) -B
>>>
>>>  LDFLAGS_vmlinux      := -static -N #-relax
>>>  CHECKFLAGS   += -D__alpha__ -m64
>>> -cflags-y     := -pipe -mno-fp-regs -ffixed-8 -msmall-data
>>> +cflags-y     := -pipe -mno-fp-regs -ffixed-8
>>>  cflags-y     += $(call cc-option, -fno-jump-tables)
>>>
>>>  cpuflags-$(CONFIG_ALPHA_EV4)         := -mcpu=ev4
>>
>> That patch did the trick!!!! Everything built without issue... I'll  
>> post
>> your patch at bugzilla.kernel.org.
>
> Don't post it to bugzilla. It'll just rot there.
>
> The author should mail linux-alpha@ to get it reviewed.


The patch is not suitable, IMHO, for the kernel as it stands.  Some of  
us prefer the small-data model as we must boot off a slow medium that  
is supported by SRM.  Using large-data results in a larger code size.

It would be nice if the build system could detect the need for the  
large-data model before compilation but I can't see how to do that  
without actually compiling the kernel.

Therefore I suggest a kernel config item be added to optionally remove  
the -msmall-data compiler option for those who are building kernels  
with data areas greater than 64kB.  I'll drum up a patch later today.

Cheers
Michael.

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