From nobody Sat Feb 7 06:35:31 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.com: domain of gnu.org designates 209.51.188.17 as permitted sender) client-ip=209.51.188.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Authentication-Results: mx.zohomail.com; spf=pass (zoho.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=fail(p=none dis=none) header.from=redhat.com ARC-Seal: i=1; a=rsa-sha256; t=1564485966; cv=none; d=zoho.com; s=zohoarc; b=HkqV543GuTBagy4E0Mp8sVcQxbFPFWsp1UAbiHijveDNJVal3W88NEjRxDD/ElJaWxRoeovG76gdsod37Ds74mvQPD9CVTU4QEoyJWlzZvi8q8mcoCx+W5e27gNOp7JqJzu2AjgFvPPad1jOf+iasg8vtcyq1mUwHHXOaJE6Dc8= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com; s=zohoarc; t=1564485966; h=Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:To:ARC-Authentication-Results; bh=sIlJoxJkZn/WPmUh9JXJicSMGkOCu8GqAOsbYq/zTlI=; b=X3x6NZFcNb+pev0lDGgwDFpNtcwW4OzFuoVIx3rgQdDVI3kVpLiUkH302eSgiXqzZipmsSCOXaosar4FN8YzLAvbl5Ky0N3xpQC0VKNX0+qav6Z0U3B9ZoDnqF+sIil/URQQAnD5WQh+L7m5PLbh/DtaxzJbiuRMrjGhkgPYGn0= ARC-Authentication-Results: i=1; mx.zoho.com; spf=pass (zoho.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=fail header.from= (p=none dis=none) header.from= Return-Path: Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) by mx.zohomail.com with SMTPS id 1564485965971834.0407763444291; Tue, 30 Jul 2019 04:26:05 -0700 (PDT) Received: from localhost ([::1]:59830 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hsQGa-000562-3k for importer@patchew.org; Tue, 30 Jul 2019 07:26:04 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:52200) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hsQFD-0003Xe-Ft for qemu-devel@nongnu.org; Tue, 30 Jul 2019 07:24:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hsQFB-0006fp-1L for qemu-devel@nongnu.org; Tue, 30 Jul 2019 07:24:38 -0400 Received: from mx1.redhat.com ([209.132.183.28]:36856) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hsQF5-0006dB-S1; Tue, 30 Jul 2019 07:24:32 -0400 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 16AE081DF1; Tue, 30 Jul 2019 11:24:31 +0000 (UTC) Received: from localhost.localdomain.com (ovpn-117-75.ams2.redhat.com [10.36.117.75]) by smtp.corp.redhat.com (Postfix) with ESMTP id 0AAEF60623; Tue, 30 Jul 2019 11:24:29 +0000 (UTC) From: Kevin Wolf To: qemu-block@nongnu.org Date: Tue, 30 Jul 2019 13:24:22 +0200 Message-Id: <20190730112425.21497-2-kwolf@redhat.com> In-Reply-To: <20190730112425.21497-1-kwolf@redhat.com> References: <20190730112425.21497-1-kwolf@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Tue, 30 Jul 2019 11:24:31 +0000 (UTC) Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.132.183.28 Subject: [Qemu-devel] [PULL 1/4] tests/multiboot: Fix load address of test kernels 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: kwolf@redhat.com, peter.maydell@linaro.org, qemu-devel@nongnu.org Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" Content-Type: text/plain; charset="utf-8" While older toolchains produced binaries where the physical load address of ELF segments was the same as the virtual address, newer versions seem to choose a different physical address if it isn't specified explicitly. The means that the test kernel doesn't use the right addresses to access e.g. format strings any more and the whole output disappears, causing all test cases to fail. Fix this by specifying the physical load address of sections explicitly. Signed-off-by: Kevin Wolf --- tests/multiboot/link.ld | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/tests/multiboot/link.ld b/tests/multiboot/link.ld index 3d49b58c60..2eafcffc4f 100644 --- a/tests/multiboot/link.ld +++ b/tests/multiboot/link.ld @@ -3,14 +3,14 @@ ENTRY(_start) SECTIONS { . =3D 0x100000; - .text : { + .text : AT(ADDR(.text)) { *(multiboot) *(.text) } - .data ALIGN(4096) : { + .data ALIGN(4096) : AT(ADDR(.data)) { *(.data) } - .rodata ALIGN(4096) : { + .rodata ALIGN(4096) : AT(ADDR(.rodata)) { *(.rodata) } .bss ALIGN(4096) : { --=20 2.20.1