Hello Heiko, On Mon, Apr 29, 2019 at 3:06 PM Heiko Schocher <[email protected]> wrote: > > Hello Simon, > > Am 25.04.2019 um 21:24 schrieb Simon Goldschmidt: > > Am 25.04.2019 um 12:50 schrieb Tom Rini: > >> On Thu, Apr 25, 2019 at 09:32:22AM +0200, Simon Goldschmidt wrote: > >>> On Thu, Apr 25, 2019 at 1:59 AM Simon Glass <[email protected]> wrote: > >>>> > >>>> Hi, > >>>> > >>>> On Wed, 24 Apr 2019 at 05:53, Tom Rini <[email protected]> wrote: > >>>>> > >>>>> On Wed, Apr 24, 2019 at 01:49:52PM +0200, Simon Goldschmidt wrote: > >>>>>> On Wed, Apr 24, 2019 at 1:27 PM Tom Rini <[email protected]> wrote: > >>>>>>> > >>>>>>> On Tue, Apr 23, 2019 at 09:54:10PM -0600, Simon Glass wrote: > >>>>>>>> On Mon, 1 Apr 2019 at 14:01, Simon Goldschmidt > >>>>>>>> <[email protected]> wrote: > >>>>>>>>> > >>>>>>>>> If the malloc range passed to mem_malloc_init() is at the end of > >>>>>>>>> address > >>>>>>>>> range and 'start + size' overflows to 0, following allocations fail > >>>>>>>>> as > >>>>>>>>> mem_malloc_end is zero (which looks like uninitialized). > >>>>>>>>> > >>>>>>>>> Fix this by subtracting 1 of 'start + size' overflows to zero. > >>>>>>>>> > >>>>>>>>> Signed-off-by: Simon Goldschmidt <[email protected]> > >>>>>>>>> --- > >>>>>>>>> > >>>>>>>>> Changes in v4: None > >>>>>>>>> Changes in v3: None > >>>>>>>>> > >>>>>>>>> common/dlmalloc.c | 4 ++++ > >>>>>>>>> 1 file changed, 4 insertions(+) > >>>>>>>> > >>>>>>>> Reviewed-by: Simon Glass <[email protected]> > >>>>>>> > >>>>>>> So, the problem with this patch is that it increases the generic > >>>>>>> malloc > >>>>>>> code size ever so slightly and blows up smartweb :( > >>>>>> > >>>>>> Ehrm, ok, so how do we proceed? > >>>>> > >>>>> A good question. Take a look at spl/u-boot-spl.map on smartweb and see > >>>>> if, of the malloc functions it doesn't discard there's something that > >>>>> maybe could be optimized somewhere? > >>>> > >>>> I wonder if we should have a Kconfig option like SPL_CHECKS which > >>>> enables these sorts of minor checks, which may only fix one board at > >>>> the cost of code size? > >>>> > >>>> Then it could be enabled by default, but disabled on this board? > >>> > >>> For a bigger change, this might be an idea, but for a change that I can > >>> cut > >>> down to 16 or even 8 bytes code size increasement, I don't think having a > >>> new option would be good. > >>> > >>> Anyway, I just tried at work and I don't get the overflow. Tom, which gcc > >>> are you using to get the size error? It works for me on Debian 9 but > >>> doesn't > >>> work with Ubuntu (both times, default cross compiler toolchain installed). > >> > >> I'm using the gcc-7.3 from kernel.org that we use in travis/etc. > > > > Ok, so I have gcc-7.3 on my Ubuntu machine as well. I don't know why 6.3 > > seems to produce smaller > > binaries (I thought they were getting smaller with new versions, not > > larger). > > > > However, I've stripped down that patch to +8 Bytes only and sent v5. > > Thanks! > > Sorry for digging so late in, but I was on vacation... > > Hmm.. the smartweb board has only 4k sram for SPL, and I have no chance > to convert it to DM to get rid of some compiler warnings ... > > I am unsure what to do now with this hardware ...
And things even get worse: as I wrote in the other thread, after updating to Ubuntu 19.04 as build system, I get gcc 8.3 as cross compiler and smartweb fails to build with that compiler (as the SPL binary is exactly 4k now). Regards, Simon _______________________________________________ U-Boot mailing list [email protected] https://lists.denx.de/listinfo/u-boot
