Fix thumbv4t-none-eabi frame pointer setting

[Lokathor]

The thumb_base profile has changed since I last remember seeing it, and now it sets the frame pointer to "always keep", which is not desired for this target. Hooking a debugger to the running program is not really done, it's preferable to have the register available for actual program use, so the default "may omit" is now set.

I thought that the target was already using "may omit" when I checked on it last month, because I forgot that the target was previously based on thumb_base rather than Default::default(). I only noticed the issue just now when creating the armv4t-none-eabi target (#99226), though this PR is not in any way conditional on that one.

[rust-highfive]

r? @cjgillot

(rust-highfive has picked a reviewer for you, use r? to override)

[rust-highfive]

⚠️ Warning ⚠️

• These commits modify compiler targets. (See the Target Tier Policy.)

[Jinxit]

Just chiming in to say that I also use thumbv4t-none-eabi and this seems like a good change to me.

[davidtwco]

I'm a little surprised from the PR description that this doesn't just manually set the frame pointer to "may omit" which thumb_base gets wrong for this specific target, but instead decides not to use thumb_base at all.

[Lokathor]

Somehow that didn't even occur to me compared to "give me the real defaults".

[davidtwco]

I think I'd prefer to see it still use thumb_base and override the changed field, rather than this approach. Unless there's a reason why this specific target is likely to diverge from thumb_base more often than not. I'm not super familiar with what we normally do for target specifications though, so others may disagree.

[Lokathor]

I can set the field here, but either way I'd prefer to not use thumb_base. Then as the target maintainer i have to try and pay attention to changes to an additional thing. Also as a user a person would have to look in 3 places instead of just 2 to understand all the details.

[davidtwco]

That's understandable, but at the same time, if there is a change to thumb_base that would be applicable here then it could easily be missed. Ultimately, this is a trade-off that's inherent to how we define these target specs, and I'm not sure it makes sense to be inconsistent about inheriting from base specs on the basis of the preference of the target maintainer, but I don't feel strongly about this. I'd like to see what others think.

[davidtwco]

@bors r+

[bors]

📌 Commit 2eac6f3 has been approved by davidtwco

It is now in the queue for this repository.

[Lokathor]

As just one example, here's the previous output of a particular function where the only important line was bx r3, and all the push/add/pop stuff was just frame pointer manipulation

08000214 <gba2k::fc3_rust>:
 8000214:    b580          push    {r7, lr}
 8000216:    af00          add    r7, sp, #0
 8000218:    4718          bx    r3
 800021a:    bc80          pop    {r7}
 800021c:    bc01          pop    {r0}
 800021e:    4700          bx    r0

and then this is what it looks like with the updated target profile in today's nightly:

08000210 <gba2k::fc3_rust>:
 8000210:    4718          bx    r3
 8000212:    4770          bx    lr

I'd call that excellent results