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
next prev parent 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