public inbox for gdb-cvs@sourceware.org help / color / mirror / Atom feed
From: Simon Marchi <simark@sourceware.org> To: gdb-cvs@sourceware.org Subject: [binutils-gdb] gdb: initialize ctf_context::builder in create_partial_symtab Date: Thu, 31 Mar 2022 21:18:31 +0000 (GMT) [thread overview] Message-ID: <20220331211831.F226E3857034@sourceware.org> (raw) https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=59f837cb11e3b96c581fe23b79f6995b7c8177ee commit 59f837cb11e3b96c581fe23b79f6995b7c8177ee Author: Simon Marchi <simon.marchi@polymtl.ca> Date: Thu Mar 31 14:20:02 2022 -0400 gdb: initialize ctf_context::builder in create_partial_symtab I built a random project with -gctf, in order to test the CTF support in GDB. With my ASan/UBSan/etc-enabled build of GDB, I get: $ ./gdb --data-directory=data-directory /tmp/babeltrace-ctf/src/lib/.libs/libbabeltrace2.so.0.0.0 ... Reading symbols from /tmp/babeltrace-ctf/src/lib/.libs/libbabeltrace2.so.0.0.0... /home/simark/src/binutils-gdb/gdb/ctfread.c:1545:31: runtime error: member call on misaligned address 0xbebebebebebebebe for type 'struct buildsym_compunit', which requires 8 byte alignment 0xbebebebebebebebe: note: pointer points here The 0xbebebebebebebebe value is a sign that the ctf_context::builder field is uninitialized. The problem probably goes under the radar if the field happens to be zero-initialized, because ctf_start_archive contains this code: if (ccx->builder == nullptr) { ccx->builder = new buildsym_compunit (of, of->original_name, nullptr, language_c, 0); If the field was zero-initialized (by chance), this will create a new buildsym_compunit. But if the field was purposely filled with random bytes by one of the sanitizers, we won't create a buildsym_compunit here and we'll continue with ccx->builder equal to 0xbebebebebebebebe. Fix this the easy way by initializing ccx->builder where the other ctf_context fields are initialized (yeah, this code could be made nicer C++, but I am going for the obvious fix here). With this patch, this passes cleanly on my system: $ make check TESTS="gdb.ctf/*.exp" RUNTESTFLAGS="CC_FOR_TARGET=/opt/gcc/git/bin/gcc" # of expected passes 40 ... where /opt/gcc/git/bin/gcc is a gcc with CTF support, given my system gcc does not have it. Change-Id: Idea1b0cf3e3708b72ecb16b1b60222439160f9b9 Diff: --- gdb/ctfread.c | 1 + 1 file changed, 1 insertion(+) diff --git a/gdb/ctfread.c b/gdb/ctfread.c index 585c664cce2..8da38cc70af 100644 --- a/gdb/ctfread.c +++ b/gdb/ctfread.c @@ -1449,6 +1449,7 @@ create_partial_symtab (const char *name, pst->context.of = objfile; pst->context.partial_symtabs = partial_symtabs; pst->context.pst = pst; + pst->context.builder = nullptr; return pst; }
reply other threads:[~2022-03-31 21:18 UTC|newest] Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20220331211831.F226E3857034@sourceware.org \ --to=simark@sourceware.org \ --cc=gdb-cvs@sourceware.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: linkBe 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).