On Sat, 2022-08-13 at 21:34 +0100, Richard Purdie via
lists.openembedded.org wrote:
> Add a patch to gcc so that relative paths are handled by -fdebug-prefix-map
> and friends. In OE we use relative paths in autotools and removing that
> creates a lot of issues we'd have to fix. This alternative allows us to
> fix the paths within gcc and improve our debug file coverage (and SPDX
> manifests) accordingly.
> 
> Signed-off-by: Richard Purdie <[email protected]>
> ---
>  meta/recipes-devtools/gcc/gcc-12.1.inc        |  1 +
>  .../gcc/gcc/prefix-map-realpath.patch         | 46 +++++++++++++++++++
>  2 files changed, 47 insertions(+)
>  create mode 100644 meta/recipes-devtools/gcc/gcc/prefix-map-realpath.patch
> 
> diff --git a/meta/recipes-devtools/gcc/gcc-12.1.inc 
> b/meta/recipes-devtools/gcc/gcc-12.1.inc
> index 56678c78bef..c42fa3d72f0 100644
> --- a/meta/recipes-devtools/gcc/gcc-12.1.inc
> +++ b/meta/recipes-devtools/gcc/gcc-12.1.inc
> @@ -65,6 +65,7 @@ SRC_URI = "${BASEURI} \
>             file://0025-Move-sched.h-include-ahead-of-user-headers.patch \
>             file://0026-rust-recursion-limit.patch \
>             
> file://0001-libsanitizer-cherry-pick-9cf13067cb5088626ba7-from-u.patch \
> +           file://prefix-map-realpath.patch \
>  "
>  SRC_URI[sha256sum] = 
> "62fd634889f31c02b64af2c468f064b47ad1ca78411c45abe6ac4b5f8dd19c7b"
>  
> diff --git a/meta/recipes-devtools/gcc/gcc/prefix-map-realpath.patch 
> b/meta/recipes-devtools/gcc/gcc/prefix-map-realpath.patch
> new file mode 100644
> index 00000000000..137fc645624
> --- /dev/null
> +++ b/meta/recipes-devtools/gcc/gcc/prefix-map-realpath.patch
> @@ -0,0 +1,46 @@
> +Relative paths don't work with -fdebug-prefix-map and friends. This
> +can lead to paths which the user wanted to be remapped being missed.
> +Setting -fdebug-prefix-map to work with a relative path isn't practical
> +either.
> +
> +Instead, call gcc's realpath function on the incomming path name before
> +comparing it with the remapping. This means other issues like symlinks
> +are also accounted for and leads to a more consistent remapping experience.
> +
> +Upstream-Status: Pending [need to see if gcc developers would accept this]
> +Signed-off-by: Richard Purdie <[email protected]>
> +
> +
> +Index: gcc-12.1.0/gcc/file-prefix-map.cc
> +===================================================================
> +--- gcc-12.1.0.orig/gcc/file-prefix-map.cc
> ++++ gcc-12.1.0/gcc/file-prefix-map.cc
> +@@ -70,19 +70,25 @@ remap_filename (file_prefix_map *maps, c
> +   file_prefix_map *map;
> +   char *s;
> +   const char *name;
> ++  char *realname;
> +   size_t name_len;
> + 
> ++  realname = lrealpath (filename);
> ++
> +   for (map = maps; map; map = map->next)
> +-    if (filename_ncmp (filename, map->old_prefix, map->old_len) == 0)
> ++    if (filename_ncmp (realname, map->old_prefix, map->old_len) == 0)
> +       break;
> +-  if (!map)
> ++  if (!map) {
> ++    free (realname);
> +     return filename;
> +-  name = filename + map->old_len;
> ++  }
> ++  name = realname + map->old_len;
> +   name_len = strlen (name) + 1;
> + 
> +   s = (char *) ggc_alloc_atomic (name_len + map->new_len);
> +   memcpy (s, map->new_prefix, map->new_len);
> +   memcpy (s + map->new_len, name, name_len);
> ++  free (realname);
> +   return s;
> + }
> + 


Seems there is a downside to this, it breaks ruby and xen-tools:

https://autobuilder.yoctoproject.org/typhoon/#/builders/117/builds/1386/steps/12/logs/stdio
https://autobuilder.yoctoproject.org/typhoon/#/builders/128/builds/482/steps/12/logs/stdio

which both do:

#include __FILE__

I'm tempted to suggest we patch that to something different in both
cases as the alternatives to debug handling are much worse.

Cheers,

Richard

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#169322): 
https://lists.openembedded.org/g/openembedded-core/message/169322
Mute This Topic: https://lists.openembedded.org/mt/93006711/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to