Date: Wed, 25 May 2011 16:42:48 +0300 From: Andriy Gapon <avg@FreeBSD.org> To: Ruslan Ermilov <ru@FreeBSD.org> Cc: Dimitry Andric <dim@FreeBSD.org>, current@FreeBSD.org, Arnaud Lacombe <lacombar@gmail.com> Subject: Re: [PATCH] Fix CFLAGS overwrite by Makefile Message-ID: <4DDD0758.2050007@FreeBSD.org> In-Reply-To: <20110525122501.GA68680@lo0.su> References: <1306267772-31084-1-git-send-email-lacombar@gmail.com> <4DDC17E5.2020700@FreeBSD.org> <BANLkTimtbH5KP0=X2EWteUYy8Ht31qHY=g@mail.gmail.com> <BANLkTin_4GpcMUtYRrLQ%2BVSNM-b8od=mLA@mail.gmail.com> <20110525122501.GA68680@lo0.su>
next in thread | previous in thread | raw e-mail | index | archive | help
on 25/05/2011 15:25 Ruslan Ermilov said the following:
> On Tue, May 24, 2011 at 11:08:52PM -0400, Arnaud Lacombe wrote:
>> Hi,
>>
>> On Tue, May 24, 2011 at 10:54 PM, Arnaud Lacombe <lacombar@gmail.com> wrote:
>>> ps: for static library and loader, I derived the total size as the sum
>>> of the size of the text/data/bss section of the member object using :
>>>
>>> size *.o | awk 'BEGIN {text=0; data=0; bss=0;}; {text+=$1; data+=$2;
>>> bss+=$3}; END {print text " " data " " bss " '$i'"}'
>>>
>>> where $i is the cpu type to test. make(1) is passed either CPUTYPE=$i
>>> for i in i[3456]86, or the empty string. The compiler used for the
>>> test is gcc, and it is the compiler build during a buildworld stage,
>>> in the tmp directory.
>>>
>> just to cut loose any question about my environment, additionally to
>> the original patch, I made the following modification to the tree to
>> try to isolate it from the host:
>> - applied the following patch:
>
> [...]
>
>> - manually created two symlinks:
>> 1) include/machine -> ../sys/i386/include/
>> 2) include/x86 -> ../sys/x86/include/
>>
>> The host is running a custom 8.2-STABLE/amd64 kernel (only config
>> change) on the following CPU:
>>
>> CPU: Intel(R) Xeon(R) CPU X3430 @ 2.40GHz (2394.00-MHz K8-class CPU)
>> Origin = "GenuineIntel" Id = 0x106e5 Family = 6 Model = 1e Stepping = 5
>> Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
>> Features2=0x98e3fd<SSE3,DTES64,MON,DS_CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT>
>> AMD Features=0x28100800<SYSCALL,NX,RDTSCP,LM>
>> AMD Features2=0x1<LAHF>
>> TSC: P-state invariant
>>
>> I am still not sure what is the default gcc target architecture on this machine.
Default target architecture should not depend on current machine.
It is in gcc manual page:
generic
Produce code optimized for the most common IA32/AMD64/EM64T
processors. If you know the CPU on which your code will run,
then you should use the corresponding -mtune option instead of
-mtune=generic. But, if you do not know exactly what CPU users
of your application will have, then you should use this option.
As new processors are deployed in the marketplace, the behavior
of this option will change. Therefore, if you upgrade to a
newer version of GCC, the code generated option will change to
reflect the processors that were most common when that version
of GCC was released.
There is no -march=generic option because -march indicates the
instruction set the compiler can use, and there is no generic
instruction set applicable to all processors. In contrast,
-mtune indicates the processor (or, in this case, collection of
processors) for which the code is optimized.
...
i686
Same as "generic", but when used as "march" option, PentiumPro
instruction set will be used, so the code will run on all i686
family chips.
> Why not go along a supported way, and do a cross-build?
There is nothing wrong about the day he does it.
And a classic cross-build won't help with setting i586 or lower that he needs:
i586, pentium
Intel Pentium CPU with no MMX support.
Just my 2 cents.
--
Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4DDD0758.2050007>