On Tue, Mar 12, 2013 at 11:07:46PM +0100, Albert ARIBAUD wrote: > Hi Tom, > > On Tue, 12 Mar 2013 13:47:33 -0400, Tom Rini <tr...@ti.com> wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > On 03/12/2013 01:19 PM, Albert ARIBAUD wrote: > > > Hi Scott, > > > > > > On Tue, 12 Mar 2013 12:06:53 -0500, Scott Wood > > > <scottw...@freescale.com> wrote: > > > > > >> On 03/12/2013 12:02:56 PM, Tom Rini wrote: > > >>> On Tue, Mar 12, 2013 at 11:55:22AM -0500, Scott Wood wrote: > > >>>> On 03/12/2013 10:30:40 AM, Tom Rini wrote: > > >>>>> On Fri, Mar 08, 2013 at 06:35:04PM -0600, Scott Wood > > >>>>> wrote: > > >>>>>> Why would eliminating all individual callbacks cause > > >>>>>> start/end > > >>> to go > > >>>>>> away? If that's the way the list mechanism works, the > > >>>>>> mechanism needs fixing. > > >>>>> > > >>>>> Yes, that's how the mechanism works. Rather than having to > > >>>>> declare that you expect to have a linker list of name $foo, > > >>>>> we dynamically determine what linker lists we have and > > >>>>> setup the linker section entry. > > >>>> > > >>>> So it would break just as hard if we happened to turn off > > >>>> all of the things that register callbacks. > > >>>> > > >>>>> I'm not sure it's broken exactly, I think maybe we just > > >>>>> need to say no env callback support in SPL since it's not > > >>>>> really user editable. > > >>>> > > >>>> That's fine, but it's still a bad mechanism. > > >>> > > >>> Yes, the mechanism has a breaking condition on trying to > > >>> reference an empty list (which is what SPL ends up with, in > > >>> this case). Poking Albert and Marek in case they have any > > >>> ideas, but this seems like a feature not a bug. > > >> > > >> How is it a feature? One of the main benefit of linker lists is > > >> for things to just work when things are configured in/out > > >> without needing ifdefs and such. Why should "everything > > >> configured out" be a special case requiring an ifdef? > > >> > > >> If we want to save some code by ifdeffing the listwalking code > > >> for SPL, that's a separate matter. > > > > > > Normally my reworked linker_list code should work fine with some > > > code going through an empty list, precisely because list start and > > > end symbols, like list entries, are generated by the compiler > > > irrespective of one another and then whatever was generated is > > > sorted by the linker. So an empty list ends up as two symbols at > > > the same address (and indeed, env callbacks, in many boards, > > > showed this pattern in the map file). > > > > OK, where's the latest/greatest of this re-work? I'll see if it also > > solves the problem I have. > > In patchwork (assigned to me, and soon to be applied on u-boot-arm if > this works for you): > > http://patchwork.ozlabs.org/patch/222904/ > http://patchwork.ozlabs.org/patch/222905/ > http://patchwork.ozlabs.org/patch/222906/ > http://patchwork.ozlabs.org/patch/222908/ > > (http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/152754/focus=154634)
For clarity over here, fixed the problem I had so I'll drop 2/2 from what I posted (1/2 is still applicable as a general thing). Thanks! -- Tom
signature.asc
Description: Digital signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
