linux-kernel - Re: [uClinux-dev] [PATCH] Valid relocation symbol for FLAT format on ARM, v2

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] [day] [month] [year] [list]

Date:	Mon, 4 Jan 2010 10:58:34 -0800
From:	Jun Sun <jsun@...sun.net>
To:	uClinux development list <uclinux-dev@...inux.org>
Cc:	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [uClinux-dev] [PATCH] Valid relocation symbol for FLAT format
	on ARM, v2

On Sat, Jan 02, 2010 at 11:09:07PM +0000, Jamie Lokier wrote:
> Jun Sun wrote:
> > +/* [jsun] new gcc 4.x generates ANCHOR symbols in order to reduce the size
> > + * of GOT table for PIC code. It is possible the ANCHOR is placed beyond
> > + * the end of data/bss segment up to 4K bytes(12 bits), because ARM allows
> > + * negative 12-bit offset. Thus we allow 0x1000 extra in reloc address range.
> > + */
> 
> Can you provide a small test program and *exact* GCC version and
> Binutils version which triggers this?  People have reported using GCC
> 4.x on ARM uClinux for some time, and I haven't seen complaints
> about this problem before.
>

gcc is derived from code saucery's 2008Q2 release, I believe. It is
gcc 4.3.3. So there is minor chance that this ANCHOR feature
is a code sourcery feature rather than a generic gcc 4.3.3. Please help
verify.

I attached the sample code and the assembly output. The command line used
to generate this is:

arm-uclinuxeabi-gcc  -c -Os                     -g -fomit-frame-pointer -pipe -msoft-float -fno-common -fno-builtin -Wall   -DEMBED -D__PIC__ -fpic -msingle-pic-base -Dlinux -D__linux__ -Dunix -D__uClinux__ -S helloworld.c

You can see from the assembly output that .LANCHOR1 is set to 8184, well
beyond the real end of bss/data segment. And it is easy to see why, because
variable x2 is then referred as a negative offset to LANCHOR1.

Cheers.

Jun

View attachment "helloworld.c" of type "text/plain" (279 bytes)

View attachment "helloworld.s" of type "text/plain" (7046 bytes)