This is the mail archive of the 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]

[Bug libc/21053] New: [SH] Namespace pollution from sys/ucontext.h

            Bug ID: 21053
           Summary: [SH] Namespace pollution from sys/ucontext.h
           Product: glibc
           Version: unspecified
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: libc
          Assignee: unassigned at sourceware dot org
          Reporter: glaubitz at physik dot
                CC: aurelien at aurel32 dot net, bugdal at aerifal dot cx,
                    drepper.fsp at gmail dot com, jrtc27 at jrtc27 dot com,
                    kkojima at rr dot, olegendo at gcc dot,
                    plugwash at p10link dot net,
                    sourceware-bugzilla at mkarcher dot,
                    ysato at users dot
  Target Milestone: ---
            Target: sh*-*-*


I recently started fixing Firefox on all of Debian's ports architectures. On
sh4 (SuperH), I ran into a problem with conflicting definitions of R0/R1:

/usr/bin/g++ -std=gnu++11 -o Unified_cpp_js_src11.o -c 
-I/<<PKGBUILDDIR>>/build-browser/dist/system_wrappers -include
/<<PKGBUILDDIR>>/config/gcc_hidden.h -DNDEBUG=1 -DTRIMMED=1 -DENABLE_S
'-DDLL_SUFFIX=".so"' -I/<<PKGBUILDDIR>>/js/src
-I/<<PKGBUILDDIR>>/build-browser/js/src  -I/<<PKGBUILDDIR>>/build-brow
ser/dist/include  -I/usr/include/nspr        -fPIC  -DMOZILLA_CLIENT -include
/<<PKGBUILDDIR>>/build-browser/js/src/js-confdefs.h -MD -MP -MF
.deps/Unified_cpp_js_src11.o.pp -Wdate-time -D_
FORTIFY_SOURCE=2 -Wall -Wc++11-compat -Wempty-body -Wignored-qualifiers
-Woverloaded-virtual -Wpointer-arith -Wsign-compare -Wtype-limits
-Wunreachable-code -Wwrite-strings -Wc++14-compat -
Wno-invalid-offsetof -Wno-error=maybe-uninitialized
-Wno-error=deprecated-declarations -Wno-error=array-bounds
-specs=/usr/share/dpkg/pie-compile.specs -fstack-protector-strong -Wformat -We
rror=format-security -fno-schedule-insns2 -fno-delete-null-pointer-checks
-fno-rtti -ffunction-sections -fdata-sections -fno-exceptions -fno-math-errno
-pthread -pipe  -g -freorder-blocks -
O3 -fomit-frame-pointer  -Wno-shadow 
In file included from
/<<PKGBUILDDIR>>/js/src/jit/BaselineBailouts.cpp: In member function 'void*
/<<PKGBUILDDIR>>/js/src/jit/BaselineBailouts.cpp:371:16: warning: unused
variable 'priorOffset' [-Wunused-variable]
         size_t priorOffset = JitFrameLayout::Size() +
In file included from
                 from /usr/include/signal.h:326,
                 from /<<PKGBUILDDIR>>/js/src/jit/MIR.h:15,
                 from /<<PKGBUILDDIR>>/js/src/jit/AliasAnalysisShared.h:10,
                 from /<<PKGBUILDDIR>>/js/src/jit/AliasAnalysisShared.cpp:7,
/<<PKGBUILDDIR>>/js/src/jit/BaselineCacheIR.cpp: In member function 'bool
/<<PKGBUILDDIR>>/js/src/jit/BaselineCacheIR.cpp:827:55: error: reference to
'R0' is ambiguous
     masm.loadValue(BaseIndex(obj, scratch, TimesOne), R0);
/usr/include/sh4-linux-gnu/sys/ucontext.h:43:3: note: candidates are:
<anonymous enum> R0
   R0 = 0,

/<<PKGBUILDDIR>>/js/src/jit/BaselineCacheIR.cpp:827: confused by earlier
errors, bailing out
Preprocessed source stored into /tmp/ccuktZXb.out file, please attach this to
your bugreport.

As it turns out, Firefox has variables called R0/R1 in the global namespace
which conflict with the definitions that exist on Linux/SH in sys/ucontext.h in

After some research, we found out that this issue has existed in the past
before on arm*-*-* and it was addressed with a patch by Peter Green (CC'ed) to
rename the register definitions in sys/ucontext.h [1].

Would it be possible to make the same changes to sys/ucontext.h as well without
breaking anything? From reading the discussion in [1], it seems the only
possible breakage could happen in gdb. However, since gdb isn't officially
supporting SH at the moment anyway, we don't have to worry about this part.

There might be a few other packages could potentially break, but I would be
willing to fix all of them and send patches upstream although I don't expect
that there are many users like JIT implementations for sh4, for example. I know
that Apple's JavaScriptCore has sh4 support, but it was recently dropped
because it was unmaintained [2].


> [1]
> [2]

You are receiving this mail because:
You are on the CC list for the bug.

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