Re: Retpolines and CFI
On 01/22/2018 01:21 PM, Florian Weimer wrote: There is a different issue with the think itself. __x86_indirect_thunk_rax: .LFB2: .cfi_startproc call .LIND5 .LIND4: pause lfence jmp .LIND4 .LIND5: mov %rax, (%rsp) ret .cfi_endproc If a signal is delivered after the mov has executed, the unwinder will eventually unwind through the signal frame and hit __x86_indirect_thunk_rax. It does not treat it as a signal frame, so the return address of the stack is decremented by one, in an attempt to obtain a program counter value which is within the call instruction. However, in this scenario, the return address is actually the start of the function, and subtracting one moves the program counter out of the unwind region for that function. I think it is possible to fix the second case by hiding the the return address at the top of the stack, like this: __x86_indirect_thunk_rax: .LFB2: .cfi_startproc call.LIND5 .LIND4: pause lfence jmp .LIND4 .LIND5: .cfi_def_cfa_offset 16 mov %rax, (%rsp) ret .cfi_endproc The unwinder should then use the other return address, from the caller of the thunk routine. Thanks, Florian
GCC 7.3 Released
The GNU Compiler Collection version 7.3 has been released. GCC 7.3 is a bug-fix release from the GCC 7 branch containing important fixes for regressions and serious bugs in GCC 7.2 with more than 99 bugs fixed since the previous release. This release includes code generation options to mitigate Spectre Variant 2 (CVE 2017-5715) for the x86 and powerpc targets. This release is available from the FTP servers listed at: http://www.gnu.org/order/ftp.html Please do not contact me directly regarding questions or comments about this release. Instead, use the resources available from http://gcc.gnu.org. As always, a vast number of people contributed to this GCC release -- far too many to thank them individually!
GCC 7.4 Status report (2018-01-25)
Status == The GCC 7 branch is again open for regression and documentation fixes. Quality Data Priority # Change from last report --- --- P1 P2 164 + 2 P3 22 + 9 P4 154 + 1 P5 28 --- --- Total P1-P3 186 + 12 Total 368 + 13 Previous Report === https://gcc.gnu.org/ml/gcc/2017-12/msg00102.html
Re: GCC 7.3 Released
Hi I don't know how to unsubscribe to this. Thanks. Vik. On 25 Jan 2018 9:48 am, "Richard Biener" wrote: > > The GNU Compiler Collection version 7.3 has been released. > > GCC 7.3 is a bug-fix release from the GCC 7 branch > containing important fixes for regressions and serious bugs in > GCC 7.2 with more than 99 bugs fixed since the previous release. > > This release includes code generation options to mitigate > Spectre Variant 2 (CVE 2017-5715) for the x86 and powerpc targets. > > This release is available from the FTP servers listed at: > > http://www.gnu.org/order/ftp.html > > Please do not contact me directly regarding questions or comments > about this release. Instead, use the resources available from > http://gcc.gnu.org. > > As always, a vast number of people contributed to this GCC release > -- far too many to thank them individually! >
Re: extern const initialized warns in C
On 22.01.2018 16:20, Jonathan Wakely wrote: On 21 January 2018 at 12:08, Georg-Johann Lay wrote: Jay K schrieb: extern const int foo = 123; Why does this warn? This is a valid portable form, with the same meaning across all compilers, and, importantly, portably to C and C++. I also wondered about this. In C99 §6.9.2 "External object definitions" there's actually the following example in clause 4: extern int i3 = 3; // definition, external linkage That's a different case. There's no advantage to the 'extern' here, because the code means the same thing in C and C++ without the 'extern', so just leave it out. I'd rather like to know why GCC is throwing a warning here. It's clear how to hack the C source, but that's a different point. It's just the case that I don't see any problem with that construct, and it was worth an explicit example in the standard. Or is it common practice to warn constructs that are "no advantage"? Johann
Re: extern const initialized warns in C
On 25 January 2018 at 12:27, Georg-Johann Lay wrote: > On 22.01.2018 16:20, Jonathan Wakely wrote: >> >> On 21 January 2018 at 12:08, Georg-Johann Lay wrote: >>> >>> Jay K schrieb: extern const int foo = 123; Why does this warn? This is a valid portable form, with the same meaning across all compilers, and, importantly, portably to C and C++. >>> >>> >>> I also wondered about this. >>> >>> In C99 §6.9.2 "External object definitions" there's actually >>> the following example in clause 4: >>> >>> extern int i3 = 3; // definition, external linkage >> >> >> That's a different case. There's no advantage to the 'extern' here, >> because the code means the same thing in C and C++ without the >> 'extern', so just leave it out. > > > I'd rather like to know why GCC is throwing a warning here. > > It's clear how to hack the C source, but that's a different point. > > It's just the case that I don't see any problem with that construct, > and it was worth an explicit example in the standard. Or is it > common practice to warn constructs that are "no advantage"? Read https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45977 (as already stated earlier in the thread).
Re: extern const initialized warns in C
On 25 January 2018 at 12:29, Jonathan Wakely wrote: > On 25 January 2018 at 12:27, Georg-Johann Lay wrote: >> On 22.01.2018 16:20, Jonathan Wakely wrote: >>> >>> On 21 January 2018 at 12:08, Georg-Johann Lay wrote: Jay K schrieb: > > > extern const int foo = 123; > > Why does this warn? > This is a valid portable form, with the same meaning > across all compilers, and, importantly, portably > to C and C++. I also wondered about this. In C99 §6.9.2 "External object definitions" there's actually the following example in clause 4: extern int i3 = 3; // definition, external linkage >>> >>> >>> That's a different case. There's no advantage to the 'extern' here, >>> because the code means the same thing in C and C++ without the >>> 'extern', so just leave it out. >> >> >> I'd rather like to know why GCC is throwing a warning here. >> >> It's clear how to hack the C source, but that's a different point. >> >> It's just the case that I don't see any problem with that construct, >> and it was worth an explicit example in the standard. Or is it >> common practice to warn constructs that are "no advantage"? > > Read https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45977 (as already > stated earlier in the thread). Also, examples in the standard exist to show what is technically valid, not what is good coding style.
Re: GCC 7.3 Released
Read the SMTP headers of the email, or go to https://gcc.gnu.org/lists.html and follow the instructions there. On 25 January 2018 at 10:48, Vikrant Abbott wrote: > Hi > > I don't know how to unsubscribe to this. > > Thanks. > Vik. > > On 25 Jan 2018 9:48 am, "Richard Biener" wrote: > >> >> The GNU Compiler Collection version 7.3 has been released. >> >> GCC 7.3 is a bug-fix release from the GCC 7 branch >> containing important fixes for regressions and serious bugs in >> GCC 7.2 with more than 99 bugs fixed since the previous release. >> >> This release includes code generation options to mitigate >> Spectre Variant 2 (CVE 2017-5715) for the x86 and powerpc targets. >> >> This release is available from the FTP servers listed at: >> >> http://www.gnu.org/order/ftp.html >> >> Please do not contact me directly regarding questions or comments >> about this release. Instead, use the resources available from >> http://gcc.gnu.org. >> >> As always, a vast number of people contributed to this GCC release >> -- far too many to thank them individually! >>
Re: GCC 7.3 Released
Thank you! On 25 Jan 2018 1:16 pm, "Jonathan Wakely" wrote: > Read the SMTP headers of the email, or go to > https://gcc.gnu.org/lists.html and follow the instructions there. > > On 25 January 2018 at 10:48, Vikrant Abbott > wrote: > > Hi > > > > I don't know how to unsubscribe to this. > > > > Thanks. > > Vik. > > > > On 25 Jan 2018 9:48 am, "Richard Biener" wrote: > > > >> > >> The GNU Compiler Collection version 7.3 has been released. > >> > >> GCC 7.3 is a bug-fix release from the GCC 7 branch > >> containing important fixes for regressions and serious bugs in > >> GCC 7.2 with more than 99 bugs fixed since the previous release. > >> > >> This release includes code generation options to mitigate > >> Spectre Variant 2 (CVE 2017-5715) for the x86 and powerpc targets. > >> > >> This release is available from the FTP servers listed at: > >> > >> http://www.gnu.org/order/ftp.html > >> > >> Please do not contact me directly regarding questions or comments > >> about this release. Instead, use the resources available from > >> http://gcc.gnu.org. > >> > >> As always, a vast number of people contributed to this GCC release > >> -- far too many to thank them individually! > >> >
Re: Retpolines and CFI
On Mon, Jan 22, 2018 at 4:21 AM, Florian Weimer wrote:
> I tried this:
>
> struct C {
> virtual ~C();
> virtual void f();
> };
>
> void
> f (C *p)
> {
> p->f();
> p->f();
> }
>
> with r256939 and -mindirect-branch=thunk -O2 on x86-64 GNU/Linux, and got
> this:
>
> _Z1fP1C:
> .LFB0:
> .cfi_startproc
> pushq %rbx
> .cfi_def_cfa_offset 16
> .cfi_offset 3, -16
> movq(%rdi), %rax
> movq%rdi, %rbx
> jmp .LIND1
> .LIND0:
> pushq 16(%rax)
> jmp __x86_indirect_thunk
> .LIND1:
> call.LIND0
> movq(%rbx), %rax
> movq%rbx, %rdi
> popq%rbx
> .cfi_def_cfa_offset 8
> movq16(%rax), %rax
> jmp __x86_indirect_thunk_rax
> .cfi_endproc
>
> This doesn't look quite right. x86-64 is supposed to have asynchronous
> unwind tables by default, but there is nothing that reflects the change in
> the (relative) frame address after .LIND0. I think that region really has
> to be moved outside of the .cfi_startproc/.cfi_endproc bracket.
I'd like to remove __x86_indirect_thunk since it can't be made compatible
with CET:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83970
That means -mindirect-branch=thunk should imply -mindirect-branch-register.
When -fno-plt is used with __x86_indirect_thunk_reg, linker can convert call
via GOT to direct branch if function is locally defined:
https://groups.google.com/forum/#!topic/x86-64-abi/eED5lzn3_Mg
H.J.
Re: Retpolines and CFI
On Thu, Jan 25, 2018 at 12:32 AM, Florian Weimer wrote: > On 01/22/2018 01:21 PM, Florian Weimer wrote: > >> There is a different issue with the think itself. >> >> __x86_indirect_thunk_rax: >> .LFB2: >> .cfi_startproc >> call.LIND5 >> .LIND4: >> pause >> lfence >> jmp .LIND4 >> .LIND5: >> mov %rax, (%rsp) >> ret >> .cfi_endproc >> >> If a signal is delivered after the mov has executed, the unwinder will >> eventually unwind through the signal frame and hit __x86_indirect_thunk_rax. >> It does not treat it as a signal frame, so the return address of the stack >> is decremented by one, in an attempt to obtain a program counter value which >> is within the call instruction. However, in this scenario, the return >> address is actually the start of the function, and subtracting one moves the >> program counter out of the unwind region for that function. > > > I think it is possible to fix the second case by hiding the the return > address at the top of the stack, like this: > > __x86_indirect_thunk_rax: > .LFB2: > .cfi_startproc > call.LIND5 > .LIND4: > pause > lfence > jmp .LIND4 > .LIND5: > .cfi_def_cfa_offset 16 > mov %rax, (%rsp) > ret > .cfi_endproc > > The unwinder should then use the other return address, from the caller of > the thunk routine. Can you open a GCC bug to track it? Thanks. -- H.J.
Re: Retpolines and CFI
On 01/25/2018 02:38 PM, H.J. Lu wrote: On Thu, Jan 25, 2018 at 12:32 AM, Florian Weimer wrote: On 01/22/2018 01:21 PM, Florian Weimer wrote: There is a different issue with the think itself. __x86_indirect_thunk_rax: .LFB2: .cfi_startproc call.LIND5 .LIND4: pause lfence jmp .LIND4 .LIND5: mov %rax, (%rsp) ret .cfi_endproc If a signal is delivered after the mov has executed, the unwinder will eventually unwind through the signal frame and hit __x86_indirect_thunk_rax. It does not treat it as a signal frame, so the return address of the stack is decremented by one, in an attempt to obtain a program counter value which is within the call instruction. However, in this scenario, the return address is actually the start of the function, and subtracting one moves the program counter out of the unwind region for that function. I think it is possible to fix the second case by hiding the the return address at the top of the stack, like this: __x86_indirect_thunk_rax: .LFB2: .cfi_startproc call.LIND5 .LIND4: pause lfence jmp .LIND4 .LIND5: .cfi_def_cfa_offset 16 mov %rax, (%rsp) ret .cfi_endproc The unwinder should then use the other return address, from the caller of the thunk routine. Can you open a GCC bug to track it? Sure, I filed: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84039 As mentioned on the bug, we now have a reported of a potential kernel issue related to retpolines and unwinding, but it's not clear that the thunk routine is at fault (which would be supplied by the kernel anyway). Thanks, Florian
Re: Unstable build/host qsorts causing differing generated target code
Am 2018-01-12 um 19:45 schrieb Jeff Law: On 01/12/2018 11:26 AM, Cory Fields wrote: Quick disclaimer: I'm 100% new to GCC code and the dev process, so there are bound to be some faulty assumptions below. I recently worked on a build of gcc, x86_64-pc-linux-gnu -> x86_64-pc-linux-musl. In order to boost my confidence in musl, I decided that I'd like to ensure that 3 (and 4) stage bootstraps succeed and compare equal. I quickly ran into failed object comparisons at stage3. The issue, as it turned out, was that musl's qsort algorithm differs significantly from gcc's, though both (as far as I can tell) are perfectly legal. The c spec allows for different results in the cast of unstable arrays. THe key here is the results can differ if the comparison function is not stable. That's inherent in the qsort algorithms. But, if the comparison functions are fixed, then the implementation differences between the qsorts won't matter. Alexander Monokov has led an effort to identify cases where the comparison functions do not provide a stable ordering and to fix them. Some remain, but the majority have been addressed over the last year. His work also includes a qsort checking implementation to try and spot these problems as part of GCC's internal consistency checking mechanisms. His work is on the development trunk and will show up in the upcoming gcc-8 release. Coincidentally I just stumbled over the differences in assembler code for a gcc-6 powerpc-eabi cross-compiler running on Linux, Cygwin64 and Solaris. With some help from IRC I found the following 3 trunk revisions seem to be enough to greatly stabilize gcc-6 (and likely gcc-7) on these platforms: r250395: 2017-07-20 Alexander Monakov * lra-assigns.c (pseudo_compare_func): Fix comparison step based on non_spilled_static_chain_regno_p. r253207: 2017-09-26 Martin Jambor * tree-sra.c (compare_access_positions): Put integral types first, stabilize sorting of integral types, remove conditions putting non-full-precision integers last. (sort_and_splice_var_accesses): Disable scalarization if a non-integert would be represented by a non-full-precision integer. r256682: 2018-01-14 Cory Fields * tree-ssa-loop-im.c (sort_bbs_in_loop_postorder_cmp): Stabilize sort. * ira-color (allocno_hard_regs_compare): Likewise. All applied cleanly to the current gcc-6-branch. I'm unsure if it's worth backporting them to the branches, but since I already prepared the list... Franz
Re: GCC 7.3 Released
unsubscribe On Thu, Jan 25, 2018 at 4:41 AM, Richard Biener wrote: > > The GNU Compiler Collection version 7.3 has been released. > > GCC 7.3 is a bug-fix release from the GCC 7 branch > containing important fixes for regressions and serious bugs in > GCC 7.2 with more than 99 bugs fixed since the previous release. > > This release includes code generation options to mitigate > Spectre Variant 2 (CVE 2017-5715) for the x86 and powerpc targets. > > This release is available from the FTP servers listed at: > > http://www.gnu.org/order/ftp.html > > Please do not contact me directly regarding questions or comments > about this release. Instead, use the resources available from > http://gcc.gnu.org. > > As always, a vast number of people contributed to this GCC release > -- far too many to thank them individually! >
Re: GCC 7.3 Released
You've just sent that to hundreds of people who can't unsubscribe you. Read the SMTP headers of the email, or go to https://gcc.gnu.org/lists.html and follow the instructions there. On 25 January 2018 at 14:56, Jimmy Shen wrote: > unsubscribe > > On Thu, Jan 25, 2018 at 4:41 AM, Richard Biener wrote: > >> >> The GNU Compiler Collection version 7.3 has been released. >> >> GCC 7.3 is a bug-fix release from the GCC 7 branch >> containing important fixes for regressions and serious bugs in >> GCC 7.2 with more than 99 bugs fixed since the previous release. >> >> This release includes code generation options to mitigate >> Spectre Variant 2 (CVE 2017-5715) for the x86 and powerpc targets. >> >> This release is available from the FTP servers listed at: >> >> http://www.gnu.org/order/ftp.html >> >> Please do not contact me directly regarding questions or comments >> about this release. Instead, use the resources available from >> http://gcc.gnu.org. >> >> As always, a vast number of people contributed to this GCC release >> -- far too many to thank them individually! >>
Re: Retpolines and CFI
On 01/25/2018 06:38 AM, H.J. Lu wrote:
> On Mon, Jan 22, 2018 at 4:21 AM, Florian Weimer wrote:
>> I tried this:
>>
>> struct C {
>> virtual ~C();
>> virtual void f();
>> };
>>
>> void
>> f (C *p)
>> {
>> p->f();
>> p->f();
>> }
>>
>> with r256939 and -mindirect-branch=thunk -O2 on x86-64 GNU/Linux, and got
>> this:
>>
>> _Z1fP1C:
>> .LFB0:
>> .cfi_startproc
>> pushq %rbx
>> .cfi_def_cfa_offset 16
>> .cfi_offset 3, -16
>> movq(%rdi), %rax
>> movq%rdi, %rbx
>> jmp .LIND1
>> .LIND0:
>> pushq 16(%rax)
>> jmp __x86_indirect_thunk
>> .LIND1:
>> call.LIND0
>> movq(%rbx), %rax
>> movq%rbx, %rdi
>> popq%rbx
>> .cfi_def_cfa_offset 8
>> movq16(%rax), %rax
>> jmp __x86_indirect_thunk_rax
>> .cfi_endproc
>>
>> This doesn't look quite right. x86-64 is supposed to have asynchronous
>> unwind tables by default, but there is nothing that reflects the change in
>> the (relative) frame address after .LIND0. I think that region really has
>> to be moved outside of the .cfi_startproc/.cfi_endproc bracket.
>
> I'd like to remove __x86_indirect_thunk since it can't be made compatible
> with CET:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83970
User code should be built with CET, not retpolines. So I don't see
that removing x86_indirect_thunk is that important because we won't be
using them together.
jeff
Re: bugs in external debug info support in libbacktrace
On Mon, Nov 27, 2017 at 2:23 AM, Milian Wolff wrote:
>
> I was made aware that libbacktrace got support for external debug info with
> [1], great work! I have just synced the latest libbacktrace into heaptrack [2]
> in a local branch and played around with it and noticed two limitations:
>
> [1]: https://github.com/gcc-mirror/gcc/commit/
> b919941efc58035debbcf69b645c072b7dd6ba4e
> [2]: https://github.com/KDE/heaptrack
>
> a) elf_open_debugfile_by_debuglink checks the crc, even if it is not provided
> by the debug file. I.e. I have a file where `debuglink_crc == 0`, but the
> got_crc calculated from elf_crc32_file is non-zero. I have patched this
> locally with the following to make it work for me:
>
> diff --git a/libbacktrace/elf.c b/libbacktrace/elf.c
> index 06823fcf59b..24bf58728fd 100644
> --- a/libbacktrace/elf.c
> +++ b/libbacktrace/elf.c
> @@ -1005,7 +1005,7 @@ elf_open_debugfile_by_debuglink (struct backtrace_state
> *state,
>if (ddescriptor < 0)
> return -1;
>
> - got_crc = elf_crc32_file (state, ddescriptor, error_callback, data);
> + got_crc = debuglink_crc ? elf_crc32_file (state, ddescriptor,
> error_callback, data) : 0;
>if (got_crc != debuglink_crc)
> {
>backtrace_close (ddescriptor, error_callback, data);
Thanks. I fixed this problem with a slightly different patch,
appended. Committed to mainline.
> b) elf_add guards the code to inspect the symtab-shndx with a `&& !debuginfo`
> check in loc 2797. This results in all files with separate debug info yielding
> `found_sym = 0` when calling elf_add, and symbol resolution is broken.
> Personally I have patched this check out to make symbol resolution work for
> me:
>
> diff --git a/libbacktrace/elf.c b/libbacktrace/elf.c
> index 06823fcf59b..6876bd3ed8e 100644
> --- a/libbacktrace/elf.c
> +++ b/libbacktrace/elf.c
> @@ -2794,7 +2794,7 @@ elf_add (struct backtrace_state *state, const char
> *filename, int descriptor,
>
>if (symtab_shndx == 0)
> symtab_shndx = dynsym_shndx;
> - if (symtab_shndx != 0 && !debuginfo)
> + if (symtab_shndx != 0)
> {
>const b_elf_shdr *symtab_shdr;
>unsigned int strtab_shndx;
>
> Could you please check whether the two patches above could be upstreamed?
I don't think that's the right approach. In the appended patch I skip
clearing *found_sym if debuginfo is set. I hope that will fix the
problem.
Ian
2018-01-25 Ian Lance Taylor
* elf.c (elf_open_debugfile_by_debuglink): Don't check CRC if the
desired CRC is zero.
(elf_add): Don't clear *found_sym and *found_dwarf if debuginfo.
Index: elf.c
===
--- elf.c (revision 257038)
+++ elf.c (working copy)
@@ -997,7 +997,6 @@ elf_open_debugfile_by_debuglink (struct
void *data)
{
int ddescriptor;
- uint32_t got_crc;
ddescriptor = elf_find_debugfile_by_debuglink (state, filename,
debuglink_name,
@@ -1005,11 +1004,16 @@ elf_open_debugfile_by_debuglink (struct
if (ddescriptor < 0)
return -1;
- got_crc = elf_crc32_file (state, ddescriptor, error_callback, data);
- if (got_crc != debuglink_crc)
+ if (debuglink_crc != 0)
{
- backtrace_close (ddescriptor, error_callback, data);
- return -1;
+ uint32_t got_crc;
+
+ got_crc = elf_crc32_file (state, ddescriptor, error_callback, data);
+ if (got_crc != debuglink_crc)
+ {
+ backtrace_close (ddescriptor, error_callback, data);
+ return -1;
+ }
}
return ddescriptor;
@@ -2634,8 +2638,11 @@ elf_add (struct backtrace_state *state,
unsigned int using_debug_view;
uint16_t *zdebug_table;
- *found_sym = 0;
- *found_dwarf = 0;
+ if (!debuginfo)
+{
+ *found_sym = 0;
+ *found_dwarf = 0;
+}
shdrs_view_valid = 0;
names_view_valid = 0;
Cortex-r52 FP double precision
Hi, As I understand from this https://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html current master branch doesn't have support of double-precision FPv5 floating-point instructions for ARMv8-R (Cortex-r52). If yes, are there any chances to see them in GCC 8 ? Alex
gcc-7-20180125 is now available
Snapshot gcc-7-20180125 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/7-20180125/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 7 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-7-branch revision 257067 You'll find: gcc-7-20180125.tar.xzComplete GCC SHA256=f4cad0895aa6dd237cbcb6e81750e40c3fb3eba8a5bcdf25a21c4ee5520c344b SHA1=3b0c38bad58b57a69260916c4f10c40baf56a099 Diffs from 7-20180111 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-7 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: GCC 7.3 Released
Hi Richard Please let me know if you have any knowledge about compiler used to this project I had some info they use gnu compiler before the change name sincerley chris http://www.samsung.com/global/business/telecommunication-systems/resource/opensource/ip-set-top-box.html SMT-6010E SMT-6010E_OpenSource.zip info from inside procesor bsp-15 mapca mapca1000a equator /pixelworks/hitachi japan VLIW ### ### Equator Technologies, Inc. ### ### ### Module name : $RCSfile: Makefile.ETI,v $ $Revision: 1.2 $ ### ### Last update : $Date: 2005/06/16 13:46:21 $ UTC ### # # Default Settings ETI_INSTALL := $(HOME)/build/eti_tools/v6.0/install ETI_TOOLKIT := $(HOME)/build/eti_tools/v6.0/install ETI_REFERENCE_INSTALL := $(HOME)/build/eti_tools/v6.0/install WORKSPACE := $(shell pwd) export HOST_ARCH := i686 export HOST_PLATFORM := Linux ARCH := BSP PLATFORM := Linux ### # Configurations # (see arch/bsp/configs/README) # Default Configuration # e.g. Dolphin #ETI_CONFIGURATION := PCIMASTER_NORD # e.g. Stingray #ETI_CONFIGURATION := NOPCIMASTER_NORD # e.g. Dolphin/Tetra with tinykernel #By Changlae Jo # We will use Ramdisk ETI_CONFIGURATION := PCIMASTER_RD # e.g. Starfish #ETI_CONFIGURATION := STARFISH_NORD PCIMASTER_NORD_VMLINUX:= vmlinux.out vmlinux.l2sei vmlinux.flashsei NOPCIMASTER_NORD_VMLINUX := vmlinux.out vmlinux.l2sei PCIMASTER_RD_VMLINUX := vmlinux.l2sei vmlinux.flashsei STARFISH_NORD_VMLINUX := vmlinux.out vmlinux.l2sei DOT_CONFIG := $(ETI_CONFIGURATION)_.config AUTOCONF_H := $(ETI_CONFIGURATION)_autoconf.h VMLINUX:= $($(ETI_CONFIGURATION)_VMLINUX) # Modules for rootfilesystem # By Changlae Jo. #TINYROOTFS_ETI_MODULES := \ # $(ETI_REFERENCE_INSTALL)/BSP_Linux/tinyrootfs/lib/modules/2.2.20/boardSupportDev.o \ # $(ETI_REFERENCE_INSTALL)/BSP_Linux/tinyrootfs/lib/modules/2.2.20/noncoregpDev.o \ # $(ETI_REFERENCE_INSTALL)/BSP_Linux/tinyrootfs/lib/modules/2.2.20/flash.o #TINYROOTFS_LINUX_MODULES := \ # $(ETI_REFERENCE_INSTALL)/BSP_Linux/tinyrootfs/lib/modules/2.2.20/fat.o \ # $(ETI_REFERENCE_INSTALL)/BSP_Linux/tinyrootfs/lib/modules/2.2.20/vfat.o \ # $(ETI_REFERENCE_INSTALL)/BSP_Linux/tinyrootfs/lib/modules/2.2.20/msdos.o # Dependencies .PHONY : check tinyrootfs_prep configure build install install.headers clean ifeq ($(ETI_CONFIGURATION),PCIMASTER_NORD) all : check configure install.headers build.modules build install.modules install post.install else # Do not install headers for non-PCI master builds. all : check configure build install endif # Prepare tinyrootfs. Copy necessary file to it ifeq ($(ETI_CONFIGURATION),PCIMASTER_RD) build: tinyrootfs_prep tinyrootfs_prep : $(TINYROOTFS_ETI_MODULES) $(TINYROOTFS_LINUX_MODULES) $(TINYROOTFS_LINUX_MODULES) : build.modules endif ifdef ETIQADEPS configure : check install.headers: configure build.modules : configure build : configure install.modules: build.modules install: build endif # Verbosity, debug etc. ifeq ($(VERBOSEBUILD),) .SILENT : endif ## # Exports BSP_Linux_CC := $(ETI_TOOLKIT)/$(HOST_ARCH)_$(HOST_PLATFORM)/bin/ecc export CC := $($(ARCH)_$(PLATFORM)_CC) -D__KERNEL__ export LD := `$(CC) -print-prog-name=ld` export NM := `$(CC) -print-prog-name=nm` export AS := $(CC) export CPP := $(CC) -E # Root filesystem for tiny kernel gets picked up from here: ETI_REFERENCE_INSTALL = /h/qa/build/eti_tools/latest ### # Rules ## configure: ifdef ETIQABUILD $(MAKE) -f Makefile xconfig > /dev/null 2>&1 & sleep 5 cp $(WORKSPACE)/arch/bsp/configs/$(DOT_CONFIG) $(WORKSPACE)/.config cp $(WORKSPACE)/arch/bsp/configs/$(AUTOCONF_H) $(WORKSPACE)/include/linux/autoconf.h else # $(MAKE) -f Makefile xconfig # by Changlae Jo $(MAKE) -f Makefile menuconfig endif $(MAKE) -f Makefile dep build.modules: $(MAKE) -C $(WORKSPACE) -f Makefile modules build: $(MAKE) -C $(WORKSPACE) -f Makefile $(VMLINUX) ## install.headers: $(MAKE) -C $(WORKSPACE) -f Makefile $(WORKSPACE)/include/linux/modversions.h echo "Copying Linux header files" mkdir -p $(ETI_INSTALL)/BSP_Linux/include cd $(WORKSPACE)/include; /bin/tar --exclude CVS -czf - linux asm asm-bsp | \ (cd $(ETI_INSTALL)/BSP_Linux/include; /bin/tar -xzf -) install.modules: mkdir -p $(ETI_INSTALL)/BSP_Linux/rootfs; \ $(MAKE) -C $(WORKSPACE) -f Makefile \ INSTALL_MOD_PATH=$(ETI_INSTALL)/BSP_Linux/rootfs \ modules_install; \ rm -f $(ETI_INSTALL)/BSP_Linux/rootfs/lib/modules/2.2.20/build install: if [ ! -f $(WORKSPACE)/arch/bsp/boot/vmlinux.out ];then\ ln -s $(WORKSPACE)/vmlinux.out $(WORKSPACE)/arch/bsp/boot/vmlinux.out; \ fi mkdir -p $(ETI_INSTALL)/util/linux_kernel/$(ETI_CONFIGURATION) install -D -m 444 $(WORKSPACE)/arch/bsp/configs/README $(ETI_INSTALL)/
