Re: .arch clobbers .cpu in assembler

[Ramana Radhakrishnan <ramana dot gcc at googlemail dot com>]

On Fri, Oct 11, 2019 at 9:06 PM John Breitenbach <breiten@lexmark.com> wrote:
>
> Hi,
>    I'm trying to port some marvell-pj4 support that originated back in
> binutils-2.19.  My understanding is that this was done by CodeSourcery
> back in 2008 or 2009, and for whatever reason, wasn't ever mainlined in
> binutils.  I'm trying to make it work with binutils-2.31.1 + gcc-8.2 but
> am running into some problems because gcc-8 has begun to emit .arch and
> .arch_extension directives.
>
> When compiling with gcc-8.2 and -mcpu=marvell-pj4, I see gcc adding the
> following to the generated assembly file (compiling with -save-temps)
>
>     .cpu marvell-pj4
>     .arch armv7-a
>     .arch_extension div
>
> The .arch and .arch_extension directives are new since trying to use
> gcc-8.2, (i.e. weren't in gcc-7.3 or any earlier versions that I've
> used)  And when configured for other cpus, I also now see a .arch and a
> .arch_extension directive.
>
> My problem is that it appears that the processing of the .arch directive
> is completely clobbering everything that I recorded from the earlier
> .cpu directive.  Thus, when it comes to processing the unique
> instructions in the pj4 or encoding a divide instruction properly,

Support for PJ4 was added upstream in binutils with
https://sourceware.org/ml/binutils/2013-01/msg00478.html . I would go
back and work out what the differences are in your downstream patch
compared to the 2013 version of the sourcebase.


> there's no record than I'm assembling for a pj4 in the "cpu_variant"
> structure.
>
> I see this code in s_arm_arch() which gets invoked when finding the
> matching architecture in arm_archs[]
>      selected_ext = arm_arch_none;
>      selected_cpu = selected_arch;
>      strcpy (selected_cpu_name, opt->name);
>      ARM_MERGE_FEATURE_SETS (cpu_variant, selected_cpu, selected_fpu);
>
> These globals in tc-arm.c (selected_ext, selected_cpu and cpu_variant)
> appear to be the only artifacts from the .cpu directive.  cpu_variant's
> prior setting is completely clobbered.

Not surprising. That's expected. In the Arm port, .cpu is a short form
for .arch and .arch_extension together.

> Similarly, when processing ".arch_extension", we clobber both
> selected_cpu and cpu_variant, eliminating any evidence of the earlier
> .cpu directive.
>
> It doesn't seem like the .arch or .arch_extension should clobber the
> .cpu ... as the .cpu should imply an arch and any extensions. From my
> naive perspective, I wonder why gcc would emit them, as .cpu contains
> everything that the assembler should need to know. I haven't explored
> any options for suppressing those directive from gcc's output.

See  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82641 for all the gory detail.

Support for Marvell pj4 came in during 2013 into GCC and it came in as such.

regards
Ramana







>
> I'd really like to make this work with the latest tools.  Its been an
> easy port for about 10 years and at least 5 compiler/binutils
> combinations and I'd like to keep it going for at least one more.  So
> thanks in advance for any suggestions. Also, I can provide more details
> as needed.
>
> I do see that the -mcpu=marvell-pj4 command line option sets
> mcpu_cpu_opt and mcpu_ext_opt, but this doesn't make its way into
> cpu_variant.
>
> Regards,
> John Breitenbach
>
>
>
>
>
>