Resolving glibc namespace conflicts with R0..Rn

Resolving glibc namespace conflicts with R0..Rn

[John Paul Adrian Glaubitz]

Hi!

We're currently running into a name conflict issue when building Firefox on sh4
with the R0..Rn register names. Apparently, there have been several packages which
were affected by this issue with the result that glibc upstream decided to resolve
this issue on ARM by renaming Rn to REG_Rn [1]. The discussion in the Firefox bugtracker
regarding the issue can be followed here [2].

Would it be possible to make this change in glibc on SH as well?

Apparently, the only big user which would suffer breakage would be gdb but since
there is currently not official SH support in gdb anyway, I think we're good
to go.

Adrian

> [1] https://sourceware.org/ml/libc-ports/2011-12/msg00032.html
> [2] https://bugzilla.mozilla.org/show_bug.cgi?id\x1329194#c15

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Resolving glibc namespace conflicts with R0..Rn

[John Paul Adrian Glaubitz]

Hi!

On 01/16/2017 01:42 PM, Oleg Endo wrote:
> Not sure why I ended up as the primary recipient of the message, but
> anyway ...

That's just by accident, I added SH people in no particular order :).

>> Would it be possible to make this change in glibc on SH as well?
> 
> I'm sorry, but I'm afraid I won't be much of a help here.  I haven't
> been involved in glibc at all and at the moment, I'm too busy with
> other things.  

No problem. I'm just trying to gather opinions on how to proceed
and if making the proposed change would cause any issues.

Thanks,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Resolving glibc namespace conflicts with R0..Rn

[Rich Felker]

On Sun, Jan 15, 2017 at 01:21:49PM +0100, John Paul Adrian Glaubitz wrote:
> Hi!
> 
> We're currently running into a name conflict issue when building Firefox on sh4
> with the R0..Rn register names. Apparently, there have been several packages which
> were affected by this issue with the result that glibc upstream decided to resolve
> this issue on ARM by renaming Rn to REG_Rn [1]. The discussion in the Firefox bugtracker
> regarding the issue can be followed here [2].
> 
> Would it be possible to make this change in glibc on SH as well?
> 
> Apparently, the only big user which would suffer breakage would be gdb but since
> there is currently not official SH support in gdb anyway, I think we're good
> to go.

I'm fine with this change. Apparently we don't have the plain Rn
macros on musl at all, perhaps for this very reason.

Of course what I'd like even better is to get rid of the REG_* macros
too except in the case where the application explicitly requests them.
A similar issue hit us recently for x86 due to g++ auto-defining
_GNU_SOURCE and subtle differences in how we defined the REG_* macros:

http://www.openwall.com/lists/musl/2017/01/03/7

Exposing junk like this made sense when you only got it by including
sys/ucontext.h, but not now that signal.h is expected to expose
ucontext_t. And unfortunately it's not just macros but types used in
the definition of ucontext_t that are namespace-polluting. So I don't
see any really good outs without breaking compatibility with stuff.
musl exposes opaque fake mcontext_t when _BSD_SOURCE and _GNU_SOURCE
are off, but in practice one or both is usually on...

Rich

Re: Resolving glibc namespace conflicts with R0..Rn

[John Paul Adrian Glaubitz]

On 01/16/2017 03:36 PM, Rich Felker wrote:
>> Apparently, the only big user which would suffer breakage would be gdb but since
>> there is currently not official SH support in gdb anyway, I think we're good
>> to go.
> 
> I'm fine with this change. Apparently we don't have the plain Rn
> macros on musl at all, perhaps for this very reason.

Ok, great. I have already opened a bug report for that:

> https://sourceware.org/bugzilla/show_bug.cgi?id!053

I can build a package with the registers renamed to test it.

> Of course what I'd like even better is to get rid of the REG_* macros
> too except in the case where the application explicitly requests them.
> A similar issue hit us recently for x86 due to g++ auto-defining
> _GNU_SOURCE and subtle differences in how we defined the REG_* macros:
> 
> http://www.openwall.com/lists/musl/2017/01/03/7
> 
> Exposing junk like this made sense when you only got it by including
> sys/ucontext.h, but not now that signal.h is expected to expose
> ucontext_t. And unfortunately it's not just macros but types used in
> the definition of ucontext_t that are namespace-polluting. So I don't
> see any really good outs without breaking compatibility with stuff.
> musl exposes opaque fake mcontext_t when _BSD_SOURCE and _GNU_SOURCE
> are off, but in practice one or both is usually on...

I agree. But I guess that would require a more involved discussion :).

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913