* shouldn't asm-generic/barebox.lds.h be arch-independent?
@ 2012-11-18 17:52 Robert P. J. Day
2012-11-18 18:21 ` Antony Pavlov
2012-11-18 18:31 ` Robert P. J. Day
0 siblings, 2 replies; 5+ messages in thread
From: Robert P. J. Day @ 2012-11-18 17:52 UTC (permalink / raw)
To: U-Boot Version 2 (barebox)
perusing the code to see how the final barebox executable is created
and ran across this opening to include/asm-generic/barebox.lds.h:
#if defined CONFIG_ARCH_IMX25 || \
defined CONFIG_ARCH_IMX35 || \
defined CONFIG_ARCH_IMX51 || \
defined CONFIG_ARCH_IMX53 || \
defined CONFIG_ARCH_IMX6 || \
defined CONFIG_X86 || \
defined CONFIG_ARCH_EP93XX
#include <mach/barebox.lds.h>
#endif
#ifndef PRE_IMAGE
#define PRE_IMAGE
#endif
i find that more than a little confusing and inappropriate -- it
strikes me that the allegedly "generic" lds.h file shouldn't be
testing for an arbitrary set of inexplicable machine/arch
combinations, especially when there is absolutely no explanation about
what makes that particular set of symbols magic with respect to this
file.
a minute or two of perusing shows that what it's for is inserting
some special "pre-image" content into the executable, but that means
that for each new selection that needs that, this file will have to be
changed and that's just messy.
the linux kernel has a simpler strategy for
asm-generic/vmlinux.lds.h, as you see in this patch snippet that added
bss first section functionality to that file earlier this year:
+/*
+ * Allow archectures to redefine BSS_FIRST_SECTIONS to add extra
+ * sections to the front of bss.
+ */
+#ifndef BSS_FIRST_SECTIONS
+#define BSS_FIRST_SECTIONS
+#endif
+
#define BSS(bss_align) \
. = ALIGN(bss_align); \
.bss : AT(ADDR(.bss) - LOAD_OFFSET) { \
+ BSS_FIRST_SECTIONS \
*(.bss..page_aligned) \
*(.dynbss) \
*(.bss) \
that would seem to be a much nicer solution as it pushes the
selection of pre-image content back to the architectures where it
belongs.
the fact that the current approach is prone to "error" can be seen
in the file arch/mips/lib/barebox.lds.S:
#include <asm-generic/barebox.lds.h>
OUTPUT_ARCH(mips)
ENTRY(_start)
SECTIONS
{
. = TEXT_BASE;
. = ALIGN(4);
.text :
{
_start = .;
*(.text_entry*)
_stext = .;
_text = .;
__bare_init_start = .;
*(.text_bare_init*)
__bare_init_end = .;
*(.text*)
}
BAREBOX_BARE_INIT_SIZE
PRE_IMAGE <--- ?????
apparently, the MIPS architecture is including the "PRE_IMAGE"
content, despite the fact that it can't possibly be defined. it's not
wrong, it's just pointless and potentially confusing.
is there some reason this wasn't done the same way the linux kernel
does it?
rday
--
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: shouldn't asm-generic/barebox.lds.h be arch-independent?
2012-11-18 17:52 shouldn't asm-generic/barebox.lds.h be arch-independent? Robert P. J. Day
@ 2012-11-18 18:21 ` Antony Pavlov
2012-11-18 18:24 ` Robert P. J. Day
2012-11-18 18:31 ` Robert P. J. Day
1 sibling, 1 reply; 5+ messages in thread
From: Antony Pavlov @ 2012-11-18 18:21 UTC (permalink / raw)
To: Robert P. J. Day; +Cc: U-Boot Version 2 (barebox)
On 18 November 2012 21:52, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
>
> perusing the code to see how the final barebox executable is created
> and ran across this opening to include/asm-generic/barebox.lds.h:
>
> #if defined CONFIG_ARCH_IMX25 || \
> defined CONFIG_ARCH_IMX35 || \
> defined CONFIG_ARCH_IMX51 || \
> defined CONFIG_ARCH_IMX53 || \
> defined CONFIG_ARCH_IMX6 || \
> defined CONFIG_X86 || \
> defined CONFIG_ARCH_EP93XX
> #include <mach/barebox.lds.h>
> #endif
>
> #ifndef PRE_IMAGE
> #define PRE_IMAGE
> #endif
>
> i find that more than a little confusing and inappropriate -- it
> strikes me that the allegedly "generic" lds.h file shouldn't be
> testing for an arbitrary set of inexplicable machine/arch
> combinations, especially when there is absolutely no explanation about
> what makes that particular set of symbols magic with respect to this
> file.
>
> a minute or two of perusing shows that what it's for is inserting
> some special "pre-image" content into the executable, but that means
> that for each new selection that needs that, this file will have to be
> changed and that's just messy.
>
> the linux kernel has a simpler strategy for
> asm-generic/vmlinux.lds.h, as you see in this patch snippet that added
> bss first section functionality to that file earlier this year:
>
> +/*
> + * Allow archectures to redefine BSS_FIRST_SECTIONS to add extra
> + * sections to the front of bss.
> + */
> +#ifndef BSS_FIRST_SECTIONS
> +#define BSS_FIRST_SECTIONS
> +#endif
> +
> #define BSS(bss_align) \
> . = ALIGN(bss_align); \
> .bss : AT(ADDR(.bss) - LOAD_OFFSET) { \
> + BSS_FIRST_SECTIONS \
> *(.bss..page_aligned) \
> *(.dynbss) \
> *(.bss) \
>
> that would seem to be a much nicer solution as it pushes the
> selection of pre-image content back to the architectures where it
> belongs.
>
> the fact that the current approach is prone to "error" can be seen
> in the file arch/mips/lib/barebox.lds.S:
>
> #include <asm-generic/barebox.lds.h>
>
> OUTPUT_ARCH(mips)
> ENTRY(_start)
> SECTIONS
> {
> . = TEXT_BASE;
>
> . = ALIGN(4);
> .text :
> {
> _start = .;
> *(.text_entry*)
> _stext = .;
> _text = .;
> __bare_init_start = .;
> *(.text_bare_init*)
> __bare_init_end = .;
> *(.text*)
> }
> BAREBOX_BARE_INIT_SIZE
>
> PRE_IMAGE <--- ?????
>
> apparently, the MIPS architecture is including the "PRE_IMAGE"
> content, despite the fact that it can't possibly be defined. it's not
> wrong, it's just pointless and potentially confusing.
Unfortunately nowadays MIPS lacks lowlevel initialization support.
Yesterday I mailed RFC about pbl (prebootloader) support. It needs
much work, but IMHO after incorporating MIPS pbl support the status of
"PRE_IMAGE" will be more clear.
--
Best regards,
Antony Pavlov
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: shouldn't asm-generic/barebox.lds.h be arch-independent?
2012-11-18 18:21 ` Antony Pavlov
@ 2012-11-18 18:24 ` Robert P. J. Day
0 siblings, 0 replies; 5+ messages in thread
From: Robert P. J. Day @ 2012-11-18 18:24 UTC (permalink / raw)
To: Antony Pavlov; +Cc: U-Boot Version 2 (barebox)
On Sun, 18 Nov 2012, Antony Pavlov wrote:
> On 18 November 2012 21:52, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
... snip ...
> > the fact that the current approach is prone to "error" can be seen
> > in the file arch/mips/lib/barebox.lds.S:
> >
> > #include <asm-generic/barebox.lds.h>
> >
> > OUTPUT_ARCH(mips)
> > ENTRY(_start)
> > SECTIONS
> > {
> > . = TEXT_BASE;
> >
> > . = ALIGN(4);
> > .text :
> > {
> > _start = .;
> > *(.text_entry*)
> > _stext = .;
> > _text = .;
> > __bare_init_start = .;
> > *(.text_bare_init*)
> > __bare_init_end = .;
> > *(.text*)
> > }
> > BAREBOX_BARE_INIT_SIZE
> >
> > PRE_IMAGE <--- ?????
> >
> > apparently, the MIPS architecture is including the "PRE_IMAGE"
> > content, despite the fact that it can't possibly be defined.
> > it's not wrong, it's just pointless and potentially confusing.
>
> Unfortunately nowadays MIPS lacks lowlevel initialization support.
> Yesterday I mailed RFC about pbl (prebootloader) support. It needs
> much work, but IMHO after incorporating MIPS pbl support the status
> of "PRE_IMAGE" will be more clear.
ok, but that still doesn't address the bigger issue that the
allegedly "generic" barebox.lds.h file really shouldn't be checking
for individual machines or architectures. IMHO.
rday
--
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: shouldn't asm-generic/barebox.lds.h be arch-independent?
2012-11-18 17:52 shouldn't asm-generic/barebox.lds.h be arch-independent? Robert P. J. Day
2012-11-18 18:21 ` Antony Pavlov
@ 2012-11-18 18:31 ` Robert P. J. Day
2012-11-19 8:32 ` Sascha Hauer
1 sibling, 1 reply; 5+ messages in thread
From: Robert P. J. Day @ 2012-11-18 18:31 UTC (permalink / raw)
To: U-Boot Version 2 (barebox)
there is one more oddity(?) with the way the linker "lds" files are
set up. if i read this correctly (and i could be wrong), here's
arch/x86/lib/barebox.lds.S:
#undef i386
#include <asm-generic/barebox.lds.h>
which gets us to that included file, which contains:
#if defined CONFIG_ARCH_IMX25 || \
defined CONFIG_ARCH_IMX35 || \
defined CONFIG_ARCH_IMX51 || \
defined CONFIG_ARCH_IMX53 || \
defined CONFIG_ARCH_IMX6 || \
defined CONFIG_X86 || \ <-- that will be true, correct?
defined CONFIG_ARCH_EP93XX
#include <mach/barebox.lds.h>
#endif
which finally takes us to
arch/x86/mach-i386/include/mach/barebox.lds.h, which is nothing more
than a collection of macro definitions. there's no "pre-image"
content to be incorporated into the final image -- it's just
preprocessor content. so why isn't all that simply at the beginning
of the main x86 barebox.lds.S file?
or am i missing something?
rday
--
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: shouldn't asm-generic/barebox.lds.h be arch-independent?
2012-11-18 18:31 ` Robert P. J. Day
@ 2012-11-19 8:32 ` Sascha Hauer
0 siblings, 0 replies; 5+ messages in thread
From: Sascha Hauer @ 2012-11-19 8:32 UTC (permalink / raw)
To: Robert P. J. Day; +Cc: U-Boot Version 2 (barebox)
On Sun, Nov 18, 2012 at 01:31:06PM -0500, Robert P. J. Day wrote:
>
> there is one more oddity(?) with the way the linker "lds" files are
> set up. if i read this correctly (and i could be wrong), here's
> arch/x86/lib/barebox.lds.S:
>
> #undef i386
> #include <asm-generic/barebox.lds.h>
>
> which gets us to that included file, which contains:
>
> #if defined CONFIG_ARCH_IMX25 || \
> defined CONFIG_ARCH_IMX35 || \
> defined CONFIG_ARCH_IMX51 || \
> defined CONFIG_ARCH_IMX53 || \
> defined CONFIG_ARCH_IMX6 || \
> defined CONFIG_X86 || \ <-- that will be true, correct?
> defined CONFIG_ARCH_EP93XX
> #include <mach/barebox.lds.h>
> #endif
Instead of having this the users should include asm/barebox.lds.h which
then in turn includes asm-generic/barebox.lds.h.
>
> which finally takes us to
> arch/x86/mach-i386/include/mach/barebox.lds.h, which is nothing more
> than a collection of macro definitions. there's no "pre-image"
> content to be incorporated into the final image -- it's just
> preprocessor content. so why isn't all that simply at the beginning
> of the main x86 barebox.lds.S file?
I don't know. It should probably be moved there.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2012-11-19 8:32 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-11-18 17:52 shouldn't asm-generic/barebox.lds.h be arch-independent? Robert P. J. Day
2012-11-18 18:21 ` Antony Pavlov
2012-11-18 18:24 ` Robert P. J. Day
2012-11-18 18:31 ` Robert P. J. Day
2012-11-19 8:32 ` Sascha Hauer
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox