Hi Greg,
trying to compile 2.5.56 with CONFIG_MTD_UCLINUX fails on i386 with
undefined reference to `_ebss'
at the final linking.
It seems _ebss is only defined on the architectures m68knommu and v850?
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
Hi Adrian,
Adrian Bunk wrote:
> trying to compile 2.5.56 with CONFIG_MTD_UCLINUX fails on i386 with
> undefined reference to `_ebss'
> at the final linking.
>
> It seems _ebss is only defined on the architectures m68knommu and v850?
Hmm, currently that is correct. There doesn't appear to be a
"standard" symbol name applied to the immediate end of the bss
section. Different architectures are using different names:
_ebss -- m68knommu, v850
__bss_stop -- i386, alpha, ppc, s390
__bss_end -- x86_64
_end -- mips, parisc, sparc, (actually most have this)
Actually it looks like _end is probably closer, it seems to
almost always fall strait after the bss, on just about every
architecture that has it.
Come to think of it _end is probably more appropriate anyway.
Since that code is trying to find the location of something
concatenated to the end of the kernel image.
Regards
Greg
------------------------------------------------------------------------
Greg Ungerer -- Chief Software Wizard EMAIL: [email protected]
SnapGear Pty Ltd PHONE: +61 7 3435 2888
825 Stanley St, FAX: +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com
On Mon, Jan 13, 2003 at 05:23:21PM +1000, Greg Ungerer wrote:
> Hi Adrian,
>
> Adrian Bunk wrote:
> >trying to compile 2.5.56 with CONFIG_MTD_UCLINUX fails on i386 with
> > undefined reference to `_ebss'
> >at the final linking.
> >
> >It seems _ebss is only defined on the architectures m68knommu and v850?
>
> Hmm, currently that is correct. There doesn't appear to be a
> "standard" symbol name applied to the immediate end of the bss
> section. Different architectures are using different names:
>
> _ebss -- m68knommu, v850
> __bss_stop -- i386, alpha, ppc, s390
> __bss_end -- x86_64
> _end -- mips, parisc, sparc, (actually most have this)
>
> Actually it looks like _end is probably closer, it seems to
> almost always fall strait after the bss, on just about every
> architecture that has it.
>
> Come to think of it _end is probably more appropriate anyway.
> Since that code is trying to find the location of something
> concatenated to the end of the kernel image.
This problem (undefined reference to `_ebss') is still present in
2.5.65.
It might not be a solution for the whole issue, but is it intentionally
that it's possible to enable CONFIG_MTD_UCLINUX on non-uClinux
architectures or should an appropriate dependency be added to the
Kconfig file?
> Regards
> Greg
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Thu, Mar 20, 2003 at 03:59:28PM +0100, Adrian Bunk wrote:
>...
> It might not be a solution for the whole issue, but is it intentionally
> that it's possible to enable CONFIG_MTD_UCLINUX on non-uClinux
> architectures or should an appropriate dependency be added to the
> Kconfig file?
The following patch should do what I was thinking of:
--- linux-2.5.65-full/drivers/mtd/maps/Kconfig.old 2003-03-20 16:56:25.000000000 +0100
+++ linux-2.5.65-full/drivers/mtd/maps/Kconfig 2003-03-20 16:56:45.000000000 +0100
@@ -348,7 +348,7 @@
config MTD_UCLINUX
tristate "Generic uClinux RAM/ROM filesystem support"
- depends on MTD_PARTITIONS
+ depends on MTD_PARTITIONS && !MMU
help
Map driver to support image based filesystems for uClinux.
Any comments on whether this is correct?
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
Hi Adrian,
This seems reasonable to me. It is after all targeted at uclinux.
I suspect noone with VM setups would be much interrested in using
it anyway.
Patch looks good to me.
Regards
Greg
Adrian Bunk wrote:
> On Thu, Mar 20, 2003 at 03:59:28PM +0100, Adrian Bunk wrote:
>
>>...
>>It might not be a solution for the whole issue, but is it intentionally
>>that it's possible to enable CONFIG_MTD_UCLINUX on non-uClinux
>>architectures or should an appropriate dependency be added to the
>>Kconfig file?
>
>
> The following patch should do what I was thinking of:
>
> --- linux-2.5.65-full/drivers/mtd/maps/Kconfig.old 2003-03-20 16:56:25.000000000 +0100
> +++ linux-2.5.65-full/drivers/mtd/maps/Kconfig 2003-03-20 16:56:45.000000000 +0100
> @@ -348,7 +348,7 @@
>
> config MTD_UCLINUX
> tristate "Generic uClinux RAM/ROM filesystem support"
> - depends on MTD_PARTITIONS
> + depends on MTD_PARTITIONS && !MMU
> help
> Map driver to support image based filesystems for uClinux.
>
>
>
> Any comments on whether this is correct?
>
>
> cu
> Adrian
>
--
------------------------------------------------------------------------
Greg Ungerer -- Chief Software Wizard EMAIL: [email protected]
SnapGear Pty Ltd PHONE: +61 7 3435 2888
825 Stanley St, FAX: +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com