From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) by sourceware.org (Postfix) with ESMTPS id EEFF6394883C for ; Mon, 9 May 2022 14:04:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org EEFF6394883C Received: by mail-lj1-x22c.google.com with SMTP id bx33so6298876ljb.12 for ; Mon, 09 May 2022 07:04:11 -0700 (PDT) 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:cc; bh=2MQXFah84baVmdjnAbmKGusuvqWAyIjcNColJjMi/aA=; b=WMORx3WtV+XxtAW/CZy+h1YyBZ4Sf/SE29sNeI63bz3T/poPOUyiRy+qpR1u75fFt6 x2aOjxRnWnJn0jL25GQM10jYtsOeaBa3jEchmOkaTxIL1Mrw98Us/YJo1ga5RarZibvU gTeCwjAv3vGlx8s5m2XzK77hEj0zmK5tjpjc5DXIAzB39ovTmQSS2PWi9MilManlPG01 tQwhyPj0vsFile+KrKL+RAH9l0LLK+TbfUME1G+Gmcgph5UWwJvpV9AJvm2rm8VJ5Qqd /knayKAiR9Xypg/QpRbgdMxPR3D7/LKlE/pUWzNih74PY42Cl/OsC7gwECcmwBreQcfb KeuA== X-Gm-Message-State: AOAM5313ZEqKTSjIVujxOtTyEq056lvZm4eKvhHqCDM75inLpk9E5Kf3 hWRbu3GQGzk8OOhtDel5Qb5+B76lNWyZBm/aa39twzI/iIM= X-Google-Smtp-Source: ABdhPJyzfFqnS5crVcNExJ/eGmRs888H6VdN2uW8Sf7nCms8ZqjdSCnuEj0lrGVaQ9gS/slCw1H5IMfwwEArb1ezDO8= X-Received: by 2002:a2e:bf1a:0:b0:249:3a3b:e90e with SMTP id c26-20020a2ebf1a000000b002493a3be90emr10895895ljr.317.1652105050104; Mon, 09 May 2022 07:04:10 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Yichao Yu Date: Mon, 9 May 2022 10:03:58 -0400 Message-ID: Subject: Re: Suspected bug in DW_OP_addr handling To: Simon Marchi Cc: gdb@sourceware.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2022 14:04:15 -0000 > My understanding is: Thanks for the detailed explanation! > > - normally, a value given by DW_OP_addr is an address that should be > relocated with the base address of the objfile OK, this is my confusion I guess. I guess I wasn't sure what "address" refers to in the dwarf spec. I now see that dwarf spec has a section dedicated to relocation (7.3) and it mentions that dw_op_addr should be relocated. I was previously confused by the "constant address" in table 7.9 in 7.7.1 and assumed that it is the full address. The following then all makes sense. > - the DW_OP_GNU_push_tls_address operation (now called > DW_OP_form_tls_address in DWARF 5) expects some kind of value on top > of the stack, identifying the TLS variable to fetch. It's > implementation-defined what this value means, but in practice it > means it's some value that should not be relocated. > - a contemporary version of GCC produces something like this for a TLS > variable's DW_AT_location: > > DW_OP_const8u 0x4, DW_OP_form_tls_address > > - A version of gcc in the past must have used this instead: > > DW_OP_addr 0x4, DW_OP_form_tls_address > > The usage of DW_OP_addr was wrong, and it made so GDB had to avoid > relocating the DW_OP_addr value in this particular case. So it is > checking, if we have DW_OP_addr followed by DW_OP_form_tls_address, then > we don't relocate, because we are in this buggy situation. > > And so the condition: > > if (op_ptr >= op_end || *op_ptr != DW_OP_GNU_push_tls_address) > result += this->m_per_objfile->objfile->text_section_offset (); > > looks right to me. It says, only relocate if: > > - DW_OP_addr is the last operation of the sequence > - the following op is not DW_OP_form_tls_address / DW_OP_GNU_push_tls_address > > Simon