[PATCH] Valid relocation symbol for FLAT format on ARM

[PATCH] Valid relocation symbol for FLAT format on ARM

[Jun Sun]

(Sent to linux-kernel, but seems nobody cared. Hopefully someone here can
pick it up)

Cheers.

Jun
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20091230/22747043/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 091226_arm_flat_valid_reloc.patch
Type: application/octet-stream
Size: 1683 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20091230/22747043/attachment.obj>

[PATCH] Valid relocation symbol for FLAT format on ARM

[Jamie Lokier]

Jun Sun wrote:
>    (Sent to linux-kernel, but seems nobody cared. Hopefully someone here
>    can pick it up)

I've included uclinux-dev at uclinux.org, because that's where I've seen
most discussion of FLAT format in general.

>    Apparently newer GCC would generate ANCHOR symbols beyond the end of
>    data/bss segment on ARM CPUs. As a result, the exiting validity checking
>    for relocation symbols in FLAT format will fail for some programs.

> -#define        flat_reloc_valid(reloc, size)           ((reloc) <= (size))
> +#define        flat_reloc_valid(reloc, size)           ((reloc) <= (size) + 0x1000)

Why 0x1000?  Is that an arbitrary number, or does it have a specific
meaning for GCC?

>    This also fixes a cosmetic error in printk. Text segment and data/bss
>    segment are allocated from two different areas. It is not meaningful to
>    give the diff between them in error reporting messages.

That part looks fine to me.

-- Jamie

ps. Russell, proof that someone is using no-MMU ARM? :-)
I'll get back to your earlier mail on that subject when I have more time, btw.

[PATCH] Valid relocation symbol for FLAT format on ARM

[Jun Sun]

On Wed, Dec 30, 2009 at 06:49:29PM +0000, Jamie Lokier wrote:
> Jun Sun wrote:
> >    (Sent to linux-kernel, but seems nobody cared. Hopefully someone here
> >    can pick it up)
> 
> I've included uclinux-dev at uclinux.org, because that's where I've seen
> most discussion of FLAT format in general.
>

Thanks. I should have probably done this at the first place.
 
> >    Apparently newer GCC would generate ANCHOR symbols beyond the end of
> >    data/bss segment on ARM CPUs. As a result, the exiting validity checking
> >    for relocation symbols in FLAT format will fail for some programs.
> 
> > -#define        flat_reloc_valid(reloc, size)           ((reloc) <= (size))
> > +#define        flat_reloc_valid(reloc, size)           ((reloc) <= (size) + 0x1000)
> 
> Why 0x1000?  Is that an arbitrary number, or does it have a specific
> meaning for GCC?
> 

I had a piece of comment in my first patch submission which explains it
well. I attached it here. This time around I thought for the simplicity
look of code and dropped it. Maybe it should still be there. :)

> >    This also fixes a cosmetic error in printk. Text segment and data/bss
> >    segment are allocated from two different areas. It is not meaningful to
> >    give the diff between them in error reporting messages.
> 
> That part looks fine to me.
> 
> -- Jamie
> 
> ps. Russell, proof that someone is using no-MMU ARM? :-)

Yes, ARM on no-MMU CPU is still alive. :) Hopefully you can see
some amazing products coming soon that we can all be proud of.

Cheers.

Jun
-------------- next part --------------
diff -Nru linux-2.6.32.2/arch/arm/include/asm/flat.h.orig linux-2.6.32.2/arch/arm/include/asm/flat.h
--- linux-2.6.32.2/arch/arm/include/asm/flat.h.orig	2009-12-18 14:27:07.000000000 -0800
+++ linux-2.6.32.2/arch/arm/include/asm/flat.h	2009-12-26 08:22:43.000000000 -0800
@@ -7,7 +7,12 @@
 
 #define	flat_argvp_envp_on_stack()		1
 #define	flat_old_ram_flag(flags)		(flags)
-#define	flat_reloc_valid(reloc, size)		((reloc) <= (size))
+#define	flat_reloc_valid(reloc, size)		((reloc) <= (size) + 0x1000)
+/* [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.
+ */
 #define	flat_get_addr_from_rp(rp, relval, flags, persistent) get_unaligned(rp)
 #define	flat_put_addr_at_rp(rp, val, relval)	put_unaligned(val,rp)
 #define	flat_get_relocate_addr(rel)		(rel)
diff -Nru linux-2.6.32.2/fs/binfmt_flat.c.orig linux-2.6.32.2/fs/binfmt_flat.c
--- linux-2.6.32.2/fs/binfmt_flat.c.orig	2009-12-18 14:27:07.000000000 -0800
+++ linux-2.6.32.2/fs/binfmt_flat.c	2009-12-26 08:22:43.000000000 -0800
@@ -355,7 +355,7 @@
 
 	if (!flat_reloc_valid(r, start_brk - start_data + text_len)) {
 		printk("BINFMT_FLAT: reloc outside program 0x%x (0 - 0x%x/0x%x)",
-		       (int) r,(int)(start_brk-start_code),(int)text_len);
+		       (int) r,(int)(start_brk-start_data+text_len),(int)text_len);
 		goto failed;
 	}
 

[PATCH] Valid relocation symbol for FLAT format on ARM

[Russell King - ARM Linux]

On Wed, Dec 30, 2009 at 06:49:29PM +0000, Jamie Lokier wrote:
> ps. Russell, proof that someone is using no-MMU ARM? :-)
> I'll get back to your earlier mail on that subject when I have more
> time, btw.

Two users, at Christmas no less.  I suspect they're only playing with
uclinux because they're bored over the holiday season. ;)

Really though, if uclinux on ARM is being used, it needs more visible
activity to ensure that it gets tested.  What was merged from Hyok's
efforts is only half the story - just the core code.  AFAIK, everything
else went in the circular filing cabinet.

Catalin did some work to bring one of the ARM boards up with a uclinux
kernel, and some of those patches were merged, but without any configs.

This in turn means is that we don't have any uclinux defconfigs, so we
don't have kautobuild running any uclinux builds - which effectively means
we have zero build coverage on uclinux.  We don't know when it breaks,
etc.

Consequently, it hardly ever gets looked at, and has probably been
rotting away since it was originally merged.

That's what the real problem is - it's not enough to have code merged
and then have a mostly silent user base.

[PATCH] Valid relocation symbol for FLAT format on ARM

[Russell King - ARM Linux]

Oh, and please drop uclinux-dev from any email that you send to me;
that list is setup to immediately reject postings from anyone who isn't
subscribed.  No ifs or buts, no moderation, no question.  Extremely
stupid policy.

[PATCH] Valid relocation symbol for FLAT format on ARM

[Jun Sun]

On Fri, Jan 01, 2010 at 08:46:05PM +0000, Russell King - ARM Linux wrote:
> On Wed, Dec 30, 2009 at 06:49:29PM +0000, Jamie Lokier wrote:
> > ps. Russell, proof that someone is using no-MMU ARM? :-)
> > I'll get back to your earlier mail on that subject when I have more
> > time, btw.
> 
> Two users, at Christmas no less.  I suspect they're only playing with
> uclinux because they're bored over the holiday season. ;)
> 

Kind of. :) We are usually pretty busy with commercial work during 
normal days. Get a little more time for community work over the holiday.

> Really though, if uclinux on ARM is being used, it needs more visible
> activity to ensure that it gets tested.  What was merged from Hyok's
> efforts is only half the story - just the core code.  AFAIK, everything
> else went in the circular filing cabinet.
> 
> Catalin did some work to bring one of the ARM boards up with a uclinux
> kernel, and some of those patches were merged, but without any configs.
> 
> This in turn means is that we don't have any uclinux defconfigs, so we
> don't have kautobuild running any uclinux builds - which effectively means
> we have zero build coverage on uclinux.  We don't know when it breaks,
> etc.

I think I or one of my colleagues can submit a working patch with defconfig 
for a commercially available ARM7 board soon. 

Will submit a revised v3 patch in a sec.

Cheers.

Jun