[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <578c3a3a-2972-2b95-b98c-aee78950f5bb@arm.com>
Date: Wed, 30 Oct 2019 11:03:43 +0000
From: James Clark <James.Clark@....com>
To: Arnaldo Carvalho de Melo <arnaldo.melo@...il.com>
CC: "linux-perf-users@...r.kernel.org" <linux-perf-users@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
nd <nd@....com>, Adrian Hunter <adrian.hunter@...el.com>,
Ian Rogers <irogers@...gle.com>, Jiri Olsa <jolsa@...nel.org>,
Josh Poimboeuf <jpoimboe@...hat.com>,
Namhyung Kim <namhyung@...nel.org>
Subject: Re: [PATCH] Fixes issue when debugging debug builds of Perf.
Hi Arnaldo,
Thanks for that, yes separating them looks better.
I will try to break down commits in the future.
> The patch came mangled, so I'm applying by hand, and separating it into
> two patches, the first for the first paragraph and the other for the
> second, ok?
By mangled do you mean the quoted printables "=3D" and "=20"?
It seems like git send-email falls back to this behavior by default:
--transfer-encoding=(7bit|8bit|quoted-printable|base64|auto)
Specify the transfer encoding to be used to send the message over SMTP.
7bit will fail upon encountering a non-ASCII message. quoted-printable can be
useful when the repository contains files that contain carriage returns, but
makes the raw patch email file (as saved from a MUA) much harder to inspect
manually. base64 is even more fool proof, but also even more opaque. auto will
use 8bit when possible, and quoted-printable otherwise.
I copied my raw patch and was able to successfully apply it with git am, even with this escaping. Although I
did upgrade to a newer version of git (2.23.0).
If I view the patch that you created, then it doesn't have quoted printable escaping. So there does
seem to be a difference somewhere.
Do you think I should use "git send-email --transfer-encoding=7bit"?
Thanks
James
On 29/10/2019 14:26, Arnaldo Carvalho de Melo wrote:
> Em Tue, Oct 29, 2019 at 11:18:52AM -0300, Arnaldo Carvalho de Melo escreveu:
>> And here is the first patch out of your larger one, I changed the
>> subject line to reflect that this is not tools/perf specific, as
>> tools/objtool/ also uses libsubcmd, added Josh, objtool's maintainer so
>> that he is made aware.
>
> And the second patch:
>
>
> commit d0381449fd9ab733ec2daf527263da9f73f1e94e
> Author: James Clark <James.Clark@....com>
> Date: Mon Oct 28 11:34:01 2019 +0000
>
> libsubcmd: Use -O0 with DEBUG=1
>
> When a 'make DEBUG=1' build is done, the command parser is still built
> with -O6 and is hard to step through, fix it making it use -O0 in that
> case.
>
> Signed-off-by: James Clark <james.clark@....com>
> Cc: Adrian Hunter <adrian.hunter@...el.com>
> Cc: Ian Rogers <irogers@...gle.com>
> Cc: Jiri Olsa <jolsa@...nel.org>
> Cc: Josh Poimboeuf <jpoimboe@...hat.com>
> Cc: Namhyung Kim <namhyung@...nel.org>
> Cc: nd <nd@....com>
> Link: http://lore.kernel.org/lkml/20191028113340.4282-1-james.clark@arm.com
> [ split from a larger patch ]
> Signed-off-by: Arnaldo Carvalho de Melo <acme@...hat.com>
>
> diff --git a/tools/lib/subcmd/Makefile b/tools/lib/subcmd/Makefile
> index 352c6062deba..1c777a72bb39 100644
> --- a/tools/lib/subcmd/Makefile
> +++ b/tools/lib/subcmd/Makefile
> @@ -27,7 +27,9 @@ ifeq ($(DEBUG),0)
> endif
> endif
>
> -ifeq ($(CC_NO_CLANG), 0)
> +ifeq ($(DEBUG),1)
> + CFLAGS += -O0
> +else ifeq ($(CC_NO_CLANG), 0)
> CFLAGS += -O3
> else
> CFLAGS += -O6
>
Powered by blists - more mailing lists