[PATCH v2] libgloss: Resolve compilation errors for mips.
Jeff Johnston
jjohnstn@redhat.com
Wed Feb 19 20:29:12 GMT 2025
I have modified the patch and will merge. See below for comments about
suggested changes from Corinna. I also
implemented one of Mike's comments regarding ptrdiff_t which wasn't
implemented in the new patch. I don't have
a mips toolset to test with so if there are any build issues, just let me
know and we'll fix them.
-- Jeff J
On Wed, Feb 19, 2025 at 2:18 AM Roger Sayle <roger@nextmovesoftware.com>
wrote:
>
> > On Feb 18 14:06, Roger Sayle wrote:
> > > As requested here's the same patch as generated by "git format-patch
> -1 HEAD"
> > > instead of the previous "git diff" format patch. p.s. either format
> > > can be applied to a clean source tree using the command "patch -p1 <
> > filename.patch".
> >
> > I'm aware of that, but newlib-cygwin is a git repo since 2016.
> > Not using git-formatted patches moves the onus for correct author
> information as
> > well as correct content of the commit message from the author to the
> commiter.
> > So I hope it's ok to request git-formated patches. A detailed commit
> message
> > doesn't hurt either.
>
> GCC maintainers still use (prefer?) "git diff" and CVS-style commit
> messages.
> The mips-elf parts of GCC (and binutils) compile, the mips-elf parts of
> newlib don't.
>
> > > --- a/libgloss/mips/cfe_mem.c
> > > +++ b/libgloss/mips/cfe_mem.c
> > > @@ -47,7 +47,7 @@ void *get_mem_info (struct s_mem *); extern char
> > > _end[];
> > >
> > > /* Address immediately after available memory. */ -static unsigned
> > > long memtop;
> > > +static void *memtop;
> > >
> > > /* Program stack size. */
> > > static unsigned long stack_size;
> >
> > Shouldn't this be changed to size_t?
>
> Wouldn't this change/break the ABI when size_t isn't a 32-bit unsigned
> long?
>
Yes, but I believe it should be unsigned long looking at the type headers.
The stack_size is used in calculations of
the s_mem struct size field which is declared as unsigned int. I think for
the time-being this
can be left as-is.
> > > @@ -107,7 +107,7 @@ __libcfe_meminit (void)
> > > /* Chop the top of memory to a 32-byte aligned location, and
> > > round the stack size up to a 32-byte multiple. */
> > > - memtop = memtop & ~(unsigned long)31;
> > > + memtop = (void*)((unsigned long)memtop & ~(unsigned long)31);
> >
> > Shouldn't unsigned long be changed to uintptr_t here, too?
>
Changed to uintptr_t.
Likewise.
> >
> > > stack_size = (stack_size + 31) & ~(unsigned long)31;
> >
> > And size_t here?
> Likewise.
>
>
Leaving as-is due to the s_mem struct.
> The goal is not to change the code's behavior (even to fix bugs) or make
> this code more portable. But purely to allow it to build with a post K&R
> compiler, and by restoring libgloss, allow GCC cross-compilers for
> mips-elf
> to be built/tested. Without access to the affected hardware, I'm hesitant
> to make changes that I can't test. Hence as the current libcfe API
> returns
> an unsigned long, I continue to do the same with my patch.
> Please feel free to submit your own follow-up patches.
>
> If the code wasn't already so badly broken that it doesn't compile
> I/someone wouldn't have to fix it. I've already left it over a year
> since originally submitting this patch to see if a newlib maintainer
> would attempt a fix using uintptr_t or size_t themselves.
> Please, please feel free to fix this yourselves.
>
> I'm happy to ping again next year.
> Many thanks in advance,
> Roger
> --
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://sourceware.org/pipermail/newlib/attachments/20250219/57cc9bbc/attachment.htm>
More information about the Newlib
mailing list