public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Heiko Schocher <hs@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v4 1/2] dlmalloc: fix malloc range at end of ram
Date: Mon, 29 Apr 2019 15:06:39 +0200	[thread overview]
Message-ID: <87d37c88-4cc4-cdc2-78df-d0ddaf4edba6@denx.de> (raw)
In-Reply-To: <7d140164-79ab-b1c6-c452-c794a2902eb8@gmail.com>

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 <sjg@chromium.org> wrote:
>>>>
>>>> Hi,
>>>>
>>>> On Wed, 24 Apr 2019 at 05:53, Tom Rini <trini@konsulko.com> 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 <trini@konsulko.com> wrote:
>>>>>>>
>>>>>>> On Tue, Apr 23, 2019 at 09:54:10PM -0600, Simon Glass wrote:
>>>>>>>> On Mon, 1 Apr 2019 at 14:01, Simon Goldschmidt
>>>>>>>> <simon.k.r.goldschmidt@gmail.com> 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 <simon.k.r.goldschmidt@gmail.com>
>>>>>>>>> ---
>>>>>>>>>
>>>>>>>>> Changes in v4: None
>>>>>>>>> Changes in v3: None
>>>>>>>>>
>>>>>>>>>   common/dlmalloc.c | 4 ++++
>>>>>>>>>   1 file changed, 4 insertions(+)
>>>>>>>>
>>>>>>>> Reviewed-by: Simon Glass <sjg@chromium.org>
>>>>>>>
>>>>>>> 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 ...

bye,
Heiko
-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: hs at denx.de

  reply	other threads:[~2019-04-29 13:06 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-01 20:01 [U-Boot] [PATCH v4 0/2] spl: full-featured heap cleanups Simon Goldschmidt
2019-04-01 20:01 ` [U-Boot] [PATCH v4 1/2] dlmalloc: fix malloc range at end of ram Simon Goldschmidt
2019-04-24  3:54   ` Simon Glass
2019-04-24 11:26     ` Tom Rini
2019-04-24 11:49       ` Simon Goldschmidt
2019-04-24 11:52         ` Tom Rini
2019-04-24 23:58           ` Simon Glass
2019-04-25  7:32             ` Simon Goldschmidt
2019-04-25 10:50               ` Tom Rini
2019-04-25 19:24                 ` Simon Goldschmidt
2019-04-29 13:06                   ` Heiko Schocher [this message]
2019-04-29 13:16                     ` Simon Goldschmidt
2019-04-29 13:20                       ` Tom Rini
2019-04-29 13:19                     ` Tom Rini
2019-04-29 15:53                       ` Simon Glass
2019-04-01 20:01 ` [U-Boot] [PATCH v4 2/2] dlmalloc: be compatible to tiny printf Simon Goldschmidt
2019-04-24  3:54   ` Simon Glass
2019-04-24 13:31   ` [U-Boot] [U-Boot, v4, " Tom Rini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87d37c88-4cc4-cdc2-78df-d0ddaf4edba6@denx.de \
    --to=hs@denx.de \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox