archive mirror
 help / color / mirror / Atom feed
From: Rasmus Villemoes <>
To: Jim Cromie <>,,
	Jonathan Corbet <>,
	Randy Dunlap <>,
Subject: Re: [PATCH 01/16] dyndbg: drop trim_prefix, obsoleted by __FILE__s relative path
Date: Wed, 30 Oct 2019 22:20:39 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On 29/10/2019 21.00, Jim Cromie wrote:
> Regarding:
> commit 2b6783191da7 ("dynamic_debug: add trim_prefix() to provide source-root relative paths")
> commit a73619a845d5 ("kbuild: use -fmacro-prefix-map to make __FILE__ a relative path")
> 2nd commit broke dynamic-debug's "file $fullpath" query form, but
> nobody noticed because 1st commit trimmed prefixes from control-file
> output, so the click-copy-pasting of fullpaths into new queries had
> ceased; that query form became unused.
> So remove the function and callers; its purpose was to strip the
> prefix from __FILE__, which is now gone.

I agree with the intent, but I wonder if this is premature. I mean, the
-fmacro-prefix-map is only for gcc 8+, so this ends up printing the full
paths when the compiler is just a little old (and the kernel was built

I don't think keeping the current workaround for a year or two more
should hurt; when int skip = strlen(__FILE__) -
strlen("lib/dynamic_debug.c"); evaluates to 0 (in-tree build, or build
with new enough gcc), I'm pretty sure gcc optimizes the rest of the
function away (it should know that strncmp(x, y, 0) gives 0, and even if
it didn't, the conditional assigns 0 to skip which it already is, so gcc
just needs to know that strncmp() is pure).

> Also drop "file $fullpath" from docs, and tweak example to cite column
> 1 of control-file as valid "file $input".

That part certainly makes sense, since the $fullpath hasn't actually
been in the control file for a long time.


  reply	other threads:[~2019-10-30 21:20 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-29 20:00 [PATCH 01/16] dyndbg: drop trim_prefix, obsoleted by __FILE__s relative path Jim Cromie
2019-10-30 21:20 ` Rasmus Villemoes [this message]
2019-11-01 16:20   ` jim.cromie

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \

* 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 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 NNTP newsgroup(s).