From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) by sourceware.org (Postfix) with ESMTPS id 134EF38515C3 for ; Sun, 29 May 2022 14:09:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 134EF38515C3 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=moxielogic.com Authentication-Results: sourceware.org; spf=none smtp.mailfrom=moxielogic.com Received: by mail-ed1-x52f.google.com with SMTP id t5so10574202edc.2 for ; Sun, 29 May 2022 07:09:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=moxielogic-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=pcsR1NeVM6ZeQ3HbSmIrEEILJ/jMr0bcocKamNVmJKs=; b=KpyN5eXcWkGfl93Y5Js0tlXFarJcwzZA3Y7rz29zn8Sdd+jQrEcpWS05l8h3NX/fW9 J3k2kpG0tMkXnZKaZrZ80sDZ9ydoXIawukTZQCBh6Gy9KPwN9TR59ioagRvi44iR5BmS me8pakkLZagC9dCf+6525wI9VskS6amh+pH27a992Dt6RSN3WKJ3QEPDBx13fNR+Kquu FwctV0eEPdhZDWTqymAWXHsFuPplFccawdEiSOx+8PN4Ln8pMCihJOgjyOv60LjLmqMq l5nZLI9MzKJQjz+QFlJE+x6w7WpCFnj6cNMmtD+/J7ydCkSVD2OFtI7+smL0zxONal5R 9LOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=pcsR1NeVM6ZeQ3HbSmIrEEILJ/jMr0bcocKamNVmJKs=; b=TSUu9Bk9G7RYpNBpTa4mdn2AF8VP7s9dWxGMispzjm4n6vBpJnpyuDm/CMnSCZBnjM ZYsJZXs3zdODKp4OXjavbekwYhAJf61hhOk0SqZKij1cODbIkTbdU9T13q5H1CLsyYPY LX6U4uRVABb+SqNtwfmQUr/xocY+licTCQRcGc1vHK08aQqGkZxbVdO7w8D8CGf4j+p7 vdSCp+53AZi5XI8w8G3h89B9kiG9U7fuP8+GVXzayx0u0Mn4RtDMYmvYQZTinjKXLV0m wNEL6oeR5ZQ4J6IdStlCZ9Zq2OLDtEnSldOWHKfWzQvTtwuWRt1mDlFhmbf88GFHBWBd 6tTQ== X-Gm-Message-State: AOAM532BeTLbVWGUHwlrsc3RLF+8Yjrrcm0WxdCGojJTDh6QkVgUomzf WO5nhMUbvwGG4qMjxeNeA9NVhg0ex/WLJRpTKfMs6LDEsesqvQ== X-Google-Smtp-Source: ABdhPJzlQECbMupO76lFwQgosw2HfsgaNB3pVp7TzttYY80idhjwd8IN0/uer0pOO0y40IfiB52iuAkkt6YaemZX5oY= X-Received: by 2002:aa7:d4c7:0:b0:42b:cf45:1701 with SMTP id t7-20020aa7d4c7000000b0042bcf451701mr21756489edr.161.1653833387674; Sun, 29 May 2022 07:09:47 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Anthony Green Date: Sun, 29 May 2022 10:09:36 -0400 Message-ID: Subject: Re: Change in libffi behaviour -- large struct args To: libffi-discuss Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: libffi-discuss@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libffi-discuss mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 May 2022 14:09:50 -0000 Interestingly, the powerpc-unknown-eabisim port mostly got this right, except that it never passed small structs in registers as it should. Does anybody care about the 32-bit embedded Power port anymore? AG On Sat, May 28, 2022 at 9:40 AM Anthony Green wrote: > > As has been discussed in various github PRs recently, I'd like to > change libffi's behaviour regarding large struct arguments. > > When passing a struct by value, most (all?) ABI definitions ask that > you try to fit structs up to a certain size into registers, and if > they are too large, make a copy and pass them on the stack. > Libffi's current behaviour is to fit small structs in registers, but > then if something is too large, pass it by reference, leaving it as an > exercise for the user to make their own copies. Many libffi users, > like cpython, do this special work themselves. I don't like this > because it exposes this ABI detail, the threshold for struct sizes, to > the libffi caller. Libffi should be making this copy itself. > > The struct_by_value_big.c test checks for this, and most ports fail > today Changing this behaviour won't introduce regressions for libffi > users, and eventually they will be able to remove their special > handling of large struct args. > > AG