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=1329194#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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

Not sure why I ended up as the primary recipient of the message, but
anyway ...

On Sun, 2017-01-15 at 13:21 +0100, John Paul Adrian Glaubitz wrote:

 
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?

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.  

Cheers,
Oleg

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 2017-01-16 at 13:44 +0100, John Paul Adrian Glaubitz wrote:

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

Oh, no worries then ;)

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.

I guess an "just do it the way it's being done on ARM" approach can't
be wrong ;)

Cheers,
Oleg

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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=21053

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)