* [PATCH] Valid relocation symbol for FLAT format on ARM
@ 2009-12-26 16:36 Jun Sun
2009-12-31 18:52 ` Mike Frysinger
0 siblings, 1 reply; 9+ messages in thread
From: Jun Sun @ 2009-12-26 16:36 UTC (permalink / raw
To: linux-kernel
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.
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.
Signed-off-by: Jun Sun <jsun@junsun.net>
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;
}
^ permalink raw reply [flat|nested] 9+ messages in thread
* [PATCH] Valid relocation symbol for FLAT format on ARM
@ 2009-12-30 16:30 Jun Sun
2009-12-30 18:49 ` Jamie Lokier
0 siblings, 1 reply; 9+ messages in thread
From: Jun Sun @ 2009-12-30 16:30 UTC (permalink / raw
To: linux-arm-kernel
(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>
^ permalink raw reply [flat|nested] 9+ messages in thread
* [PATCH] Valid relocation symbol for FLAT format on ARM
2009-12-30 16:30 Jun Sun
@ 2009-12-30 18:49 ` Jamie Lokier
2009-12-31 5:45 ` Jun Sun
2010-01-01 20:46 ` Russell King - ARM Linux
0 siblings, 2 replies; 9+ messages in thread
From: Jamie Lokier @ 2009-12-30 18:49 UTC (permalink / raw
To: linux-arm-kernel
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [PATCH] Valid relocation symbol for FLAT format on ARM
2009-12-30 18:49 ` Jamie Lokier
@ 2009-12-31 5:45 ` Jun Sun
2010-01-01 20:46 ` Russell King - ARM Linux
1 sibling, 0 replies; 9+ messages in thread
From: Jun Sun @ 2009-12-31 5:45 UTC (permalink / raw
To: linux-arm-kernel
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;
}
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] Valid relocation symbol for FLAT format on ARM
2009-12-26 16:36 [PATCH] Valid relocation symbol for FLAT format on ARM Jun Sun
@ 2009-12-31 18:52 ` Mike Frysinger
2010-01-01 1:16 ` Jun Sun
0 siblings, 1 reply; 9+ messages in thread
From: Mike Frysinger @ 2009-12-31 18:52 UTC (permalink / raw
To: Jun Sun; +Cc: linux-kernel, uclinux-dev
On Sat, Dec 26, 2009 at 11:36, Jun Sun wrote:
> 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.
>
> 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.
>
> Signed-off-by: Jun Sun <jsun@junsun.net>
>
> 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
you really should use git to generate the patch. if you're going to
do it by hand, you need to format it correctly. you're missing the
--- marker between your change log and the start of the patch.
> --- linux-2.6.32.2/fs/binfmt_flat.c
> +++ linux-2.6.32.2/fs/binfmt_flat.c
> @@ -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;
> }
this should be a separate patch since it is unrelated to your other change
-mike
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] Valid relocation symbol for FLAT format on ARM
2009-12-31 18:52 ` Mike Frysinger
@ 2010-01-01 1:16 ` Jun Sun
0 siblings, 0 replies; 9+ messages in thread
From: Jun Sun @ 2010-01-01 1:16 UTC (permalink / raw
To: Mike Frysinger; +Cc: linux-kernel, uclinux-dev
On Thu, Dec 31, 2009 at 01:52:08PM -0500, Mike Frysinger wrote:
> On Sat, Dec 26, 2009 at 11:36, Jun Sun wrote:
> > 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.
> >
> > 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.
> >
> > Signed-off-by: Jun Sun <jsun@junsun.net>
> >
> > 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
>
> you really should use git to generate the patch. if you're going to
> do it by hand, you need to format it correctly. you're missing the
> --- marker between your change log and the start of the patch.
>
> > --- linux-2.6.32.2/fs/binfmt_flat.c
> > +++ linux-2.6.32.2/fs/binfmt_flat.c
> > @@ -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;
> > ?? ?? ?? ??}
>
> this should be a separate patch since it is unrelated to your other change
> -mike
Thanks for the feedback. Have not submitted any patches for a while.
New patches are coming in a sec.
Cheers.
Jun
^ permalink raw reply [flat|nested] 9+ messages in thread
* [PATCH] Valid relocation symbol for FLAT format on ARM
2009-12-30 18:49 ` Jamie Lokier
2009-12-31 5:45 ` Jun Sun
@ 2010-01-01 20:46 ` Russell King - ARM Linux
2010-01-01 21:01 ` Russell King - ARM Linux
2010-01-02 17:26 ` Jun Sun
1 sibling, 2 replies; 9+ messages in thread
From: Russell King - ARM Linux @ 2010-01-01 20:46 UTC (permalink / raw
To: linux-arm-kernel
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [PATCH] Valid relocation symbol for FLAT format on ARM
2010-01-01 20:46 ` Russell King - ARM Linux
@ 2010-01-01 21:01 ` Russell King - ARM Linux
2010-01-02 17:26 ` Jun Sun
1 sibling, 0 replies; 9+ messages in thread
From: Russell King - ARM Linux @ 2010-01-01 21:01 UTC (permalink / raw
To: linux-arm-kernel
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [PATCH] Valid relocation symbol for FLAT format on ARM
2010-01-01 20:46 ` Russell King - ARM Linux
2010-01-01 21:01 ` Russell King - ARM Linux
@ 2010-01-02 17:26 ` Jun Sun
1 sibling, 0 replies; 9+ messages in thread
From: Jun Sun @ 2010-01-02 17:26 UTC (permalink / raw
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2010-01-02 17:26 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-12-26 16:36 [PATCH] Valid relocation symbol for FLAT format on ARM Jun Sun
2009-12-31 18:52 ` Mike Frysinger
2010-01-01 1:16 ` Jun Sun
-- strict thread matches above, loose matches on Subject: below --
2009-12-30 16:30 Jun Sun
2009-12-30 18:49 ` Jamie Lokier
2009-12-31 5:45 ` Jun Sun
2010-01-01 20:46 ` Russell King - ARM Linux
2010-01-01 21:01 ` Russell King - ARM Linux
2010-01-02 17:26 ` Jun Sun
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.