This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Remove ioperm etc. support for arm (was: Re: _ioperm support for Arm)
On Wed, May 29, 2019 at 04:53:46PM +0200, Florian Weimer wrote:
> So it looks like to me like a later architectue version.
Yes, right. build-many-glibcs.py seems to explicitly call out ARMv5TE and
later, and it also builds at least one library with gcc's default
architecture settings (which you get to choose at the point you build
the compiler, and I think the default defaults have also changed at
various points in the past). But there's no explicit selection of
anything older than ARMv5TE so I think we should assume it isn't getting
tested.
> I would welcome comments on the commit message. The patch itself has
> been “tested” with build-many-glibcs.py on all 32-bit Arm architectures.
The commit message looks fine to me, or at least I couldn't think of
anything better to write.
> void
> -_outb (unsigned char b, unsigned long int port)
> +outb (unsigned char b, unsigned long int port)
Does this cause symbols that were previously weak to become strong? If
so, is that ok? It would be a bit unfortunate if the act of deprecating
these functions caused them to suddenly start interposing something else,
or do symbol versions prevent that from happening?
> unsigned int
> -_inl (unsigned long int port)
> +inl (unsigned long int port)
> {
> - return *((volatile unsigned long *)(IO_ADDR (port)));
> + return 0;
> }
The outcome of calling inl() etc without a previous successful call to
ioperm() would have been SIGSEGV, so it would be ok to replace this
with *((volatile unsigned long *)0). But what you have is fine too.
p.