public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "mark at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug target/113045] armv7l-unknown-linux-gnueabihf: valgrind error during build of libcc1 Date: Tue, 19 Dec 2023 17:18:07 +0000 [thread overview] Message-ID: <bug-113045-4-qtuasnoQjF@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-113045-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113045 --- Comment #19 from Mark Wielaard <mark at gcc dot gnu.org> --- (In reply to David Binderman from comment #18) > (In reply to Mark Wielaard from comment #17) > > I am surprised valgrind memcheck doesn't produce more output, normally it > > would tell you why & where it found the address invalid. > > The valgrind output I gave originally looks to be in the usual valgrind > format to me. > Perhaps you are assuming some other debugging tool like asan or ubsan ? Normally valgrind adds something like: Address 0xaaaaaa is x bytes inside a block of size y free'd please a stacktrace where that block was allocated/freed In this case I would expect to say something like that the address that is being access is after a block. Assuming it is indeed not accessible. The read of 4 bytes is interesting, it seems to mean that valgrind decided to chop up this read into smaller blocks. > > I assume somehow > > valgrind memcheck believes it is reading past the end of a data buffer, > > while the code assumes this is fine because it will mask off the bits it > > won't use. > > valgrind doesn't normally produce an error for copying around un-initialised > bytes. > > However, it will produce an error if those bytes are used in a decision > like an if statement. Or it will produce an error if it is an unaddressible location. Which seems to be the case here. I would try to figure out which address exactly it is, what the exact arm/neon (?) instruction it is that is being executed. How many bytes it is supposed to read and if that many bytes are actually available. If this is an overread then you might try --partial-loads-ok=yes (although that should be the default these days). If that doesn't work then valgrind might have chopped up the read into smaller blocks, so memcheck cannot see that it is a larger load and the backend (VEX/priv/guest_arm_toIR.c) might have to be adjusted.
next prev parent reply other threads:[~2023-12-19 17:18 UTC|newest] Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-12-16 16:39 [Bug target/113045] New: " dcb314 at hotmail dot com 2023-12-16 16:44 ` [Bug target/113045] " pinskia at gcc dot gnu.org 2023-12-17 17:35 ` dcb314 at hotmail dot com 2023-12-17 18:18 ` redi at gcc dot gnu.org 2023-12-17 18:21 ` redi at gcc dot gnu.org 2023-12-17 18:50 ` dcb314 at hotmail dot com 2023-12-17 18:57 ` dcb314 at hotmail dot com 2023-12-17 19:55 ` dcb314 at hotmail dot com 2023-12-17 20:06 ` pinskia at gcc dot gnu.org 2023-12-17 20:11 ` pinskia at gcc dot gnu.org 2023-12-17 21:05 ` redi at gcc dot gnu.org 2023-12-17 22:22 ` redi at gcc dot gnu.org 2023-12-17 22:25 ` redi at gcc dot gnu.org 2023-12-18 8:18 ` rguenth at gcc dot gnu.org 2023-12-19 8:23 ` dcb314 at hotmail dot com 2023-12-19 8:28 ` dcb314 at hotmail dot com 2023-12-19 9:22 ` redi at gcc dot gnu.org 2023-12-19 12:58 ` mark at gcc dot gnu.org 2023-12-19 16:53 ` dcb314 at hotmail dot com 2023-12-19 17:18 ` mark at gcc dot gnu.org [this message] 2024-01-02 14:40 ` rearnsha at gcc dot gnu.org 2024-01-02 14:49 ` rearnsha at gcc dot gnu.org 2024-01-02 15:05 ` dcb314 at hotmail dot com 2024-01-02 15:14 ` schwab@linux-m68k.org 2024-01-02 15:18 ` rearnsha at gcc dot gnu.org 2024-01-02 16:25 ` mark at gcc dot gnu.org 2024-01-02 16:28 ` rearnsha at gcc dot gnu.org 2024-01-02 16:35 ` rearnsha at gcc dot gnu.org 2024-01-02 17:23 ` rearnsha at gcc dot gnu.org
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=bug-113045-4-qtuasnoQjF@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.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).