This is the mail archive of the libc-help@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: glibc compiled with mcmodel=large


On Mon, Feb 20, 2012 at 10:27 AM, Carlos O'Donell
<carlos@systemhalted.org> wrote:
> On Mon, Feb 20, 2012 at 9:53 AM, Zeng Bin <ezengbin@gmail.com> wrote:
>> 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.
>
> I can confirm that in the past 10+ years of working on the project
> we've never talked about mcmodel=large.
>
> Therefore it was likely never written to support that option.
>
> You only compile glibc once (distros and tool vendors compile it many
> times for many options) for either 64-bit or 32-bit. The code doesn't
> compile both at the same time.
>
> Speaking for upstream, we'd be happy to support mcmodel=large, but
> you'd have to make a case for it and present the patches to enable it.
> That discussion would happen on libc-alpha@sourceware.org.
>
> Cheers,
> Carlos.

It is understandable that mcmodel=large is a rarely used feature and
few people need it. It would be nice to have it for some situations.
As the code sizes of large projects grow, people might need to more
frequently later.

The problem with this is that some 32-bit code can be linked to high
addresses (by high addresses, I mean larger than 0x80000000) because
32-bit symbols are not signed extended. When ported to 64-bit, they
are. So the address 0x80000000 would be signed extended to
0xffffffff80000000.

Thank you very much for the reply. I appreciate it a lot.


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