From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C4F77C47094 for ; Thu, 10 Jun 2021 14:28:10 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 2A3A360C40 for ; Thu, 10 Jun 2021 14:28:10 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2A3A360C40 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:33938 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lrLfF-0004vK-Co for qemu-devel@archiver.kernel.org; Thu, 10 Jun 2021 10:28:09 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:60242) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lrLdW-0002Uv-6L for qemu-devel@nongnu.org; Thu, 10 Jun 2021 10:26:22 -0400 Received: from mail-ej1-x62b.google.com ([2a00:1450:4864:20::62b]:34803) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lrLdT-0004tP-U9 for qemu-devel@nongnu.org; Thu, 10 Jun 2021 10:26:21 -0400 Received: by mail-ej1-x62b.google.com with SMTP id g8so44542641ejx.1 for ; Thu, 10 Jun 2021 07:26:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=81SMQU+t0cJZ1cQ8798i8DpIPvrCW27Vrxe7wfzWkMo=; b=PHAd2CLnh3mLSIcyUEWKJh3G8ublAVD8hdoyPEIrfzBXZrBgNCJss07uBr+NFQoX8m Mq1TzF00O6efmR8+Tz7ez7ISutdU58CTEvNTIBGTHTOhmvkj3XF82oamXSOjd0VEGS6u CkFRAIVeKSv+B/G6K7891JHZ6ipU+VuNibFqigDSxOMTma58ssJ6o7yLzv8Ez8cQyv5S 8fvf1DzlV3HD21Vf/aGcx707ey305eof7pOnps252Eby9gBYQhBs+8ebG80e9zwSPA/I FOGrC7gOVVaArmI5z022cf6iApy0FWUFV0QW2Q2A9diu8IuIihftrYukDnLYpYB3UOVp /9DA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=81SMQU+t0cJZ1cQ8798i8DpIPvrCW27Vrxe7wfzWkMo=; b=Xyec0bhphv/w4j35qalx+mK7OBZ/P9yZTcCD5ruyAIOWwN0MCGuJpPY+L6fhxrtTjF zxyTx4lHiUFJAP8lbsARw3VZxpA874U9QPQS+JLRfoQJg6clNaOl+TdZaJztiCpz/WcJ W0i2uncPYjPEaWu1JV4dmFnUKnkFUOou5H6kGGQszvITymB1sc8w1qmdRXcFWdgj/jRw +SQQ31x0tg5+BnZepaBL8Ob+oouLBUD+HD/p1QjWeWTsFjxG+N0qdOqT8EOSq7UpCB5p 7ugWWlDIRjB5f6Vf0RU/VCps68+eaBxulVyzxHaMdooNu+Xs8k9pY635gmEnoD0qHNWB v3lQ== X-Gm-Message-State: AOAM5306zIPymNpvPJf4QO3E8Qzb86MJR6dq5Mb35OkTE83FKMyQGZZ+ VQD47CNlyJ82/Pd600vG37SUaUfL+vbVmJYOxX+e+w== X-Google-Smtp-Source: ABdhPJyHu3dZC+3iLTzCERGod8IDbvpT/w1e6ILS3mz7jPe4f3Cb6wrCsVIJvzKTAhdanMZwNlCasXf2BFrjGBvTPfg= X-Received: by 2002:a17:906:a108:: with SMTP id t8mr4762519ejy.407.1623335177856; Thu, 10 Jun 2021 07:26:17 -0700 (PDT) MIME-Version: 1.0 References: <20210610102617.17281-1-alex.bennee@linaro.org> <87im2liz4x.fsf@linaro.org> In-Reply-To: <87im2liz4x.fsf@linaro.org> From: Peter Maydell Date: Thu, 10 Jun 2021 15:25:44 +0100 Message-ID: Subject: Re: [PATCH v2] semihosting/arm-compat: remove heuristic softmmu SYS_HEAPINFO To: =?UTF-8?B?QWxleCBCZW5uw6ll?= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=2a00:1450:4864:20::62b; envelope-from=peter.maydell@linaro.org; helo=mail-ej1-x62b.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: qemu-arm , Andrew Strauss , QEMU Developers Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On Thu, 10 Jun 2021 at 15:16, Alex Benn=C3=A9e wro= te: > > > Peter Maydell writes: > > I'm told that the Arm C compiler C library always assumes that > > the "stack base" value is what it should set SP to, so reporting 0 > > for that will break binaries that were built with it. > > > > As the TODO comment notes, the "heap base" is a bit of a guess, > > but putting stackbase at top-of-RAM seems generally sensible. > > > > What bug are we trying to fix here? > > Having newlib use a value that's wrong and therefor plant it's heap in > the middle of the loaded code. > > > I think one possible implementation that might not be too > > hard to make work would be: > > > > (1) find the guest physical address of the main machine > > RAM (machine->ram). You can do this with flatview_for_each_range() > > similar to what rom_ptr_for_as() does. (It might be mapped > > more than once, we could just pick the first one.) > > Currently this is done by common_semi_find_region_base which pokes > around get_system_memory()->subregions to find a region containing an > initialised register pointer. Yes. I am suggesting we throw that code away, since (a) assuming any register happens to point in to the main RAM is dubious and (b) iterating through the subregions of get_system_memory() is not guaranteed to work either (consider the case where the system memory is inside a container MR rather than a direct child of the system memory MR). > > (2) find the largest contiguous extent of that RAM which > > is not covered by a ROM blob, by iterating through the > > ROM blob data. (This sounds like one of those slightly > > irritating but entirely tractable algorithms questions :-)) > > Does that assume that any rom blob (so anything from -kernel, -pflash or > -generic-loader?) will have also included space for guest data and bss? Yes; the elf loader code creates rom blobs whose rom->romsize covers both initialized data from the ELF file and space to be zeroed. thanks -- PMM