From: Pedro Alves <pedro@palves.net>
To: Thiago Jung Bauermann <thiago.bauermann@linaro.org>,
Bernd Edlinger <bernd.edlinger@hotmail.de>
Cc: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Subject: Re: [PATCH v3 1/2] gdb/testsuite: Add libc_has_debug_info require helper
Date: Fri, 26 Apr 2024 17:35:43 +0100 [thread overview]
Message-ID: <b0409c48-7f9c-4430-91d9-dc7cfa86a9c7@palves.net> (raw)
In-Reply-To: <87il0425gu.fsf@linaro.org>
On 2024-04-26 04:00, Thiago Jung Bauermann wrote:
>
> Hello Bernd,
>
> Bernd Edlinger <bernd.edlinger@hotmail.de> writes:
>
>> Hi Thiago,
>>
>> On 4/24/24 18:25, Thiago Jung Bauermann wrote:
>>>>
>>> Thank you! Pushed as commit f5ef12c3f1af.
>>
>> I think I have an issue with this commmit.
>> I use a self-built riscv-unknown-elf toolchain with newlib,
>> so there is no libc at all, regardless of debug info.
>> since today, I see messages like:
>> Running /home/ed/gnu/binutils-build-riscv64/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/relativedebug.exp ...
>> FAIL: gdb.base/relativedebug.exp: info sharedlibrary libc.so
>> ERROR: tcl error sourcing /home/ed/gnu/binutils-build-riscv64/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/relativedebug.exp.
>> ERROR: tcl error code TCL READ VARNAME
>> ERROR: can't read "libc_has_debug_info": no such variable
>> while executing
>> "verbose "$me: returning $libc_has_debug_info" 2"
>> (procedure "gdb_real__libc_has_debug_info" line 47)
>> invoked from within
>> "gdb_real__libc_has_debug_info"
>
> <snip>
>
> Sorry for the trouble. I should have simulated a situation where GDB
> can't find libc.so in the inferior. I was able to reproduce the error
> above when I did.
>
> Could you please test the patch that I just sent?
>
>> while previously that looked like:
>>
>> gdb compile failed, /home/ed/gnu/riscv64-unknown-elf/lib/gcc/riscv64-unknown-elf/14.0.1/../../../../riscv64-unknown-elf/bin/ld: /tmp/ccjr19GC.o: in function `main':
>> /home/ed/gnu/binutils-build-riscv64/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/relativedebug.c:30:(.text+0x28): undefined reference to `alarm'
>> /home/ed/gnu/riscv64-unknown-elf/lib/gcc/riscv64-unknown-elf/14.0.1/../../../../riscv64-unknown-elf/bin/ld:
>> /home/ed/gnu/binutils-build-riscv64/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/relativedebug.c:31:(.text+0x30):
>> undefined reference to `pause'
>> /home/ed/gnu/riscv64-unknown-elf/lib/gcc/riscv64-unknown-elf/14.0.1/../../../../riscv64-unknown-elf/bin/ld:
>> /home/ed/gnu/binutils-build-riscv64/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/relativedebug.c:31:(.text+0x38):
>> undefined reference to `pause'
>> collect2: error: ld returned 1 exit status
>> UNTESTED: gdb.base/relativedebug.exp: failed to compile
>>
>> so not very noisy, newlib does apparently not have alarm, pause, sleep, and similar,
>> but much easier to understand the output...
>
> On the plus side, with this problem fixed gdb.base/relativedebug.exp
> should exit early with:
>
> (gdb) info sharedlibrary libc.so
> No shared libraries matched.
> (gdb) UNSUPPORTED: gdb.base/relativedebug.exp: require failed: libc_has_debug_info (libc not found in the inferior)
>
> Which will be even easier to understand the output. :-)
>
I don't think that's a good outcome, actually. It'll disable the testcase on systems that link
with their libc statically (even if has debug info), or systems that name their libc something else.
And I worry that the require predicate will start being used more with that particularity.
The original check only returned early if a library called "*libc*" was found, and, it didn't
have debug info. If those conditions didn't match, the testcase proceeded. That seems a
lot safer. As in, only if we know for sure we have a libc without debug info, do we return early.
next prev parent reply other threads:[~2024-04-26 16:35 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-22 23:06 [PATCH v3 0/2] Add testcase for libc memory operations Thiago Jung Bauermann
2024-04-22 23:06 ` [PATCH v3 1/2] gdb/testsuite: Add libc_has_debug_info require helper Thiago Jung Bauermann
2024-04-23 17:09 ` Kevin Buettner
2024-04-24 16:25 ` Thiago Jung Bauermann
2024-04-25 19:39 ` Bernd Edlinger
2024-04-26 3:00 ` Thiago Jung Bauermann
2024-04-26 5:06 ` Bernd Edlinger
2024-04-26 16:35 ` Pedro Alves [this message]
2024-04-26 17:18 ` Thiago Jung Bauermann
2024-04-30 1:57 ` Thiago Jung Bauermann
2024-04-22 23:07 ` [PATCH v3 2/2] gdb/testsuite: Add gdb.base/memops-watchpoint.exp Thiago Jung Bauermann
2024-04-23 17:52 ` Kevin Buettner
2024-04-24 17:05 ` Thiago Jung Bauermann
2024-04-24 23:22 ` Kevin Buettner
2024-04-26 1:42 ` Thiago Jung Bauermann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b0409c48-7f9c-4430-91d9-dc7cfa86a9c7@palves.net \
--to=pedro@palves.net \
--cc=bernd.edlinger@hotmail.de \
--cc=gdb-patches@sourceware.org \
--cc=thiago.bauermann@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).