[Bug c/102755] New: Built gcc cross compiler always tries to use "as" instead of cross assembler

[Bug c/102755] New: Built gcc cross compiler always tries to use "as" instead of cross assembler

[dr.duncan.p.simpson at gmx dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102755

            Bug ID: 102755
           Summary: Built gcc cross compiler always tries to use "as"
                    instead of  cross assembler
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: dr.duncan.p.simpson at gmx dot com
  Target Milestone: ---
              Host: x86_64-linux-gnu
            Target: aarch64-linux-gnu

Created attachment 51604
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51604&action=edit
Proposed minimal fix

In gcc.c the assembler name is hard coded as "as" and the --with-as option does
not change this. When building an aarch64-linxu-gnu cross compiler the build
process used aarc64-linux-gnu-as but the built cross compiler attempted to use
"as", which does not work. While I could override the spec file that is a
suboptimal solution.

This affects at least the gcc-12 tip version and probably most other versions
too. The proposed fix has been tested without --with-as and with
--with-as=/usr/local/bin/aarch64-linux-gnu-as.

[Bug driver/102755] Built gcc cross compiler always tries to use "as" instead of cross assembler

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102755

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2021-10-14
          Component|c                           |driver
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |WAITING

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
This should have been taken care of by this part:
static char*
find_a_program (const char *name)
{
  /* Do not search if default matches query. */

#ifdef DEFAULT_ASSEMBLER
  if (! strcmp (name, "as") && access (DEFAULT_ASSEMBLER, X_OK) == 0)
    return xstrdup (DEFAULT_ASSEMBLER);
#endif


So why is it not?

[Bug driver/102755] Built gcc cross compiler always tries to use "as" instead of cross assembler

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102755

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |build

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
What exact configure line did you do?
Also what exact error message is happening and when? While building gcc's
library or otherwise?

[Bug driver/102755] Built gcc cross compiler always tries to use "as" instead of cross assembler

[dr.duncan.p.simpson at gmx dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102755

--- Comment #3 from Duncan Simpson <dr.duncan.p.simpson at gmx dot com> ---
On 15/10/2021 00:32, pinskia at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102755
>
> Andrew Pinski <pinskia at gcc dot gnu.org> changed:
>
>             What    |Removed                     |Added
> ----------------------------------------------------------------------------
>             Keywords|                            |build
>
> --- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
> What exact configure line did you do?
> Also what exact error message is happening and when? While building gcc's
> library or otherwise?

I *can* build the cross compiler because the override spec files get the
assembler name right when I use --with-as=<cross assembler>. There are
no problems building the compiler or libraries.

The problem only occurs when I attempt to cross compile something
because as, which is a x86_64 native assembler, dies badly when fed
arm64 options and assembly language. What the proposed fix does is make
--wirh-as also affect the built compiler.

[Bug driver/102755] Built gcc cross compiler always tries to use "as" instead of cross assembler

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102755

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Duncan Simpson from comment #3)
> I *can* build the cross compiler because the override spec files get the
> assembler name right when I use --with-as=<cross assembler>. There are
> no problems building the compiler or libraries.

There is no override of the spec file going on.

Again when a program is executed via the specs, it goes through the
find_a_program function and that does the following:

#ifdef DEFAULT_ASSEMBLER
  if (! strcmp (name, "as") && access (DEFAULT_ASSEMBLER, X_OK) == 0)
    return xstrdup (DEFAULT_ASSEMBLER);
#endif

Which says if the program name matches exactly "as", and the DEFAULT_ASSEMBLER
is defined and has executable access return DEFAULT_ASSEMBLER.

So your patch should have been a nop really as DEFAULT_ASSEMBLER should have
been used for "as".

Can you show exactly how it was failing before and add -v to the command line
too?

[Bug driver/102755] Built gcc cross compiler always tries to use "as" instead of cross assembler

[dr.duncan.p.simpson at gmx dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102755

Duncan Simpson <dr.duncan.p.simpson at gmx dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|---                         |WORKSFORME

--- Comment #5 from Duncan Simpson <dr.duncan.p.simpson at gmx dot com> ---
The find_a_program logic does seem to fix most versions of this issue. It might
be insufficient if default tool is "foo" but finding it requires path searching
which access(2) does not do. Attempying to build gcc with that problem dies
with a sane message quickly, so I don't think that is a major problem.

The version I was testing had a version of gcc,c which completely ignored
DEFUALT_ASEEMBLER and the built in specs lead to the assumption that running a
program called "as" with execvp(2) was the correct thing to do. The build did
use the compiler passed using --with-as.