From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mta-201a.earthlink-vadesecure.net (mta-201a.earthlink-vadesecure.net [51.81.229.180]) by sourceware.org (Postfix) with ESMTPS id C98AD38618D7 for ; Thu, 2 Jun 2022 03:39:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C98AD38618D7 Received: from Black ([173.73.24.216]) by smtp.earthlink-vadesecure.net ESMTP vsel2nmtao01p with ngmta id 92021576-16f4b09e7ed72bbf; Thu, 02 Jun 2022 03:39:18 +0000 From: "Vsevolod Alekseyev" To: Subject: Readelf bug? Date: Wed, 1 Jun 2022 23:39:16 -0400 Message-ID: <000501d87632$56c038b0$0440aa10$@sprynet.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: Adh2MeelOx2KKRyzTwCVSwwxGYEwEw== Content-Language: ru X-Spam-Status: No, score=1.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, HTML_MESSAGE, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2022 03:39:22 -0000 I'm debugging a DWARF parser library. We are testing it against GNU readelf, and we've found a discrepancy on the dump of the interpreted .eh_frame section of a particular x86_64 ELF binary. The binary's first FDE in .eh_frame has initial_location 0x1060, and the following instructions: DW_CFA_advance_loc 4 # Move PC by 4 DW_CFA_undefined 16 # Change the rule for R16 to undefined The linked CIE marks R16 as the return address, and has the following instructions: DW_CFA_def_cfa 7, 8 # CFA is at R7+8 DW_CFA_offset 16, 1 # Set the rule for R16 to [CFA+1*data_aligment_factor]) The GNU readelf, if executed with --debug-dump=frames-interp, dumps the FDE as follows: 00000018 0000000000000014 0000001c FDE cie=00000000 pc=0000000000001060..0000000000001086 LOC CFA ra 0000000000001060 rsp+8 u 0000000000001064 rsp+8 u Meanwhile, the alternative parser thinks that at the range [0x1060-0x1064), the rule for RA/R16 should be as inherited from the CIE, and it goes c-8. I've debugged readelf (the latest master, as of 06/01/22), to that point. There are two passes over the FDE instructions: one starting on dwarf.c:9296, the other starting at dwarf.c:9442. On the first pass, when DW_CFA_undefined is encountered, there is the following case statement: READ_ULEB (reg, start, block_end); if (frame_need_space (fc, reg) >= 0) fc->col_type[reg] = DW_CFA_undefined; break; If I understand correctly, the intended purpose of the first pass is to allocate enough memory in the fc->col_type and fc->col_offset arrays, and the logic of this operator's handling was meant to be: if this register was not mentioned before, allocate space for it, and reset its rule to undefined. HOWEVER, if the register WAS mentioned before (e. g. in the CIE), frame_need_space() returns 0, and the if() body executes anyway, and resets the rule for the register to undefined, erasing the initial state as specified by the CIE. I think the if statement should go, instead, "if (frame_need_space (fc, reg) > 0)". Same for other register-rule-type operators on the first pass. The binary can be seen at https://github.com/eliben/pyelftools/issues/409#issuecomment-1136720254 I'd submit a Bugzilla ticket, but registration is closed. Thank you!