From: Pedro Alves <palves@redhat.com>
To: "Metzger, Markus T" <markus.t.metzger@intel.com>
Cc: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Subject: Re: [PATCH 1/5] configure: check for libipt
Date: Tue, 30 Jun 2015 15:01:00 -0000 [thread overview]
Message-ID: <5592AF29.7070206@redhat.com> (raw)
In-Reply-To: <A78C989F6D9628469189715575E55B233316813A@IRSMSX104.ger.corp.intel.com>
On 06/30/2015 03:54 PM, Metzger, Markus T wrote:
>> Is the library host independent? That is, does it handle
>> host vs target endianness, integer types, etc.? E.g., is a big endian PPC
>> host debugging against an x86-64 gdbserver able to use libipt? Another
>> example would be a big endian PPC host loading an x86-64 core dump that
>> includes ipt data (once we get to it).
>
> No. It may not be too hard to make it work, though. Most of the memory
> accesses are byte-wise, already.
>
> I don't have a PPC system to test this configuration.
FYI, there's a few quite powerful ppc64 machines in the
gcc compile farm (gcc110-gcc112):
https://gcc.gnu.org/wiki/CompileFarm
> Is this something
> where Sergio's buildbot can help? How is this cross-platform testing
> usually handled?
Probably not, as no buildslave configured in our buildbot does any cross testing.
It wouldn't be impossible, we could use the gcc compile farm machines for
that, just nobody ever set it up.
> Until libipt is available for PPC, you simply can't build a GDB with Intel PT
> support on PPC. When you configure GDB, HAVE_LIBIPT will be undefined
> and GDB will fall back to BTS or report an error. We're not breaking anything.
> The feature will just not be available on all platforms.
OK, that's fine. Was just checking.
Thanks,
Pedro Alves
next prev parent reply other threads:[~2015-06-30 15:01 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-23 8:22 [PATCH 0/5] Support Intel(R) Processor Trace Markus Metzger
2015-06-23 8:22 ` [PATCH 4/5] btrace: store raw btrace data Markus Metzger
2015-06-30 12:56 ` Pedro Alves
2015-06-23 8:22 ` [PATCH 1/5] configure: check for libipt Markus Metzger
2015-06-30 12:56 ` Pedro Alves
2015-06-30 14:54 ` Metzger, Markus T
2015-06-30 15:01 ` Pedro Alves [this message]
2015-06-23 8:22 ` [PATCH 5/5] btrace: maintenance commands Markus Metzger
2015-06-23 15:28 ` Eli Zaretskii
2015-06-24 7:05 ` Metzger, Markus T
2015-06-24 14:38 ` Eli Zaretskii
2015-06-30 12:57 ` Pedro Alves
2015-06-23 8:22 ` [PATCH 3/5] btrace, linux: use data_size and data_offset Markus Metzger
2015-06-30 12:56 ` Pedro Alves
2015-06-23 8:23 ` [PATCH 2/5] btrace: support Intel(R) Processor Trace Markus Metzger
2015-06-23 15:32 ` Eli Zaretskii
2015-06-30 12:56 ` Pedro Alves
2015-06-30 14:54 ` Metzger, Markus T
2015-06-30 15:08 ` Pedro Alves
2015-07-01 8:39 ` Metzger, Markus T
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=5592AF29.7070206@redhat.com \
--to=palves@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=markus.t.metzger@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox