linux-kernel - Re: [PATCH/RFC] powerpc: avoid generating .eh

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:	Tue, 24 Feb 2009 08:25:35 -0300
From:	Alexandre Oliva <aoliva@...hat.com>
To:	Sam Ravnborg <sam@...nborg.org>
Cc:	Kyle McMartin <kyle@...radead.org>, linuxppc-dev@...abs.org,
	linux-kernel@...r.kernel.org, kyle@...hat.com, roland@...hat.com
Subject: Re: [PATCH/RFC] powerpc: avoid generating .eh_frame sections with gcc-4.4

On Feb 24, 2009, Sam Ravnborg <sam@...nborg.org> wrote:

> On Tue, Feb 24, 2009 at 01:51:12AM -0500, Kyle McMartin wrote:
>> From: Kyle McMartin <kyle@...hat.com>
>> 
>> On ppc64 (at least) gcc-4.4 is defaulting to generating .eh_frame
>> sections, which are, for the kernel, fairly pointless. Additionally, on
>> ppc64 this generates a relocation format which the kernel module loader
>> does not currently support (R_PPC64_REL32.)
>> 
>> Alexandre Oliva verifies that -fno-dwarf2-cfi-asm prevents this
>> .eh_frame section from being generated.
>> 
>> These seem to be used for unwinding, but it doesn't look like we
>> currently use them anywhere. (In fact, we explicitly dump them in the
>> x86_64 linker script.)

> A grep for "eh_frame" shows too many hits in the kernel to convince
> me this is true.

I don't know whether .eh_frame is used for anything in the kernel.  It
doesn't matter, as far as the patch is concerned.

What the flag above does is to restore the .eh_frame behavior from GCC
4.3, in which, when compiling with -g, rather than using .cfi assembler
directives, GCC emitted .debug_frame and (when needed) .eh_frame itself.

The "when needed" is key.  The assembler doesn't know which of these to
emit, so it emits both in response to .cfi directives.  It's also
possible that the assembler selects more efficient relocations than GCC.
Regardless, it's precisely the presence of new relocations in .eh_frame
that caused the reported problem.

This flag will just restore the .eh_frame that you had with earlier
versions of GCC, so that you don't have to cope with the enlarged and
possibly modified one that the combination of new GCC and new binutils
generates when compiling with -g.  It will thus still serve whatever
purpose it did before.

I hope this helps,

-- 
Alexandre Oliva           http://www.lsd.ic.unicamp.br/~oliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist      Red Hat Brazil Compiler Engineer
--
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/