Ah, figured out the -mfdpic thing, [PATCH] included.

Rob Landley rob at landley.net
Sun Feb 13 20:22:52 UTC 2011


On 02/12/2011 12:01 AM, Khem Raj wrote:
> On (10/02/11 13:42), Rob Landley wrote:
>> I mentioned that my build was dying due to trying to use -mfdpic which
>> is a target-specific option for the FRV processor:
>>
>>   http://lists.uclibc.org/pipermail/uclibc/2011-January/044701.html
>>   https://bugs.busybox.net/show_bug.cgi?id=3193
>>
>> The problem is that uClibc has an utterly useless user-visible
>> "TARGET_HAS_MMU" as well as "TARGET_USE_MMU", and I took the first out
>> of miniconfig because I'd complained about the redundant option during
>> the dev cycle and thought it was gone.
> 
> hmmm yeah seems notion of using mmu and having mmu could be combined. 
> The case where chip has mmu but one still would like to not use it 
> can be deemed as
> 
> TARGET_HAS_MMU is not set

I don't see why the MMU choice and the floating point coprocessor choice
are significantly different at the design level.  We don't have separate
"has floating point" and "would like to use floating point" symbols.
>From the C library's point of view, it's a binary decision.

The kernel may need to know an FPU is there just so it can quiesce the
thing even if it's not adding extra register saves to each process
context switch.  But from the C library's point of view either the
kernel's giving it access to a working MMU, or it isn't.

> I dont see any particular use of knowing that I have mmu when I dont
> want to use it

I could just about imagine the kernel needing to do something to get the
MMU out of the way, so it needs to know it's there even when it's not
going to set up page tables.

But the kernel is not the C library.  From libc's point of view you
either have one or you don't.  Having two different user visible config
options for the same choice is strange and confusing.

Rob


More information about the uClibc mailing list