Re: glibc compiled with mcmodel=large

[Zeng Bin <ezengbin at gmail dot com>]

Thanks for the suggestion! Definitely, I can track down the bug with
-E and -save-temps. The question is whether glibc-2.14 which is the
latest release supports being compiled with -mcmodel=large? If it
does, there might be only a few bugs in it when compiled with ubuntu
system. If it does not (when it was designed, it was not taken into
careful consideration because few people would use this feature), it
might take too much efforts to fix all of them. It might save time and
even increase the performance by going the other direction and trying
hard to optimize the size of code so that no glibc compiled with
mcmodel=large is needed. For example,  in the following code snippet
from start.S from gcc-4.6.2:
      /* Pass address of our own entry points to .fini and .init.  */
        /* movq $__libc_csu_fini, %r8  by bzeng */
        movabs $__libc_csu_fini, %r8
        /* movq $__libc_csu_init, %rcx by bzeng */
        movabs $__libc_csu_init, %rcx

        /* movq $BP_SYM (main), %rdi */
        movabs $BP_SYM (main), %rdi

        /* Call the user's main function, and exit with its value.
           But let the libc call main.    */
        call BP_SYM (__libc_start_main)
The movq instruction needs to be replaced with movabs to support mcmodel=large.

Can anyone confirm that glibc was coded to support mcmodel=large? Is
there any configuration flag that I can use to compile only 64-bit
libraries instead of both 32-bit and 64-bit? Definitely, 32-bit
libraries do not need to support mcmodel=large due to the address
space restriction.

Thanks a lot again.

On Fri, Feb 17, 2012 at 5:43 PM, Carlos O'Donell
<carlos@systemhalted.org> wrote:
> On Fri, Feb 17, 2012 at 4:19 PM, Zeng Bin <ezengbin@gmail.com> wrote:
>> Hi all,
>>
>> I am really stumped on this problem. I have been trying to compile
>> glibc-2.14 with mcmodel=large on.
>>
>> glibc-2.14 is configured like this:
>> ../src/configure
>> --prefix=/home/bzeng/tools/glibc/glibc-2.14-git/install/
>> CFLAGS="-mcmodel=large -O2 -U_FORTIFY_SOURCE" -enable-add-ons
>> --without-selinux --disable-profile
>>
>> During the make, it reported this error:
>>
>> ../sysdeps/x86_64/multiarch/init-arch.c: In function ‘__init_cpu_features’:
>> ../sysdeps/x86_64/multiarch/init-arch.c:53:3: error: inconsistent
>> operand constraints in an ‘asm’
>> ../sysdeps/x86_64/multiarch/init-arch.c:32:3: error: inconsistent
>> operand constraints in an ‘asm’
>> ../sysdeps/x86_64/multiarch/init-arch.c:32:3: error: inconsistent
>> operand constraints in an ‘asm’
>> make[2]: *** [/home/bzeng/tools/glibc/glibc-2.14-git/build/csu/init-arch.os]
>> Error 1
>> make[2]: Leaving directory `/home/bzeng/tools/glibc/glibc-2.14-git/src/csu'
>> make[1]: *** [csu/subdir_lib] Error 2
>> make[1]: Leaving directory `/home/bzeng/tools/glibc/glibc-2.14-git/src'
>> make: *** [all] Error 2
>>
>> Did anyone compile glibc with -mcmodel=large on? Any suggestion would
>> be appreciated. Also, if there is a distro compiled with
>> -mcmodel=large, would you please point me ?to the right link?
>
> I don't know of any distro that builds with -mcmodel=large.
>
> Your best bet is to look at the pre-processed code by re-running the
> failed compile with -E and -save-temps.
>
> Remove the #line markers and recompile to get sensible line numbers on errors.
>
> Then with the sensible line numbers track down the offending assembly
> and try to understand why the compiler thinks it's wrong.
>
> You might genuinely be hitting a compiler bug.
>
> Cheers,
> Carlos.