public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: "H.J. Lu" <hjl.tools@gmail.com>
To: Nick Alcock <nick.alcock@oracle.com>
Cc: Alan Modra <amodra@gmail.com>, Binutils <binutils@sourceware.org>,
	weimin.pan@oracle.com
Subject: Re: [PATCH 00/13] CTF dumper improvements, a lookup testsuite, and bugfixes
Date: Tue, 5 Jan 2021 07:53:02 -0800	[thread overview]
Message-ID: <CAMe9rOrdGJr+nMVnuE6vf9CNka-OBjcTxy4KEDEHOZsQf81-Xw@mail.gmail.com> (raw)
In-Reply-To: <877dorpg37.fsf@esperi.org.uk>

On Tue, Jan 5, 2021 at 7:19 AM Nick Alcock via Binutils
<binutils@sourceware.org> wrote:
>
> On 30 Dec 2020, Alan Modra via Binutils spake thusly:
>
> > Good.  :-)  Looks OK to commit.  Note that the top-level changes
> > should be committed to the gcc repo, otherwise they are likely to
> > disappear the next time someone syncs the binutils top-level from
> > gcc.
>
> Pushed! I'll see about sending the top-level stuff out next (it's so
> simple that it should be easy to get in before the next sync, and if we
> *do* miss it, all that happens is that make check-libctf does nothing
> for a bit: no harm).
>
> (As usual, this works everywhere I can try it, with one exception I just
> noticed: the new libctf-writable testsuite works on non-ELF platforms,
> with tests that link to the newly-built libctf, but on a
> cygwin-to-mingw64 cross in one of my cygwin64 installations -- but only
> one -- I'm seeing very odd stuff that looks almost like a buffer overrun
> in the dynamic linker: complaints that it can't find shared libraries
> whose names are complete garbage. I've ignored that for now because
> whatever it is it's not a libctf bug and shouldn't really hold up a
> libctf testsuite finally landing for everyone else. So my apologies if
> anyone sees ERROR or FAIL results in that situation.)

All libctf tests failed for cross binutils without a cross compiler:

ERROR: aarch64-linux-cc does not exist

-- 
H.J.

  reply	other threads:[~2021-01-05 15:53 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-18 19:51 Nick Alcock
2020-12-18 19:51 ` [PATCH 01/13] libctf: do not print array declarators backwards Nick Alcock
2020-12-18 19:51 ` [PATCH 02/13] libctf, ld: CTF dumper changes for consistency Nick Alcock
2020-12-18 19:51 ` [PATCH 03/13] libctf, ld: more dumper improvements Nick Alcock
2020-12-18 19:51 ` [PATCH 04/13] libctf, ld: prohibit doing things with forwards prohibited in C Nick Alcock
2020-12-27 17:43   ` Nick Alcock
2020-12-28  2:04     ` Nick Alcock
2020-12-29 11:52       ` [PATCH v2] libctf, ld: prohibit getting the size or alignment of forwards Nick Alcock
2020-12-18 19:51 ` [PATCH 05/13] libctf, ld: dump enums: generally improve dump formatting Nick Alcock
2020-12-18 19:51 ` [PATCH REVIEW 06/13] libctf: rip out BFD_DEPENDENCIES / BFD_LIBADD Nick Alcock
2020-12-18 19:51 ` [PATCH REVIEW 07/13] libctf: new testsuite Nick Alcock
2020-12-29 11:52   ` [PATCH v2] " Nick Alcock
2020-12-18 19:51 ` [PATCH 08/13] libctf: new test of enum lookups with the _next iterator Nick Alcock
2020-12-18 19:51 ` [PATCH 09/13] libctf: warn about information loss because of unreleased format changes Nick Alcock
2020-12-18 19:51 ` [PATCH 10/13] libctf, include: support unnamed structure members better Nick Alcock
2020-12-18 19:51 ` [PATCH 11/13] libctf: remove outdated comment about parent dict importing Nick Alcock
2020-12-18 19:51 ` [PATCH 12/13] libctf: fix lookups of pointers by name in parent dicts Nick Alcock
2020-12-18 19:51 ` [PATCH 13/13] libctf, ld: fix formatting of forwards to unions and enums Nick Alcock
2020-12-30  4:14 ` [PATCH 00/13] CTF dumper improvements, a lookup testsuite, and bugfixes Alan Modra
2020-12-31 13:00   ` Nick Alcock
2021-01-02  4:55     ` Alan Modra
2021-01-05 15:18   ` Nick Alcock
2021-01-05 15:53     ` H.J. Lu [this message]
2021-01-05 17:13       ` Nick Alcock
2021-01-05 18:52         ` H.J. Lu
2021-01-05 19:05           ` Nick Alcock
2021-01-05 19:09             ` H.J. Lu
2021-01-05 19:32               ` Nick Alcock
2021-01-05 19:56           ` Nick Alcock

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=CAMe9rOrdGJr+nMVnuE6vf9CNka-OBjcTxy4KEDEHOZsQf81-Xw@mail.gmail.com \
    --to=hjl.tools@gmail.com \
    --cc=amodra@gmail.com \
    --cc=binutils@sourceware.org \
    --cc=nick.alcock@oracle.com \
    --cc=weimin.pan@oracle.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).