public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: David Edelsohn <dje.gcc@gmail.com>
To: "REIX, Tony" <tony.reix@atos.net>
Cc: Ian Taylor <iant@golang.org>,
		"SARTER, MATTHIEU (ext)" <matthieu.sarter.external@atos.net>,
	GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH,AIX] Enable libiberty to read AIX XCOFF
Date: Wed, 07 Jun 2017 14:43:00 -0000	[thread overview]
Message-ID: <CAGWvny=8XevmD_0pFk-ca5vL6U=rE+f9HXUm4TX3L6nWZ1t3WA@mail.gmail.com> (raw)
In-Reply-To: <B37989F2852398498001550C29155BE5CF0C53@FRCRPVV9EX4MSX.ww931.my-it-solutions.net>

On Wed, Jun 7, 2017 at 10:22 AM, REIX, Tony <tony.reix@atos.net> wrote:
> Hi David,
>
> I'll fix the code incorrectly indented.

I already have fixed the indentation in my copy.

>
> About your comment about our code looking for TEXT section by looking at string ".text"  , please note that our patch fixes a file called "simple-object-xcoff.c" : SIMPLE.
> Do not expect us to handle more than required.
>
> However, are you sure that  -ffunction-sections  is implemented on AIX ?

-ffunction-sections is implemented on AIX.  It is used quite
frequently for additional performance.  The libstdc++ library builds
with the option.

On second thought, his probably doesn't affect your code because the
implementation is working at the COFF section level, not the XCOFF
storage mapping class level.

>
> Moreover, if it is not implemented on AIX, don't you think that such an option which is documented as:
> " Place each function or data item into its own section in the output file if the
> target supports arbitrary sections. The name of the function or the name of
> the data item determines the section’s name in the output file.
> Use these options on systems where the linker can perform optimizations to
> improve locality of reference in the instruction space. Most systems using the
> ELF object format and SPARC processors running Solaris 2 have linkers with
> such optimizations. AIX may have these optimizations in the future.
> Only use these options when there are significant benefits from doing so. When
> you specify these options, the assembler and linker create larger object and
> executable files and are also slower."
> is not compatible with the already existing high complexity of GCC Go implementation ?and should be forbidden with Go on AIX ?
>
>
> We have tried another approach:
> 127a128
>> #define STYP_TEXT                     0x20
> 408a410
>>   unsigned int flags;
> 482a485,486
>>         flags = fetch_32 (scnhdr + offsetof (struct external_scnhdr,
>>                                              u.xcoff64.s_flags));
> 489a494,495
>>         flags = fetch_32 (scnhdr + offsetof (struct external_scnhdr,
>>                                              u.xcoff32.s_flags));
> 492c498
> <       if (strcmp (name, ".text") == 0)
> ---
>>       if ((flags & 0xffff) == STYP_TEXT)
>
> However, that makes never-seen-before errors to appear when running libgo tests in always-succeeding libgo tests, like: bufio & bytes.
>
>
> Since we have many other GCC Go stuff on AIX to handle, wouldn't it be possible to start with this implementation and to improve it later if it needs to be hardened ?
> Document it as a limitation.

As I wrote in my original reply, it's an incremental start.

".text" may be sufficient.  We'll see.

Thanks, David

  reply	other threads:[~2017-06-07 14:43 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-06 23:25 David Edelsohn
2017-06-06 23:52 ` DJ Delorie
2017-06-07 13:16   ` REIX, Tony
2017-06-07 15:37     ` [PATCH,AIX] " DJ Delorie
2017-06-07 14:23 ` REIX, Tony
2017-06-07 14:43   ` David Edelsohn [this message]
     [not found] <B37989F2852398498001550C29155BE5CD3512@FRCRPVV9EX3MSX.ww931.my-it-solutions.net>
2017-05-15 14:12 ` [PATCH,AIX] " REIX, Tony

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='CAGWvny=8XevmD_0pFk-ca5vL6U=rE+f9HXUm4TX3L6nWZ1t3WA@mail.gmail.com' \
    --to=dje.gcc@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=iant@golang.org \
    --cc=matthieu.sarter.external@atos.net \
    --cc=tony.reix@atos.net \
    /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).