Message ID | 262f296e-673b-47f0-a764-276939161d64@suse.com |
---|---|
State | Unresolved |
Headers |
Return-Path: <binutils-bounces+ouuuleilei=gmail.com@sourceware.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:50ea:b0:106:860b:bbdd with SMTP id r10csp698958dyd; Fri, 9 Feb 2024 00:11:40 -0800 (PST) X-Google-Smtp-Source: AGHT+IFaCajtT4e9U7JAvd54TtDYM/tPRHwBYzbjbgt+ZcituUF7ZaVgCNXq4EbuPUBzJpA+swva X-Received: by 2002:a0c:cc86:0:b0:68c:7f05:cd87 with SMTP id f6-20020a0ccc86000000b0068c7f05cd87mr993960qvl.41.1707466300278; Fri, 09 Feb 2024 00:11:40 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1707466300; cv=pass; d=google.com; s=arc-20160816; b=DFhbvmQf/6F0srWOwK/XeBUDOoGG3zfoADMNp6ngqYFg1FGvfQAQJCJCUjh8K569oq 1cHFak4JnY7q3+/ubg9K0gFaUL/uWaqRyWhn/xBOyTUokF8fWYbbgqmD0wiHmtTI3y9q cfUiFlxqHPNbOnIB4hM3iIDQ/mVNeWjO/esjWLazltCefC+/d8M3Ykw5JFDJYiZupoCx P5QpxSEaDOnPXTkpT5UdCSgUj+EzY7szb72tN7behFKGMDQcYj65F1D3DCr29uQ5jFtR XbO5+FB6cXB0u+kNcWaMsvbkcKhXHqeWDAH1HtGsqbkQH7Kej1/MhNGDhMX2IdDWPZ3f GQJg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=errors-to:list-subscribe:list-help:list-post:list-archive :list-unsubscribe:list-id:precedence:content-transfer-encoding :autocrypt:subject:from:cc:to:content-language:user-agent :mime-version:date:message-id:dkim-signature:arc-filter:dmarc-filter :delivered-to; bh=hdTpYzd+nsAWK7P44vxUxHIdS7LeLCypU7qNjQIdCSc=; fh=5IAXylCuwHCMoXc3Cu7sdK3kghbdq9Nglo0jBCVfRIM=; b=WJO9gGltFNb37STr5MmMYj8Fmqwu/yWiVn88gsMNsuphtVEGHhb/Hj+Wj9Knj2jGiV gxv/9yvbRhcKtyh/qRQcef1JozayMvkvqDYKXD1ry51uwg6GYjYMKmjv40Lrwcm6QdOJ LTRf1KlI2sXke975qQbmVDzTpLI2kFL1TA9QrsVkOzLf9GIWU7rSf5p6EuDm1GDA5Ztz m1rlMevx/CDPwfCHZfEdgcR77w1IF9oPZSmKEFlouVtCPpkqH5a4BwqAUyMG+VDIJHtM PvFmT1PHUYkRj411OWbzxe3QwrJavwiuaO6tVCDpFXFZpTYjYe4vt6HytGmri/jM+0KS 44LQ==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@suse.com header.s=google header.b=cDkTfJcp; arc=pass (i=1); spf=pass (google.com: domain of binutils-bounces+ouuuleilei=gmail.com@sourceware.org designates 2620:52:3:1:0:246e:9693:128c as permitted sender) smtp.mailfrom="binutils-bounces+ouuuleilei=gmail.com@sourceware.org"; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=suse.com X-Forwarded-Encrypted: i=2; AJvYcCUGLRBJiBtg+dmpGg0tU/SG998HtiYb1HAjASHOzl5BFWWN4BWYxWVQ+k1sGzuEueqpb9labn4neACVpn4CONUn/XRqtg== Received: from server2.sourceware.org (server2.sourceware.org. [2620:52:3:1:0:246e:9693:128c]) by mx.google.com with ESMTPS id 3-20020a05621420a300b0068c64c00962si1382940qvd.532.2024.02.09.00.11.40 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 09 Feb 2024 00:11:40 -0800 (PST) Received-SPF: pass (google.com: domain of binutils-bounces+ouuuleilei=gmail.com@sourceware.org designates 2620:52:3:1:0:246e:9693:128c as permitted sender) client-ip=2620:52:3:1:0:246e:9693:128c; Authentication-Results: mx.google.com; dkim=pass header.i=@suse.com header.s=google header.b=cDkTfJcp; arc=pass (i=1); spf=pass (google.com: domain of binutils-bounces+ouuuleilei=gmail.com@sourceware.org designates 2620:52:3:1:0:246e:9693:128c as permitted sender) smtp.mailfrom="binutils-bounces+ouuuleilei=gmail.com@sourceware.org"; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=suse.com Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id DE2823858283 for <ouuuleilei@gmail.com>; Fri, 9 Feb 2024 08:11:39 +0000 (GMT) X-Original-To: binutils@sourceware.org Delivered-To: binutils@sourceware.org Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) by sourceware.org (Postfix) with ESMTPS id 450073858417 for <binutils@sourceware.org>; Fri, 9 Feb 2024 08:11:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 450073858417 Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 450073858417 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::332 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1707466283; cv=none; b=ciNt/LMIrtl98+WPLS1y5zq0cbYxw6LDwu4ND+yhg7/rVQsEwxYAH+8J9yTUL/1frWiX3zsVMCRDo7m8UpJKdvJTvTMHR0pUNF54b/A4Tqe3QLIqxHglQi2fh9nTm0yC3mfCjROInk9Itggq0IZD7uzu6/gIxDfzcuilKNPiqU4= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1707466283; c=relaxed/simple; bh=0Xi8umXNgEBl7UfhH0umLh+LjER9Fid/jlqhNPcymBw=; h=DKIM-Signature:Message-ID:Date:MIME-Version:To:From:Subject; b=DdfLi7JZHiyZL1Meer9mlxcIuzR27c4QA4jHdRUBK8RxY4kS3sRMYFSbFZKIbD/G8M8fjAiI6hLb6KwmvOR7UBnhtCYTMYnmaC0W4xroybMT8fqYbIXy3L/OhXlbe+Af4LHuI8dD2/JnoH4TtXK/HURAnUKO/Ky4OhifUvbETio= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-wm1-x332.google.com with SMTP id 5b1f17b1804b1-4105a6be071so3479235e9.1 for <binutils@sourceware.org>; Fri, 09 Feb 2024 00:11:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1707466280; x=1708071080; darn=sourceware.org; h=content-transfer-encoding:autocrypt:subject:from:cc:to :content-language:user-agent:mime-version:date:message-id:from:to:cc :subject:date:message-id:reply-to; bh=hdTpYzd+nsAWK7P44vxUxHIdS7LeLCypU7qNjQIdCSc=; b=cDkTfJcpy4bD3GRjSYj5F31TllI9UkUyXUSp/40FD9prs3zwqgkpnXT5AgRC30MPYN 9a9jDLe4vzCtmspgz3yO3PVn3bUYLftjey/Y7/gVkWGup7HNYeXG90Iq1rowSf40Hei+ x40UNZiql2Ha8IY2/4OBcR7gnKZ7/j3flpr/IZ2NNjjjehc8Afw6wIVBFnGxpfV5XdoD +D7eNUcyTGzo4hmyWUQdtMctqY8QFxIBUnIUZtdkxpiZv/2nKpd53wiHfwZE/51AArxb 5uZ7Fah9n0/+OW5iiEVQOL4YgRNQUvf/NI99diNnX6mBZrjtYulgB3SprXDrtzWlrY/M myAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707466280; x=1708071080; h=content-transfer-encoding:autocrypt:subject:from:cc:to :content-language:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=hdTpYzd+nsAWK7P44vxUxHIdS7LeLCypU7qNjQIdCSc=; b=Jl8EZBR7Ng8NvWkMEC/g5PRYlb8y0aH0yQe7PXiGlHaFGjj6FXrNavqXPXjcmohOEo 0R4FxlJIEml7JUt7udPvxERRr4Rt6EHAiDOhVCY89BeWlMIDR+H1h30iCnTLiqXseQy5 PQy3hZdlEzIIEE6HI45vmQTUenA6kVjGaBpPL63NLRWUKlvB3zuIw6WkQI0iElTbWp1C nvUpwtHLmfAxlxfwf3ejLS9SZHLZ4Usym4MMbrssTwjJTjqwVtrSfHDa2pVPuUc5JHCG P27gAf77Gor6teYubNsmadRxaiZqWxrbpv5mvhc0p1muuXXNPHjyNBJ9DVTha6gpExG/ 9MVA== X-Gm-Message-State: AOJu0YzpElTEJVggp+rgB8ysFvIi7mFuyTzGujg3slMiZ7j9A3NL5lG5 uWwhvUEElIMSFx/BYpIKfOyqb38sfEAb9YpjLlDVCoPxxRVsIbVza89K7DTymer3H9DwgeP/1v8 = X-Received: by 2002:a05:600c:1e28:b0:40f:ee21:2054 with SMTP id ay40-20020a05600c1e2800b0040fee212054mr313837wmb.8.1707466280068; Fri, 09 Feb 2024 00:11:20 -0800 (PST) X-Forwarded-Encrypted: i=1; AJvYcCWfecJTG/OayfzmiGw4VZBoH2TWHNSwl469ws3leQz5lViOYLADfkVLbri8MXsR1VHA8mC5BlHDL52LsLIaW6frXjazvAHq Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id m3-20020adfa3c3000000b0033b512b2031sm1155326wrb.114.2024.02.09.00.11.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 09 Feb 2024 00:11:19 -0800 (PST) Message-ID: <262f296e-673b-47f0-a764-276939161d64@suse.com> Date: Fri, 9 Feb 2024 09:11:19 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: Binutils <binutils@sourceware.org> Cc: "H.J. Lu" <hjl.tools@gmail.com>, Indu Bhagat <indu.bhagat@oracle.com> From: Jan Beulich <jbeulich@suse.com> Subject: [PATCH] x86: adjust which Dwarf2 register numbers to use Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3025.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, 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: binutils@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Binutils mailing list <binutils.sourceware.org> List-Unsubscribe: <https://sourceware.org/mailman/options/binutils>, <mailto:binutils-request@sourceware.org?subject=unsubscribe> List-Archive: <https://sourceware.org/pipermail/binutils/> List-Post: <mailto:binutils@sourceware.org> List-Help: <mailto:binutils-request@sourceware.org?subject=help> List-Subscribe: <https://sourceware.org/mailman/listinfo/binutils>, <mailto:binutils-request@sourceware.org?subject=subscribe> Errors-To: binutils-bounces+ouuuleilei=gmail.com@sourceware.org X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1790408182918615214 X-GMAIL-MSGID: 1790408182918615214 |
Series |
x86: adjust which Dwarf2 register numbers to use
|
|
Checks
Context | Check | Description |
---|---|---|
snail/binutils-gdb-check | warning | Git am fail log |
Commit Message
Jan Beulich
Feb. 9, 2024, 8:11 a.m. UTC
Consumers can't know which execution mode is in effect for a certain piece of code; they can only go from object file properties. Hence which register numbers to encode ought to depend solely on object file type.
Comments
On 2/9/24 00:11, Jan Beulich wrote: > Consumers can't know which execution mode is in effect for a certain > piece of code; they can only go from object file properties. Hence which > register numbers to encode ought to depend solely on object file type. > > --- a/gas/config/tc-i386.c > +++ b/gas/config/tc-i386.c > @@ -5409,7 +5409,7 @@ ginsn_dw2_regnum (const reg_entry *ireg) > if (ireg->reg_num == RegIP || ireg->reg_num == RegIZ) > return GINSN_DW2_REGNUM_RSI_DUMMY; > > - dwarf_reg = ireg->dw2_regnum[flag_code >> 1]; > + dwarf_reg = ireg->dw2_regnum[object_64bit]; > > if (dwarf_reg == Dw2Inval) > { > @@ -17461,7 +17461,7 @@ tc_x86_parse_to_dw2regnum (expressionS * > if ((addressT) exp->X_add_number < i386_regtab_size) > { > exp->X_add_number = i386_regtab[exp->X_add_number] > - .dw2_regnum[flag_code >> 1]; > + .dw2_regnum[object_64bit]; > if (exp->X_add_number != Dw2Inval) > exp->X_op = O_constant; > } On one hand, I see that the suggested code changes are making things semantically clearer, I would like to understand: 1. If there is a scenario where flag_code is CODE16_BIT / CODE32_BIT and object_64bit equal to 1 is supported. gcc passes --32 when using -m16 or -m32. 2. Irrespective of #1, shouldn't we then also use "if (object_64bit == 1)" instead of "if (flag_code == CODE_64BIT)" in md_begin where we set the value of x86_dwarf2_return_column etc ? Thanks
On 15.02.2024 23:22, Indu Bhagat wrote: > On 2/9/24 00:11, Jan Beulich wrote: >> Consumers can't know which execution mode is in effect for a certain >> piece of code; they can only go from object file properties. Hence which >> register numbers to encode ought to depend solely on object file type. >> >> --- a/gas/config/tc-i386.c >> +++ b/gas/config/tc-i386.c >> @@ -5409,7 +5409,7 @@ ginsn_dw2_regnum (const reg_entry *ireg) >> if (ireg->reg_num == RegIP || ireg->reg_num == RegIZ) >> return GINSN_DW2_REGNUM_RSI_DUMMY; >> >> - dwarf_reg = ireg->dw2_regnum[flag_code >> 1]; >> + dwarf_reg = ireg->dw2_regnum[object_64bit]; >> >> if (dwarf_reg == Dw2Inval) >> { >> @@ -17461,7 +17461,7 @@ tc_x86_parse_to_dw2regnum (expressionS * >> if ((addressT) exp->X_add_number < i386_regtab_size) >> { >> exp->X_add_number = i386_regtab[exp->X_add_number] >> - .dw2_regnum[flag_code >> 1]; >> + .dw2_regnum[object_64bit]; >> if (exp->X_add_number != Dw2Inval) >> exp->X_op = O_constant; >> } > > On one hand, I see that the suggested code changes are making things > semantically clearer, I would like to understand: > > 1. If there is a scenario where flag_code is CODE16_BIT / CODE32_BIT and > object_64bit equal to 1 is supported. gcc passes --32 when using -m16 > or -m32. Well, gcc may never produce such input, but hand-written assembly can. > 2. Irrespective of #1, shouldn't we then also use "if (object_64bit == > 1)" instead of "if (flag_code == CODE_64BIT)" in md_begin where we set > the value of x86_dwarf2_return_column etc ? Good point, let me make a v2. Jan
On 2/15/24 23:26, Jan Beulich wrote: > On 15.02.2024 23:22, Indu Bhagat wrote: >> On 2/9/24 00:11, Jan Beulich wrote: >>> Consumers can't know which execution mode is in effect for a certain >>> piece of code; they can only go from object file properties. Hence which >>> register numbers to encode ought to depend solely on object file type. >>> >>> --- a/gas/config/tc-i386.c >>> +++ b/gas/config/tc-i386.c >>> @@ -5409,7 +5409,7 @@ ginsn_dw2_regnum (const reg_entry *ireg) >>> if (ireg->reg_num == RegIP || ireg->reg_num == RegIZ) >>> return GINSN_DW2_REGNUM_RSI_DUMMY; >>> >>> - dwarf_reg = ireg->dw2_regnum[flag_code >> 1]; >>> + dwarf_reg = ireg->dw2_regnum[object_64bit]; >>> >>> if (dwarf_reg == Dw2Inval) >>> { >>> @@ -17461,7 +17461,7 @@ tc_x86_parse_to_dw2regnum (expressionS * >>> if ((addressT) exp->X_add_number < i386_regtab_size) >>> { >>> exp->X_add_number = i386_regtab[exp->X_add_number] >>> - .dw2_regnum[flag_code >> 1]; >>> + .dw2_regnum[object_64bit]; >>> if (exp->X_add_number != Dw2Inval) >>> exp->X_op = O_constant; >>> } >> >> On one hand, I see that the suggested code changes are making things >> semantically clearer, I would like to understand: >> >> 1. If there is a scenario where flag_code is CODE16_BIT / CODE32_BIT and >> object_64bit equal to 1 is supported. gcc passes --32 when using -m16 >> or -m32. > > Well, gcc may never produce such input, but hand-written assembly can. > Then, should we also use sp[object_64bit] instead of sp[flag_code >> 1] in tc_x86_frame_initial_instructions? Otherwise the assert "gas_assert (exp.X_op == O_constant)" will trigger, e.g. with .code16 and --64. >> 2. Irrespective of #1, shouldn't we then also use "if (object_64bit == >> 1)" instead of "if (flag_code == CODE_64BIT)" in md_begin where we set >> the value of x86_dwarf2_return_column etc ? > > Good point, let me make a v2. > > Jan
On 21.02.2024 00:04, Indu Bhagat wrote: > On 2/15/24 23:26, Jan Beulich wrote: >> On 15.02.2024 23:22, Indu Bhagat wrote: >>> On 2/9/24 00:11, Jan Beulich wrote: >>>> Consumers can't know which execution mode is in effect for a certain >>>> piece of code; they can only go from object file properties. Hence which >>>> register numbers to encode ought to depend solely on object file type. >>>> >>>> --- a/gas/config/tc-i386.c >>>> +++ b/gas/config/tc-i386.c >>>> @@ -5409,7 +5409,7 @@ ginsn_dw2_regnum (const reg_entry *ireg) >>>> if (ireg->reg_num == RegIP || ireg->reg_num == RegIZ) >>>> return GINSN_DW2_REGNUM_RSI_DUMMY; >>>> >>>> - dwarf_reg = ireg->dw2_regnum[flag_code >> 1]; >>>> + dwarf_reg = ireg->dw2_regnum[object_64bit]; >>>> >>>> if (dwarf_reg == Dw2Inval) >>>> { >>>> @@ -17461,7 +17461,7 @@ tc_x86_parse_to_dw2regnum (expressionS * >>>> if ((addressT) exp->X_add_number < i386_regtab_size) >>>> { >>>> exp->X_add_number = i386_regtab[exp->X_add_number] >>>> - .dw2_regnum[flag_code >> 1]; >>>> + .dw2_regnum[object_64bit]; >>>> if (exp->X_add_number != Dw2Inval) >>>> exp->X_op = O_constant; >>>> } >>> >>> On one hand, I see that the suggested code changes are making things >>> semantically clearer, I would like to understand: >>> >>> 1. If there is a scenario where flag_code is CODE16_BIT / CODE32_BIT and >>> object_64bit equal to 1 is supported. gcc passes --32 when using -m16 >>> or -m32. >> >> Well, gcc may never produce such input, but hand-written assembly can. > > Then, should we also use sp[object_64bit] instead of sp[flag_code >> 1] > in tc_x86_frame_initial_instructions? Otherwise the assert "gas_assert > (exp.X_op == O_constant)" will trigger, e.g. with .code16 and --64. Indeed. Need to make a v3 then, and probably go hunt for any other "flag_code >> 1". It's really odd how "well" those uses are scattered across, with no mention of the need to stay in sync (which wouldn't have been much of a problem if it had been got right from the beginning). Of course I question the invocation of parsing a register name there; the two numbers that can result are well known. Parsing would perhaps be warranted if, say, for COFF different numbers would result (and hence determining them at build time wouldn't be as easy). So I may end up simplifying this beyond just switching to use of object_64bit. Jan
--- a/gas/config/tc-i386.c +++ b/gas/config/tc-i386.c @@ -5409,7 +5409,7 @@ ginsn_dw2_regnum (const reg_entry *ireg) if (ireg->reg_num == RegIP || ireg->reg_num == RegIZ) return GINSN_DW2_REGNUM_RSI_DUMMY; - dwarf_reg = ireg->dw2_regnum[flag_code >> 1]; + dwarf_reg = ireg->dw2_regnum[object_64bit]; if (dwarf_reg == Dw2Inval) { @@ -17461,7 +17461,7 @@ tc_x86_parse_to_dw2regnum (expressionS * if ((addressT) exp->X_add_number < i386_regtab_size) { exp->X_add_number = i386_regtab[exp->X_add_number] - .dw2_regnum[flag_code >> 1]; + .dw2_regnum[object_64bit]; if (exp->X_add_number != Dw2Inval) exp->X_op = O_constant; }