From: Patrick Ohly <patrick.ohly@intel.com>
To: Mark Hatle <mark.hatle@windriver.com>,
Richard Purdie <richard.purdie@intel.com>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [PATCH v3 2/8] gdb-cross: avoid tune specific paths
Date: Tue, 11 Apr 2017 18:29:00 +0200 [thread overview]
Message-ID: <1491928140.10884.191.camel@intel.com> (raw)
In-Reply-To: <97be7aaf-58b0-05a2-b352-942cd82aca01@windriver.com>
On Tue, 2017-04-11 at 10:16 -0500, Mark Hatle wrote:
> On 4/11/17 9:56 AM, Patrick Ohly wrote:
> > gdb-cross used to be specific to the tune flags, but isn't
> > anymore. Therefore it is enough to use TARGET_SYS instead of
> > TUNE_PKGARCH to create a unique path.
>
> Are you sure about this.
It's what Richard told me and he proposed this fix (forgot to mention
that), so ultimately this is a question for him.
> On non-intel architectures, it used to be VERY common
> that the specific instruction set for a process was programmed into gdb.
I'm not seeing anything in gdb-cross where that happens. The TUNEFLAGS
dependency was just for the datadir, not for anything else that might
configure the instruction set.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
next prev parent reply other threads:[~2017-04-11 16:29 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-11 14:56 [PATCH v3 0/8] yocto-compat-layer: bitbake-diffsigs support + per machine checks + OE-core fixes Patrick Ohly
2017-04-11 14:56 ` [PATCH v3 1/8] go-cross: avoid libgcc dependency Patrick Ohly
2017-04-11 14:56 ` [PATCH v3 2/8] gdb-cross: avoid tune specific paths Patrick Ohly
2017-04-11 15:16 ` Mark Hatle
2017-04-11 16:29 ` Patrick Ohly [this message]
2017-04-11 16:56 ` Khem Raj
2017-04-11 17:19 ` Richard Purdie
2017-04-11 18:12 ` Mark Hatle
2017-04-11 14:56 ` [PATCH v3 3/8] -cross recipes: ignore TARGET_ARCH sstate hash Patrick Ohly
2017-04-11 18:25 ` Richard Purdie
2017-04-11 18:28 ` Patrick Ohly
2017-04-11 14:56 ` [PATCH v3 4/8] yocto-compat-layer: include bitbake-diffsigs output Patrick Ohly
2017-04-11 14:56 ` [PATCH v3 5/8] yocto-compat-layer: also determine tune flags for each task Patrick Ohly
2017-04-11 14:56 ` [PATCH v3 6/8] yocto-compat-layer: add --additional-layers Patrick Ohly
2017-04-11 14:57 ` [PATCH v3 7/8] yocto-compat-layer: test signature differences when setting MACHINE Patrick Ohly
2017-04-11 14:57 ` [PATCH v3 8/8] yocto-compat-layer: better handling of per-machine world build breakage Patrick Ohly
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=1491928140.10884.191.camel@intel.com \
--to=patrick.ohly@intel.com \
--cc=mark.hatle@windriver.com \
--cc=openembedded-core@lists.openembedded.org \
--cc=richard.purdie@intel.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.