[Bug target/114143] New: Non-thumb arm32 code in thumb multilib for libgcc and in -mthumb build

[Bug target/114143] New: Non-thumb arm32 code in thumb multilib for libgcc and in -mthumb build

[hp at gcc dot gnu.org]

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

            Bug ID: 114143
           Summary: Non-thumb arm32 code in thumb multilib for libgcc and
                    in -mthumb build
           Product: gcc
           Version: 13.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: hp at gcc dot gnu.org
  Target Milestone: ---
            Target: arm-eabi

Building an arm-eabi newlib toolchain configured simply with --target arm-eabi,
I expect the simplest thumb1 library code in libraries linked in when I compile
and link the main code using e.g. -O2 -mcpu=cortex-m7+nofp -msoft-float.  To my
surprise, I get 32-bit ("arm32") code linked in.  Needless to say, it crashes
for this reason on the target Cortex-M7 system. On inspection the linked-in
thumb multilib is full of 32-bit code.  Ditto some of the newlib code for some
optimized functions implemented in assembly code (like strcmp), but that may be
a separate bug unless the preprocessor macros that newlib uses in the build,
are wrong for the same reason as in this PR.

While I can work around this by adding --with-arch=armv7e-m at configure-time,
I think a "plain" arm-eabi configuration being unusable for thumb-only builds
with -mthumb is a bug or at least a surprising caveat worth being documented.

Example code, for a tool-chain configured with --target arm-eabi as above:

a.c; compile with "-O2 -mthumb" to simulate other library code:
```
unsigned udivide(unsigned a, unsigned b)
{
  return a / b;
}'''

b.c; compile with "-msoft-float -mthumb -mcpu=cortex-m7+nofp -O2" simulating
code you care about:
```extern unsigned udivide(unsigned, unsigned);
int main()
{
  __builtin_exit (udivide(42, 6));
}'''

Link a.o and b.o producing ab using gcc with e.g. "-msoft-float -mthumb
-mcpu=cortex-m7+nofp" to make sure you get the right multilib.  Inspect ab
using arm-eabi-objdump -d.  Observe udivide calling  __udivsi3, with __udivsi3
containing arm32 code.

[Bug target/114143] Non-thumb arm32 code in thumb multilib for libgcc and in -mthumb build

[clyon at gcc dot gnu.org]

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

Christophe Lyon <clyon at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |clyon at gcc dot gnu.org

--- Comment #1 from Christophe Lyon <clyon at gcc dot gnu.org> ---
What configure flags did you use? Only --target arm-eabi" ?
What does gcc --print-multi-lib say?

[Bug target/114143] Non-thumb arm32 code in thumb multilib for libgcc and in -mthumb build

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw <rearnsha at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2024-02-28
             Status|UNCONFIRMED                 |WAITING
     Ever confirmed|0                           |1

--- Comment #2 from Richard Earnshaw <rearnsha at gcc dot gnu.org> ---
You probably haven't built the correct multilibs.  See Christophe's comments

[Bug target/114143] Non-thumb arm32 code in thumb multilib for libgcc and in -mthumb build

[hp at gcc dot gnu.org]

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

Hans-Peter Nilsson <hp at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW

--- Comment #3 from Hans-Peter Nilsson <hp at gcc dot gnu.org> ---
(In reply to Christophe Lyon from comment #1)
> What configure flags did you use? Only --target arm-eabi" ?

The exact configure options that were used are (besides --prefix):
--target=arm-eabi --with-gnu-ld --with-gnu-as --with-newlib
--enable-languages=c,c++,lto --enable-checking=release

This particular gcc version was trunk: r14-9089-gb4c88cc717e5
It was built together with newlib as of git 4e77fa9b8bf4 (about 2024-02-13)
Binutils as of about 2024-02-21.  Also seen with binutils-2.42, gcc-13.2.0,
newlib-4.4.0.20231231 so I doubt the exact versions are key.

> What does gcc --print-multi-lib say?

.;
thumb;@mthumb
arm/autofp/v5te/fpu;@marm@mfpu=auto@march=armv5te+fp@mfloat-abi=hard
thumb/autofp/v7/fpu;@mthumb@mfpu=auto@march=armv7+fp@mfloat-abi=hard

> You probably haven't built the correct multilibs.

If that suggestion boils down to incorrect configure options or make
invocation, for the latter:

$ make -j7
then much later
$ make install

If I can't build a whole-thumb binary then why include the thumb multilibs
there at all?

If certain --with-* options are a requirement for that, IMO this should at
least be documented.

[Bug target/114143] Non-thumb arm32 code in thumb multilib for libgcc and in -mthumb build

[rearnsha at gcc dot gnu.org]

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

--- Comment #4 from Richard Earnshaw <rearnsha at gcc dot gnu.org> ---
You're going to need --with-multilib=aprofile,rmprofile if you want the full
set of multilibs.  But beware it builds a *lot* of them.

We don't enable this by default because it conflicts with --with-arch,
--with-cpu and --with-float configure options.  Describing how to pick the
right multilib when there are so many to chose from is just too complex to
describe when the base architecture isn't nailed down.

[Bug target/114143] Non-thumb arm32 code in thumb multilib for libgcc and in -mthumb build

[rearnsha at gcc dot gnu.org]

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

--- Comment #5 from Richard Earnshaw <rearnsha at gcc dot gnu.org> ---
(In reply to Richard Earnshaw from comment #4)
> You're going to need --with-multilib=aprofile,rmprofile if you want the full
> set of multilibs.  But beware it builds a *lot* of them.

Sorry, I mean --with-multilib-list, not --with-multilib.  To make things worse,
configure will silently ignore options it does not recognize.

[Bug target/114143] Non-thumb arm32 code in thumb multilib for libgcc and in -mthumb build

[hp at gcc dot gnu.org]

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

--- Comment #6 from Hans-Peter Nilsson <hp at gcc dot gnu.org> ---
Can --with-multilib-list=aprofile,rmprofile at least be made the default when
no colliding --with-* options are specified?

Would that blow up "everyone"'s CI due to the extra build time?
If so, perhaps then just for release builds?
Or do you suggest another solution?  (I hope we agree that there *is* a
problem.)