From owner-svn-src-all@freebsd.org Wed Jan 13 01:48:21 2016 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 491C0A6EEF1; Wed, 13 Jan 2016 01:48:21 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-yk0-f179.google.com (mail-yk0-f179.google.com [209.85.160.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 089E71510; Wed, 13 Jan 2016 01:48:20 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-yk0-f179.google.com with SMTP id a85so395282609ykb.1; Tue, 12 Jan 2016 17:48:20 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=Za1vnLyf2v+dwuhUnSjWVzs3Om8Ksphyt9vdcXsgZ9M=; b=M/E968wGtkJRCWVH0uy1Vutk9fGafMa4plpJ/+nhoYwDrYONws/cc+lQ5XF3Ima0XO jkfkA1H2hhjnX0zvFynavSaCtOZmTrOiElC+0BMoU98dinaRr6QLVkY8/ho/dR64MO+X cXFuAbf4APLOsBTlWyzSNa7YHxz5S4g3QYU7SANH98F3fVyNTHY3i9wE6esWhixdKwgT eusaaKYGsLdv2/U4UlPF65NphrOh05MTY3PfSt6EXlB5T8ZL8a/hTm3nZ7QZhgCG5qCD by++ny56dlgb0E4cggjivy0FzbzcEvMcGjk2dI9lmyf/30werp6iJ73nx5UabjzBWA04 afSQ== X-Gm-Message-State: ALoCoQk7JNrrp9MIBL4obmbDi3LPSL+m2Y18a6khgEVzlCsOBJT7K8jDm6edOtnuNPkxtSpOcPg4nld5QYS9ofc7VOznVQijRA== X-Received: by 10.129.80.7 with SMTP id e7mr95048679ywb.329.1452649369418; Tue, 12 Jan 2016 17:42:49 -0800 (PST) Received: from mail-yk0-f169.google.com (mail-yk0-f169.google.com. [209.85.160.169]) by smtp.gmail.com with ESMTPSA id r130sm104178910ywe.49.2016.01.12.17.42.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 Jan 2016 17:42:49 -0800 (PST) Received: by mail-yk0-f169.google.com with SMTP id x67so473962094ykd.2; Tue, 12 Jan 2016 17:42:48 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.129.31.67 with SMTP id f64mr97551431ywf.94.1452649368597; Tue, 12 Jan 2016 17:42:48 -0800 (PST) Reply-To: cem@FreeBSD.org Received: by 10.37.4.69 with HTTP; Tue, 12 Jan 2016 17:42:48 -0800 (PST) In-Reply-To: <1452648737.46848.50.camel@freebsd.org> References: <201601120217.u0C2HdBC089684@repo.freebsd.org> <1452645668.46848.34.camel@freebsd.org> <56959DA7.9050206@freebsd.org> <1452646442.46848.37.camel@freebsd.org> <5695A5C4.9000409@multiplay.co.uk> <1452648737.46848.50.camel@freebsd.org> Date: Tue, 12 Jan 2016 17:42:48 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: svn commit: r293724 - in head/sys/boot: arm64/libarm64 common efi/boot1 efi/fdt efi/include efi/include/arm64 efi/libefi efi/loader efi/loader/arch/amd64 efi/loader/arch/arm efi/loader/arch/arm64 i... From: Conrad Meyer To: Ian Lepore Cc: Steven Hartland , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 01:48:21 -0000 On Tue, Jan 12, 2016 at 5:32 PM, Ian Lepore wrote: > Yep, but then I had to do this because ef->off is 64 bits even on 32 > bit arches, so I got a pointer/int size mismatch warning... > > Index: common/load_elf.c > =================================================================== > --- common/load_elf.c (revision 293796) > +++ common/load_elf.c (working copy) > @@ -886,7 +886,7 @@ __elfN(parse_modmetadata)(struct preloaded_file *f > error = __elfN(reloc_ptr)(fp, ef, v, &md, sizeof(md)); > if (error == EOPNOTSUPP) { > md.md_cval += ef->off; > - md.md_data = (void *)((uintptr_t)md.md_data + ef->off); > + md.md_data = (void *)(uintptr_t)((uintptr_t)md.md_data + > ef->off); > } else if (error != 0) > return (error); > #endif > > > That is just some special kind of ugly. Yes. You could maybe do: md.md_data = (c_caddr_t)md.md_data + (ptrdiff_t)ef->off; Instead. Yes, the ptrdiff_t will truncate uint64_t on 32-bit pointer platforms, but the result is truncated regardless when it is stored in the md_data pointer. And the result under modulus is equivalent. (You could even change the type of md_data to c_caddr_t from 'const void *' to make it easier to do math on. Then this could just be: md.md_data += (ptrdiff_t)ef->off;) Best, Conrad