This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Remove ioperm etc. support for arm


* Phil Blundell:

>>  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?

Yes, it does.

> 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?

The SHLIB_COMPAT check returns false for static builds, so nothing ends
up in libc.a after this change.

The weak/strong alias difference is not supposed to matter for dynamic
linking.  (glibc used to be buggy, and there is the LD_DYNAMIC_WEAK
override to get the old behavior, but I haven't heard of anyone using
it.)  It's also hard to get the dynamic linker to search beyond
libc.so.6 in a different DSO because libc.so.6 obviously does not have a
DT_NEEDED dependency on some application-provided DSO.

>>  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.

Thanks.

Florian


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]