From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTPS id BB71F4C8EF for ; Tue, 11 Mar 2025 23:45:22 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 31FEE68D5E3; Wed, 12 Mar 2025 01:45:19 +0200 (EET) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05olkn2063.outbound.protection.outlook.com [40.92.91.63]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 1D93268D5CA for ; Wed, 12 Mar 2025 01:45:13 +0200 (EET) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=ucyUi0PXrWaBUOBYcE+UJifI7a8WX++X6R5iU8NZpVG6r+Pe8wkT2Q3pULUaKsMT2Mm0O3g1Aq5s/0zgKyjpUF96yFRluBwq3X9owMHcSdEBIzVmuWHMmaUcUJX6QByhJ5nnXKD0s5koLIaeML8eCy8qOwLU1bEmnKVDHIq+dyCjs4vQQyyJAEFLJexqpZEtq1sviO/8S700c+WKaaalPq+npQzcbdfrddV7O2ReFMI3w6jnf9W5wSabfWwxfApO628LVSBl89u6uUxw4DF4zekaoM2QGhmwjH0m4rTu2Yw6mZvKBRdS7iuWH7NSB8JacHhFcL6E8RiJUpaSlcpPNw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Cj2mr77nnKXbwGzSXALc3PitMtAWkyP+bgxgm2C4gJY=; b=e/PWReaAefqexsq0Cr/6bu+9HK1ynz1V2ezowvUgTw+tId9ftTW4vNZPGDoqQVO2dWx+OE/wMAKWrlHwQC5l6Eox19HwrukOHUXtq/FS/yvTl0bsu5gK5t93KrvI1/QSvtRhQOeh+OGArjBMGKAm5jhvnhgD8QcIuyAlTUkyJdDmi4DI1NwEWQfjy3bH2/HG3cEm2KYB7ajR2e0Y2fv7eigMT8Jsz5mkDa37vfd+vxppqhat5ccf+Q6eBRMh9pBCw9JGlBELgNI97Tycp0R6afPfVIR+joOH/drN9wSBeu8agO/eoD7d7orBJtTtPN4zywuG2ofOHBcM5ITyjVwdFQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Cj2mr77nnKXbwGzSXALc3PitMtAWkyP+bgxgm2C4gJY=; b=df6yuHbiG7gxDSNYNmGSAZ8MwQQ6b52WzNG97aISmirkG4nVf6t0EIlRwsHLQ8DwlyxvimiDH7LXCGngNUxRcVnKLUAhf8zjBtuxyxaIfz23hKw1UbFV9rYRkawy0+m6Ob0BoAAxgfyFw4fOmyLCP7h6w7lwvkHKhJTcNezJiEc/9K0TB41FWo8xGxQ+EuwiHNhGjzwk+An7LwuaTsbo3a9GK2i2CUDHImYN2Zh6BZ8sZ7rOLQNoKiVPYGSKRHjspFidpITTyuW94XNooK/08Tj1JiZ8lwWNdpS8NJmQTZmSoJVhwfu9r1ATf6eEB9l35iXdm3LQAKPb9iyyERpqnw== Received: from GV1P250MB0737.EURP250.PROD.OUTLOOK.COM (2603:10a6:150:8e::17) by PR3P250MB0369.EURP250.PROD.OUTLOOK.COM (2603:10a6:102:17c::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8534.20; Tue, 11 Mar 2025 23:45:11 +0000 Received: from GV1P250MB0737.EURP250.PROD.OUTLOOK.COM ([fe80::d6a1:e3af:a5f1:b614]) by GV1P250MB0737.EURP250.PROD.OUTLOOK.COM ([fe80::d6a1:e3af:a5f1:b614%4]) with mapi id 15.20.8511.026; Tue, 11 Mar 2025 23:45:11 +0000 Message-ID: Date: Wed, 12 Mar 2025 00:45:09 +0100 User-Agent: Mozilla Thunderbird To: ffmpeg-devel@ffmpeg.org References: <20250303205612.3955254-1-prka@google.com> <20250311191737.2393125-1-prka@google.com> Content-Language: en-US From: Andreas Rheinhardt In-Reply-To: <20250311191737.2393125-1-prka@google.com> X-ClientProxiedBy: ZR2P278CA0045.CHEP278.PROD.OUTLOOK.COM (2603:10a6:910:47::18) To GV1P250MB0737.EURP250.PROD.OUTLOOK.COM (2603:10a6:150:8e::17) X-Microsoft-Original-Message-ID: <15a0957c-6756-4ad7-9885-957db909f767@outlook.com> MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: GV1P250MB0737:EE_|PR3P250MB0369:EE_ X-MS-Office365-Filtering-Correlation-Id: b8090b92-9e6e-4476-6311-08dd60f6c352 X-Microsoft-Antispam: BCL:0; ARA:14566002|19110799003|7092599003|5072599009|6090799003|15080799006|461199028|8060799006|41001999003|3412199025|10035399004|440099028; X-Microsoft-Antispam-Message-Info: =?utf-8?B?UmtxVGpXeU5QZmpLSzV6UmozdVlGNFZQZjV4TEVhNWJzUkttNVdRRUxuSVdn?= =?utf-8?B?bXBFRC9BRFFkMjRUaCtpSlNiSUVIaHZUdXpMR1ZvQkNhSE80alM1d2JzMGlJ?= =?utf-8?B?NmZDMDhoUnVVejFET0NvYmFKWDk0WmVvRGttZm1NclZhK1VITGZCbi9mU1lu?= =?utf-8?B?cFZHbUMrTk1NclVYWXhJNS82R2Zvc1c5VUJMbEFTa1JiNkF6NUVIejZOT2pi?= =?utf-8?B?c3ZoVHlrNStzcGVTR0g0RUYwcTd6WlB1TFVEYUhpNFdpR0NwdnRQZHlDeTNK?= =?utf-8?B?RjhReldHOW5mMGZxdDZYTFVoZ3NwN09DSEg0NERianlRN3VIcWNhcm9ESW5u?= =?utf-8?B?aEplVWxaTEJsTVAxS2lZbWFoYVJ5cUFsTXdRdC8weXNpOTg2YnBIK2VzMnYr?= =?utf-8?B?MFJXaXB0RjBPSXBtVjVnMVg1WTBlaHRwVGNUTVNPWm9oaFNpOTNDNE1yZjBv?= =?utf-8?B?RFZhNWdGbmh2Skp2UkV6ZUQxSkd5RnJMWTdXR1k5QlEvYi8xTFo4RjV6Nm16?= =?utf-8?B?cG1yMXJCMmZEUkZzcDk4SVVvNk9rOGIxMnI3WUFXY2RUTGNSTG5zazdWWFow?= =?utf-8?B?Sk5nRE4vazdXMk5IS25JamI2ZnppQXFxU2N3dytPVFdCelRPRHpiR3p2MjVn?= =?utf-8?B?Y3RFR0orZ3JLVyt4RjdJRis1MnFKdGRxYlpMWXVhU1o0TzdHS3lRS0lXRTFI?= =?utf-8?B?TTRmUnZsWFVXRXprcFIxWWdhNzFOVHIrL0VvamI5THlpYkdrN21SYXNIYUlH?= =?utf-8?B?WkI2dzJpanRDdWcxU2VPdlczWUtKeUZ3WWdOa3dKOHJXcnlSMWd4aitORjFW?= =?utf-8?B?WlBzUXBYSU9Kb2FJWlRQMDR4dC9qY2hHWXMyazhRaUtaRGdna25peWppZEhH?= =?utf-8?B?OWVGTVgxdlpyNGVWcEkvVmlxU0l3MFFTalhBcXh4bkJtaUpOT3NaemNMeWNK?= =?utf-8?B?VTZ3eEtjL1gwSElvSW8vUWtBeklCUlZYaGNiL1pkZW12RGQrOVc1eHF6bzRo?= =?utf-8?B?TCtSZ2ZWM3dpWkxEOFYzMkJmM1ZibjJuWXZoYWtFMkU1L2pqT2RndTkxc01U?= =?utf-8?B?YzlNR3I2RnRLN3lsS3hiRGZpT0NhdDl2S1dTTHJWanJZMDVOYWxFREJ4c2VW?= =?utf-8?B?Z2ZDSFFYeElOMS9LTDZhak4zYlVmOVFueHVzQlRFQmg2S1JUREpGMlBKZ2Nq?= =?utf-8?B?MXpCWHNrNnUzbHB6K0JKNXZweUkxc0tIRkludDF4OHJsa2FWMklWMzI2ZjhJ?= =?utf-8?B?ZlF5TXVCcThPZk5RNk5NakRXV0JHSHcxMk8wMUkyWnVmYVBWYnUvOXRpam8z?= =?utf-8?B?dFJkM00xeEh6YU5EeHBjT1lQTkVQeVVPVDkrT1pNSFhsc2MwRElEYXVQajJZ?= =?utf-8?B?eTZ3S1oxVHViRy9LeUoyR1E5YkhvUmppL3YvOTE0azViT1VPYWh5bno2cDB2?= =?utf-8?B?OEgySTNqOW42Z2FzYnNkeVpyUDUyMFExamxiMG9EMVZjZVBmbU5Hekx4b0hC?= =?utf-8?B?SXlldkVpSGRlZFNGc3RFMTgvZS8yUUdxUG5MaDk3UmtLVTBJeHVpeUMwYWpa?= =?utf-8?Q?IcMjb9YRu4Ai16qbdLZ+e41zCG7EfooWQ/dJRaTfxfSlx1?= X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?cU5DeXI3dFlMMGVNQjgxc2MyeVVOWThuaWNJWjhNdlNtWTAwQVlCUmRtQzRH?= =?utf-8?B?SFZ4clV4cWxzd3V4am5DY2xXdXBIVy9sQ2MvaUdrYWo4ZHJKaU15OUMvQXh2?= =?utf-8?B?Wkw5NG9DYzV5eGZINDVLVTVPdTlpdHZERWUxKzlsZ3c4M1R5YjI5ZEQ1Z0lI?= =?utf-8?B?b0xSQnFFVVJEUnZCTWlhWHlSd3RZM3pXUjY5eWtkS2VUSXkzK2NhbE1yVTVy?= =?utf-8?B?c3dBWitiMFRoRzJhVGR0cjkrSk5hSkkvUlZzbU9YQnY4VzNheERkdytpL3gw?= =?utf-8?B?ZjdpV0xKUVQxTnA2M1lxMWh3cnhRQ2ZTeVVMS05rZ2JvalpNc0VKZW5KU3Z3?= =?utf-8?B?a3VBSGVXWG1WbDdDOGZDY2dzUUpFYlRyUklrSDI3TllNMTZnZnQ0NXV3bmor?= =?utf-8?B?RjdUN3VLWWQ2SXZhbTF4NUhxRUxHMUIwVGN1T0RFeXlmMmZxWUJkSFpna3I2?= =?utf-8?B?KzJZL2ExY283eDVPTWZ4Vndac04zL0diYTNveitVZFJndHZXczI3KzhHWnpM?= =?utf-8?B?Mkk5UnM4UzdldEtsOWYwbWs2NmhmUUJodEVrUi9acWd3SjFncWxYbkdJUmJw?= =?utf-8?B?bnAvSDVwMHJObWUrZk5peEZPMm8zVDNLdWM1a2orOWZCMzhpRk16eS9waWZj?= =?utf-8?B?dVVvUzF1L0hPUVpZL0xobXNnRTlaVExDSDd4aW1kL0xLVlViWTh0azM0ODRP?= =?utf-8?B?Y3RoV0tPTG95a3BOLzZZVVI2elR6bjgyckprMzVQTnlkT2xxN2k5dWlDWnhh?= =?utf-8?B?OXNpbVNpSXhHbUxJTjFhK1VpcjV4azRNR3ZFQjhRMzZ3Y0dsSjh3NXpicnlq?= =?utf-8?B?MFJZWENwcHdaQzhrbWpsbSszbWdQWDQ3MnR1c2lFZVBweFk3RUUySkNzcW43?= =?utf-8?B?M2YyMU1HakpvSnhoWU1EOXdqTW9MY3RTQmFzd3JLV0hWSzVLSmJHZTFWMXBx?= =?utf-8?B?VFVmKzFTWm5nVDJhVjVNbkJrTUlSYlBYMFAxa250YkdTamVwbTRLVGJUWGdB?= =?utf-8?B?ajJqTEJWSElsN05STVZwRGwvWkFQOGgxd0N0NUtwQ1NVU0dLNHoyUTI2VDh5?= =?utf-8?B?OUlzbVF4RVdiRUZDUEwzUG43MUVxbnR6bVZWbXBqVzduZzZya0czQW1wMnRr?= =?utf-8?B?YVFJeHNmeTFITE8xOWZoMTB3aksyNmVqRmt2WUpmUkFWd1AxLzZlRTIzQ1JR?= =?utf-8?B?WStxSHlReTlDMmljRkZmU0VVQWpuNmZ6cmk3THUvNFJOMXVuOE8xS3Q2NlJG?= =?utf-8?B?cjdiU2xrNW9zUGNyY1FWUlAzZU5RdDFkM3U2Q01McFN6c0cyQjk2YkxHWUQz?= =?utf-8?B?UVlzSHBwbXhnY29uRDkwRVV1Sm5wRHVuUzk1Yk1ObU1ZS3E3TndUV1pYTTBw?= =?utf-8?B?aDNtT2tKc3ZVdmkyTWFkZjlKSmFmUHJPbHdGV2NieFF0R2xaVUV2Q3NjM0Z1?= =?utf-8?B?dHhRbjlOTE9QSHZBWHkvakw0a0dkeWNYbldvUUpObWRSU29xMXZWZ3F0Y1BS?= =?utf-8?B?TFpiWjFFYk93eFhsd0VCSjJqNEdYWXFpWUQrRGYxOGswVElNNWVTL0xIMGpm?= =?utf-8?B?SHFIUi9CSXhEbTdDUFhia1NFNUZKTFU2Yis1MkFRRFpPQlZ5d3dUUkVpSjFx?= =?utf-8?B?d0FidkY0MFUvMzZRV0hOamltczc2UTdwaURESC9nUDJXajFISUJtWUJBZHgr?= =?utf-8?B?cEZzQTNTeC96NjhCWW5MQWJxQk9hMDNoMHFKUm9aYVdQUzFialNMbHZRPT0=?= X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: b8090b92-9e6e-4476-6311-08dd60f6c352 X-MS-Exchange-CrossTenant-AuthSource: GV1P250MB0737.EURP250.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Mar 2025 23:45:11.4463 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: PR3P250MB0369 Subject: Re: [FFmpeg-devel] [PATCH v4] Mark C globals with small code model X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: Pranav Kant via ffmpeg-devel: > By default, all globals in C/C++ compiled by clang are allocated > in non-large data sections. See [1] for background on code models. > For PIC (Position independent code), this is fine as long as binary is > small but as binary size increases, users maybe want to use medium/large > code models (-mcmodel=medium) which moves data in to large sections. > As data in these large sections cannot be accessed using PIC code > anymore (as it may be too far away), compiler ends up using a different > instruction sequence when building C/C++ code -- using GOT to access > these globals (which can be relaxed by linker at link time if binary > ends up being smaller). However, assembly files continue to access these > globals defined in C/C++ files using older (and invalid instruction > sequence). So, we mark all such globals with an attribute that forces > them to be allocated in small sections allowing them to validly be > accessed from the assembly code. > > This patch should not have any affect on builds that use small code > model, which is the default mode. > > [1] https://eli.thegreenplace.net/2012/01/03/understanding-the-x64-code-models > > Signed-off-by: Pranav Kant > --- > libavcodec/ac3dsp.c | 2 ++ > libavcodec/cabac.c | 2 ++ > libavcodec/x86/constants.c | 8 ++++++++ > libavutil/attributes.h | 6 ++++++ > libavutil/attributes_internal.h | 16 ++++++++++++++++ > 5 files changed, 34 insertions(+) > > diff --git a/libavcodec/ac3dsp.c b/libavcodec/ac3dsp.c > index 730fa70fff..d16b6c24c3 100644 > --- a/libavcodec/ac3dsp.c > +++ b/libavcodec/ac3dsp.c > @@ -25,6 +25,7 @@ > > #include "config.h" > #include "libavutil/attributes.h" > +#include "libavutil/attributes_internal.h" > #include "libavutil/common.h" > #include "libavutil/intmath.h" > #include "libavutil/mem_internal.h" > @@ -104,6 +105,7 @@ static void ac3_update_bap_counts_c(uint16_t mant_cnt[16], uint8_t *bap, > mant_cnt[bap[len]]++; > } > > +attribute_mcmodel_small > DECLARE_ALIGNED(16, const uint16_t, ff_ac3_bap_bits)[16] = { Shouldn't stuff like this be applied to the declaration so that C code can also take advantage of the knowledge that this object will be placed in the small code section? > 0, 0, 0, 3, 0, 4, 5, 6, 7, 8, 9, 10, 11, 12, 14, 16 > }; > diff --git a/libavcodec/cabac.c b/libavcodec/cabac.c > index 7d41cd2ae6..b8c6db29a2 100644 > --- a/libavcodec/cabac.c > +++ b/libavcodec/cabac.c > @@ -24,11 +24,13 @@ > * Context Adaptive Binary Arithmetic Coder. > */ > > +#include "libavutil/attributes_internal.h" > #include "libavutil/error.h" > #include "libavutil/mem_internal.h" > > #include "cabac.h" > > +attribute_mcmodel_small > DECLARE_ASM_ALIGNED(1, const uint8_t, ff_h264_cabac_tables)[512 + 4*2*64 + 4*64 + 63] = { Your commit message ("However, assembly files continue to access") speaks only of assembly files, i.e. external asm. Yet this here is only used by inline ASM. Looking through the code the reason for this is that I thought that specifying the memory model is only necessary for stuff used by external asm, yet ff_h264_cabac_tables does not seem to be used by external ASM at all, only inline ASM. If I see this correctly, the reason for this is that LOCAL_MANGLE (and therefore MANGLE) uses rip addressing on x64 when configure sets the RIP define. But this means that the set of files needing attribute_mcmodel_small is a superset of the files currently using DECLARE_ASM_ALIGNED. This means that one would only need two macros for the variables accessed by ASM: One for only external ASM and one for inline ASM (and potentially external ASM) instead of adding attribute_mcmodel_small at various places in the codebase. > 9,8,7,7,6,6,6,6,5,5,5,5,5,5,5,5, > 4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4, > diff --git a/libavcodec/x86/constants.c b/libavcodec/x86/constants.c > index bc7f2b17b8..347b7dd1d3 100644 > --- a/libavcodec/x86/constants.c > +++ b/libavcodec/x86/constants.c > @@ -18,17 +18,21 @@ > * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA > */ > > +#include "libavutil/attributes_internal.h" > #include "libavutil/mem_internal.h" > #include "libavutil/x86/asm.h" // for xmm_reg > #include "constants.h" > > +attribute_mcmodel_small > DECLARE_ALIGNED(32, const ymm_reg, ff_pw_1) = { 0x0001000100010001ULL, 0x0001000100010001ULL,> 0x0001000100010001ULL, 0x0001000100010001ULL }; > DECLARE_ALIGNED(32, const ymm_reg, ff_pw_2) = { 0x0002000200020002ULL, 0x0002000200020002ULL, > 0x0002000200020002ULL, 0x0002000200020002ULL }; > DECLARE_ASM_ALIGNED(16, const xmm_reg, ff_pw_3) = { 0x0003000300030003ULL, 0x0003000300030003ULL }; > +attribute_mcmodel_small > DECLARE_ASM_ALIGNED(32, const ymm_reg, ff_pw_4) = { 0x0004000400040004ULL, 0x0004000400040004ULL, > 0x0004000400040004ULL, 0x0004000400040004ULL }; > +attribute_mcmodel_small > DECLARE_ASM_ALIGNED(16, const xmm_reg, ff_pw_5) = { 0x0005000500050005ULL, 0x0005000500050005ULL }; > DECLARE_ALIGNED(16, const xmm_reg, ff_pw_8) = { 0x0008000800080008ULL, 0x0008000800080008ULL }; > DECLARE_ASM_ALIGNED(16, const xmm_reg, ff_pw_9) = { 0x0009000900090009ULL, 0x0009000900090009ULL }; > @@ -49,6 +53,7 @@ DECLARE_ALIGNED(32, const ymm_reg, ff_pw_256) = { 0x0100010001000100ULL, 0x010 > DECLARE_ALIGNED(32, const ymm_reg, ff_pw_512) = { 0x0200020002000200ULL, 0x0200020002000200ULL, > 0x0200020002000200ULL, 0x0200020002000200ULL }; > DECLARE_ALIGNED(16, const xmm_reg, ff_pw_1019) = { 0x03FB03FB03FB03FBULL, 0x03FB03FB03FB03FBULL }; > +attribute_mcmodel_small > DECLARE_ALIGNED(32, const ymm_reg, ff_pw_1023) = { 0x03ff03ff03ff03ffULL, 0x03ff03ff03ff03ffULL, > 0x03ff03ff03ff03ffULL, 0x03ff03ff03ff03ffULL}; > DECLARE_ALIGNED(32, const ymm_reg, ff_pw_1024) = { 0x0400040004000400ULL, 0x0400040004000400ULL, > @@ -66,13 +71,16 @@ DECLARE_ALIGNED(32, const ymm_reg, ff_pw_m1) = { 0xFFFFFFFFFFFFFFFFULL, 0xFFF > > DECLARE_ALIGNED(32, const ymm_reg, ff_pb_0) = { 0x0000000000000000ULL, 0x0000000000000000ULL, > 0x0000000000000000ULL, 0x0000000000000000ULL }; > +attribute_mcmodel_small > DECLARE_ALIGNED(32, const ymm_reg, ff_pb_1) = { 0x0101010101010101ULL, 0x0101010101010101ULL, > 0x0101010101010101ULL, 0x0101010101010101ULL }; > DECLARE_ALIGNED(32, const ymm_reg, ff_pb_2) = { 0x0202020202020202ULL, 0x0202020202020202ULL, > 0x0202020202020202ULL, 0x0202020202020202ULL }; > +attribute_mcmodel_small > DECLARE_ALIGNED(32, const ymm_reg, ff_pb_3) = { 0x0303030303030303ULL, 0x0303030303030303ULL, > 0x0303030303030303ULL, 0x0303030303030303ULL }; > DECLARE_ALIGNED(32, const xmm_reg, ff_pb_15) = { 0x0F0F0F0F0F0F0F0FULL, 0x0F0F0F0F0F0F0F0FULL }; > +attribute_mcmodel_small > DECLARE_ALIGNED(32, const ymm_reg, ff_pb_80) = { 0x8080808080808080ULL, 0x8080808080808080ULL, > 0x8080808080808080ULL, 0x8080808080808080ULL }; > DECLARE_ALIGNED(32, const ymm_reg, ff_pb_FE) = { 0xFEFEFEFEFEFEFEFEULL, 0xFEFEFEFEFEFEFEFEULL, Why do you add this attribute to only eight of these constants? How did you come up with this list? In addition to the above, git grep cextern shows that there are several more variables than just these one (e.g. ff_h263_loop_filter_strength, ff_sbr_noise_table). > diff --git a/libavutil/attributes.h b/libavutil/attributes.h > index 04c615c952..dfc35fa31e 100644 > --- a/libavutil/attributes.h > +++ b/libavutil/attributes.h > @@ -40,6 +40,12 @@ > # define AV_HAS_BUILTIN(x) 0 > #endif > > +#ifdef __has_attribute > +# define AV_HAS_ATTRIBUTE(x) __has_attribute(x) > +#else > +# define AV_HAS_ATTRIBUTE(x) 0 > +#endif > + > #ifndef av_always_inline > #if AV_GCC_VERSION_AT_LEAST(3,1) > # define av_always_inline __attribute__((always_inline)) inline > diff --git a/libavutil/attributes_internal.h b/libavutil/attributes_internal.h > index bc85ce77ff..c557fa0af0 100644 > --- a/libavutil/attributes_internal.h > +++ b/libavutil/attributes_internal.h > @@ -19,6 +19,7 @@ > #ifndef AVUTIL_ATTRIBUTES_INTERNAL_H > #define AVUTIL_ATTRIBUTES_INTERNAL_H > > +#include "config.h" > #include "attributes.h" > > #if (AV_GCC_VERSION_AT_LEAST(4,0) || defined(__clang__)) && (defined(__ELF__) || defined(__MACH__)) > @@ -33,4 +34,19 @@ > > #define EXTERN extern attribute_visibility_hidden > > +/** > + * Some globals defined in C files are used from hardcoded asm that assumes small > + * code model (that is, accessing these globals without GOT). This is a problem > + * when FFMpeg is built with medium code model (-mcmodel=medium) which allocates s/FFMpeg/FFmpeg/ > + * all globals in a data section that's unreachable with PC relative instructions > + * (small code model instruction sequence). We mark all such globals with this > + * attribute_mcmodel_small to ensure assembly accessible globals continue to be > + * allocated in sections reachable from PC relative instructions. > + */ > +#if ARCH_X86_64 && defined(__ELF__) && AV_HAS_ATTRIBUTE(model) You make this ARCH_X86_64 only, yet the concept of code models also exists for other arches, e.g. AArch64. I presume that assembly for other arches presumes that we are not using the large code model for accesses, so that the same issue can happen with them. Then we have two options: a) Continue to use the same macro you are adding here. This will mean that stuff only used in assembly by different arches will nevertheless be declared as using the small code model, potentially clogging the small symbol address space unnecessarily. b) Use one macro per arch. I presume we want to go with a), because the objects we are talking about are so small that they should be in the small data section anyway. > +# define attribute_mcmodel_small __attribute__((model("small"))) > +#else > +# define attribute_mcmodel_small > +#endif > + > #endif /* AVUTIL_ATTRIBUTES_INTERNAL_H */ _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".