unofficial mirror of bug-guix@gnu.org 
 help / color / mirror / code / Atom feed
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’.




  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).