From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 7JtJI7Q/UmoxAQMAWB0awg (envelope-from ) for ; Sat, 11 Jul 2026 09:05:56 -0400 Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=Ss43rlnA; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 81E781E070; Sat, 11 Jul 2026 09:05:56 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-5.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED autolearn=ham autolearn_force=no version=4.0.1 Received: from vm01.sourceware.org (vm01.sourceware.org [IPv6:2620:52:6:3111::32]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id CE72C1E070 for ; Sat, 11 Jul 2026 09:05:55 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id DD4134BA2E22 for ; Sat, 11 Jul 2026 13:05:53 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org DD4134BA2E22 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1783775153; bh=8Zz7qKG+EbsnuTJQVYyGxH74D2DChhChk+xyKyo0fU0=; h=To:Subject:In-Reply-To:References:Date:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=Ss43rlnA/hE7o8W9OXaAcsqCwrrZFj/n6EqICdRMUJGt3h027iCzZbFRVg/KxckEn niAn2bJSmGGlUBverIDqMGOwQQnQi7K7xFCwHNM2BW9WTNkhTyULzdt8ojYg8W2frL Q82XvpxZln9Oe9Ih5MnbBmuy+b0ceZhMI46imuYE= Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTP id A08AD4BA2E20 for ; Sat, 11 Jul 2026 13:05:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A08AD4BA2E20 ARC-Filter: OpenARC Filter v1.0.0 sourceware.org A08AD4BA2E20 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1783775117; cv=none; b=Z2UZN6qnu2q8fg8zHkYsYQx+WjPJVmIMRwyAW0weQs48cjrBWYFrfuBwKgOfaRfM3jYa30KpYO2EhfW8W8o3bC4QwsaMt68tjDkQZkWYAVhNoiILovjrfz7OTv+LTkzvmNJbsM2HtBEFagl5J5DIZ0VO4z2HRqjGtgoFOEeKJ9w= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1783775117; c=relaxed/simple; bh=5D6wPmG2ix+NmpPP6vV7NQxbXIxS2+Jy596nYgYpqp8=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=dBvSbt5GUBkhQSc9Y8sjvtKFryKCQEMzrl9be4u78LOGTHXLKqU29DqxC8j2fCLHj3m03U/PBm3VhzS0NxfoZraPh6u3pzAg5j0KLK9Htm+ZDgQOTfYemfRgJumKiiGXKoAjApkCoWH7nn3dtrApKEBfEK6PowN6JebxEeWjxNM= ARC-Authentication-Results: i=1; sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=RY3PLZM2 DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A08AD4BA2E20 Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-694-OtPOp46EPmC1BWqHZ9EtAA-1; Sat, 11 Jul 2026 09:05:15 -0400 X-MC-Unique: OtPOp46EPmC1BWqHZ9EtAA-1 X-Mimecast-MFC-AGG-ID: OtPOp46EPmC1BWqHZ9EtAA_1783775115 Received: by mail-wm1-f69.google.com with SMTP id 5b1f17b1804b1-4926fa2cb17so16136605e9.1 for ; Sat, 11 Jul 2026 06:05:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783775115; x=1784379915; h=content-type:mime-version:message-id:date:references:in-reply-to :subject:to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=8Zz7qKG+EbsnuTJQVYyGxH74D2DChhChk+xyKyo0fU0=; b=n9obmE9OL0LwxzCbfL4w9I5M8Zw8tdiuKvVI1OlXoOqPXeCzV5LXRhjecBvq/i6k2s l5r+DX4Qi4+bQjjERFV5cf9/2BaCL6Wkk5FYaZ4BiUOLKJERAJOTQpKCF5jSsR2PWHbp 1PG0RVIJVKZlrQPYzGnG0OK1BM9+pnZnnDIsDLRNER536afrkx+FAx9K886Q6z6kfKto PfRp78lahAe9BSSYgTFP0Z1OYX3bb8f5E7W2kLIvsCa9HesT9kylMr5fy2flJephHUAo NdHW0Ioyf93fczO2MCBHCjtQbIm2/Po/SJYZw7D/LcnhAE7kPKoosEgPCUzpPX8MOzNr AEYA== X-Forwarded-Encrypted: i=1; AHgh+Rqs+jzTWD8PkZg8UGBhHwMNl/gQX0JNUVQskwTsjtWC+fpt9MDeZenZyRNYvkRT9Emj1Fs=@sourceware.org X-Gm-Message-State: AOJu0YxPsXCt3MNUmJLT9uXpFX+eV7YGrJkfJWr3q0zLhbATYTA6etM0 xjeuxmUxy6/+acQ84W06SZJboJboaHj5sLAPiMEm2l+QE/WcLzQYUEePfKUzpaRO2GXFc5SBlLB A1gj/K0FkCrM94/yuR7rG/Li+BlXgj2ma083YXOjAZ4dhsn6pEnxy+niVFgsI X-Gm-Gg: AfdE7cla4nr/y8I7DHugOWa4hu0T08gcVWMSSmuOl7VFbfEDZ2HZjsMc7RsSiROMbBK 6hdvB/bohlYZCxslE/P7HRMn3u/ULrrOItrTqkAUL4Qq+gODMBzmbDT2tbk97LeRhtjdLWXBkT7 8fgR/QkOeQrRJs2EV+rGw2b3VmxFxDjCXMG3QPgx1Ob77rj7eWYWVd7GAVzEWmWYUXPOHgSS0LR LAfpZ1zAgXpIGm1N78w8txxbCeI7F+mZ0GqfXknhf4tWIuO5/fWl0DAvL0Y8m3yRUVo/zKigv1i gf7X5g3kBC/NJH+DvaAsI1bkRMiCQeJOtuBGgHK0k7u4YSRfCrqrRM7kg5Qf5LRXbwywoY/SKVH ZSNaTD9Q= X-Received: by 2002:a05:600c:c8f:b0:493:ee34:d875 with SMTP id 5b1f17b1804b1-493f88bd7famr23701005e9.10.1783775114622; Sat, 11 Jul 2026 06:05:14 -0700 (PDT) X-Received: by 2002:a05:600c:c8f:b0:493:ee34:d875 with SMTP id 5b1f17b1804b1-493f88bd7famr23700645e9.10.1783775113975; Sat, 11 Jul 2026 06:05:13 -0700 (PDT) Received: from localhost ([109.144.18.126]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-493eb6d5055sm213322015e9.5.2026.07.11.06.05.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 11 Jul 2026 06:05:13 -0700 (PDT) To: Zhao Yiming , gdb@sourceware.org Subject: Re: Fwd: RISC-V bare-metal: GDB loses source line info when .text starts at 0x0 In-Reply-To: <87wlv8tacj.fsf@redhat.com> References: <87wlv8tacj.fsf@redhat.com> Date: Sat, 11 Jul 2026 14:05:12 +0100 Message-ID: <87zezxekxj.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: 8lcPV8vvoBwBNhPhJL9jh9_xbILVJaDb6x3jmYjmrNg_1783775115 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Andrew Burgess via Gdb Reply-To: Andrew Burgess Errors-To: gdb-bounces~public-inbox=simark.ca@sourceware.org Sender: "Gdb" Andrew Burgess writes: > Zhao Yiming via Gdb writes: > >> Hi GDB maintainers, >> >> I am seeing a possible GDB source-line lookup issue while remote-debugging a >> bare-metal RISC-V ELF. >> >> Environment: >> - GDB: 15.2.90.20241210-git, Xuantie-900 elf newlib gcc Toolchain V3.2.0 >> B-20250627 >> - GCC: 14.1.1 20240710, same Xuantie toolchain >> - ld: GNU ld 2.42.50 >> - QEMU: qemu-system-riscv64 8.2.94 (cskysim V5.2.8 B-20250721) >> - Host: Windows 10.0.19045.6466 >> >> Build flags: >> >> -O0 -g -ffunction-sections -fdata-sections -Wl,--gc-sections >> >> The failing ELF is linked as a bare-metal image with .text VMA = 0x0. >> >> Reproducer outline: >> >> target remote :1234 >> load >> b main >> c >> s >> s >> n >> n >> n >> n >> >> After stepping out of SPI_ModifyGlobalReg(), GDB prints only: >> >> 0x00000000000002dc in I2C_PinMuxSetup () >> >> Expected: >> >> I2C_PinMuxSetup (...) at ../src/demoI2c.c:36 >> >> The line information appears to exist: >> >> addr2line -e LRV4201_SPI_I2C_2.elf 0x2dc >> -> ../src/demoI2c.c:36 >> >> Relevant symbols: >> >> 0000000000000000 T Reset_Handler >> 00000000000002ca T I2C_PinMuxSetup >> 0000000000000920 T SPI_ModifyGlobalReg >> >> Additional observations: >> >> 1. If the linker script changes .text from 0x0 to a non-zero address, the >> GDB problem disappears. >> 2. If .text still starts at 0x0 but Reset_Handler is placed in .text instead >> of .text.init, the problem also disappears. >> 3. The failing ELF contains many zero-address decoded line-table rows from >> demoI2c.c/demoSpi.c. A no-gc build and a reduced working project do not. >> >> I attached a small archive with decoded line tables, objdump section >> headers, >> addr2line output, build flags, linker script, and relevant sources. The full >> ELFs are not attached because of the mailing list size limit, but I can >> provide >> them or file a Bugzilla issue if preferred. >> > > If you could file a bugzilla, include this description, and attach > everything including the ELFs, that would make things easier. If you > post the link I'll try to take a look when I have time. > > I'm not surprised that there are issues here, some of the older GDB code > still makes use of 0 as a "magic" flag indicating no-data, etc. I've > worked on targets that allow code to be placed at address 0, and fixed > some of these issues in the past, so it would be nice to fix this one > too. I took a look into this and opened this bug: https://sourceware.org/bugzilla/show_bug.cgi?id=34389 The problem originates from the linker's function garbage collection (IMHO). Garbage collection deletes the function sections, but doesn't (unfortunately) try to patch up any of the DWARF. As a result things like `.debug_rnglists` which point at a deleted function are left with a start address of 0, the range of the deleted function is effectively moved to start at address zero. The `.debug_rnglists` is then used by GDB when building the address map for its compunit_symtab objects (effectively a DWARF compilation unit). These compunit_symtab are expanded lazily depending on the order in which you make use of them, so if you first visit a compunit_symtab which contains a garbage collected function then this compunit_symtab will always be the first that GDB checks when looking for an address. The garbage collected function, with its range starting at 0, in effect "claims" that range of addresses. There are some heuristics in GDB to try and spot garbage collection and try to fix up some of the confusing incoming data, but it's not perfect, and clearly in this case, it isn't sufficient. I don't have a plan for fixing this in GDB right now. Thanks, Andrew