mbox series

[0/4] lm32: varargs patches

Message ID 20250113202607.3288177-1-keithp@keithp.com
Headers
Series lm32: varargs patches |

Message

Keith Packard Jan. 13, 2025, 8:08 p.m. UTC 
  In doing picolibc testing for lm32, I discovered that varargs handling
had an issue when the set of anonymous arguments spanned register
arguments and stack arguments.

On lm32, FIRST_PARM_OFFSET is '4', meaning there are four bytes
between the stack top and the first non-register parameter. When a
varargs function runs, the anonymous parameters in registers get
pushed to the stack below this gap. To process the args, this gap
needs to be skipped at the right time.

This series converts va_list into a struct to add a pointer to the gap
and code is added to va_arg to see when an argument spans the gap.

While developing this series, I identified a few other related issues
which affected this change by comparing the lm32 code to arc, which
has a similar implementation for saving the register parameters. Those
changes are first in the series with the gap skipping code provided in
the final patch.

Comments

Jeffrey Law Jan. 15, 2025, 5:27 a.m. UTC | #1 
On 1/13/25 1:08 PM, Keith Packard wrote:
> 
> In doing picolibc testing for lm32, I discovered that varargs handling
> had an issue when the set of anonymous arguments spanned register
> arguments and stack arguments.
> 
> On lm32, FIRST_PARM_OFFSET is '4', meaning there are four bytes
> between the stack top and the first non-register parameter. When a
> varargs function runs, the anonymous parameters in registers get
> pushed to the stack below this gap. To process the args, this gap
> needs to be skipped at the right time.
> 
> This series converts va_list into a struct to add a pointer to the gap
> and code is added to va_arg to see when an argument spans the gap.
> 
> While developing this series, I identified a few other related issues
> which affected this change by comparing the lm32 code to arc, which
> has a similar implementation for saving the register parameters. Those
> changes are first in the series with the gap skipping code provided in
> the final patch.
Just a couple notes.

lm32 is currently scheduled to be deprecated as it hasn't been converted 
to use LRA instead of reload.  Deprecation would happen with the gcc-15 
release and removal in gcc-16 if nobody steps forward to do the conversion.

The last real change to the lm32 port that wasn't stuff like copyright 
dates, or other system-wide adjustments was back in 2018, a trivial fix 
from me.  Prior to that 2014.  Point being I think it's unlikely anyone 
will step forward to fix this port.

Second, we're in regression bugfixing mode only right now.  Essentially 
all changes should be fixing regressions against prior releases.  But 
given the nature of this change and its narrow potential impact in terms 
of getting the release made, I'll go ahead and push it through.

Thanks,
jeff
Keith Packard Jan. 15, 2025, 6:14 a.m. UTC | #2 
> lm32 is currently scheduled to be deprecated as it hasn't been converted 
> to use LRA instead of reload.  Deprecation would happen with the gcc-15 
> release and removal in gcc-16 if nobody steps forward to do the
> conversion.

I kinda wondered. Frankly, I treated this adventure as a way to learn
more about GCC internals and do a 'real' patch. I have no practical use
for LatticeMico32 myself. But, I'm happy to have the fix integrated and
provide yet another (even if temporary) target for picolibc testing.

Don't treat this as any kind of vote for continued support; I'll be just
as happy to see gcc's code base be reduced by one not-terribly-relevant
architecture. Deleting code is one of the purest pleasures in software
development.
Jeffrey Law Jan. 16, 2025, 5 a.m. UTC | #3 
On 1/14/25 11:14 PM, Keith Packard wrote:
> 
>> lm32 is currently scheduled to be deprecated as it hasn't been converted
>> to use LRA instead of reload.  Deprecation would happen with the gcc-15
>> release and removal in gcc-16 if nobody steps forward to do the
>> conversion.
> 
> I kinda wondered. Frankly, I treated this adventure as a way to learn
> more about GCC internals and do a 'real' patch. I have no practical use
> for LatticeMico32 myself. But, I'm happy to have the fix integrated and
> provide yet another (even if temporary) target for picolibc testing.
Sounds good.  I did something similar with a partial LLVM port for the 
v850 chip series.  Never pushed it far enough to integrate as the whole 
point was to get a better working knowledge of LLVM backend/target 
interfaces.


> 
> Don't treat this as any kind of vote for continued support; I'll be just
> as happy to see gcc's code base be reduced by one not-terribly-relevant
> architecture. Deleting code is one of the purest pleasures in software
> development.
Yea.  For it to be a vote for continued support someone would really 
need to step in to do that reload->LRA conversion as the plan of record 
is to rip out the old reload code completely.

Those conversions can sometimes be trivially easy and other times mind 
bending hard.  All the trivially easy ones have been done.  I wouldn't 
really expect lm32 to be tough, but surprises happen.  If you wanted to 
get a deeper understanding of how GCC works, that might be a way to do it.

Jeff


>