From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-x533.google.com (mail-pg1-x533.google.com [IPv6:2607:f8b0:4864:20::533]) by sourceware.org (Postfix) with ESMTPS id 9C3DA3858D1E for ; Fri, 30 Sep 2022 21:40:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 9C3DA3858D1E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=dabbelt.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=dabbelt.com Received: by mail-pg1-x533.google.com with SMTP id f193so5231583pgc.0 for ; Fri, 30 Sep 2022 14:40:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dabbelt-com.20210112.gappssmtp.com; s=20210112; h=content-transfer-encoding:mime-version:message-id:to:from :in-reply-to:subject:date:from:to:cc:subject:date; bh=UQv8HNVDCbbVxKq9wETyvusT1X1DonUlMbONpOWkoBw=; b=2UGQmzpwkR2wfTUPZApf5cwTvb8QwJNEd6OcZMzZdJW+7wkqXkF3YvGMcF6rXhjpuE y2tE639YlnJ1A2MWNRhPcq/EDnt8Eu9yujvbv/4aVtTejqMk82AcS5lijrD8khDvu5u5 FSZttHs3mwNC4PUeBnNFsvxt1nnG7YTO8Z8yJSotwgsQJzIauLiDA/lsPDcHEIDjknXM PhxcvGd+xvhRF/x63kH5TTdP8qRdPv/BCla5Ac+87zz5WYZnADHN679yaTu17uRARKbv ZDpjG0XrnsEYAvlE/gX5E7rrWMwACzsBtm3N4q4d5gKSt2tG9cN8EzvWCaUfjRZir+CN p6vg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:message-id:to:from :in-reply-to:subject:date:x-gm-message-state:from:to:cc:subject:date; bh=UQv8HNVDCbbVxKq9wETyvusT1X1DonUlMbONpOWkoBw=; b=fTM8jeKsZo/LQIUKI8G5i0j6DZ6hbQ74zisjBQImWW2E9ovYxqWjwwNfviAQxgLvLd 1kJrQPXMSTWOhPYwbWF43OFfHWay83PwrR2TsXl6CII4ogHjevqUkQm/1z6v8PM/Z/SF 3JPDWCuLcqwcgwRiHxSFChuffuPyQE6nCZ4nOsSUqdHDvlOmKIDhVwKE49dtdm0mSNBe cAI/Jh7pgYi+L+65BkGq8NQt+tjP8hn1+Fyku3Gh7O8hQ7RgpYqyGdPI2oRoA2yp1juM /eLVGmgiYrJHiIOGFanxVDGGoBBsjuiQYvgtAyQTnjfBfB6Ao8HIgbanowACnZsDrv76 lf7A== X-Gm-Message-State: ACrzQf2+go2vsTjUT1a7FRnezGUDf33f9xFoRw9QLF7hoVVHaNoCZ0KB YTzUhzJCjqt3eYS1z+KVgNDaE4pzx7phBSmZ X-Google-Smtp-Source: AMsMyM7/J4unCRXn2NYCkhgkeIu3d4JEM9SZMR196b8Y37NBsmksuKjPqRHLqOmvJ7U2pR8Y6CZIYA== X-Received: by 2002:a63:5811:0:b0:43c:9d3d:700a with SMTP id m17-20020a635811000000b0043c9d3d700amr9457016pgb.419.1664574043977; Fri, 30 Sep 2022 14:40:43 -0700 (PDT) Received: from localhost (76-210-143-223.lightspeed.sntcca.sbcglobal.net. [76.210.143.223]) by smtp.gmail.com with ESMTPSA id w2-20020a170902e88200b0017829a3df46sm2389711plg.204.2022.09.30.14.40.42 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 30 Sep 2022 14:40:42 -0700 (PDT) Date: Fri, 30 Sep 2022 14:40:42 -0700 (PDT) X-Google-Original-Date: Fri, 30 Sep 2022 14:40:39 PDT (-0700) Subject: Re: Risc - V failures inside ld-undefined In-Reply-To: From: Palmer Dabbelt To: binutils@sourceware.org Message-ID: Mime-Version: 1.0 (MHng) Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-5.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Fri, 30 Sep 2022 05:29:36 PDT (-0700), binutils@sourceware.org wrote: > Hi all, > > I've been running the ld testsuite for Risc-V targets using a cross > compiler and I'm seeing some failures in "undefined". > PASS: undefined > FAIL: undefined function > FAIL: undefined line > > As I'm using a custom gcc, I just want confirmation from the Risc-V > maintainers that these two tests are either failing or being skipped > on their side. They're not failing for me in a local run, unless I'm somehow misunderstanding the test results. My "make check-ld" shows === ld Summary === # of expected passes 797 # of expected failures 8 # of untested testcases 26 # of unsupported tests 175 ./ld-new 2.39.50.20220930 > I've a patch fixing the testsuite for cross-compiler which might > explain why it has always been skipped until now and why this error > has been masked. OK, probably best to send the patch, then? There's certainly been cases before where we've missed failures because they're being skipped due to environment issues, if it's possible to get the test running for more people then it'll be more likely to get fixed -- at least with it showing up in the tests as an unexpected failure it'll be harder to forget about. > Note that I've investigated a bit and it seems to be related to > R_RISCV_ALIGN and the associated linker relaxation. > Instead of showing > | ld: tmpdir/undefined.o: in function `function': > | .../undefined.c:9: undefined reference to `this_function_is_not_defined' > the error is: > | riscv64-elf-ld: tmpdir/undefined.o: in function `.Ltext0': > | undefined.c:(.text+0x0): undefined reference to > `this_function_is_not_defined' > > The idea is that "function" has an alignment of 2 and thus gas will > add NOP instructions and a R_RISCV_ALIGN relocation before it (within > tc-riscv.c:riscv_frag_align_code). > | $ riscv64-elf-objdump -D tmpdir/undefined.o > | 0000000000000000 <.Ltext0>: > | 0: 0001 nop > | > | 0000000000000002 : > | 2: 00000317 auipc t1,0x0 > | 6: 00030067 jr t1 # 2 > > When the linker will relax these NOPs (in > elfnn-riscv.c:riscv_relax_delete_bytes), it will correctly change the > relocation offset but not the DWARF information. Thus, when the error > is trying to get the nearest line using _bfd_dwarf2_find_nearest_line, > it ends up using a modified offset with non-modified DWARF information > and targets the wrong symbol. > I guess riscv_relax_delete_bytes can be improved to adjust the DWARF > part too. But I'm not familiar with this part of bfd and I'm not sure > it's even possible. > Otherwise, I guess XFAIL these tests should be fine as they are > similar to other XFAILs related to DWARF-2 (on arm-elf). Even if not > having a "function" being shown in the error might be problematic. That seems like a plausible issue, and it's certainly not surprising that there's a bug in debug info handling related to relaxation -- both because we've had those before, and because it's the combination of some complex and hard to test topics. Probably best to just start with getting this running for everyone so we can chew on it a bit, if it is a XFAIL then we should at least have some sort of error here rather than just producing bad binaries. > Anyway, the fact that I'm using a custom gcc shouldn't matter here but > I want to confirm that first. That also seems reasonable, but there's quite a bit of coupling between the compiler, assembler, and linker when it comes to DWARF on RISC-V as we don't support all the flavors of DWARF-relate directives. We should have errors for all those, but it's entirely possible something has been missed. That's even more likely if your custom compiler that's doing something different than we normally test against, but IMO that's still a bug that we should fix (at least with an error message). > > Thanks, > Clément