All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Tomasz Meresinski <tomasz.meresinski@comarch.com>, poky@yoctoproject.org
Subject: Re: GCC patch Reuse-fdebug-prefix-map-to-replace-ffile-prefix-map.patch
Date: Wed, 21 Sep 2016 14:27:47 +0100	[thread overview]
Message-ID: <1474464467.7207.315.camel@linuxfoundation.org> (raw)
In-Reply-To: <7b50926a-35bb-0fe3-394d-80dca52161a4@comarch.com>

On Wed, 2016-09-21 at 14:20 +0200, Tomasz Meresinski wrote:
> Hi
> I found some difficulties when compiling some of our internal 
> applications because of gcc patch called 
> "Reuse-fdebug-prefix-map-to-replace-ffile-prefix-map.patch"
> As far as I can see it makes __FILE__ macro to point to Yocto source 
> file location not build system's.
> 
> Now let me describe that problem:
> 1) CMake script gets source directory (so it's build system path)
> 2) CMake calculates its length and adds it as a define to
> application 
> (call it LEN)
> 3) A simple way to get a filename from __FILE__ macro is to compute 
> __FILE__ + LEN
> 4) Crash
> 
> Is this patch really a big deal?

Without it, build paths get encoded into the binaries. This means the
binaries differ depending on where they're built, it also means those
paths can be exposed to end users which can be confusing and doesn't
match the debug source locations used on target.

If you don't care about those things, its not a big deal. Personally, I
do believe that reproducible binaries are important though. I think
cmake is making some assumptions here it shouldn't.

Cheers,

Richard





      reply	other threads:[~2016-09-21 13:28 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-21 12:20 GCC patch Reuse-fdebug-prefix-map-to-replace-ffile-prefix-map.patch Tomasz Meresinski
2016-09-21 13:27 ` Richard Purdie [this message]

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=1474464467.7207.315.camel@linuxfoundation.org \
    --to=richard.purdie@linuxfoundation.org \
    --cc=poky@yoctoproject.org \
    --cc=tomasz.meresinski@comarch.com \
    /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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.