From: "Ludovic Courtès" <ludo@gnu.org>
To: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Cc: 54728@debbugs.gnu.org
Subject: bug#54728: [PATCH 2/2] gnu: valgrind: fix ld.so symbols not found
Date: Fri, 15 Apr 2022 18:21:33 +0200 [thread overview]
Message-ID: <87czhi48s2.fsf@gnu.org> (raw)
In-Reply-To: <20220414233012.13243-2-GNUtoo@cyberdimension.org> (Denis Carikli's message of "Fri, 15 Apr 2022 01:30:12 +0200")
Hello!
Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org> skribis:
> (define-public valgrind/interactive
> - (package/inherit
> - valgrind
> - (inputs
> - ;; GDB is needed to provide a sane default for `--db-command'.
> - `(("gdb" ,gdb)))
> - (properties '())))
> + (package/inherit valgrind
> + (inputs
> + ;; GDB is needed to provide a sane default for `--db-command'.
> + `(("gdb" ,gdb)
> + ("libc:debug" ,(@@ (gnu packages commencement) glibc-final) "debug")))
Rather: ("libc:debug" ,(canonical-package glibc) "debug").
> + (arguments
> + (substitute-keyword-arguments (package-arguments valgrind)
> + ((#:phases those-phases #~%standard-phases)
> + #~(let* ((those-phases #$those-phases)
> + (unpack (assoc-ref those-phases 'unpack)))
> + (modify-phases those-phases
> + (add-before 'build 'patch-default-debuginfo-path
> + (lambda _
> + ;; This helps Valgrind find the debug symbols of ld.so.
> + ;; Without it, Valgrind does not work in a Guix shell
> + ;; container and cannot be used as-is during packages tests
> + ;; phases
> + (substitute* '
> + ("coregrind/m_debuginfo/readelf.c"
> + "docs/xml/manual-core-adv.xml"
> + "docs/xml/manual-core.xml")
> + (("/usr/lib/debug")
> + (string-append
> + (assoc-ref %build-inputs "libc:debug")
> + "/lib/debug")))
> + ;; We also need to account for the bigger path in
> + ;; the malloc-ed variables
> + (substitute* '
> + ("coregrind/m_debuginfo/readelf.c")
> + (("VG_\\(strlen\\)\\(buildid\\) \\+ 33")
> + (string-append
> + "VG_(strlen)(buildid) + "
> + (number->string
> + (+ (string-length
> + (string-append
> + (assoc-ref %build-inputs "libc:debug")
> + "/lib/debug"))
> + (string-length "/.build-id//.debug")
> + 1)))))
> + (substitute* '
> + ("coregrind/m_debuginfo/readelf.c")
> + ((string-append
> + "VG_\\(strlen\\)\\(objdir\\) \\+ "
> + "VG_\\(strlen\\)\\(debugname\\) \\+ 64")
> + (string-append
> + "VG_(strlen)(objdir) + VG_(strlen)(debugname) + "
> + (number->string
> + (+ (string-length
> + (string-append
> + (assoc-ref
> + %build-inputs
> + "libc:debug")
> + "/lib/debug"))
> + (string-length
> + "/usr/lib/debug")
> + 1)))))
I find this patch-as-code snippet rather difficult to follow; it might
also break easily if minor things change in those C files.
How about making it an actual patch? In the patch, you’d have
placeholders for the store file names, like @LIBC_DEBUG_DIRECTORY@; the
phase would replace those placeholders with ‘substitute*’.
How does that sound?
Thanks,
Ludo’.
next prev parent reply other threads:[~2022-04-15 16:22 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-05 15:01 bug#54728: Valgrind not working out of the box due to stripped ld.so Denis 'GNUtoo' Carikli
2022-04-07 16:40 ` Ludovic Courtès
2022-04-14 23:26 ` Denis 'GNUtoo' Carikli
2022-04-14 23:30 ` bug#54728: [PATCH 1/2] gnu: valgrind: impots: sort imports alphabetically Denis 'GNUtoo' Carikli
2022-04-14 23:30 ` bug#54728: [PATCH 2/2] gnu: valgrind: fix ld.so symbols not found Denis 'GNUtoo' Carikli
2022-04-15 16:21 ` Ludovic Courtès [this message]
2022-04-25 16:39 ` Denis 'GNUtoo' Carikli
2022-04-25 17:41 ` Maxime Devos
2022-04-26 1:39 ` Denis 'GNUtoo' Carikli
2022-04-26 1:39 ` bug#54728: [PATCH v2 1/2] gnu: valgrind: impots: sort imports alphabetically Denis 'GNUtoo' Carikli
2022-04-26 1:39 ` bug#54728: [PATCH v2 2/2] gnu: valgrind: fix ld.so symbols not found Denis 'GNUtoo' Carikli
2022-04-26 22:37 ` Denis 'GNUtoo' Carikli
2022-05-06 20:16 ` Denis 'GNUtoo' Carikli
2022-05-06 20:20 ` Maxime Devos
2022-05-09 9:24 ` bug#54728: Valgrind not working out of the box due to stripped ld.so Ludovic Courtès
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
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87czhi48s2.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=54728@debbugs.gnu.org \
--cc=GNUtoo@cyberdimension.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.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
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).