* [PATCH u-boot-marvell 01/39] ddr: marvell: axp: align signature of mv_xor_mem_init() with a38x
2021-03-07 4:24 [PATCH u-boot 00/39] U-Boot LTO (Sandbox + Some ARM boards) Marek Behún
@ 2021-03-07 4:25 ` Marek Behún
2021-03-08 6:50 ` Bin Meng
2021-03-07 4:25 ` [PATCH u-boot-marvell 02/39] ddr: marvell: axp: fix array types have different bounds warning Marek Behún
` (37 subsequent siblings)
38 siblings, 1 reply; 139+ messages in thread
From: Marek Behún @ 2021-03-07 4:25 UTC (permalink / raw)
To: u-boot
In arch/arm/mach-mvebu/dram.c we always include axp's xor.h for common
XOR definitions, regardless whether we compile for axp or a38x.
But the declaration of this function has a different signature in axp's
xor.h from the one used in a38x' implementation - one parameter is u64
instead of u32. This can result in wrong argument's being passed to that
function on a38x with no one the wiser.
I discovered this when building U-Boot for Turris Omnia with LTO. The
compiler complains about the different signatures being thrown into the
same linking process:
axp/xor.h:67:5: warning: type of ?mv_xor_mem_init? does not match
original declaration [-Wlto-type-mismatch]
67 | int mv_xor_mem_init(u32 chan, u32 start_ptr, u32 block_size,
| ^
a38x/xor.c:165:5: note: type mismatch in parameter 3
165 | int mv_xor_mem_init(u32 chan, u32 start_ptr, unsigned long long
| ^
a38x/xor.c:165:5: note: type ?long long unsigned int? should match
type ?u32?
Fix this by changing the type of the block_size argument in the axp's
implementation and header file to the one used in a38x (and upstream
mv-ddr-marvell).
Signed-off-by: Marek Beh?n <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
---
drivers/ddr/marvell/axp/xor.c | 4 ++--
drivers/ddr/marvell/axp/xor.h | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/ddr/marvell/axp/xor.c b/drivers/ddr/marvell/axp/xor.c
index 17bfe6a7bf..76aea96682 100644
--- a/drivers/ddr/marvell/axp/xor.c
+++ b/drivers/ddr/marvell/axp/xor.c
@@ -152,8 +152,8 @@ static int mv_xor_ctrl_set(u32 chan, u32 xor_ctrl)
return MV_OK;
}
-int mv_xor_mem_init(u32 chan, u32 start_ptr, u32 block_size, u32 init_val_high,
- u32 init_val_low)
+int mv_xor_mem_init(u32 chan, u32 start_ptr, unsigned long long block_size,
+ u32 init_val_high, u32 init_val_low)
{
u32 tmp;
diff --git a/drivers/ddr/marvell/axp/xor.h b/drivers/ddr/marvell/axp/xor.h
index 97d1056432..a7c6ae840c 100644
--- a/drivers/ddr/marvell/axp/xor.h
+++ b/drivers/ddr/marvell/axp/xor.h
@@ -64,7 +64,7 @@ int mv_xor_state_get(u32 chan);
void mv_sys_xor_init(MV_DRAM_INFO *dram_info);
void mv_sys_xor_finish(void);
int mv_xor_transfer(u32 chan, int xor_type, u32 xor_chain_ptr);
-int mv_xor_mem_init(u32 chan, u32 start_ptr, u32 block_size, u32 init_val_high,
- u32 init_val_low);
+int mv_xor_mem_init(u32 chan, u32 start_ptr, unsigned long long block_size,
+ u32 init_val_high, u32 init_val_low);
#endif /* __XOR_H */
--
2.26.2
^ permalink raw reply related [flat|nested] 139+ messages in thread* [PATCH u-boot-marvell 01/39] ddr: marvell: axp: align signature of mv_xor_mem_init() with a38x
2021-03-07 4:25 ` [PATCH u-boot-marvell 01/39] ddr: marvell: axp: align signature of mv_xor_mem_init() with a38x Marek Behún
@ 2021-03-08 6:50 ` Bin Meng
0 siblings, 0 replies; 139+ messages in thread
From: Bin Meng @ 2021-03-08 6:50 UTC (permalink / raw)
To: u-boot
On Sun, Mar 7, 2021 at 12:26 PM Marek Beh?n <marek.behun@nic.cz> wrote:
>
> In arch/arm/mach-mvebu/dram.c we always include axp's xor.h for common
> XOR definitions, regardless whether we compile for axp or a38x.
>
> But the declaration of this function has a different signature in axp's
> xor.h from the one used in a38x' implementation - one parameter is u64
> instead of u32. This can result in wrong argument's being passed to that
> function on a38x with no one the wiser.
>
> I discovered this when building U-Boot for Turris Omnia with LTO. The
> compiler complains about the different signatures being thrown into the
> same linking process:
>
> axp/xor.h:67:5: warning: type of ?mv_xor_mem_init? does not match
> original declaration [-Wlto-type-mismatch]
> 67 | int mv_xor_mem_init(u32 chan, u32 start_ptr, u32 block_size,
> | ^
> a38x/xor.c:165:5: note: type mismatch in parameter 3
> 165 | int mv_xor_mem_init(u32 chan, u32 start_ptr, unsigned long long
> | ^
> a38x/xor.c:165:5: note: type ?long long unsigned int? should match
> type ?u32?
>
> Fix this by changing the type of the block_size argument in the axp's
> implementation and header file to the one used in a38x (and upstream
> mv-ddr-marvell).
>
> Signed-off-by: Marek Beh?n <marek.behun@nic.cz>
> Reviewed-by: Stefan Roese <sr@denx.de>
> ---
> drivers/ddr/marvell/axp/xor.c | 4 ++--
> drivers/ddr/marvell/axp/xor.h | 4 ++--
> 2 files changed, 4 insertions(+), 4 deletions(-)
>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
^ permalink raw reply [flat|nested] 139+ messages in thread
* [PATCH u-boot-marvell 02/39] ddr: marvell: axp: fix array types have different bounds warning
2021-03-07 4:24 [PATCH u-boot 00/39] U-Boot LTO (Sandbox + Some ARM boards) Marek Behún
2021-03-07 4:25 ` [PATCH u-boot-marvell 01/39] ddr: marvell: axp: align signature of mv_xor_mem_init() with a38x Marek Behún
@ 2021-03-07 4:25 ` Marek Behún
2021-03-08 6:41 ` Stefan Roese
2021-03-08 6:50 ` Bin Meng
2021-03-07 4:25 ` [PATCH u-boot-dm 03/39] regmap: fix a serious pointer casting bug Marek Behún
` (36 subsequent siblings)
38 siblings, 2 replies; 139+ messages in thread
From: Marek Behún @ 2021-03-07 4:25 UTC (permalink / raw)
To: u-boot
The arrays `pbs_dq_mapping`, `div_ratio1to1` and `div_ratio2to1` have
different bounds declared in header files where these variables are also
defined from the ones declared in source files.
This causes the compiler to complain (when building with LTO):
ddr3_sdram.c:24:12: warning: type of ?pbs_dq_mapping? does not match
original declaration
[-Wlto-type-mismatch]
ddr3_patterns_64bit.h:911:5: note: array types have different bounds
ddr3_patterns_64bit.h:911:5: note: ?pbs_dq_mapping? was previously
declared here
ddr3_dfs.c:45:11: warning: type of ?div_ratio1to1? does not match
original declaration [-Wlto-type-mismatch]
ddr3_axp_vars.h:167:4: note: array types have different bounds
ddr3_axp_vars.h:167:4: note: ?div_ratio1to1? was previously declared
here
ddr3_dfs.c:46:11: warning: type of ?div_ratio2to1? does not match
original declaration [-Wlto-type-mismatch]
ddr3_axp_vars.h:196:4: note: array types have different bounds
ddr3_axp_vars.h:196:4: note: ?div_ratio2to1? was previously declared
here
CI managed to trigger this as an error when compiling with LTO for AXP.
Fix this by using values from the header files, which seem to be the
correct ones.
Signed-off-by: Marek Beh?n <marek.behun@nic.cz>
---
drivers/ddr/marvell/axp/ddr3_dfs.c | 4 ++--
drivers/ddr/marvell/axp/ddr3_sdram.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/ddr/marvell/axp/ddr3_dfs.c b/drivers/ddr/marvell/axp/ddr3_dfs.c
index b58c0fe01e..2a4596680b 100644
--- a/drivers/ddr/marvell/axp/ddr3_dfs.c
+++ b/drivers/ddr/marvell/axp/ddr3_dfs.c
@@ -42,8 +42,8 @@ extern u8 div_ratio[CLK_VCO][CLK_DDR];
extern void get_target_freq(u32 freq_mode, u32 *ddr_freq, u32 *hclk_ps);
#else
extern u16 odt_dynamic[ODT_OPT][MAX_CS];
-extern u8 div_ratio1to1[CLK_CPU][CLK_DDR];
-extern u8 div_ratio2to1[CLK_CPU][CLK_DDR];
+extern u8 div_ratio1to1[CLK_VCO][CLK_DDR];
+extern u8 div_ratio2to1[CLK_VCO][CLK_DDR];
#endif
extern u16 odt_static[ODT_OPT][MAX_CS];
diff --git a/drivers/ddr/marvell/axp/ddr3_sdram.c b/drivers/ddr/marvell/axp/ddr3_sdram.c
index 3a266c6de4..0b150b20f3 100644
--- a/drivers/ddr/marvell/axp/ddr3_sdram.c
+++ b/drivers/ddr/marvell/axp/ddr3_sdram.c
@@ -21,7 +21,7 @@ extern u32 pbs_pattern_32b[2][LEN_PBS_PATTERN];
#if defined(MV88F78X60)
extern u32 pbs_pattern_64b[2][LEN_PBS_PATTERN];
#endif
-extern u32 pbs_dq_mapping[PUP_NUM_64BIT][DQ_NUM];
+extern u32 pbs_dq_mapping[PUP_NUM_64BIT + 1][DQ_NUM];
#if defined(MV88F78X60) || defined(MV88F672X)
/* PBS locked dq (per pup) */
--
2.26.2
^ permalink raw reply related [flat|nested] 139+ messages in thread* [PATCH u-boot-marvell 02/39] ddr: marvell: axp: fix array types have different bounds warning
2021-03-07 4:25 ` [PATCH u-boot-marvell 02/39] ddr: marvell: axp: fix array types have different bounds warning Marek Behún
@ 2021-03-08 6:41 ` Stefan Roese
2021-03-08 6:45 ` Marek Behun
2021-03-08 6:46 ` Marek Behun
2021-03-08 6:50 ` Bin Meng
1 sibling, 2 replies; 139+ messages in thread
From: Stefan Roese @ 2021-03-08 6:41 UTC (permalink / raw)
To: u-boot
On 07.03.21 05:25, Marek Beh?n wrote:
> The arrays `pbs_dq_mapping`, `div_ratio1to1` and `div_ratio2to1` have
> different bounds declared in header files where these variables are also
> defined from the ones declared in source files.
>
> This causes the compiler to complain (when building with LTO):
> ddr3_sdram.c:24:12: warning: type of ?pbs_dq_mapping? does not match
> original declaration
> [-Wlto-type-mismatch]
> ddr3_patterns_64bit.h:911:5: note: array types have different bounds
> ddr3_patterns_64bit.h:911:5: note: ?pbs_dq_mapping? was previously
> declared here
>
> ddr3_dfs.c:45:11: warning: type of ?div_ratio1to1? does not match
> original declaration [-Wlto-type-mismatch]
> ddr3_axp_vars.h:167:4: note: array types have different bounds
> ddr3_axp_vars.h:167:4: note: ?div_ratio1to1? was previously declared
> here
>
> ddr3_dfs.c:46:11: warning: type of ?div_ratio2to1? does not match
> original declaration [-Wlto-type-mismatch]
> ddr3_axp_vars.h:196:4: note: array types have different bounds
> ddr3_axp_vars.h:196:4: note: ?div_ratio2to1? was previously declared
> here
>
> CI managed to trigger this as an error when compiling with LTO for AXP.
>
> Fix this by using values from the header files, which seem to be the
> correct ones.
>
> Signed-off-by: Marek Beh?n <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
Thanks,
Stefan
> ---
> drivers/ddr/marvell/axp/ddr3_dfs.c | 4 ++--
> drivers/ddr/marvell/axp/ddr3_sdram.c | 2 +-
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/ddr/marvell/axp/ddr3_dfs.c b/drivers/ddr/marvell/axp/ddr3_dfs.c
> index b58c0fe01e..2a4596680b 100644
> --- a/drivers/ddr/marvell/axp/ddr3_dfs.c
> +++ b/drivers/ddr/marvell/axp/ddr3_dfs.c
> @@ -42,8 +42,8 @@ extern u8 div_ratio[CLK_VCO][CLK_DDR];
> extern void get_target_freq(u32 freq_mode, u32 *ddr_freq, u32 *hclk_ps);
> #else
> extern u16 odt_dynamic[ODT_OPT][MAX_CS];
> -extern u8 div_ratio1to1[CLK_CPU][CLK_DDR];
> -extern u8 div_ratio2to1[CLK_CPU][CLK_DDR];
> +extern u8 div_ratio1to1[CLK_VCO][CLK_DDR];
> +extern u8 div_ratio2to1[CLK_VCO][CLK_DDR];
> #endif
> extern u16 odt_static[ODT_OPT][MAX_CS];
>
> diff --git a/drivers/ddr/marvell/axp/ddr3_sdram.c b/drivers/ddr/marvell/axp/ddr3_sdram.c
> index 3a266c6de4..0b150b20f3 100644
> --- a/drivers/ddr/marvell/axp/ddr3_sdram.c
> +++ b/drivers/ddr/marvell/axp/ddr3_sdram.c
> @@ -21,7 +21,7 @@ extern u32 pbs_pattern_32b[2][LEN_PBS_PATTERN];
> #if defined(MV88F78X60)
> extern u32 pbs_pattern_64b[2][LEN_PBS_PATTERN];
> #endif
> -extern u32 pbs_dq_mapping[PUP_NUM_64BIT][DQ_NUM];
> +extern u32 pbs_dq_mapping[PUP_NUM_64BIT + 1][DQ_NUM];
>
> #if defined(MV88F78X60) || defined(MV88F672X)
> /* PBS locked dq (per pup) */
>
Viele Gr??e,
Stefan
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: sr at denx.de
^ permalink raw reply [flat|nested] 139+ messages in thread
* [PATCH u-boot-marvell 02/39] ddr: marvell: axp: fix array types have different bounds warning
2021-03-08 6:41 ` Stefan Roese
@ 2021-03-08 6:45 ` Marek Behun
2021-03-08 6:50 ` Stefan Roese
2021-03-08 6:46 ` Marek Behun
1 sibling, 1 reply; 139+ messages in thread
From: Marek Behun @ 2021-03-08 6:45 UTC (permalink / raw)
To: u-boot
> Reviewed-by: Stefan Roese <sr@denx.de>
Thanks, Stefan.
Do you want to merge this into your repo u-boot-marvell, or shall Tom
merge this once this series is mature?
Marek
^ permalink raw reply [flat|nested] 139+ messages in thread
* [PATCH u-boot-marvell 02/39] ddr: marvell: axp: fix array types have different bounds warning
2021-03-08 6:45 ` Marek Behun
@ 2021-03-08 6:50 ` Stefan Roese
2021-03-09 13:54 ` Tom Rini
0 siblings, 1 reply; 139+ messages in thread
From: Stefan Roese @ 2021-03-08 6:50 UTC (permalink / raw)
To: u-boot
On 08.03.21 07:45, Marek Behun wrote:
>> Reviewed-by: Stefan Roese <sr@denx.de>
>
> Thanks, Stefan.
> Do you want to merge this into your repo u-boot-marvell, or shall Tom
> merge this once this series is mature?
AFAIU, your patch series touches many architectures / platforms. It'
currently assigned to Tom in patchwork and it perhaps makes more sense
to pull it as one patchset.
If it is preferred that I shall pull the 2 Marvell related patches
via the Marvell repo, I can definitely do so. But for now I'm waiting
for Tom to handle this.
BTW: Many thanks for working on this. The size improvement is great and
the additional bug fixes are also very helpful. :)
Thanks,
Stefan
^ permalink raw reply [flat|nested] 139+ messages in thread
* [PATCH u-boot-marvell 02/39] ddr: marvell: axp: fix array types have different bounds warning
2021-03-08 6:50 ` Stefan Roese
@ 2021-03-09 13:54 ` Tom Rini
2021-03-12 8:54 ` Stefan Roese
0 siblings, 1 reply; 139+ messages in thread
From: Tom Rini @ 2021-03-09 13:54 UTC (permalink / raw)
To: u-boot
On Mon, Mar 08, 2021 at 07:50:59AM +0100, Stefan Roese wrote:
> On 08.03.21 07:45, Marek Behun wrote:
> > > Reviewed-by: Stefan Roese <sr@denx.de>
> >
> > Thanks, Stefan.
> > Do you want to merge this into your repo u-boot-marvell, or shall Tom
> > merge this once this series is mature?
>
> AFAIU, your patch series touches many architectures / platforms. It'
> currently assigned to Tom in patchwork and it perhaps makes more sense
> to pull it as one patchset.
>
> If it is preferred that I shall pull the 2 Marvell related patches
> via the Marvell repo, I can definitely do so. But for now I'm waiting
> for Tom to handle this.
If it's not exposing problems prior to LTO, I'll take it as the series,
if it's exposing problems today and it should go in now rather than for
v2021.07, please pick it up for the marvell tree. Thanks!
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20210309/2796d53c/attachment.sig>
^ permalink raw reply [flat|nested] 139+ messages in thread
* [PATCH u-boot-marvell 02/39] ddr: marvell: axp: fix array types have different bounds warning
2021-03-09 13:54 ` Tom Rini
@ 2021-03-12 8:54 ` Stefan Roese
0 siblings, 0 replies; 139+ messages in thread
From: Stefan Roese @ 2021-03-12 8:54 UTC (permalink / raw)
To: u-boot
On 09.03.21 14:54, Tom Rini wrote:
> On Mon, Mar 08, 2021 at 07:50:59AM +0100, Stefan Roese wrote:
>> On 08.03.21 07:45, Marek Behun wrote:
>>>> Reviewed-by: Stefan Roese <sr@denx.de>
>>>
>>> Thanks, Stefan.
>>> Do you want to merge this into your repo u-boot-marvell, or shall Tom
>>> merge this once this series is mature?
>>
>> AFAIU, your patch series touches many architectures / platforms. It'
>> currently assigned to Tom in patchwork and it perhaps makes more sense
>> to pull it as one patchset.
>>
>> If it is preferred that I shall pull the 2 Marvell related patches
>> via the Marvell repo, I can definitely do so. But for now I'm waiting
>> for Tom to handle this.
>
> If it's not exposing problems prior to LTO, I'll take it as the series,
> if it's exposing problems today and it should go in now rather than for
> v2021.07, please pick it up for the marvell tree. Thanks!
I've added 2 Marvell related patches to my patch queue for master now.
Pull request will follow soon,
Thanks,
Stefan
^ permalink raw reply [flat|nested] 139+ messages in thread
* [PATCH u-boot-marvell 02/39] ddr: marvell: axp: fix array types have different bounds warning
2021-03-08 6:41 ` Stefan Roese
2021-03-08 6:45 ` Marek Behun
@ 2021-03-08 6:46 ` Marek Behun
2021-03-08 6:58 ` Stefan Roese
1 sibling, 1 reply; 139+ messages in thread
From: Marek Behun @ 2021-03-08 6:46 UTC (permalink / raw)
To: u-boot
And BTW do you have time to test this series on some ARM boards?
^ permalink raw reply [flat|nested] 139+ messages in thread
* [PATCH u-boot-marvell 02/39] ddr: marvell: axp: fix array types have different bounds warning
2021-03-08 6:46 ` Marek Behun
@ 2021-03-08 6:58 ` Stefan Roese
2021-03-08 7:04 ` Marek Behun
0 siblings, 1 reply; 139+ messages in thread
From: Stefan Roese @ 2021-03-08 6:58 UTC (permalink / raw)
To: u-boot
Hi Marek,
On 08.03.21 07:46, Marek Behun wrote:
> And BTW do you have time to test this series on some ARM boards?
I can test this on the theadorable Armada XP board, which also uses
SPL. Do you have a git repo I should use? Or is the patch series from
yesterday the "latest and greatest"?
Thanks,
Stefan
^ permalink raw reply [flat|nested] 139+ messages in thread
* [PATCH u-boot-marvell 02/39] ddr: marvell: axp: fix array types have different bounds warning
2021-03-08 6:58 ` Stefan Roese
@ 2021-03-08 7:04 ` Marek Behun
0 siblings, 0 replies; 139+ messages in thread
From: Marek Behun @ 2021-03-08 7:04 UTC (permalink / raw)
To: u-boot
On Mon, 8 Mar 2021 07:58:30 +0100
Stefan Roese <sr@denx.de> wrote:
> Hi Marek,
>
> On 08.03.21 07:46, Marek Behun wrote:
> > And BTW do you have time to test this series on some ARM boards?
>
> I can test this on the theadorable Armada XP board, which also uses
> SPL. Do you have a git repo I should use? Or is the patch series from
> yesterday the "latest and greatest"?
>
> Thanks,
> Stefan
https://github.com/elkablo/u-boot branch lto
but you need to also add the last patch from this series on the mailing
list, which enables LTO for all ARM boards, or enable CONFIG_LTO=y
manually after defconfig
Marek
^ permalink raw reply [flat|nested] 139+ messages in thread
* [PATCH u-boot-marvell 02/39] ddr: marvell: axp: fix array types have different bounds warning
2021-03-07 4:25 ` [PATCH u-boot-marvell 02/39] ddr: marvell: axp: fix array types have different bounds warning Marek Behún
2021-03-08 6:41 ` Stefan Roese
@ 2021-03-08 6:50 ` Bin Meng
1 sibling, 0 replies; 139+ messages in thread
From: Bin Meng @ 2021-03-08 6:50 UTC (permalink / raw)
To: u-boot
On Sun, Mar 7, 2021 at 12:26 PM Marek Beh?n <marek.behun@nic.cz> wrote:
>
> The arrays `pbs_dq_mapping`, `div_ratio1to1` and `div_ratio2to1` have
> different bounds declared in header files where these variables are also
> defined from the ones declared in source files.
>
> This causes the compiler to complain (when building with LTO):
> ddr3_sdram.c:24:12: warning: type of ?pbs_dq_mapping? does not match
> original declaration
> [-Wlto-type-mismatch]
> ddr3_patterns_64bit.h:911:5: note: array types have different bounds
> ddr3_patterns_64bit.h:911:5: note: ?pbs_dq_mapping? was previously
> declared here
>
> ddr3_dfs.c:45:11: warning: type of ?div_ratio1to1? does not match
> original declaration [-Wlto-type-mismatch]
> ddr3_axp_vars.h:167:4: note: array types have different bounds
> ddr3_axp_vars.h:167:4: note: ?div_ratio1to1? was previously declared
> here
>
> ddr3_dfs.c:46:11: warning: type of ?div_ratio2to1? does not match
> original declaration [-Wlto-type-mismatch]
> ddr3_axp_vars.h:196:4: note: array types have different bounds
> ddr3_axp_vars.h:196:4: note: ?div_ratio2to1? was previously declared
> here
>
> CI managed to trigger this as an error when compiling with LTO for AXP.
>
> Fix this by using values from the header files, which seem to be the
> correct ones.
>
> Signed-off-by: Marek Beh?n <marek.behun@nic.cz>
> ---
> drivers/ddr/marvell/axp/ddr3_dfs.c | 4 ++--
> drivers/ddr/marvell/axp/ddr3_sdram.c | 2 +-
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
^ permalink raw reply [flat|nested] 139+ messages in thread
* [PATCH u-boot-dm 03/39] regmap: fix a serious pointer casting bug
2021-03-07 4:24 [PATCH u-boot 00/39] U-Boot LTO (Sandbox + Some ARM boards) Marek Behún
2021-03-07 4:25 ` [PATCH u-boot-marvell 01/39] ddr: marvell: axp: align signature of mv_xor_mem_init() with a38x Marek Behún
2021-03-07 4:25 ` [PATCH u-boot-marvell 02/39] ddr: marvell: axp: fix array types have different bounds warning Marek Behún
@ 2021-03-07 4:25 ` Marek Behún
2021-03-08 7:10 ` Bin Meng
2021-03-07 4:25 ` [PATCH u-boot 04/39] api: fix a potential serious bug caused by undef CONFIG_SYS_64BIT_LBA Marek Behún
` (35 subsequent siblings)
38 siblings, 1 reply; 139+ messages in thread
From: Marek Behún @ 2021-03-07 4:25 UTC (permalink / raw)
To: u-boot
There is a serious bug in regmap_read() and regmap_write() functions
where an uint pointer is cast to (void *) which is then cast to (u8 *),
(u16 *), (u32 *) or (u64 *), depending on register width of the map.
For example given a regmap with 16-bit register width the code
int val = 0x12340000;
regmap_read(map, 0, &val);
only changes the lower 16 bits of val on little-endian machines.
The upper 16 bits will remain 0x1234.
Nobody noticed this probably because this bug can be triggered with
regmap_write() only on big-endian architectures (which are not used by
many people anymore), and on little endian this bug has consequences
only if register width is 8 or 16 bits and also the memory place to
which regmap_read() should store it's result has non-zero upper bits,
which it seems doesn't happen anywhere in U-Boot normally. CI managed to
trigger this bug in unit test of dm_test_devm_regmap_field when compiled
for sandbox_defconfig using LTO.
Fix this simply by taking into account that regmap_raw_read() and
regmap_raw_write() behave as if the data given to these functions were
in little-endian format, i.e. use cpu_to_le32() / le32_to_cpu(). In
regmap_read() also zero out the space so that we don't get invalid
result if regmap_raw_read() does not fill the whole object.
Signed-off-by: Marek Beh?n <marek.behun@nic.cz>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heiko Schocher <hs@denx.de>
---
drivers/core/regmap.c | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/core/regmap.c b/drivers/core/regmap.c
index b51ce108c1..5d37006fff 100644
--- a/drivers/core/regmap.c
+++ b/drivers/core/regmap.c
@@ -435,7 +435,16 @@ int regmap_raw_read(struct regmap *map, uint offset, void *valp, size_t val_len)
int regmap_read(struct regmap *map, uint offset, uint *valp)
{
- return regmap_raw_read(map, offset, valp, map->width);
+ int res;
+
+ *valp = 0;
+ res = regmap_raw_read(map, offset, valp, map->width);
+ if (res)
+ return res;
+
+ *valp = le32_to_cpu(*valp);
+
+ return 0;
}
static inline void __write_8(u8 *addr, const u8 *val,
@@ -546,6 +555,8 @@ int regmap_raw_write(struct regmap *map, uint offset, const void *val,
int regmap_write(struct regmap *map, uint offset, uint val)
{
+ val = cpu_to_le32(val);
+
return regmap_raw_write(map, offset, &val, map->width);
}
--
2.26.2
^ permalink raw reply related [flat|nested] 139+ messages in thread* [PATCH u-boot-dm 03/39] regmap: fix a serious pointer casting bug
2021-03-07 4:25 ` [PATCH u-boot-dm 03/39] regmap: fix a serious pointer casting bug Marek Behún
@ 2021-03-08 7:10 ` Bin Meng
0 siblings, 0 replies; 139+ messages in thread
From: Bin Meng @ 2021-03-08 7:10 UTC (permalink / raw)
To: u-boot
On Sun, Mar 7, 2021 at 12:26 PM Marek Beh?n <marek.behun@nic.cz> wrote:
>
> There is a serious bug in regmap_read() and regmap_write() functions
> where an uint pointer is cast to (void *) which is then cast to (u8 *),
> (u16 *), (u32 *) or (u64 *), depending on register width of the map.
>
> For example given a regmap with 16-bit register width the code
> int val = 0x12340000;
> regmap_read(map, 0, &val);
> only changes the lower 16 bits of val on little-endian machines.
> The upper 16 bits will remain 0x1234.
>
> Nobody noticed this probably because this bug can be triggered with
> regmap_write() only on big-endian architectures (which are not used by
> many people anymore), and on little endian this bug has consequences
> only if register width is 8 or 16 bits and also the memory place to
> which regmap_read() should store it's result has non-zero upper bits,
> which it seems doesn't happen anywhere in U-Boot normally. CI managed to
> trigger this bug in unit test of dm_test_devm_regmap_field when compiled
> for sandbox_defconfig using LTO.
>
> Fix this simply by taking into account that regmap_raw_read() and
> regmap_raw_write() behave as if the data given to these functions were
> in little-endian format, i.e. use cpu_to_le32() / le32_to_cpu(). In
> regmap_read() also zero out the space so that we don't get invalid
> result if regmap_raw_read() does not fill the whole object.
>
> Signed-off-by: Marek Beh?n <marek.behun@nic.cz>
> Reviewed-by: Simon Glass <sjg@chromium.org>
> Reviewed-by: Heiko Schocher <hs@denx.de>
> ---
> drivers/core/regmap.c | 13 ++++++++++++-
> 1 file changed, 12 insertions(+), 1 deletion(-)
>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Maybe we can create a test case on QEMU PPC to cover the big endian targets?
Regards,
Bin
^ permalink raw reply [flat|nested] 139+ messages in thread
* [PATCH u-boot 04/39] api: fix a potential serious bug caused by undef CONFIG_SYS_64BIT_LBA
2021-03-07 4:24 [PATCH u-boot 00/39] U-Boot LTO (Sandbox + Some ARM boards) Marek Behún
` (2 preceding siblings ...)
2021-03-07 4:25 ` [PATCH u-boot-dm 03/39] regmap: fix a serious pointer casting bug Marek Behún
@ 2021-03-07 4:25 ` Marek Behún
2021-03-08 7:09 ` Bin Meng
2021-03-07 4:25 ` [PATCH u-boot 05/39] checkpatch: require quotes around section name in the __section() macro Marek Behún
` (34 subsequent siblings)
38 siblings, 1 reply; 139+ messages in thread
From: Marek Behún @ 2021-03-07 4:25 UTC (permalink / raw)
To: u-boot
The api_public.h header file undefined macro CONFIG_SYS_64BIT_LBA.
But api/api_storage.c includes this header before including part.h,
causing the type of lbaint_t and subsequently the type signature of
blk_dread() and blk_dwrite() functions to change from the rest of U-Boot
(if CONFIG_SYS_64BIT_LBA is defined for the board).
This is of course wrong, because the call to blk_dread() / blk_dwrite()
will recieve mangled arguments.
Fix this by removing the undef of macro CONFIG_SYS_64BIT_LBA and instead
make the immediate code do what it would do as if the macro was not
defined.
Add a FIXME to whoever is maintaining this code.
CI managed to trigger this bug when compiling for lsxhl_defconfig, which
has CONFIG_API selected. The compiler complained about blk_dwrite() and
blk_dread() not matching original declarations:
include/blk.h:280:15: warning: type of ?blk_dwrite? does not match
original declaration
[-Wlto-type-mismatch]
280 | unsigned long blk_dwrite(struct blk_desc *block_dev, lbaint_t st
| ^
drivers/block/blk-uclass.c:456:15: note: type mismatch in parameter 2
456 | unsigned long blk_dwrite(struct blk_desc *block_dev, lbaint_t st
| ^
Signed-off-by: Marek Beh?n <marek.behun@nic.cz>
---
include/api_public.h | 23 ++++++++++++++++++-----
1 file changed, 18 insertions(+), 5 deletions(-)
diff --git a/include/api_public.h b/include/api_public.h
index def103ce22..5a4465ea89 100644
--- a/include/api_public.h
+++ b/include/api_public.h
@@ -70,12 +70,25 @@ struct sys_info {
int mr_no; /* number of memory regions */
};
-#undef CONFIG_SYS_64BIT_LBA
-#ifdef CONFIG_SYS_64BIT_LBA
-typedef u_int64_t lbasize_t;
-#else
+/*
+ * FIXME: Previously this code was:
+ *
+ * #undef CONFIG_SYS_64BIT_LBA
+ * #ifdef CONFIG_SYS_64BIT_LBA
+ * typedef u_int64_t lbasize_t;
+ * #else
+ * typedef unsigned long lbasize_t;
+ * #endif
+ *
+ * But we cannot just undefine CONFIG_SYS_64BIT_LBA, because then in
+ * api/api_storage.c the type signature of lbaint_t will be different if
+ * CONFIG_SYS_64BIT_LBA is enabled for the board, which can result in various
+ * bugs.
+ * So simply define lbasize_t as an unsigned long, since this was what was done
+ * anyway for at least 13 years, but don't undefine CONFIG_SYS_64BIT_LBA.
+ */
typedef unsigned long lbasize_t;
-#endif
+
typedef unsigned long lbastart_t;
#define DEV_TYP_NONE 0x0000
--
2.26.2
^ permalink raw reply related [flat|nested] 139+ messages in thread* [PATCH u-boot 04/39] api: fix a potential serious bug caused by undef CONFIG_SYS_64BIT_LBA
2021-03-07 4:25 ` [PATCH u-boot 04/39] api: fix a potential serious bug caused by undef CONFIG_SYS_64BIT_LBA Marek Behún
@ 2021-03-08 7:09 ` Bin Meng
2021-03-08 7:21 ` Marek Behun
0 siblings, 1 reply; 139+ messages in thread
From: Bin Meng @ 2021-03-08 7:09 UTC (permalink / raw)
To: u-boot
Hi Marek,
On Sun, Mar 7, 2021 at 12:26 PM Marek Beh?n <marek.behun@nic.cz> wrote:
>
> The api_public.h header file undefined macro CONFIG_SYS_64BIT_LBA.
>
> But api/api_storage.c includes this header before including part.h,
> causing the type of lbaint_t and subsequently the type signature of
> blk_dread() and blk_dwrite() functions to change from the rest of U-Boot
> (if CONFIG_SYS_64BIT_LBA is defined for the board).
>
> This is of course wrong, because the call to blk_dread() / blk_dwrite()
> will recieve mangled arguments.
typo: receive
>
> Fix this by removing the undef of macro CONFIG_SYS_64BIT_LBA and instead
> make the immediate code do what it would do as if the macro was not
> defined.
>
> Add a FIXME to whoever is maintaining this code.
>
> CI managed to trigger this bug when compiling for lsxhl_defconfig, which
> has CONFIG_API selected. The compiler complained about blk_dwrite() and
> blk_dread() not matching original declarations:
>
> include/blk.h:280:15: warning: type of ?blk_dwrite? does not match
> original declaration
> [-Wlto-type-mismatch]
> 280 | unsigned long blk_dwrite(struct blk_desc *block_dev, lbaint_t st
> | ^
> drivers/block/blk-uclass.c:456:15: note: type mismatch in parameter 2
> 456 | unsigned long blk_dwrite(struct blk_desc *block_dev, lbaint_t st
> | ^
>
> Signed-off-by: Marek Beh?n <marek.behun@nic.cz>
> ---
> include/api_public.h | 23 ++++++++++++++++++-----
> 1 file changed, 18 insertions(+), 5 deletions(-)
>
> diff --git a/include/api_public.h b/include/api_public.h
> index def103ce22..5a4465ea89 100644
> --- a/include/api_public.h
> +++ b/include/api_public.h
> @@ -70,12 +70,25 @@ struct sys_info {
> int mr_no; /* number of memory regions */
> };
>
> -#undef CONFIG_SYS_64BIT_LBA
> -#ifdef CONFIG_SYS_64BIT_LBA
> -typedef u_int64_t lbasize_t;
> -#else
> +/*
> + * FIXME: Previously this code was:
> + *
> + * #undef CONFIG_SYS_64BIT_LBA
> + * #ifdef CONFIG_SYS_64BIT_LBA
> + * typedef u_int64_t lbasize_t;
> + * #else
> + * typedef unsigned long lbasize_t;
> + * #endif
> + *
> + * But we cannot just undefine CONFIG_SYS_64BIT_LBA, because then in
> + * api/api_storage.c the type signature of lbaint_t will be different if
> + * CONFIG_SYS_64BIT_LBA is enabled for the board, which can result in various
> + * bugs.
> + * So simply define lbasize_t as an unsigned long, since this was what was done
> + * anyway for at least 13 years, but don't undefine CONFIG_SYS_64BIT_LBA.
> + */
> typedef unsigned long lbasize_t;
Does "typedef lbaint_t labsize_t" help?
> -#endif
> +
> typedef unsigned long lbastart_t;
Regards,
Bin
^ permalink raw reply [flat|nested] 139+ messages in thread* [PATCH u-boot 04/39] api: fix a potential serious bug caused by undef CONFIG_SYS_64BIT_LBA
2021-03-08 7:09 ` Bin Meng
@ 2021-03-08 7:21 ` Marek Behun
0 siblings, 0 replies; 139+ messages in thread
From: Marek Behun @ 2021-03-08 7:21 UTC (permalink / raw)
To: u-boot
On Mon, 8 Mar 2021 15:09:51 +0800
Bin Meng <bmeng.cn@gmail.com> wrote:
> Hi Marek,
>
> On Sun, Mar 7, 2021 at 12:26 PM Marek Beh?n <marek.behun@nic.cz> wrote:
> >
> > The api_public.h header file undefined macro CONFIG_SYS_64BIT_LBA.
> >
> > But api/api_storage.c includes this header before including part.h,
> > causing the type of lbaint_t and subsequently the type signature of
> > blk_dread() and blk_dwrite() functions to change from the rest of U-Boot
> > (if CONFIG_SYS_64BIT_LBA is defined for the board).
> >
> > This is of course wrong, because the call to blk_dread() / blk_dwrite()
> > will recieve mangled arguments.
>
> typo: receive
>
> >
> > Fix this by removing the undef of macro CONFIG_SYS_64BIT_LBA and instead
> > make the immediate code do what it would do as if the macro was not
> > defined.
> >
> > Add a FIXME to whoever is maintaining this code.
> >
> > CI managed to trigger this bug when compiling for lsxhl_defconfig, which
> > has CONFIG_API selected. The compiler complained about blk_dwrite() and
> > blk_dread() not matching original declarations:
> >
> > include/blk.h:280:15: warning: type of ?blk_dwrite? does not match
> > original declaration
> > [-Wlto-type-mismatch]
> > 280 | unsigned long blk_dwrite(struct blk_desc *block_dev, lbaint_t st
> > | ^
> > drivers/block/blk-uclass.c:456:15: note: type mismatch in parameter 2
> > 456 | unsigned long blk_dwrite(struct blk_desc *block_dev, lbaint_t st
> > | ^
> >
> > Signed-off-by: Marek Beh?n <marek.behun@nic.cz>
> > ---
> > include/api_public.h | 23 ++++++++++++++++++-----
> > 1 file changed, 18 insertions(+), 5 deletions(-)
> >
> > diff --git a/include/api_public.h b/include/api_public.h
> > index def103ce22..5a4465ea89 100644
> > --- a/include/api_public.h
> > +++ b/include/api_public.h
> > @@ -70,12 +70,25 @@ struct sys_info {
> > int mr_no; /* number of memory regions */
> > };
> >
> > -#undef CONFIG_SYS_64BIT_LBA
> > -#ifdef CONFIG_SYS_64BIT_LBA
> > -typedef u_int64_t lbasize_t;
> > -#else
> > +/*
> > + * FIXME: Previously this code was:
> > + *
> > + * #undef CONFIG_SYS_64BIT_LBA
> > + * #ifdef CONFIG_SYS_64BIT_LBA
> > + * typedef u_int64_t lbasize_t;
> > + * #else
> > + * typedef unsigned long lbasize_t;
> > + * #endif
> > + *
> > + * But we cannot just undefine CONFIG_SYS_64BIT_LBA, because then in
> > + * api/api_storage.c the type signature of lbaint_t will be different if
> > + * CONFIG_SYS_64BIT_LBA is enabled for the board, which can result in various
> > + * bugs.
> > + * So simply define lbasize_t as an unsigned long, since this was what was done
> > + * anyway for at least 13 years, but don't undefine CONFIG_SYS_64BIT_LBA.
> > + */
> > typedef unsigned long lbasize_t;
>
> Does "typedef lbaint_t labsize_t" help?
That could break API applications...
^ permalink raw reply [flat|nested] 139+ messages in thread
* [PATCH u-boot 05/39] checkpatch: require quotes around section name in the __section() macro
2021-03-07 4:24 [PATCH u-boot 00/39] U-Boot LTO (Sandbox + Some ARM boards) Marek Behún
` (3 preceding siblings ...)
2021-03-07 4:25 ` [PATCH u-boot 04/39] api: fix a potential serious bug caused by undef CONFIG_SYS_64BIT_LBA Marek Behún
@ 2021-03-07 4:25 ` Marek Behún
2021-03-07 4:47 ` Marek Vasut
2021-03-07 4:25 ` [PATCH u-boot 06/39] treewide: Convert macro and uses of __section(foo) to __section("foo") Marek Behún
` (33 subsequent siblings)
38 siblings, 1 reply; 139+ messages in thread
From: Marek Behún @ 2021-03-07 4:25 UTC (permalink / raw)
To: u-boot
This is how Linux does this now, see Linux commit 339f29d91acf.
Signed-off-by: Marek Beh?n <marek.behun@nic.cz>
---
scripts/checkpatch.pl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 755f4802a4..fd1e9c4d24 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -6065,7 +6065,7 @@ sub process {
my $old = substr($rawline, $-[1], $+[1] - $-[1]);
my $new = substr($old, 1, -1);
if (WARN("PREFER_SECTION",
- "__section($new) is preferred over __attribute__((section($old)))\n" . $herecurr) &&
+ "__section(\"$new\") is preferred over __attribute__((section($old)))\n" . $herecurr) &&
$fix) {
$fixed[$fixlinenr] =~ s/\b__attribute__\s*\(\s*\(\s*_*section_*\s*\(\s*\Q$old\E\s*\)\s*\)\s*\)/__section($new)/;
}
--
2.26.2
^ permalink raw reply related [flat|nested] 139+ messages in thread* [PATCH u-boot 05/39] checkpatch: require quotes around section name in the __section() macro
2021-03-07 4:25 ` [PATCH u-boot 05/39] checkpatch: require quotes around section name in the __section() macro Marek Behún
@ 2021-03-07 4:47 ` Marek Vasut
2021-03-07 4:55 ` Marek Behun
0 siblings, 1 reply; 139+ messages in thread
From: Marek Vasut @ 2021-03-07 4:47 UTC (permalink / raw)
To: u-boot
On 3/7/21 5:25 AM, Marek Beh?n wrote:
> This is how Linux does this now, see Linux commit 339f29d91acf.
>
> Signed-off-by: Marek Beh?n <marek.behun@nic.cz>
> ---
> scripts/checkpatch.pl | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> index 755f4802a4..fd1e9c4d24 100755
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -6065,7 +6065,7 @@ sub process {
> my $old = substr($rawline, $-[1], $+[1] - $-[1]);
> my $new = substr($old, 1, -1);
> if (WARN("PREFER_SECTION",
> - "__section($new) is preferred over __attribute__((section($old)))\n" . $herecurr) &&
> + "__section(\"$new\") is preferred over __attribute__((section($old)))\n" . $herecurr) &&
> $fix) {
> $fixed[$fixlinenr] =~ s/\b__attribute__\s*\(\s*\(\s*_*section_*\s*\(\s*\Q$old\E\s*\)\s*\)\s*\)/__section($new)/;
Shouldn't some of the patches which are clearly fixes be sent as
separate fixes, so they can be picked while the LTO support is being
worked on ?
^ permalink raw reply [flat|nested] 139+ messages in thread* [PATCH u-boot 05/39] checkpatch: require quotes around section name in the __section() macro
2021-03-07 4:47 ` Marek Vasut
@ 2021-03-07 4:55 ` Marek Behun
0 siblings, 0 replies; 139+ messages in thread
From: Marek Behun @ 2021-03-07 4:55 UTC (permalink / raw)
To: u-boot
On Sun, 7 Mar 2021 05:47:56 +0100
Marek Vasut <marex@denx.de> wrote:
> On 3/7/21 5:25 AM, Marek Beh?n wrote:
> > This is how Linux does this now, see Linux commit 339f29d91acf.
> >
> > Signed-off-by: Marek Beh?n <marek.behun@nic.cz>
> > ---
> > scripts/checkpatch.pl | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> > index 755f4802a4..fd1e9c4d24 100755
> > --- a/scripts/checkpatch.pl
> > +++ b/scripts/checkpatch.pl
> > @@ -6065,7 +6065,7 @@ sub process {
> > my $old = substr($rawline, $-[1], $+[1] - $-[1]);
> > my $new = substr($old, 1, -1);
> > if (WARN("PREFER_SECTION",
> > - "__section($new) is preferred over __attribute__((section($old)))\n" . $herecurr) &&
> > + "__section(\"$new\") is preferred over __attribute__((section($old)))\n" . $herecurr) &&
> > $fix) {
> > $fixed[$fixlinenr] =~ s/\b__attribute__\s*\(\s*\(\s*_*section_*\s*\(\s*\Q$old\E\s*\)\s*\)\s*\)/__section($new)/;
>
> Shouldn't some of the patches which are clearly fixes be sent as
> separate fixes, so they can be picked while the LTO support is being
> worked on ?
Yes, ideally it would be better, but:
this patch is connected to patch 6 of this series, and patch 6 needs to
be in this series because otherwise people trying to apply this series
would get an error.
The first 4 patches are also fixes for something else, but they
were discovered thanks to LTO and without them users will get
warnings/errors when trying to build for some boards.
Tom, should I send these patches separately? Also the first 3 patches
should maybe be applied via Stefan and Simon, via their trees...
Marek
^ permalink raw reply [flat|nested] 139+ messages in thread
* [PATCH u-boot 06/39] treewide: Convert macro and uses of __section(foo) to __section("foo")
2021-03-07 4:24 [PATCH u-boot 00/39] U-Boot LTO (Sandbox + Some ARM boards) Marek Behún
` (4 preceding siblings ...)
2021-03-07 4:25 ` [PATCH u-boot 05/39] checkpatch: require quotes around section name in the __section() macro Marek Behún
@ 2021-03-07 4:25 ` Marek Behún
2021-03-08 7:27 ` Bin Meng
2021-03-07 4:25 ` [PATCH u-boot 07/39] compiler.h: align the __ADDRESSABLE macro with Linux' version Marek Behún
` (32 subsequent siblings)
38 siblings, 1 reply; 139+ messages in thread
From: Marek Behún @ 2021-03-07 4:25 UTC (permalink / raw)
To: u-boot
This commit does the same thing as Linux commit 33def8498fdd.
Use a more generic form for __section that requires quotes to avoid
complications with clang and gcc differences.
Remove the quote operator # from compiler_attributes.h __section macro.
Convert all unquoted __section(foo) uses to quoted __section("foo").
Also convert __attribute__((section("foo"))) uses to __section("foo")
even if the __attribute__ has multiple list entry forms.
Signed-off-by: Marek Beh?n <marek.behun@nic.cz>
---
arch/arm/cpu/arm926ejs/spear/spl.c | 2 +-
arch/arm/cpu/armv7/ls102xa/ls102xa_psci.c | 2 +-
arch/arm/cpu/armv8/fsl-layerscape/spl.c | 2 +-
arch/arm/cpu/armv8/spl_data.c | 4 +--
arch/arm/include/asm/secure.h | 6 ++---
arch/arm/include/asm/setup.h | 2 +-
arch/arm/lib/sections.c | 31 ++++++++++++-----------
arch/arm/lib/spl.c | 2 +-
arch/arm/mach-at91/spl.c | 2 +-
arch/arm/mach-k3/am6_init.c | 2 +-
arch/arm/mach-k3/j721e_init.c | 4 +--
arch/arm/mach-mvebu/mbus.c | 4 +--
arch/arm/mach-mvebu/timer.c | 2 +-
arch/arm/mach-nexell/clock.c | 6 ++---
arch/arm/mach-nexell/timer.c | 6 ++---
arch/arm/mach-socfpga/spl_a10.c | 2 +-
arch/arm/mach-sunxi/board.c | 2 +-
arch/arm/mach-tegra/board.c | 2 +-
arch/arm/mach-tegra/cboot.c | 8 +++---
arch/mips/mach-jz47xx/jz4780/jz4780.c | 2 +-
arch/nds32/include/asm/setup.h | 6 ++---
arch/powerpc/include/asm/cache.h | 4 +--
arch/riscv/cpu/cpu.c | 4 +--
arch/sandbox/include/asm/getopt.h | 2 +-
arch/sandbox/lib/sections.c | 9 ++++---
arch/x86/cpu/coreboot/tables.c | 2 +-
arch/x86/cpu/coreboot/timestamp.c | 2 +-
arch/x86/lib/sections.c | 9 ++++---
arch/xtensa/cpu/cpu.c | 2 +-
board/bosch/shc/board.c | 2 +-
board/broadcom/bcmstb/bcmstb.c | 2 +-
board/samsung/arndale/arndale_spl.c | 2 +-
board/samsung/smdk5250/smdk5250_spl.c | 2 +-
board/samsung/smdk5420/smdk5420_spl.c | 2 +-
board/siemens/draco/board.c | 2 +-
board/xilinx/common/fru_ops.c | 2 +-
drivers/bios_emulator/biosemu.c | 4 +--
drivers/firmware/psci.c | 2 +-
drivers/pinctrl/nxp/pinctrl-imx5.c | 2 +-
drivers/pinctrl/nxp/pinctrl-imx7.c | 2 +-
drivers/pinctrl/nxp/pinctrl-imx8m.c | 2 +-
drivers/power/pmic/pmic_tps62362.c | 2 +-
drivers/power/pmic/pmic_tps65217.c | 2 +-
drivers/power/pmic/pmic_tps65218.c | 2 +-
drivers/power/pmic/pmic_tps65910.c | 2 +-
drivers/serial/serial_pl01x.c | 4 +--
include/efi_loader.h | 4 +--
include/linker_lists.h | 24 +++++++++---------
include/linux/compiler.h | 8 +++---
include/linux/compiler_attributes.h | 2 +-
lib/trace.c | 4 +--
51 files changed, 108 insertions(+), 105 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/spear/spl.c b/arch/arm/cpu/arm926ejs/spear/spl.c
index 08b98a2d06..b5b9945a87 100644
--- a/arch/arm/cpu/arm926ejs/spear/spl.c
+++ b/arch/arm/cpu/arm926ejs/spear/spl.c
@@ -22,7 +22,7 @@
* The BSS cannot be used for this purpose because it will be zeroed after
* having stored the pointer, so force the location to the data section.
*/
-u32 bootrom_stash_sp __attribute__((section(".data")));
+u32 bootrom_stash_sp __section(".data");
static void ddr_clock_init(void)
{
diff --git a/arch/arm/cpu/armv7/ls102xa/ls102xa_psci.c b/arch/arm/cpu/armv7/ls102xa/ls102xa_psci.c
index 4a4b3c6f23..28a7945207 100644
--- a/arch/arm/cpu/armv7/ls102xa/ls102xa_psci.c
+++ b/arch/arm/cpu/armv7/ls102xa/ls102xa_psci.c
@@ -13,7 +13,7 @@
#include <fsl_immap.h>
#include "fsl_epu.h"
-#define __secure __attribute__((section("._secure.text")))
+#define __secure __section("._secure.text")
#define CCSR_GICD_CTLR 0x1000
#define CCSR_GICC_CTLR 0x2000
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/spl.c b/arch/arm/cpu/armv8/fsl-layerscape/spl.c
index d5131bcf4b..f3e7e07412 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/spl.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/spl.c
@@ -40,7 +40,7 @@ u32 spl_boot_device(void)
#ifdef CONFIG_SPL_BUILD
/* Define board data structure */
-static struct bd_info bdata __attribute__ ((section(".data")));
+static struct bd_info bdata __section(".data");
void spl_board_init(void)
{
diff --git a/arch/arm/cpu/armv8/spl_data.c b/arch/arm/cpu/armv8/spl_data.c
index 8fd986a67a..8f1231c86e 100644
--- a/arch/arm/cpu/armv8/spl_data.c
+++ b/arch/arm/cpu/armv8/spl_data.c
@@ -6,8 +6,8 @@
#include <common.h>
#include <spl.h>
-char __data_save_start[0] __section(.__data_save_start);
-char __data_save_end[0] __section(.__data_save_end);
+char __data_save_start[0] __section(".__data_save_start");
+char __data_save_end[0] __section(".__data_save_end");
u32 cold_reboot_flag = 1;
diff --git a/arch/arm/include/asm/secure.h b/arch/arm/include/asm/secure.h
index 64e5582c1f..c7b00be8e0 100644
--- a/arch/arm/include/asm/secure.h
+++ b/arch/arm/include/asm/secure.h
@@ -4,8 +4,8 @@
#include <config.h>
#include <asm/global_data.h>
-#define __secure __attribute__ ((section ("._secure.text")))
-#define __secure_data __attribute__ ((section ("._secure.data")))
+#define __secure __section("._secure.text")
+#define __secure_data __section("._secure.data")
#ifndef __ASSEMBLY__
@@ -22,7 +22,7 @@ typedef struct secure_svc_tbl {
*/
#define DECLARE_SECURE_SVC(_name, _id, _fn) \
static const secure_svc_tbl_t __secure_svc_ ## _name \
- __attribute__((used, section("._secure_svc_tbl_entries"))) \
+ __used __section("._secure_svc_tbl_entries") \
= { \
.id = _id, \
.func = _fn }
diff --git a/arch/arm/include/asm/setup.h b/arch/arm/include/asm/setup.h
index 3a4e902af1..e0e2d7e360 100644
--- a/arch/arm/include/asm/setup.h
+++ b/arch/arm/include/asm/setup.h
@@ -235,7 +235,7 @@ struct tagtable {
int (*parse)(const struct tag *);
};
-#define __tag __attribute__((unused, __section__(".taglist")))
+#define __tag __attribute__((unused)) __section(".taglist")
#define __tagtable(tag, fn) \
static struct tagtable __tagtable_##fn __tag = { tag, fn }
diff --git a/arch/arm/lib/sections.c b/arch/arm/lib/sections.c
index 3bb2d8468c..857879711c 100644
--- a/arch/arm/lib/sections.c
+++ b/arch/arm/lib/sections.c
@@ -2,6 +2,7 @@
/*
* Copyright 2013 Albert ARIBAUD <albert.u.boot@aribaud.net>
*/
+#include <linux/compiler.h>
/**
* These two symbols are declared in a C file so that the linker
@@ -18,18 +19,18 @@
* aliasing warnings.
*/
-char __bss_start[0] __attribute__((section(".__bss_start")));
-char __bss_end[0] __attribute__((section(".__bss_end")));
-char __image_copy_start[0] __attribute__((section(".__image_copy_start")));
-char __image_copy_end[0] __attribute__((section(".__image_copy_end")));
-char __rel_dyn_start[0] __attribute__((section(".__rel_dyn_start")));
-char __rel_dyn_end[0] __attribute__((section(".__rel_dyn_end")));
-char __secure_start[0] __attribute__((section(".__secure_start")));
-char __secure_end[0] __attribute__((section(".__secure_end")));
-char __secure_stack_start[0] __attribute__((section(".__secure_stack_start")));
-char __secure_stack_end[0] __attribute__((section(".__secure_stack_end")));
-char __efi_runtime_start[0] __attribute__((section(".__efi_runtime_start")));
-char __efi_runtime_stop[0] __attribute__((section(".__efi_runtime_stop")));
-char __efi_runtime_rel_start[0] __attribute__((section(".__efi_runtime_rel_start")));
-char __efi_runtime_rel_stop[0] __attribute__((section(".__efi_runtime_rel_stop")));
-char _end[0] __attribute__((section(".__end")));
+char __bss_start[0] __section(".__bss_start");
+char __bss_end[0] __section(".__bss_end");
+char __image_copy_start[0] __section(".__image_copy_start");
+char __image_copy_end[0] __section(".__image_copy_end");
+char __rel_dyn_start[0] __section(".__rel_dyn_start");
+char __rel_dyn_end[0] __section(".__rel_dyn_end");
+char __secure_start[0] __section(".__secure_start");
+char __secure_end[0] __section(".__secure_end");
+char __secure_stack_start[0] __section(".__secure_stack_start");
+char __secure_stack_end[0] __section(".__secure_stack_end");
+char __efi_runtime_start[0] __section(".__efi_runtime_start");
+char __efi_runtime_stop[0] __section(".__efi_runtime_stop");
+char __efi_runtime_rel_start[0] __section(".__efi_runtime_rel_start");
+char __efi_runtime_rel_stop[0] __section(".__efi_runtime_rel_stop");
+char _end[0] __section(".__end");
diff --git a/arch/arm/lib/spl.c b/arch/arm/lib/spl.c
index b2b54f28fc..8e2bdf3536 100644
--- a/arch/arm/lib/spl.c
+++ b/arch/arm/lib/spl.c
@@ -26,7 +26,7 @@ DECLARE_GLOBAL_DATA_PTR;
* WARNING: This is going away very soon. Don't use it and don't submit
* pafches that rely on it. The global_data area is set up in crt0.S.
*/
-gd_t gdata __attribute__ ((section(".data")));
+gd_t gdata __section(".data");
#endif
/*
diff --git a/arch/arm/mach-at91/spl.c b/arch/arm/mach-at91/spl.c
index 156150c89c..8d537998c9 100644
--- a/arch/arm/mach-at91/spl.c
+++ b/arch/arm/mach-at91/spl.c
@@ -26,7 +26,7 @@ void at91_disable_wdt(void)
#include <asm/arch/sama5_boot.h>
struct {
u32 r4;
-} bootrom_stash __attribute__((section(".data")));
+} bootrom_stash __section(".data");
u32 spl_boot_device(void)
{
diff --git a/arch/arm/mach-k3/am6_init.c b/arch/arm/mach-k3/am6_init.c
index d78d2b8751..425b3f93c8 100644
--- a/arch/arm/mach-k3/am6_init.c
+++ b/arch/arm/mach-k3/am6_init.c
@@ -77,7 +77,7 @@ static void ctrl_mmr_unlock(void)
* but the .bss is cleared between writing and reading this variable, so move
* it to the .data section.
*/
-u32 bootindex __attribute__((section(".data")));
+u32 bootindex __section(".data");
static void store_boot_index_from_rom(void)
{
diff --git a/arch/arm/mach-k3/j721e_init.c b/arch/arm/mach-k3/j721e_init.c
index 1a4f796e5e..76a04a9035 100644
--- a/arch/arm/mach-k3/j721e_init.c
+++ b/arch/arm/mach-k3/j721e_init.c
@@ -125,8 +125,8 @@ void k3_mmc_restart_clock(void)
* but the .bss is cleared between writing and reading this variable, so move
* it to the .data section.
*/
-u32 bootindex __attribute__((section(".data")));
-static struct rom_extended_boot_data bootdata __section(.data);
+u32 bootindex __section(".data");
+static struct rom_extended_boot_data bootdata __section(".data");
static void store_boot_info_from_rom(void)
{
diff --git a/arch/arm/mach-mvebu/mbus.c b/arch/arm/mach-mvebu/mbus.c
index f29abe5911..3b1b9f73eb 100644
--- a/arch/arm/mach-mvebu/mbus.c
+++ b/arch/arm/mach-mvebu/mbus.c
@@ -98,9 +98,9 @@ struct mvebu_mbus_soc_data {
};
struct mvebu_mbus_state mbus_state
- __attribute__ ((section(".data")));
+ __section(".data");
static struct mbus_dram_target_info mbus_dram_info
- __attribute__ ((section(".data")));
+ __section(".data");
/*
* Functions to manipulate the address decoding windows
diff --git a/arch/arm/mach-mvebu/timer.c b/arch/arm/mach-mvebu/timer.c
index 43b3ed15d0..557a378776 100644
--- a/arch/arm/mach-mvebu/timer.c
+++ b/arch/arm/mach-mvebu/timer.c
@@ -14,7 +14,7 @@
#define TIMER_LOAD_VAL 0xffffffff
-static int init_done __attribute__((section(".data"))) = 0;
+static int init_done __section(".data") = 0;
/*
* Timer initialization
diff --git a/arch/arm/mach-nexell/clock.c b/arch/arm/mach-nexell/clock.c
index a0ba2d8e0c..d5b46a87a1 100644
--- a/arch/arm/mach-nexell/clock.c
+++ b/arch/arm/mach-nexell/clock.c
@@ -99,7 +99,7 @@ static const char * const clk_core[] = {
* in board_init_f(), respectively! I.e. global variables can not be used!
*/
static struct clk_dev_peri clk_periphs[]
- __attribute__((section(".data"))) = {
+ __section(".data") = {
CLK_PERI_1S(DEV_NAME_TIMER, 0, CLK_ID_TIMER_0,
PHY_BASEADDR_CLKGEN14, (I_PLL_0_2)),
CLK_PERI_1S(DEV_NAME_TIMER, 1, CLK_ID_TIMER_1,
@@ -167,7 +167,7 @@ static struct clk_dev_peri clk_periphs[]
#define MAX_DIVIDER ((1 << 8) - 1) /* 256, align 2 */
static struct clk_dev st_clk_devs[CLK_DEVS_NUM]
- __attribute__((section(".data")));
+ __section(".data");
#define clk_dev_get(n) ((struct clk_dev *)&st_clk_devs[n])
#define clk_container(p) (container_of(p, struct clk_dev, clk))
@@ -196,7 +196,7 @@ struct _core_hz_ {
* in board_init_f(), respectively! I.e. global variables can not be used!
*/
/* core clock */
-static struct _core_hz_ core_hz __attribute__((section(".data")));
+static struct _core_hz_ core_hz __section(".data");
#define CORE_HZ_SIZE (sizeof(core_hz) / 4)
diff --git a/arch/arm/mach-nexell/timer.c b/arch/arm/mach-nexell/timer.c
index fecee67265..3b311fd22a 100644
--- a/arch/arm/mach-nexell/timer.c
+++ b/arch/arm/mach-nexell/timer.c
@@ -23,9 +23,9 @@
* Section ".data" must be used because BSS is not available before relocation,
* in board_init_f(), respectively! I.e. global variables can not be used!
*/
-static unsigned long timestamp __attribute__ ((section(".data")));
-static unsigned long lastdec __attribute__ ((section(".data")));
-static int timerinit __attribute__ ((section(".data")));
+static unsigned long timestamp __section(".data");
+static unsigned long lastdec __section(".data");
+static int timerinit __section(".data");
/* macro to hw timer tick config */
static long TIMER_FREQ = 1000000;
diff --git a/arch/arm/mach-socfpga/spl_a10.c b/arch/arm/mach-socfpga/spl_a10.c
index 92231b5ba3..b5f43f09d1 100644
--- a/arch/arm/mach-socfpga/spl_a10.c
+++ b/arch/arm/mach-socfpga/spl_a10.c
@@ -40,7 +40,7 @@ DECLARE_GLOBAL_DATA_PTR;
SOCFPGA_PHYS_OCRAM_SIZE - \
BOOTROM_SHARED_MEM_SIZE)
#define RST_STATUS_SHARED_ADDR (BOOTROM_SHARED_MEM_ADDR + 0x438)
-static u32 rst_mgr_status __section(.data);
+static u32 rst_mgr_status __section(".data");
/*
* Bootrom will clear the status register in reset manager and stores the
diff --git a/arch/arm/mach-sunxi/board.c b/arch/arm/mach-sunxi/board.c
index fa2b6fcfd6..ec0ee62a9e 100644
--- a/arch/arm/mach-sunxi/board.c
+++ b/arch/arm/mach-sunxi/board.c
@@ -39,7 +39,7 @@ struct fel_stash {
uint32_t cr;
};
-struct fel_stash fel_stash __attribute__((section(".data")));
+struct fel_stash fel_stash __section(".data");
#ifdef CONFIG_ARM64
#include <asm/armv8/mmu.h>
diff --git a/arch/arm/mach-tegra/board.c b/arch/arm/mach-tegra/board.c
index 21852e2388..95d6555a0d 100644
--- a/arch/arm/mach-tegra/board.c
+++ b/arch/arm/mach-tegra/board.c
@@ -45,7 +45,7 @@ enum {
UART_COUNT = 5,
};
-static bool from_spl __attribute__ ((section(".data")));
+static bool from_spl __section(".data");
#ifndef CONFIG_SPL_BUILD
void save_boot_params(unsigned long r0, unsigned long r1, unsigned long r2,
diff --git a/arch/arm/mach-tegra/cboot.c b/arch/arm/mach-tegra/cboot.c
index bb46fb23ff..55eb819860 100644
--- a/arch/arm/mach-tegra/cboot.c
+++ b/arch/arm/mach-tegra/cboot.c
@@ -49,7 +49,7 @@ extern struct mm_region tegra_mem_map[];
*/
/* The number of valid entries in ram_banks[] */
-static int ram_bank_count __attribute__((section(".data")));
+static int ram_bank_count __section(".data");
/*
* The usable top-of-RAM for U-Boot. This is both:
@@ -57,15 +57,15 @@ static int ram_bank_count __attribute__((section(".data")));
* b) At the end of a region that has enough space to hold the relocated U-Boot
* and all other allocations made around it (stack, heap, page tables, etc.)
*/
-static u64 ram_top __attribute__((section(".data")));
+static u64 ram_top __section(".data");
/* The base address of the region of RAM that ends at ram_top */
-static u64 region_base __attribute__((section(".data")));
+static u64 region_base __section(".data");
/*
* Explicitly put this in the .data section because it is written before the
* .bss section is zeroed out but it needs to persist.
*/
-unsigned long cboot_boot_x0 __attribute__((section(".data")));
+unsigned long cboot_boot_x0 __section(".data");
void cboot_save_boot_params(unsigned long x0, unsigned long x1,
unsigned long x2, unsigned long x3)
diff --git a/arch/mips/mach-jz47xx/jz4780/jz4780.c b/arch/mips/mach-jz47xx/jz4780/jz4780.c
index 43f5651f83..fefba12873 100644
--- a/arch/mips/mach-jz47xx/jz4780/jz4780.c
+++ b/arch/mips/mach-jz47xx/jz4780/jz4780.c
@@ -23,7 +23,7 @@
#ifdef CONFIG_SPL_BUILD
/* Pointer to the global data structure for SPL */
DECLARE_GLOBAL_DATA_PTR;
-gd_t gdata __attribute__ ((section(".bss")));
+gd_t gdata __section(".bss");
void board_init_f(ulong dummy)
{
diff --git a/arch/nds32/include/asm/setup.h b/arch/nds32/include/asm/setup.h
index 8217bbf6fe..a7d52373c6 100644
--- a/arch/nds32/include/asm/setup.h
+++ b/arch/nds32/include/asm/setup.h
@@ -155,7 +155,7 @@ struct tagtable {
#ifdef __KERNEL__
-#define __tag __used __attribute__((__section__(".taglist")))
+#define __tag __used __section(".taglist")
#define __tagtable(tag, fn) \
static struct tagtable __tagtable_##fn __tag = { tag, fn }
@@ -182,8 +182,8 @@ struct early_params {
};
#define __early_param(name, fn) \
-static struct early_params __early_##fn __used \
-__attribute__((__section__("__early_param"))) = { name, fn }
+static struct early_params __early_##fn __used \
+__section("__early_param") = { name, fn }
#endif
#endif
diff --git a/arch/powerpc/include/asm/cache.h b/arch/powerpc/include/asm/cache.h
index 445a366807..ac8eeb4caa 100644
--- a/arch/powerpc/include/asm/cache.h
+++ b/arch/powerpc/include/asm/cache.h
@@ -41,8 +41,8 @@
#define __cacheline_aligned __attribute__((__aligned__(L1_CACHE_BYTES)))
#else
#define __cacheline_aligned \
- __attribute__((__aligned__(L1_CACHE_BYTES), \
- __section__(".data.cacheline_aligned")))
+ __attribute__((__aligned__(L1_CACHE_BYTES))) \
+ __section(".data.cacheline_aligned")
#endif
#if defined(__KERNEL__) && !defined(__ASSEMBLY__)
diff --git a/arch/riscv/cpu/cpu.c b/arch/riscv/cpu/cpu.c
index 85592f5bee..0a879aee7b 100644
--- a/arch/riscv/cpu/cpu.c
+++ b/arch/riscv/cpu/cpu.c
@@ -17,10 +17,10 @@
* before the bss section is available.
*/
#ifdef CONFIG_OF_PRIOR_STAGE
-phys_addr_t prior_stage_fdt_address __attribute__((section(".data")));
+phys_addr_t prior_stage_fdt_address __section(".data");
#endif
#ifndef CONFIG_XIP
-u32 hart_lottery __attribute__((section(".data"))) = 0;
+u32 hart_lottery __section(".data") = 0;
/*
* The main hart running U-Boot has acquired available_harts_lock until it has
diff --git a/arch/sandbox/include/asm/getopt.h b/arch/sandbox/include/asm/getopt.h
index 3048c2cc30..d2145ad6e2 100644
--- a/arch/sandbox/include/asm/getopt.h
+++ b/arch/sandbox/include/asm/getopt.h
@@ -44,7 +44,7 @@ struct sandbox_cmdline_option {
.callback = sandbox_cmdline_cb_##f, \
}; \
/* Ppointer to the struct in a special section for the linker script */ \
- static __attribute__((section(".u_boot_sandbox_getopt"), used)) \
+ static __used __section(".u_boot_sandbox_getopt") \
struct sandbox_cmdline_option \
*sandbox_cmdline_option_##f##_ptr = \
&sandbox_cmdline_option_##f
diff --git a/arch/sandbox/lib/sections.c b/arch/sandbox/lib/sections.c
index 697a8167dd..2559eeea38 100644
--- a/arch/sandbox/lib/sections.c
+++ b/arch/sandbox/lib/sections.c
@@ -3,10 +3,11 @@
* Copyright 2013 Albert ARIBAUD <albert.u.boot@aribaud.net>
*
*/
+#include <linux/compiler.h>
-char __efi_runtime_start[0] __attribute__((section(".__efi_runtime_start")));
-char __efi_runtime_stop[0] __attribute__((section(".__efi_runtime_stop")));
+char __efi_runtime_start[0] __section(".__efi_runtime_start");
+char __efi_runtime_stop[0] __section(".__efi_runtime_stop");
char __efi_runtime_rel_start[0]
- __attribute__((section(".__efi_runtime_rel_start")));
+ __section(".__efi_runtime_rel_start");
char __efi_runtime_rel_stop[0]
- __attribute__((section(".__efi_runtime_rel_stop")));
+ __section(".__efi_runtime_rel_stop");
diff --git a/arch/x86/cpu/coreboot/tables.c b/arch/x86/cpu/coreboot/tables.c
index c52741ac9d..bb10422905 100644
--- a/arch/x86/cpu/coreboot/tables.c
+++ b/arch/x86/cpu/coreboot/tables.c
@@ -19,7 +19,7 @@ DECLARE_GLOBAL_DATA_PTR;
* with zeroes when transitioning from "ROM", which is really RAM, to other
* RAM.
*/
-struct sysinfo_t lib_sysinfo __attribute__((section(".data")));
+struct sysinfo_t lib_sysinfo __section(".data");
/*
* Some of this is x86 specific, and the rest of it is generic. Right now,
diff --git a/arch/x86/cpu/coreboot/timestamp.c b/arch/x86/cpu/coreboot/timestamp.c
index 0162597809..273c15ee74 100644
--- a/arch/x86/cpu/coreboot/timestamp.c
+++ b/arch/x86/cpu/coreboot/timestamp.c
@@ -23,7 +23,7 @@ struct timestamp_table {
struct timestamp_entry entries[0]; /* Variable number of entries */
} __packed;
-static struct timestamp_table *ts_table __attribute__((section(".data")));
+static struct timestamp_table *ts_table __section(".data");
void timestamp_init(void)
{
diff --git a/arch/x86/lib/sections.c b/arch/x86/lib/sections.c
index 8d1700776d..375029ead0 100644
--- a/arch/x86/lib/sections.c
+++ b/arch/x86/lib/sections.c
@@ -2,10 +2,11 @@
/*
* Copyright 2013 Albert ARIBAUD <albert.u.boot@aribaud.net>
*/
+#include <linux/compiler.h>
-char __efi_runtime_start[0] __attribute__((section(".__efi_runtime_start")));
-char __efi_runtime_stop[0] __attribute__((section(".__efi_runtime_stop")));
+char __efi_runtime_start[0] __section(".__efi_runtime_start");
+char __efi_runtime_stop[0] __section(".__efi_runtime_stop");
char __efi_runtime_rel_start[0]
- __attribute__((section(".__efi_runtime_rel_start")));
+ __section(".__efi_runtime_rel_start");
char __efi_runtime_rel_stop[0]
- __attribute__((section(".__efi_runtime_rel_stop")));
+ __section(".__efi_runtime_rel_stop");
diff --git a/arch/xtensa/cpu/cpu.c b/arch/xtensa/cpu/cpu.c
index 85d3464607..a09e103fc1 100644
--- a/arch/xtensa/cpu/cpu.c
+++ b/arch/xtensa/cpu/cpu.c
@@ -20,7 +20,7 @@
DECLARE_GLOBAL_DATA_PTR;
-gd_t *gd __attribute__((section(".data")));
+gd_t *gd __section(".data");
#if defined(CONFIG_DISPLAY_CPUINFO)
/*
diff --git a/board/bosch/shc/board.c b/board/bosch/shc/board.c
index bfce291691..ffaaaa84f6 100644
--- a/board/bosch/shc/board.c
+++ b/board/bosch/shc/board.c
@@ -45,7 +45,7 @@
DECLARE_GLOBAL_DATA_PTR;
-static struct shc_eeprom __attribute__((section(".data"))) header;
+static struct shc_eeprom __section(".data") header;
static int shc_eeprom_valid;
/*
diff --git a/board/broadcom/bcmstb/bcmstb.c b/board/broadcom/bcmstb/bcmstb.c
index f6bdf1f5f4..1daa350e1d 100644
--- a/board/broadcom/bcmstb/bcmstb.c
+++ b/board/broadcom/bcmstb/bcmstb.c
@@ -22,7 +22,7 @@
DECLARE_GLOBAL_DATA_PTR;
-#define BCMSTB_DATA_SECTION __attribute__((section(".data")))
+#define BCMSTB_DATA_SECTION __section(".data")
struct bcmstb_boot_parameters bcmstb_boot_parameters BCMSTB_DATA_SECTION;
diff --git a/board/samsung/arndale/arndale_spl.c b/board/samsung/arndale/arndale_spl.c
index baa5048335..6ad0273e04 100644
--- a/board/samsung/arndale/arndale_spl.c
+++ b/board/samsung/arndale/arndale_spl.c
@@ -10,7 +10,7 @@
/* Parameters of early board initialization in SPL */
static struct spl_machine_param machine_param
- __attribute__((section(".machine_param"))) = {
+ __section(".machine_param") = {
.signature = SIGNATURE,
.version = 1,
.params = "vmubfasirM",
diff --git a/board/samsung/smdk5250/smdk5250_spl.c b/board/samsung/smdk5250/smdk5250_spl.c
index eb25dfc0a0..b0ef34dd6a 100644
--- a/board/samsung/smdk5250/smdk5250_spl.c
+++ b/board/samsung/smdk5250/smdk5250_spl.c
@@ -12,7 +12,7 @@
/* Parameters of early board initialization in SPL */
static struct spl_machine_param machine_param
- __attribute__((section(".machine_param"))) = {
+ __section(".machine_param") = {
.signature = SIGNATURE,
.version = 1,
.params = "vmubfasirM",
diff --git a/board/samsung/smdk5420/smdk5420_spl.c b/board/samsung/smdk5420/smdk5420_spl.c
index 72748ec089..84126f5608 100644
--- a/board/samsung/smdk5420/smdk5420_spl.c
+++ b/board/samsung/smdk5420/smdk5420_spl.c
@@ -12,7 +12,7 @@
/* Parameters of early board initialization in SPL */
static struct spl_machine_param machine_param
- __attribute__((section(".machine_param"))) = {
+ __section(".machine_param") = {
.signature = SIGNATURE,
.version = 1,
.params = "vmubfasirM",
diff --git a/board/siemens/draco/board.c b/board/siemens/draco/board.c
index b512bdbfab..01fdfb5cb4 100644
--- a/board/siemens/draco/board.c
+++ b/board/siemens/draco/board.c
@@ -41,7 +41,7 @@
#include <nand.h>
#ifdef CONFIG_SPL_BUILD
-static struct draco_baseboard_id __attribute__((section(".data"))) settings;
+static struct draco_baseboard_id __section(".data") settings;
#if DDR_PLL_FREQ == 303
#if !defined(CONFIG_TARGET_ETAMIN)
diff --git a/board/xilinx/common/fru_ops.c b/board/xilinx/common/fru_ops.c
index 44f0913f2e..6ed63bb7ee 100644
--- a/board/xilinx/common/fru_ops.c
+++ b/board/xilinx/common/fru_ops.c
@@ -14,7 +14,7 @@
#include "fru.h"
-struct fru_table fru_data __section(.data);
+struct fru_table fru_data __section(".data");
static u16 fru_cal_area_len(u8 len)
{
diff --git a/drivers/bios_emulator/biosemu.c b/drivers/bios_emulator/biosemu.c
index 9d4f07c074..82befbae66 100644
--- a/drivers/bios_emulator/biosemu.c
+++ b/drivers/bios_emulator/biosemu.c
@@ -50,7 +50,7 @@
#include "biosemui.h"
BE_sysEnv _BE_env = {{0}};
-static X86EMU_memFuncs _BE_mem __attribute__((section(GOT2_TYPE))) = {
+static X86EMU_memFuncs _BE_mem __section(GOT2_TYPE) = {
BE_rdb,
BE_rdw,
BE_rdl,
@@ -59,7 +59,7 @@ static X86EMU_memFuncs _BE_mem __attribute__((section(GOT2_TYPE))) = {
BE_wrl,
};
-static X86EMU_pioFuncs _BE_pio __attribute__((section(GOT2_TYPE))) = {
+static X86EMU_pioFuncs _BE_pio __section(GOT2_TYPE) = {
BE_inb,
BE_inw,
BE_inl,
diff --git a/drivers/firmware/psci.c b/drivers/firmware/psci.c
index 68953cc4f4..a87c8799b7 100644
--- a/drivers/firmware/psci.c
+++ b/drivers/firmware/psci.c
@@ -29,7 +29,7 @@
#if CONFIG_IS_ENABLED(EFI_LOADER)
int __efi_runtime_data psci_method;
#else
-int psci_method __attribute__ ((section(".data")));
+int psci_method __section(".data");
#endif
unsigned long __efi_runtime invoke_psci_fn
diff --git a/drivers/pinctrl/nxp/pinctrl-imx5.c b/drivers/pinctrl/nxp/pinctrl-imx5.c
index 71e0c94c96..b32b748cfc 100644
--- a/drivers/pinctrl/nxp/pinctrl-imx5.c
+++ b/drivers/pinctrl/nxp/pinctrl-imx5.c
@@ -10,7 +10,7 @@
#include "pinctrl-imx.h"
-static struct imx_pinctrl_soc_info imx5_pinctrl_soc_info __attribute__((section(".data")));
+static struct imx_pinctrl_soc_info imx5_pinctrl_soc_info __section(".data");
static int imx5_pinctrl_probe(struct udevice *dev)
{
diff --git a/drivers/pinctrl/nxp/pinctrl-imx7.c b/drivers/pinctrl/nxp/pinctrl-imx7.c
index 8301413ac7..77ddb8e0b9 100644
--- a/drivers/pinctrl/nxp/pinctrl-imx7.c
+++ b/drivers/pinctrl/nxp/pinctrl-imx7.c
@@ -9,7 +9,7 @@
#include "pinctrl-imx.h"
-static struct imx_pinctrl_soc_info imx7_pinctrl_soc_info __attribute__((section(".data")));
+static struct imx_pinctrl_soc_info imx7_pinctrl_soc_info __section(".data");
static struct imx_pinctrl_soc_info imx7_lpsr_pinctrl_soc_info = {
.flags = ZERO_OFFSET_VALID,
diff --git a/drivers/pinctrl/nxp/pinctrl-imx8m.c b/drivers/pinctrl/nxp/pinctrl-imx8m.c
index 99c6d014d6..6ea66a080b 100644
--- a/drivers/pinctrl/nxp/pinctrl-imx8m.c
+++ b/drivers/pinctrl/nxp/pinctrl-imx8m.c
@@ -8,7 +8,7 @@
#include "pinctrl-imx.h"
-static struct imx_pinctrl_soc_info imx8mq_pinctrl_soc_info __attribute__((section(".data")));
+static struct imx_pinctrl_soc_info imx8mq_pinctrl_soc_info __section(".data");
static int imx8mq_pinctrl_probe(struct udevice *dev)
{
diff --git a/drivers/power/pmic/pmic_tps62362.c b/drivers/power/pmic/pmic_tps62362.c
index 76fd14db59..59190d6f67 100644
--- a/drivers/power/pmic/pmic_tps62362.c
+++ b/drivers/power/pmic/pmic_tps62362.c
@@ -11,7 +11,7 @@
#include <power/tps62362.h>
#if CONFIG_IS_ENABLED(DM_I2C)
-struct udevice *tps62362_dev __attribute__((section(".data"))) = NULL;
+struct udevice *tps62362_dev __section(".data") = NULL;
#endif
/**
diff --git a/drivers/power/pmic/pmic_tps65217.c b/drivers/power/pmic/pmic_tps65217.c
index 54b5bed99a..c7f532df4d 100644
--- a/drivers/power/pmic/pmic_tps65217.c
+++ b/drivers/power/pmic/pmic_tps65217.c
@@ -8,7 +8,7 @@
#include <i2c.h>
#include <power/tps65217.h>
-struct udevice *tps65217_dev __attribute__((section(".data"))) = NULL;
+struct udevice *tps65217_dev __section(".data") = NULL;
/**
* tps65217_reg_read() - Generic function that can read a TPS65217 register
diff --git a/drivers/power/pmic/pmic_tps65218.c b/drivers/power/pmic/pmic_tps65218.c
index f8bae4545c..6717490180 100644
--- a/drivers/power/pmic/pmic_tps65218.c
+++ b/drivers/power/pmic/pmic_tps65218.c
@@ -86,7 +86,7 @@ int tps65218_reg_write(uchar prot_level, uchar dest_reg, uchar dest_val,
return 0;
}
#else
-struct udevice *tps65218_dev __attribute__((section(".data"))) = NULL;
+struct udevice *tps65218_dev __section(".data") = NULL;
int tps65218_reg_read(uchar dest_reg, uchar *dest_val)
{
diff --git a/drivers/power/pmic/pmic_tps65910.c b/drivers/power/pmic/pmic_tps65910.c
index 84a58c28d8..fcd0a654a8 100644
--- a/drivers/power/pmic/pmic_tps65910.c
+++ b/drivers/power/pmic/pmic_tps65910.c
@@ -8,7 +8,7 @@
#include <i2c.h>
#include <power/tps65910.h>
-struct udevice *tps65910_dev __attribute__((section(".data"))) = NULL;
+struct udevice *tps65910_dev __section(".data") = NULL;
static inline int tps65910_read_reg(int addr, uchar *buf)
{
diff --git a/drivers/serial/serial_pl01x.c b/drivers/serial/serial_pl01x.c
index 4f9de0da76..5283d5ed11 100644
--- a/drivers/serial/serial_pl01x.c
+++ b/drivers/serial/serial_pl01x.c
@@ -30,8 +30,8 @@ DECLARE_GLOBAL_DATA_PTR;
#ifndef CONFIG_DM_SERIAL
static volatile unsigned char *const port[] = CONFIG_PL01x_PORTS;
-static enum pl01x_type pl01x_type __attribute__ ((section(".data")));
-static struct pl01x_regs *base_regs __attribute__ ((section(".data")));
+static enum pl01x_type pl01x_type __section(".data");
+static struct pl01x_regs *base_regs __section(".data");
#define NUM_PORTS (sizeof(port)/sizeof(port[0]))
#endif
diff --git a/include/efi_loader.h b/include/efi_loader.h
index 68daa1a4a9..e38b41952d 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -670,8 +670,8 @@ ssize_t efi_dp_check_length(const struct efi_device_path *dp,
* Use these to indicate that your code / data should go into the EFI runtime
* section and thus still be available when the OS is running
*/
-#define __efi_runtime_data __attribute__ ((section (".data.efi_runtime")))
-#define __efi_runtime __attribute__ ((section (".text.efi_runtime")))
+#define __efi_runtime_data __section(".data.efi_runtime")
+#define __efi_runtime __section(".text.efi_runtime")
/* Indicate supported runtime services */
efi_status_t efi_init_runtime_supported(void);
diff --git a/include/linker_lists.h b/include/linker_lists.h
index fd98ecd297..0259d34919 100644
--- a/include/linker_lists.h
+++ b/include/linker_lists.h
@@ -69,8 +69,8 @@
*/
#define ll_entry_declare(_type, _name, _list) \
_type _u_boot_list_2_##_list##_2_##_name __aligned(4) \
- __attribute__((unused, \
- section(".u_boot_list_2_"#_list"_2_"#_name)))
+ __attribute__((unused)) \
+ __section(".u_boot_list_2_"#_list"_2_"#_name)
/**
* ll_entry_declare_list() - Declare a list of link-generated array entries
@@ -92,8 +92,8 @@
*/
#define ll_entry_declare_list(_type, _name, _list) \
_type _u_boot_list_2_##_list##_2_##_name[] __aligned(4) \
- __attribute__((unused, \
- section(".u_boot_list_2_"#_list"_2_"#_name)))
+ __attribute__((unused)) \
+ __section(".u_boot_list_2_"#_list"_2_"#_name)
/*
* We need a 0-byte-size type for iterator symbols, and the compiler
@@ -125,8 +125,8 @@
#define ll_entry_start(_type, _list) \
({ \
static char start[0] __aligned(CONFIG_LINKER_LIST_ALIGN) \
- __attribute__((unused, \
- section(".u_boot_list_2_"#_list"_1"))); \
+ __attribute__((unused)) \
+ __section(".u_boot_list_2_"#_list"_1"); \
(_type *)&start; \
})
@@ -151,8 +151,8 @@
*/
#define ll_entry_end(_type, _list) \
({ \
- static char end[0] __aligned(4) __attribute__((unused, \
- section(".u_boot_list_2_"#_list"_3"))); \
+ static char end[0] __aligned(4) __attribute__((unused)) \
+ __section(".u_boot_list_2_"#_list"_3"); \
(_type *)&end; \
})
/**
@@ -229,8 +229,8 @@
*/
#define ll_start(_type) \
({ \
- static char start[0] __aligned(4) __attribute__((unused, \
- section(".u_boot_list_1"))); \
+ static char start[0] __aligned(4) __attribute__((unused)) \
+ __section(".u_boot_list_1"); \
(_type *)&start; \
})
@@ -252,8 +252,8 @@
*/
#define ll_end(_type) \
({ \
- static char end[0] __aligned(4) __attribute__((unused, \
- section(".u_boot_list_3"))); \
+ static char end[0] __aligned(4) __attribute__((unused)) \
+ __section(".u_boot_list_3"); \
(_type *)&end; \
})
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index 5e3b3c08e9..82a8a4ede9 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -24,7 +24,7 @@ void ftrace_likely_update(struct ftrace_likely_data *f, int val,
long ______r; \
static struct ftrace_likely_data \
__aligned(4) \
- __section(_ftrace_annotated_branch) \
+ __section("_ftrace_annotated_branch") \
______f = { \
.data.func = __func__, \
.data.file = __FILE__, \
@@ -60,7 +60,7 @@ void ftrace_likely_update(struct ftrace_likely_data *f, int val,
#define __trace_if_value(cond) ({ \
static struct ftrace_branch_data \
__aligned(4) \
- __section(_ftrace_branch) \
+ __section("_ftrace_branch") \
__if_trace = { \
.func = __func__, \
.file = __FILE__, \
@@ -118,7 +118,7 @@ void ftrace_likely_update(struct ftrace_likely_data *f, int val,
".popsection\n\t"
/* Annotate a C jump table to allow objtool to follow the code flow */
-#define __annotate_jump_table __section(.rodata..c_jump_table)
+#define __annotate_jump_table __section(".rodata..c_jump_table")
#else
#define annotate_reachable()
@@ -294,7 +294,7 @@ unsigned long read_word_at_a_time(const void *addr)
* visible to the compiler.
*/
#define __ADDRESSABLE(sym) \
- static void * __section(.discard.addressable) __used \
+ static void * __section(".discard.addressable") __used \
__PASTE(__addressable_##sym, __LINE__) = (void *)&sym;
/**
diff --git a/include/linux/compiler_attributes.h b/include/linux/compiler_attributes.h
index cdf0165966..44c9a08d73 100644
--- a/include/linux/compiler_attributes.h
+++ b/include/linux/compiler_attributes.h
@@ -246,7 +246,7 @@
* gcc: https://gcc.gnu.org/onlinedocs/gcc/Common-Variable-Attributes.html#index-section-variable-attribute
* clang: https://clang.llvm.org/docs/AttributeReference.html#section-declspec-allocate
*/
-#define __section(S) __attribute__((__section__(#S)))
+#define __section(S) __attribute__((__section__(S)))
/*
* gcc: https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-unused-function-attribute
diff --git a/lib/trace.c b/lib/trace.c
index 9e34b19537..505a31806c 100644
--- a/lib/trace.c
+++ b/lib/trace.c
@@ -13,8 +13,8 @@
DECLARE_GLOBAL_DATA_PTR;
-static char trace_enabled __attribute__((section(".data")));
-static char trace_inited __attribute__((section(".data")));
+static char trace_enabled __section(".data");
+static char trace_inited __section(".data");
/* The header block at the start of the trace memory area */
struct trace_hdr {
--
2.26.2
^ permalink raw reply related [flat|nested] 139+ messages in thread* [PATCH u-boot 06/39] treewide: Convert macro and uses of __section(foo) to __section("foo")
2021-03-07 4:25 ` [PATCH u-boot 06/39] treewide: Convert macro and uses of __section(foo) to __section("foo") Marek Behún
@ 2021-03-08 7:27 ` Bin Meng
0 siblings, 0 replies; 139+ messages in thread
From: Bin Meng @ 2021-03-08 7:27 UTC (permalink / raw)
To: u-boot
On Sun, Mar 7, 2021 at 12:26 PM Marek Beh?n <marek.behun@nic.cz> wrote:
>
> This commit does the same thing as Linux commit 33def8498fdd.
>
> Use a more generic form for __section that requires quotes to avoid
> complications with clang and gcc differences.
>
> Remove the quote operator # from compiler_attributes.h __section macro.
>
> Convert all unquoted __section(foo) uses to quoted __section("foo").
> Also convert __attribute__((section("foo"))) uses to __section("foo")
> even if the __attribute__ has multiple list entry forms.
>
> Signed-off-by: Marek Beh?n <marek.behun@nic.cz>
> ---
> arch/arm/cpu/arm926ejs/spear/spl.c | 2 +-
> arch/arm/cpu/armv7/ls102xa/ls102xa_psci.c | 2 +-
> arch/arm/cpu/armv8/fsl-layerscape/spl.c | 2 +-
> arch/arm/cpu/armv8/spl_data.c | 4 +--
> arch/arm/include/asm/secure.h | 6 ++---
> arch/arm/include/asm/setup.h | 2 +-
> arch/arm/lib/sections.c | 31 ++++++++++++-----------
> arch/arm/lib/spl.c | 2 +-
> arch/arm/mach-at91/spl.c | 2 +-
> arch/arm/mach-k3/am6_init.c | 2 +-
> arch/arm/mach-k3/j721e_init.c | 4 +--
> arch/arm/mach-mvebu/mbus.c | 4 +--
> arch/arm/mach-mvebu/timer.c | 2 +-
> arch/arm/mach-nexell/clock.c | 6 ++---
> arch/arm/mach-nexell/timer.c | 6 ++---
> arch/arm/mach-socfpga/spl_a10.c | 2 +-
> arch/arm/mach-sunxi/board.c | 2 +-
> arch/arm/mach-tegra/board.c | 2 +-
> arch/arm/mach-tegra/cboot.c | 8 +++---
> arch/mips/mach-jz47xx/jz4780/jz4780.c | 2 +-
> arch/nds32/include/asm/setup.h | 6 ++---
> arch/powerpc/include/asm/cache.h | 4 +--
> arch/riscv/cpu/cpu.c | 4 +--
> arch/sandbox/include/asm/getopt.h | 2 +-
> arch/sandbox/lib/sections.c | 9 ++++---
> arch/x86/cpu/coreboot/tables.c | 2 +-
> arch/x86/cpu/coreboot/timestamp.c | 2 +-
> arch/x86/lib/sections.c | 9 ++++---
> arch/xtensa/cpu/cpu.c | 2 +-
> board/bosch/shc/board.c | 2 +-
> board/broadcom/bcmstb/bcmstb.c | 2 +-
> board/samsung/arndale/arndale_spl.c | 2 +-
> board/samsung/smdk5250/smdk5250_spl.c | 2 +-
> board/samsung/smdk5420/smdk5420_spl.c | 2 +-
> board/siemens/draco/board.c | 2 +-
> board/xilinx/common/fru_ops.c | 2 +-
> drivers/bios_emulator/biosemu.c | 4 +--
> drivers/firmware/psci.c | 2 +-
> drivers/pinctrl/nxp/pinctrl-imx5.c | 2 +-
> drivers/pinctrl/nxp/pinctrl-imx7.c | 2 +-
> drivers/pinctrl/nxp/pinctrl-imx8m.c | 2 +-
> drivers/power/pmic/pmic_tps62362.c | 2 +-
> drivers/power/pmic/pmic_tps65217.c | 2 +-
> drivers/power/pmic/pmic_tps65218.c | 2 +-
> drivers/power/pmic/pmic_tps65910.c | 2 +-
> drivers/serial/serial_pl01x.c | 4 +--
> include/efi_loader.h | 4 +--
> include/linker_lists.h | 24 +++++++++---------
> include/linux/compiler.h | 8 +++---
> include/linux/compiler_attributes.h | 2 +-
> lib/trace.c | 4 +--
> 51 files changed, 108 insertions(+), 105 deletions(-)
>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
^ permalink raw reply [flat|nested] 139+ messages in thread
* [PATCH u-boot 07/39] compiler.h: align the __ADDRESSABLE macro with Linux' version
2021-03-07 4:24 [PATCH u-boot 00/39] U-Boot LTO (Sandbox + Some ARM boards) Marek Behún
` (5 preceding siblings ...)
2021-03-07 4:25 ` [PATCH u-boot 06/39] treewide: Convert macro and uses of __section(foo) to __section("foo") Marek Behún
@ 2021-03-07 4:25 ` Marek Behún
2021-03-08 7:27 ` Bin Meng
2021-03-07 4:25 ` [PATCH u-boot 08/39] linker_lists: prepare macros to avoid code repetition Marek Behún
` (31 subsequent siblings)
38 siblings, 1 reply; 139+ messages in thread
From: Marek Behún @ 2021-03-07 4:25 UTC (permalink / raw)
To: u-boot
Use UNIQUE_ID in the __ADDRESSABLE macro.
Signed-off-by: Marek Beh?n <marek.behun@nic.cz>
---
include/linux/compiler.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index 82a8a4ede9..98dd3fc4cc 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -295,7 +295,7 @@ unsigned long read_word_at_a_time(const void *addr)
*/
#define __ADDRESSABLE(sym) \
static void * __section(".discard.addressable") __used \
- __PASTE(__addressable_##sym, __LINE__) = (void *)&sym;
+ __UNIQUE_ID(__PASTE(__addressable_,sym)) = (void *)&sym;
/**
* offset_to_ptr - convert a relative memory offset to an absolute pointer
--
2.26.2
^ permalink raw reply related [flat|nested] 139+ messages in thread* [PATCH u-boot 07/39] compiler.h: align the __ADDRESSABLE macro with Linux' version
2021-03-07 4:25 ` [PATCH u-boot 07/39] compiler.h: align the __ADDRESSABLE macro with Linux' version Marek Behún
@ 2021-03-08 7:27 ` Bin Meng
2021-03-08 9:23 ` Marek Behun
0 siblings, 1 reply; 139+ messages in thread
From: Bin Meng @ 2021-03-08 7:27 UTC (permalink / raw)
To: u-boot
On Sun, Mar 7, 2021 at 12:26 PM Marek Beh?n <marek.behun@nic.cz> wrote:
>
> Use UNIQUE_ID in the __ADDRESSABLE macro.
>
> Signed-off-by: Marek Beh?n <marek.behun@nic.cz>
> ---
> include/linux/compiler.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/linux/compiler.h b/include/linux/compiler.h
> index 82a8a4ede9..98dd3fc4cc 100644
> --- a/include/linux/compiler.h
> +++ b/include/linux/compiler.h
> @@ -295,7 +295,7 @@ unsigned long read_word_at_a_time(const void *addr)
> */
> #define __ADDRESSABLE(sym) \
> static void * __section(".discard.addressable") __used \
> - __PASTE(__addressable_##sym, __LINE__) = (void *)&sym;
> + __UNIQUE_ID(__PASTE(__addressable_,sym)) = (void *)&sym;
nits: need one space after ,
>
> /**
> * offset_to_ptr - convert a relative memory offset to an absolute pointer
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
^ permalink raw reply [flat|nested] 139+ messages in thread* [PATCH u-boot 07/39] compiler.h: align the __ADDRESSABLE macro with Linux' version
2021-03-08 7:27 ` Bin Meng
@ 2021-03-08 9:23 ` Marek Behun
2021-03-08 10:29 ` Bin Meng
0 siblings, 1 reply; 139+ messages in thread
From: Marek Behun @ 2021-03-08 9:23 UTC (permalink / raw)
To: u-boot
On Mon, 8 Mar 2021 15:27:41 +0800
Bin Meng <bmeng.cn@gmail.com> wrote:
> > #define __ADDRESSABLE(sym) \
> > static void * __section(".discard.addressable") __used \
> > - __PASTE(__addressable_##sym, __LINE__) = (void *)&sym;
> > + __UNIQUE_ID(__PASTE(__addressable_,sym)) = (void *)&sym;
>
> nits: need one space after ,
This is copy-paster from Linux, so it should be first fixed there.
^ permalink raw reply [flat|nested] 139+ messages in thread* [PATCH u-boot 07/39] compiler.h: align the __ADDRESSABLE macro with Linux' version
2021-03-08 9:23 ` Marek Behun
@ 2021-03-08 10:29 ` Bin Meng
2021-03-08 11:04 ` Marek Behun
0 siblings, 1 reply; 139+ messages in thread
From: Bin Meng @ 2021-03-08 10:29 UTC (permalink / raw)
To: u-boot
On Mon, Mar 8, 2021 at 5:23 PM Marek Behun <marek.behun@nic.cz> wrote:
>
> On Mon, 8 Mar 2021 15:27:41 +0800
> Bin Meng <bmeng.cn@gmail.com> wrote:
>
> > > #define __ADDRESSABLE(sym) \
> > > static void * __section(".discard.addressable") __used \
> > > - __PASTE(__addressable_##sym, __LINE__) = (void *)&sym;
> > > + __UNIQUE_ID(__PASTE(__addressable_,sym)) = (void *)&sym;
> >
> > nits: need one space after ,
>
> This is copy-paster from Linux, so it should be first fixed there.
Do you mean this whole file is copy-paster from Linux? Is this the
only place that U-Boot's version is different? If not, probably we
need to do a sync with the Linux one.
Regards,
Bin
^ permalink raw reply [flat|nested] 139+ messages in thread* [PATCH u-boot 07/39] compiler.h: align the __ADDRESSABLE macro with Linux' version
2021-03-08 10:29 ` Bin Meng
@ 2021-03-08 11:04 ` Marek Behun
0 siblings, 0 replies; 139+ messages in thread
From: Marek Behun @ 2021-03-08 11:04 UTC (permalink / raw)
To: u-boot
On Mon, 8 Mar 2021 18:29:29 +0800
Bin Meng <bmeng.cn@gmail.com> wrote:
> On Mon, Mar 8, 2021 at 5:23 PM Marek Behun <marek.behun@nic.cz> wrote:
> >
> > On Mon, 8 Mar 2021 15:27:41 +0800
> > Bin Meng <bmeng.cn@gmail.com> wrote:
> >
> > > > #define __ADDRESSABLE(sym) \
> > > > static void * __section(".discard.addressable") __used \
> > > > - __PASTE(__addressable_##sym, __LINE__) = (void *)&sym;
> > > > + __UNIQUE_ID(__PASTE(__addressable_,sym)) = (void *)&sym;
> > >
> > > nits: need one space after ,
> >
> > This is copy-paster from Linux, so it should be first fixed there.
>
> Do you mean this whole file is copy-paster from Linux? Is this the
> only place that U-Boot's version is different? If not, probably we
> need to do a sync with the Linux one.
Currently it is different from Linux's version, but yes, this and other
files are periodically synced with Linux' version.
I am not going to do a whole sync of all these headers in this series,
though.
Marek
^ permalink raw reply [flat|nested] 139+ messages in thread
* [PATCH u-boot 08/39] linker_lists: prepare macros to avoid code repetition
2021-03-07 4:24 [PATCH u-boot 00/39] U-Boot LTO (Sandbox + Some ARM boards) Marek Behún
` (6 preceding siblings ...)
2021-03-07 4:25 ` [PATCH u-boot 07/39] compiler.h: align the __ADDRESSABLE macro with Linux' version Marek Behún
@ 2021-03-07 4:25 ` Marek Behún
2021-03-08 7:44 ` Bin Meng
2021-03-07 4:25 ` [PATCH u-boot 09/39] test/py: improve regular expression for ut subtest symbol matcher Marek Behún
` (30 subsequent siblings)
38 siblings, 1 reply; 139+ messages in thread
From: Marek Behún @ 2021-03-07 4:25 UTC (permalink / raw)
To: u-boot
Prepare private macros expanding to linker list entry symbol name and
declaration to avoid nasty code repetition in the next patch.
We also avoid some code repetition in current code with these macros.
Signed-off-by: Marek Beh?n <marek.behun@nic.cz>
---
include/linker_lists.h | 46 ++++++++++++++++++++++++++++--------------
1 file changed, 31 insertions(+), 15 deletions(-)
diff --git a/include/linker_lists.h b/include/linker_lists.h
index 0259d34919..815a90691a 100644
--- a/include/linker_lists.h
+++ b/include/linker_lists.h
@@ -19,6 +19,27 @@
#if !defined(__ASSEMBLY__)
+/**
+ * __llname() - Private macro expanding to symbol name for linker list entry
+ * @_name: Name of the entry
+ * @_list: name of the list. Should contain only characters allowed
+ * in a C variable name!
+ */
+#define __llname(_name, _list) \
+ _u_boot_list_2_##_list##_2_##_name
+
+/**
+ * __lldecl() - Private macro expanding to declaration of linker list entry
+ * @_type: Data type of the entry
+ * @_name: Name of the entry
+ * @_list: name of the list. Should contain only characters allowed
+ * in a C variable name!
+ */
+#define __lldecl(_type, _name, _list) \
+ _type __aligned(4) __attribute__((unused)) \
+ __section(".u_boot_list_2_"#_list"_2_"#_name) \
+ __llname(_name, _list)
+
/**
* llsym() - Access a linker-generated array entry
* @_type: Data type of the entry
@@ -27,7 +48,7 @@
* in a C variable name!
*/
#define llsym(_type, _name, _list) \
- ((_type *)&_u_boot_list_2_##_list##_2_##_name)
+ ((_type *)&__llname(_name, _list))
/**
* ll_entry_declare() - Declare linker-generated array entry
@@ -67,10 +88,8 @@
* .y = 4,
* };
*/
-#define ll_entry_declare(_type, _name, _list) \
- _type _u_boot_list_2_##_list##_2_##_name __aligned(4) \
- __attribute__((unused)) \
- __section(".u_boot_list_2_"#_list"_2_"#_name)
+#define ll_entry_declare(_type, _name, _list) \
+ __lldecl(_type, _name, _list)
/**
* ll_entry_declare_list() - Declare a list of link-generated array entries
@@ -90,10 +109,8 @@
* { .x = 1, .y = 7 }
* };
*/
-#define ll_entry_declare_list(_type, _name, _list) \
- _type _u_boot_list_2_##_list##_2_##_name[] __aligned(4) \
- __attribute__((unused)) \
- __section(".u_boot_list_2_"#_list"_2_"#_name)
+#define ll_entry_declare_list(_type, _name, _list) \
+ __lldecl(_type, _name, _list)[]
/*
* We need a 0-byte-size type for iterator symbols, and the compiler
@@ -203,12 +220,11 @@
* ...
* struct my_sub_cmd *c = ll_entry_get(struct my_sub_cmd, my_sub_cmd, cmd_sub);
*/
-#define ll_entry_get(_type, _name, _list) \
- ({ \
- extern _type _u_boot_list_2_##_list##_2_##_name; \
- _type *_ll_result = \
- &_u_boot_list_2_##_list##_2_##_name; \
- _ll_result; \
+#define ll_entry_get(_type, _name, _list) \
+ ({ \
+ extern _type __llname(_name, _list); \
+ _type *_ll_result = &__llname(_name, _list); \
+ _ll_result; \
})
/**
--
2.26.2
^ permalink raw reply related [flat|nested] 139+ messages in thread* [PATCH u-boot 09/39] test/py: improve regular expression for ut subtest symbol matcher
2021-03-07 4:24 [PATCH u-boot 00/39] U-Boot LTO (Sandbox + Some ARM boards) Marek Behún
` (7 preceding siblings ...)
2021-03-07 4:25 ` [PATCH u-boot 08/39] linker_lists: prepare macros to avoid code repetition Marek Behún
@ 2021-03-07 4:25 ` Marek Behún
2021-03-07 4:25 ` [PATCH u-boot 10/39] linker_lists: declare lists and entries as __ADDRESSABLE for LTO Marek Behún
` (29 subsequent siblings)
38 siblings, 0 replies; 139+ messages in thread
From: Marek Behún @ 2021-03-07 4:25 UTC (permalink / raw)
To: u-boot
Improve the regular expression that matches unittest symbols in
u-boot.sym.
Currently we do not enforce no prefix in symbol string, but with the
soon to come change in linker lists declaring lists and entries with the
__ADDRESSABLE macro (because of LTO), the symbol file will contain for
every symbol of the form
_u_boot_list_2_X_2_Y
also symbol
__UNIQUE_ID___addressable__u_boot_list_2_X_2_YN,
(where N at the end is some number).
In order to avoid matching these additional symbols, ensure that the
character before "_u_boot_list_2" is not a symbol name character.
Signed-off-by: Marek Beh?n <marek.behun@nic.cz>
---
test/py/conftest.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/test/py/conftest.py b/test/py/conftest.py
index 9bfd926345..3ea3fa5220 100644
--- a/test/py/conftest.py
+++ b/test/py/conftest.py
@@ -226,7 +226,7 @@ def pytest_configure(config):
import u_boot_console_exec_attach
console = u_boot_console_exec_attach.ConsoleExecAttach(log, ubconfig)
-re_ut_test_list = re.compile(r'_u_boot_list_2_(.*)_test_2_\1_test_(.*)\s*$')
+re_ut_test_list = re.compile(r'[^a-zA-Z0-9_]_u_boot_list_2_(.*)_test_2_\1_test_(.*)\s*$')
def generate_ut_subtest(metafunc, fixture_name, sym_path):
"""Provide parametrization for a ut_subtest fixture.
--
2.26.2
^ permalink raw reply related [flat|nested] 139+ messages in thread* [PATCH u-boot 10/39] linker_lists: declare lists and entries as __ADDRESSABLE for LTO
2021-03-07 4:24 [PATCH u-boot 00/39] U-Boot LTO (Sandbox + Some ARM boards) Marek Behún
` (8 preceding siblings ...)
2021-03-07 4:25 ` [PATCH u-boot 09/39] test/py: improve regular expression for ut subtest symbol matcher Marek Behún
@ 2021-03-07 4:25 ` Marek Behún
2021-03-08 7:44 ` Bin Meng
2021-03-07 4:25 ` [PATCH u-boot 11/39] binman: declare symbols externally visible Marek Behún
` (28 subsequent siblings)
38 siblings, 1 reply; 139+ messages in thread
From: Marek Behún @ 2021-03-07 4:25 UTC (permalink / raw)
To: u-boot
Use the __ADDRESSABLE() macro to make entries and lists declared by
ll_entry_declare() and ll_entry_declare_list() addressable so that when
building with LTO the compiler does not optimize this data away.
Signed-off-by: Marek Beh?n <marek.behun@nic.cz>
---
include/linker_lists.h | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/include/linker_lists.h b/include/linker_lists.h
index 815a90691a..c9c3b3c2ad 100644
--- a/include/linker_lists.h
+++ b/include/linker_lists.h
@@ -88,7 +88,9 @@
* .y = 4,
* };
*/
-#define ll_entry_declare(_type, _name, _list) \
+#define ll_entry_declare(_type, _name, _list) \
+ __lldecl(_type, _name, _list); \
+ __ADDRESSABLE(__llname(_name, _list)); \
__lldecl(_type, _name, _list)
/**
@@ -109,7 +111,9 @@
* { .x = 1, .y = 7 }
* };
*/
-#define ll_entry_declare_list(_type, _name, _list) \
+#define ll_entry_declare_list(_type, _name, _list) \
+ __lldecl(_type, _name, _list)[]; \
+ __ADDRESSABLE(__llname(_name, _list)); \
__lldecl(_type, _name, _list)[]
/*
--
2.26.2
^ permalink raw reply related [flat|nested] 139+ messages in thread* [PATCH u-boot 11/39] binman: declare symbols externally visible
2021-03-07 4:24 [PATCH u-boot 00/39] U-Boot LTO (Sandbox + Some ARM boards) Marek Behún
` (9 preceding siblings ...)
2021-03-07 4:25 ` [PATCH u-boot 10/39] linker_lists: declare lists and entries as __ADDRESSABLE for LTO Marek Behún
@ 2021-03-07 4:25 ` Marek Behún
2021-03-07 4:59 ` Marek Behun
2021-03-07 4:25 ` [PATCH u-boot 12/39] string: make memcpy() and memset() visible to fix LTO linking errors Marek Behún
` (27 subsequent siblings)
38 siblings, 1 reply; 139+ messages in thread
From: Marek Behún @ 2021-03-07 4:25 UTC (permalink / raw)
To: u-boot
Use the `externally_visible` attribute to declare binman symbols
externally visible, so that when building with LTO the compiler does not
optimize this data away.
Signed-off-by: Marek Beh?n <marek.behun@nic.cz>
---
include/binman_sym.h | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/include/binman_sym.h b/include/binman_sym.h
index 72e6765fe5..f9c0e681c9 100644
--- a/include/binman_sym.h
+++ b/include/binman_sym.h
@@ -34,7 +34,8 @@
*/
#define binman_sym_declare(_type, _entry_name, _prop_name) \
_type binman_symname(_entry_name, _prop_name) \
- __attribute__((aligned(4), unused, section(".binman_sym")))
+ __attribute__((aligned(4), unused, externally_visible, \
+ section(".binman_sym")))
/**
* binman_sym_extern() - Declare a extern symbol that will be used at run-time
@@ -59,7 +60,7 @@
*/
#define binman_sym_declare_optional(_type, _entry_name, _prop_name) \
_type binman_symname(_entry_name, _prop_name) \
- __attribute__((aligned(4), weak, unused, \
+ __attribute__((aligned(4), weak, unused, externally_visible \
section(".binman_sym")))
/**
--
2.26.2
^ permalink raw reply related [flat|nested] 139+ messages in thread* [PATCH u-boot 11/39] binman: declare symbols externally visible
2021-03-07 4:25 ` [PATCH u-boot 11/39] binman: declare symbols externally visible Marek Behún
@ 2021-03-07 4:59 ` Marek Behun
2021-03-08 7:47 ` Bin Meng
0 siblings, 1 reply; 139+ messages in thread
From: Marek Behun @ 2021-03-07 4:59 UTC (permalink / raw)
To: u-boot
I forgot to drop this patch. It is not needed, please ignore it.
Marek
^ permalink raw reply [flat|nested] 139+ messages in thread
* [PATCH u-boot 11/39] binman: declare symbols externally visible
2021-03-07 4:59 ` Marek Behun
@ 2021-03-08 7:47 ` Bin Meng
2021-03-08 9:26 ` Marek Behun
0 siblings, 1 reply; 139+ messages in thread
From: Bin Meng @ 2021-03-08 7:47 UTC (permalink / raw)
To: u-boot
Hi Marek,
On Sun, Mar 7, 2021 at 12:59 PM Marek Behun <marek.behun@nic.cz> wrote:
>
> I forgot to drop this patch. It is not needed, please ignore it.
>
Why is this not needed anymore?
Regards,
Bin
^ permalink raw reply [flat|nested] 139+ messages in thread
* [PATCH u-boot 11/39] binman: declare symbols externally visible
2021-03-08 7:47 ` Bin Meng
@ 2021-03-08 9:26 ` Marek Behun
2021-03-08 10:31 ` Bin Meng
0 siblings, 1 reply; 139+ messages in thread
From: Marek Behun @ 2021-03-08 9:26 UTC (permalink / raw)
To: u-boot
On Mon, 8 Mar 2021 15:47:38 +0800
Bin Meng <bmeng.cn@gmail.com> wrote:
> Hi Marek,
>
> On Sun, Mar 7, 2021 at 12:59 PM Marek Behun <marek.behun@nic.cz> wrote:
> >
> > I forgot to drop this patch. It is not needed, please ignore it.
> >
>
> Why is this not needed anymore?
It was not needed at all, binman does not fail when its symbols are not
explicitly declared to be visible.
^ permalink raw reply [flat|nested] 139+ messages in thread
* [PATCH u-boot 11/39] binman: declare symbols externally visible
2021-03-08 9:26 ` Marek Behun
@ 2021-03-08 10:31 ` Bin Meng
2021-03-08 11:07 ` Marek Behun
0 siblings, 1 reply; 139+ messages in thread
From: Bin Meng @ 2021-03-08 10:31 UTC (permalink / raw)
To: u-boot
On Mon, Mar 8, 2021 at 5:26 PM Marek Behun <marek.behun@nic.cz> wrote:
>
> On Mon, 8 Mar 2021 15:47:38 +0800
> Bin Meng <bmeng.cn@gmail.com> wrote:
>
> > Hi Marek,
> >
> > On Sun, Mar 7, 2021 at 12:59 PM Marek Behun <marek.behun@nic.cz> wrote:
> > >
> > > I forgot to drop this patch. It is not needed, please ignore it.
> > >
> >
> > Why is this not needed anymore?
>
> It was not needed at all, binman does not fail when its symbols are not
> explicitly declared to be visible.
Then why was it needed in the previous patch? Or is this due to
undeterminism of LTO?
Regards,
Bin
^ permalink raw reply [flat|nested] 139+ messages in thread
* [PATCH u-boot 11/39] binman: declare symbols externally visible
2021-03-08 10:31 ` Bin Meng
@ 2021-03-08 11:07 ` Marek Behun
0 siblings, 0 replies; 139+ messages in thread
From: Marek Behun @ 2021-03-08 11:07 UTC (permalink / raw)
To: u-boot
On Mon, 8 Mar 2021 18:31:26 +0800
Bin Meng <bmeng.cn@gmail.com> wrote:
> On Mon, Mar 8, 2021 at 5:26 PM Marek Behun <marek.behun@nic.cz> wrote:
> >
> > On Mon, 8 Mar 2021 15:47:38 +0800
> > Bin Meng <bmeng.cn@gmail.com> wrote:
> >
> > > Hi Marek,
> > >
> > > On Sun, Mar 7, 2021 at 12:59 PM Marek Behun <marek.behun@nic.cz> wrote:
> > > >
> > > > I forgot to drop this patch. It is not needed, please ignore it.
> > > >
> > >
> > > Why is this not needed anymore?
> >
> > It was not needed at all, binman does not fail when its symbols are not
> > explicitly declared to be visible.
>
> Then why was it needed in the previous patch? Or is this due to
> undeterminism of LTO?
It wasn't needed. I did not test binman then, I just grepped for all
occurances of __attribute__, found occurances where it looked like it
would break LTO and applied, just to be sure.
^ permalink raw reply [flat|nested] 139+ messages in thread
* [PATCH u-boot 12/39] string: make memcpy() and memset() visible to fix LTO linking errors
2021-03-07 4:24 [PATCH u-boot 00/39] U-Boot LTO (Sandbox + Some ARM boards) Marek Behún
` (10 preceding siblings ...)
2021-03-07 4:25 ` [PATCH u-boot 11/39] binman: declare symbols externally visible Marek Behún
@ 2021-03-07 4:25 ` Marek Behún
2021-03-08 7:56 ` Bin Meng
2021-03-07 4:25 ` [PATCH u-boot 13/39] efi_loader: fix warning when linking with LTO Marek Behún
` (26 subsequent siblings)
38 siblings, 1 reply; 139+ messages in thread
From: Marek Behún @ 2021-03-07 4:25 UTC (permalink / raw)
To: u-boot
It seems that sometimes (happening on ARM64, for example with
turris_mox_defconfig) GCC, when linking with LTO, changes the symbol
names of some functions, for example lib/string.c's memcpy() function to
memcpy.isra.0.
This is a problem however when GCC for a code such as this:
struct some_struct *info = get_some_struct();
struct some struct tmpinfo;
tmpinfo = *info;
emits a call to memcpy() by builtin behaviour, to copy *info to tmpinfo.
memset() can be generated sometimes as well.
This then results in the following linking error:
.../lz4.c:93: undefined reference to `memcpy'
.../uuid.c:206: more undefined references to `memcpy' follow
Make memcpy() and memset() visible by using the __used macro to avoid
this error.
Signed-off-by: Marek Beh?n <marek.behun@nic.cz>
---
lib/string.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/lib/string.c b/lib/string.c
index 73b984123d..bfda3952ee 100644
--- a/lib/string.c
+++ b/lib/string.c
@@ -16,6 +16,7 @@
*/
#include <config.h>
+#include <linux/compiler.h>
#include <linux/types.h>
#include <linux/string.h>
#include <linux/ctype.h>
@@ -490,7 +491,7 @@ char *strswab(const char *s)
*
* Do not use memset() to access IO space, use memset_io() instead.
*/
-void * memset(void * s,int c,size_t count)
+__used void * memset(void * s,int c,size_t count)
{
unsigned long *sl = (unsigned long *) s;
char *s8;
@@ -529,7 +530,7 @@ void * memset(void * s,int c,size_t count)
* You should not use this function to access IO space, use memcpy_toio()
* or memcpy_fromio() instead.
*/
-void * memcpy(void *dest, const void *src, size_t count)
+__used void * memcpy(void *dest, const void *src, size_t count)
{
unsigned long *dl = (unsigned long *)dest, *sl = (unsigned long *)src;
char *d8, *s8;
--
2.26.2
^ permalink raw reply related [flat|nested] 139+ messages in thread* [PATCH u-boot 12/39] string: make memcpy() and memset() visible to fix LTO linking errors
2021-03-07 4:25 ` [PATCH u-boot 12/39] string: make memcpy() and memset() visible to fix LTO linking errors Marek Behún
@ 2021-03-08 7:56 ` Bin Meng
2021-03-08 10:19 ` Marek Behun
0 siblings, 1 reply; 139+ messages in thread
From: Bin Meng @ 2021-03-08 7:56 UTC (permalink / raw)
To: u-boot
Hi Marek,
On Sun, Mar 7, 2021 at 12:26 PM Marek Beh?n <marek.behun@nic.cz> wrote:
>
> It seems that sometimes (happening on ARM64, for example with
> turris_mox_defconfig) GCC, when linking with LTO, changes the symbol
> names of some functions, for example lib/string.c's memcpy() function to
> memcpy.isra.0.
>
> This is a problem however when GCC for a code such as this:
> struct some_struct *info = get_some_struct();
> struct some struct tmpinfo;
> tmpinfo = *info;
> emits a call to memcpy() by builtin behaviour, to copy *info to tmpinfo.
> memset() can be generated sometimes as well.
>
> This then results in the following linking error:
> .../lz4.c:93: undefined reference to `memcpy'
> .../uuid.c:206: more undefined references to `memcpy' follow
>
> Make memcpy() and memset() visible by using the __used macro to avoid
> this error.
This sounds like a GCC bug of using -fno-builtin and -flto. Could you
file a bugzilla to GCC people to get some comments?
>
> Signed-off-by: Marek Beh?n <marek.behun@nic.cz>
> ---
> lib/string.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
Regards,
Bin
^ permalink raw reply [flat|nested] 139+ messages in thread
* [PATCH u-boot 12/39] string: make memcpy() and memset() visible to fix LTO linking errors
2021-03-08 7:56 ` Bin Meng
@ 2021-03-08 10:19 ` Marek Behun
2021-03-08 10:23 ` Pali Rohár
0 siblings, 1 reply; 139+ messages in thread
From: Marek Behun @ 2021-03-08 10:19 UTC (permalink / raw)
To: u-boot
On Mon, 8 Mar 2021 15:56:01 +0800
Bin Meng <bmeng.cn@gmail.com> wrote:
> Hi Marek,
>
> On Sun, Mar 7, 2021 at 12:26 PM Marek Beh?n <marek.behun@nic.cz> wrote:
> >
> > It seems that sometimes (happening on ARM64, for example with
> > turris_mox_defconfig) GCC, when linking with LTO, changes the symbol
> > names of some functions, for example lib/string.c's memcpy() function to
> > memcpy.isra.0.
> >
> > This is a problem however when GCC for a code such as this:
> > struct some_struct *info = get_some_struct();
> > struct some struct tmpinfo;
> > tmpinfo = *info;
> > emits a call to memcpy() by builtin behaviour, to copy *info to tmpinfo.
> > memset() can be generated sometimes as well.
> >
> > This then results in the following linking error:
> > .../lz4.c:93: undefined reference to `memcpy'
> > .../uuid.c:206: more undefined references to `memcpy' follow
> >
> > Make memcpy() and memset() visible by using the __used macro to avoid
> > this error.
>
> This sounds like a GCC bug of using -fno-builtin and -flto. Could you
> file a bugzilla to GCC people to get some comments?
This is not LTO related. -fno-builtin still generates memcpy() call for
the following code:
typedef struct {
int a[40];
char b[50];
int c[60];
} a;
void cp(a *d, const a *s) {
*d = *s;
}
when compiled with
armv7a-hardfloat-linux-gnueabi-gcc -O2 -fno-builtin -ffreestanding \
-nostdlib -S
it produces code
push {r4, lr}
mov ip, #4096
sub ip, sp, ip
str r0, [ip, #4088]
mov r2, #452
bl memcpy
pop {r4, pc}
.size cp, .-cp
I don't think this is a bug. Or if it is, it is a wontfix. Just
implement memcpy into your code, so that gcc does not have to emit
shitstorms of instructions because of assignment operator :)
Marek
^ permalink raw reply [flat|nested] 139+ messages in thread* [PATCH u-boot 12/39] string: make memcpy() and memset() visible to fix LTO linking errors
2021-03-08 10:19 ` Marek Behun
@ 2021-03-08 10:23 ` Pali Rohár
2021-03-08 10:40 ` Bin Meng
0 siblings, 1 reply; 139+ messages in thread
From: Pali Rohár @ 2021-03-08 10:23 UTC (permalink / raw)
To: u-boot
On Monday 08 March 2021 11:19:33 Marek Behun wrote:
> On Mon, 8 Mar 2021 15:56:01 +0800
> Bin Meng <bmeng.cn@gmail.com> wrote:
>
> > Hi Marek,
> >
> > On Sun, Mar 7, 2021 at 12:26 PM Marek Beh?n <marek.behun@nic.cz> wrote:
> > >
> > > It seems that sometimes (happening on ARM64, for example with
> > > turris_mox_defconfig) GCC, when linking with LTO, changes the symbol
> > > names of some functions, for example lib/string.c's memcpy() function to
> > > memcpy.isra.0.
> > >
> > > This is a problem however when GCC for a code such as this:
> > > struct some_struct *info = get_some_struct();
> > > struct some struct tmpinfo;
> > > tmpinfo = *info;
> > > emits a call to memcpy() by builtin behaviour, to copy *info to tmpinfo.
> > > memset() can be generated sometimes as well.
> > >
> > > This then results in the following linking error:
> > > .../lz4.c:93: undefined reference to `memcpy'
> > > .../uuid.c:206: more undefined references to `memcpy' follow
> > >
> > > Make memcpy() and memset() visible by using the __used macro to avoid
> > > this error.
> >
> > This sounds like a GCC bug of using -fno-builtin and -flto. Could you
> > file a bugzilla to GCC people to get some comments?
>
> This is not LTO related. -fno-builtin still generates memcpy() call for
> the following code:
>
> typedef struct {
> int a[40];
> char b[50];
> int c[60];
> } a;
>
> void cp(a *d, const a *s) {
> *d = *s;
> }
>
> when compiled with
> armv7a-hardfloat-linux-gnueabi-gcc -O2 -fno-builtin -ffreestanding \
> -nostdlib -S
>
> it produces code
>
> push {r4, lr}
> mov ip, #4096
> sub ip, sp, ip
> str r0, [ip, #4088]
> mov r2, #452
> bl memcpy
> pop {r4, pc}
> .size cp, .-cp
>
> I don't think this is a bug. Or if it is, it is a wontfix. Just
> implement memcpy into your code, so that gcc does not have to emit
> shitstorms of instructions because of assignment operator :)
>
> Marek
This is not a bug but rather a feature of gcc. Documentation for
-nodefaultlibs and -nostdlib contains:
The compiler may generate calls to "memcmp", "memset", "memcpy" and
"memmove". These entries are usually resolved by entries in libc.
These entry points should be supplied through some other mechanism when
this option is specified.
^ permalink raw reply [flat|nested] 139+ messages in thread* [PATCH u-boot 12/39] string: make memcpy() and memset() visible to fix LTO linking errors
2021-03-08 10:23 ` Pali Rohár
@ 2021-03-08 10:40 ` Bin Meng
2021-03-08 10:55 ` Pali Rohár
0 siblings, 1 reply; 139+ messages in thread
From: Bin Meng @ 2021-03-08 10:40 UTC (permalink / raw)
To: u-boot
On Mon, Mar 8, 2021 at 6:23 PM Pali Roh?r <pali@kernel.org> wrote:
>
> On Monday 08 March 2021 11:19:33 Marek Behun wrote:
> > On Mon, 8 Mar 2021 15:56:01 +0800
> > Bin Meng <bmeng.cn@gmail.com> wrote:
> >
> > > Hi Marek,
> > >
> > > On Sun, Mar 7, 2021 at 12:26 PM Marek Beh?n <marek.behun@nic.cz> wrote:
> > > >
> > > > It seems that sometimes (happening on ARM64, for example with
> > > > turris_mox_defconfig) GCC, when linking with LTO, changes the symbol
> > > > names of some functions, for example lib/string.c's memcpy() function to
> > > > memcpy.isra.0.
> > > >
> > > > This is a problem however when GCC for a code such as this:
> > > > struct some_struct *info = get_some_struct();
> > > > struct some struct tmpinfo;
> > > > tmpinfo = *info;
> > > > emits a call to memcpy() by builtin behaviour, to copy *info to tmpinfo.
> > > > memset() can be generated sometimes as well.
> > > >
> > > > This then results in the following linking error:
> > > > .../lz4.c:93: undefined reference to `memcpy'
> > > > .../uuid.c:206: more undefined references to `memcpy' follow
> > > >
> > > > Make memcpy() and memset() visible by using the __used macro to avoid
> > > > this error.
> > >
> > > This sounds like a GCC bug of using -fno-builtin and -flto. Could you
> > > file a bugzilla to GCC people to get some comments?
> >
> > This is not LTO related. -fno-builtin still generates memcpy() call for
> > the following code:
> >
> > typedef struct {
> > int a[40];
> > char b[50];
> > int c[60];
> > } a;
> >
> > void cp(a *d, const a *s) {
> > *d = *s;
> > }
> >
> > when compiled with
> > armv7a-hardfloat-linux-gnueabi-gcc -O2 -fno-builtin -ffreestanding \
> > -nostdlib -S
> >
> > it produces code
> >
> > push {r4, lr}
> > mov ip, #4096
> > sub ip, sp, ip
> > str r0, [ip, #4088]
> > mov r2, #452
> > bl memcpy
> > pop {r4, pc}
> > .size cp, .-cp
> >
> > I don't think this is a bug. Or if it is, it is a wontfix. Just
> > implement memcpy into your code, so that gcc does not have to emit
> > shitstorms of instructions because of assignment operator :)
> >
> > Marek
>
> This is not a bug but rather a feature of gcc. Documentation for
> -nodefaultlibs and -nostdlib contains:
>
> The compiler may generate calls to "memcmp", "memset", "memcpy" and
> "memmove". These entries are usually resolved by entries in libc.
> These entry points should be supplied through some other mechanism when
> this option is specified.
Yeah I know this. My question was why when LTO is enabled, we have to
explicitly mark these APIs as __used? I should have asked clearly, is
this a bug of LTO?
Regards,
Bin
^ permalink raw reply [flat|nested] 139+ messages in thread* [PATCH u-boot 12/39] string: make memcpy() and memset() visible to fix LTO linking errors
2021-03-08 10:40 ` Bin Meng
@ 2021-03-08 10:55 ` Pali Rohár
2021-03-08 11:31 ` Marek Behun
` (2 more replies)
0 siblings, 3 replies; 139+ messages in thread
From: Pali Rohár @ 2021-03-08 10:55 UTC (permalink / raw)
To: u-boot
On Monday 08 March 2021 18:40:58 Bin Meng wrote:
> On Mon, Mar 8, 2021 at 6:23 PM Pali Roh?r <pali@kernel.org> wrote:
> >
> > On Monday 08 March 2021 11:19:33 Marek Behun wrote:
> > > On Mon, 8 Mar 2021 15:56:01 +0800
> > > Bin Meng <bmeng.cn@gmail.com> wrote:
> > >
> > > > Hi Marek,
> > > >
> > > > On Sun, Mar 7, 2021 at 12:26 PM Marek Beh?n <marek.behun@nic.cz> wrote:
> > > > >
> > > > > It seems that sometimes (happening on ARM64, for example with
> > > > > turris_mox_defconfig) GCC, when linking with LTO, changes the symbol
> > > > > names of some functions, for example lib/string.c's memcpy() function to
> > > > > memcpy.isra.0.
> > > > >
> > > > > This is a problem however when GCC for a code such as this:
> > > > > struct some_struct *info = get_some_struct();
> > > > > struct some struct tmpinfo;
> > > > > tmpinfo = *info;
> > > > > emits a call to memcpy() by builtin behaviour, to copy *info to tmpinfo.
> > > > > memset() can be generated sometimes as well.
> > > > >
> > > > > This then results in the following linking error:
> > > > > .../lz4.c:93: undefined reference to `memcpy'
> > > > > .../uuid.c:206: more undefined references to `memcpy' follow
> > > > >
> > > > > Make memcpy() and memset() visible by using the __used macro to avoid
> > > > > this error.
> > > >
> > > > This sounds like a GCC bug of using -fno-builtin and -flto. Could you
> > > > file a bugzilla to GCC people to get some comments?
> > >
> > > This is not LTO related. -fno-builtin still generates memcpy() call for
> > > the following code:
> > >
> > > typedef struct {
> > > int a[40];
> > > char b[50];
> > > int c[60];
> > > } a;
> > >
> > > void cp(a *d, const a *s) {
> > > *d = *s;
> > > }
> > >
> > > when compiled with
> > > armv7a-hardfloat-linux-gnueabi-gcc -O2 -fno-builtin -ffreestanding \
> > > -nostdlib -S
> > >
> > > it produces code
> > >
> > > push {r4, lr}
> > > mov ip, #4096
> > > sub ip, sp, ip
> > > str r0, [ip, #4088]
> > > mov r2, #452
> > > bl memcpy
> > > pop {r4, pc}
> > > .size cp, .-cp
> > >
> > > I don't think this is a bug. Or if it is, it is a wontfix. Just
> > > implement memcpy into your code, so that gcc does not have to emit
> > > shitstorms of instructions because of assignment operator :)
> > >
> > > Marek
> >
> > This is not a bug but rather a feature of gcc. Documentation for
> > -nodefaultlibs and -nostdlib contains:
> >
> > The compiler may generate calls to "memcmp", "memset", "memcpy" and
> > "memmove". These entries are usually resolved by entries in libc.
> > These entry points should be supplied through some other mechanism when
> > this option is specified.
>
> Yeah I know this. My question was why when LTO is enabled, we have to
> explicitly mark these APIs as __used? I should have asked clearly, is
> this a bug of LTO?
I see... What is the _exact_ command line arguments called when this
linking issue happen? I know that when gcc's LTO is enabled it depends
on other of objects and libraries which are linking. And I'm not sure if
all -whole-archive option can make order of archives independent when
dealing with these builtin function references. At least I cannot find
exact gcc documentation about linking order.
^ permalink raw reply [flat|nested] 139+ messages in thread* [PATCH u-boot 12/39] string: make memcpy() and memset() visible to fix LTO linking errors
2021-03-08 10:55 ` Pali Rohár
@ 2021-03-08 11:31 ` Marek Behun
2021-03-08 11:36 ` Marek Behun
2021-03-12 10:09 ` Marek Behun
2 siblings, 0 replies; 139+ messages in thread
From: Marek Behun @ 2021-03-08 11:31 UTC (permalink / raw)
To: u-boot
On Mon, 8 Mar 2021 11:55:32 +0100
Pali Roh?r <pali@kernel.org> wrote:
> On Monday 08 March 2021 18:40:58 Bin Meng wrote:
> > On Mon, Mar 8, 2021 at 6:23 PM Pali Roh?r <pali@kernel.org> wrote:
> > >
> > > On Monday 08 March 2021 11:19:33 Marek Behun wrote:
> > > > On Mon, 8 Mar 2021 15:56:01 +0800
> > > > Bin Meng <bmeng.cn@gmail.com> wrote:
> > > >
> > > > > Hi Marek,
> > > > >
> > > > > On Sun, Mar 7, 2021 at 12:26 PM Marek Beh?n <marek.behun@nic.cz> wrote:
> > > > > >
> > > > > > It seems that sometimes (happening on ARM64, for example with
> > > > > > turris_mox_defconfig) GCC, when linking with LTO, changes the symbol
> > > > > > names of some functions, for example lib/string.c's memcpy() function to
> > > > > > memcpy.isra.0.
> > > > > >
> > > > > > This is a problem however when GCC for a code such as this:
> > > > > > struct some_struct *info = get_some_struct();
> > > > > > struct some struct tmpinfo;
> > > > > > tmpinfo = *info;
> > > > > > emits a call to memcpy() by builtin behaviour, to copy *info to tmpinfo.
> > > > > > memset() can be generated sometimes as well.
> > > > > >
> > > > > > This then results in the following linking error:
> > > > > > .../lz4.c:93: undefined reference to `memcpy'
> > > > > > .../uuid.c:206: more undefined references to `memcpy' follow
> > > > > >
> > > > > > Make memcpy() and memset() visible by using the __used macro to avoid
> > > > > > this error.
> > > > >
> > > > > This sounds like a GCC bug of using -fno-builtin and -flto. Could you
> > > > > file a bugzilla to GCC people to get some comments?
> > > >
> > > > This is not LTO related. -fno-builtin still generates memcpy() call for
> > > > the following code:
> > > >
> > > > typedef struct {
> > > > int a[40];
> > > > char b[50];
> > > > int c[60];
> > > > } a;
> > > >
> > > > void cp(a *d, const a *s) {
> > > > *d = *s;
> > > > }
> > > >
> > > > when compiled with
> > > > armv7a-hardfloat-linux-gnueabi-gcc -O2 -fno-builtin -ffreestanding \
> > > > -nostdlib -S
> > > >
> > > > it produces code
> > > >
> > > > push {r4, lr}
> > > > mov ip, #4096
> > > > sub ip, sp, ip
> > > > str r0, [ip, #4088]
> > > > mov r2, #452
> > > > bl memcpy
> > > > pop {r4, pc}
> > > > .size cp, .-cp
> > > >
> > > > I don't think this is a bug. Or if it is, it is a wontfix. Just
> > > > implement memcpy into your code, so that gcc does not have to emit
> > > > shitstorms of instructions because of assignment operator :)
> > > >
> > > > Marek
> > >
> > > This is not a bug but rather a feature of gcc. Documentation for
> > > -nodefaultlibs and -nostdlib contains:
> > >
> > > The compiler may generate calls to "memcmp", "memset", "memcpy" and
> > > "memmove". These entries are usually resolved by entries in libc.
> > > These entry points should be supplied through some other mechanism when
> > > this option is specified.
> >
> > Yeah I know this. My question was why when LTO is enabled, we have to
> > explicitly mark these APIs as __used? I should have asked clearly, is
> > this a bug of LTO?
>
> I see... What is the _exact_ command line arguments called when this
> linking issue happen? I know that when gcc's LTO is enabled it depends
> on other of objects and libraries which are linking. And I'm not sure if
> all -whole-archive option can make order of archives independent when
> dealing with these builtin function references. At least I cannot find
> exact gcc documentation about linking order.
remove the __used flag for memcpy, add -save-temps to the final linking
command in order not to delete ltrans assembly files,
compile for turris_mox_defconfig with V=1
the final linking fails and you can study the assembly file it
generated
^ permalink raw reply [flat|nested] 139+ messages in thread* [PATCH u-boot 12/39] string: make memcpy() and memset() visible to fix LTO linking errors
2021-03-08 10:55 ` Pali Rohár
2021-03-08 11:31 ` Marek Behun
@ 2021-03-08 11:36 ` Marek Behun
2021-03-12 10:09 ` Marek Behun
2 siblings, 0 replies; 139+ messages in thread
From: Marek Behun @ 2021-03-08 11:36 UTC (permalink / raw)
To: u-boot
On Mon, 8 Mar 2021 11:55:32 +0100
Pali Roh?r <pali@kernel.org> wrote:
> On Monday 08 March 2021 18:40:58 Bin Meng wrote:
> > On Mon, Mar 8, 2021 at 6:23 PM Pali Roh?r <pali@kernel.org> wrote:
> > >
> > > On Monday 08 March 2021 11:19:33 Marek Behun wrote:
> > > > On Mon, 8 Mar 2021 15:56:01 +0800
> > > > Bin Meng <bmeng.cn@gmail.com> wrote:
> > > >
> > > > > Hi Marek,
> > > > >
> > > > > On Sun, Mar 7, 2021 at 12:26 PM Marek Beh?n <marek.behun@nic.cz> wrote:
> > > > > >
> > > > > > It seems that sometimes (happening on ARM64, for example with
> > > > > > turris_mox_defconfig) GCC, when linking with LTO, changes the symbol
> > > > > > names of some functions, for example lib/string.c's memcpy() function to
> > > > > > memcpy.isra.0.
> > > > > >
> > > > > > This is a problem however when GCC for a code such as this:
> > > > > > struct some_struct *info = get_some_struct();
> > > > > > struct some struct tmpinfo;
> > > > > > tmpinfo = *info;
> > > > > > emits a call to memcpy() by builtin behaviour, to copy *info to tmpinfo.
> > > > > > memset() can be generated sometimes as well.
> > > > > >
> > > > > > This then results in the following linking error:
> > > > > > .../lz4.c:93: undefined reference to `memcpy'
> > > > > > .../uuid.c:206: more undefined references to `memcpy' follow
> > > > > >
> > > > > > Make memcpy() and memset() visible by using the __used macro to avoid
> > > > > > this error.
> > > > >
> > > > > This sounds like a GCC bug of using -fno-builtin and -flto. Could you
> > > > > file a bugzilla to GCC people to get some comments?
> > > >
> > > > This is not LTO related. -fno-builtin still generates memcpy() call for
> > > > the following code:
> > > >
> > > > typedef struct {
> > > > int a[40];
> > > > char b[50];
> > > > int c[60];
> > > > } a;
> > > >
> > > > void cp(a *d, const a *s) {
> > > > *d = *s;
> > > > }
> > > >
> > > > when compiled with
> > > > armv7a-hardfloat-linux-gnueabi-gcc -O2 -fno-builtin -ffreestanding \
> > > > -nostdlib -S
> > > >
> > > > it produces code
> > > >
> > > > push {r4, lr}
> > > > mov ip, #4096
> > > > sub ip, sp, ip
> > > > str r0, [ip, #4088]
> > > > mov r2, #452
> > > > bl memcpy
> > > > pop {r4, pc}
> > > > .size cp, .-cp
> > > >
> > > > I don't think this is a bug. Or if it is, it is a wontfix. Just
> > > > implement memcpy into your code, so that gcc does not have to emit
> > > > shitstorms of instructions because of assignment operator :)
> > > >
> > > > Marek
> > >
> > > This is not a bug but rather a feature of gcc. Documentation for
> > > -nodefaultlibs and -nostdlib contains:
> > >
> > > The compiler may generate calls to "memcmp", "memset", "memcpy" and
> > > "memmove". These entries are usually resolved by entries in libc.
> > > These entry points should be supplied through some other mechanism when
> > > this option is specified.
> >
> > Yeah I know this. My question was why when LTO is enabled, we have to
> > explicitly mark these APIs as __used? I should have asked clearly, is
> > this a bug of LTO?
>
> I see... What is the _exact_ command line arguments called when this
> linking issue happen? I know that when gcc's LTO is enabled it depends
> on other of objects and libraries which are linking. And I'm not sure if
> all -whole-archive option can make order of archives independent when
> dealing with these builtin function references. At least I cannot find
> exact gcc documentation about linking order.
Soo, it seems that the compiler generates a copy of memcpy called
memcpy.isra.0 which is a version with -fipa-sra optimization.
Then it thinks the original memcpy is not used, since it replaces all
calls to memcpy.isra.0, but the original memcpy is still being called
for assignment operator. So maybe it is a bug of gcc, and gcc should
use memcpy.isra.0 for the assignment operator as well...
^ permalink raw reply [flat|nested] 139+ messages in thread* [PATCH u-boot 12/39] string: make memcpy() and memset() visible to fix LTO linking errors
2021-03-08 10:55 ` Pali Rohár
2021-03-08 11:31 ` Marek Behun
2021-03-08 11:36 ` Marek Behun
@ 2021-03-12 10:09 ` Marek Behun
2021-03-12 11:11 ` Bin Meng
2 siblings, 1 reply; 139+ messages in thread
From: Marek Behun @ 2021-03-12 10:09 UTC (permalink / raw)
To: u-boot
I created a gcc bug for this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99559
^ permalink raw reply [flat|nested] 139+ messages in thread
* [PATCH u-boot 13/39] efi_loader: fix warning when linking with LTO
2021-03-07 4:24 [PATCH u-boot 00/39] U-Boot LTO (Sandbox + Some ARM boards) Marek Behún
` (11 preceding siblings ...)
2021-03-07 4:25 ` [PATCH u-boot 12/39] string: make memcpy() and memset() visible to fix LTO linking errors Marek Behún
@ 2021-03-07 4:25 ` Marek Behún
2021-03-08 7:56 ` Bin Meng
2021-03-07 4:25 ` [PATCH u-boot 14/39] lib: crc32: make the crc_table variable non-const Marek Behún
` (25 subsequent siblings)
38 siblings, 1 reply; 139+ messages in thread
From: Marek Behún @ 2021-03-07 4:25 UTC (permalink / raw)
To: u-boot
When linking with LTO, the compiler complains about type mismatch of
variables `__efi_runtime_start`, `__efi_runtime_stop`,
`__efi_runtime_rel_start` and `__efi_runtime_rel_stop`:
include/efi_loader.h:218:21: warning: type of ?__efi_runtime_start?
does not match original
declaration [-Wlto-type-mismatch]
218 | extern unsigned int __efi_runtime_start, __efi_runtime_stop;
| ^
arch/sandbox/lib/sections.c:7:6: note: ?__efi_runtime_start? was
previously declared here
7 | char __efi_runtime_start[0] __attribute__((section(".__efi_run
| ^
Change the type to char[] in include/efi_loader.h.
Signed-off-by: Marek Beh?n <marek.behun@nic.cz>
---
include/efi_loader.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/efi_loader.h b/include/efi_loader.h
index e38b41952d..a8281b3c95 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -215,8 +215,8 @@ extern const efi_guid_t efi_guid_capsule_report;
/* GUID of firmware management protocol */
extern const efi_guid_t efi_guid_firmware_management_protocol;
-extern unsigned int __efi_runtime_start, __efi_runtime_stop;
-extern unsigned int __efi_runtime_rel_start, __efi_runtime_rel_stop;
+extern char __efi_runtime_start[], __efi_runtime_stop[];
+extern char __efi_runtime_rel_start[], __efi_runtime_rel_stop[];
/**
* struct efi_open_protocol_info_item - open protocol info item
--
2.26.2
^ permalink raw reply related [flat|nested] 139+ messages in thread* [PATCH u-boot 13/39] efi_loader: fix warning when linking with LTO
2021-03-07 4:25 ` [PATCH u-boot 13/39] efi_loader: fix warning when linking with LTO Marek Behún
@ 2021-03-08 7:56 ` Bin Meng
0 siblings, 0 replies; 139+ messages in thread
From: Bin Meng @ 2021-03-08 7:56 UTC (permalink / raw)
To: u-boot
On Sun, Mar 7, 2021 at 12:26 PM Marek Beh?n <marek.behun@nic.cz> wrote:
>
> When linking with LTO, the compiler complains about type mismatch of
> variables `__efi_runtime_start`, `__efi_runtime_stop`,
> `__efi_runtime_rel_start` and `__efi_runtime_rel_stop`:
>
> include/efi_loader.h:218:21: warning: type of ?__efi_runtime_start?
> does not match original
> declaration [-Wlto-type-mismatch]
> 218 | extern unsigned int __efi_runtime_start, __efi_runtime_stop;
> | ^
> arch/sandbox/lib/sections.c:7:6: note: ?__efi_runtime_start? was
> previously declared here
> 7 | char __efi_runtime_start[0] __attribute__((section(".__efi_run
> | ^
>
> Change the type to char[] in include/efi_loader.h.
>
> Signed-off-by: Marek Beh?n <marek.behun@nic.cz>
> ---
> include/efi_loader.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
^ permalink raw reply [flat|nested] 139+ messages in thread
* [PATCH u-boot 14/39] lib: crc32: make the crc_table variable non-const
2021-03-07 4:24 [PATCH u-boot 00/39] U-Boot LTO (Sandbox + Some ARM boards) Marek Behún
` (12 preceding siblings ...)
2021-03-07 4:25 ` [PATCH u-boot 13/39] efi_loader: fix warning when linking with LTO Marek Behún
@ 2021-03-07 4:25 ` Marek Behún
2021-03-07 4:46 ` Marek Vasut
2021-03-07 4:25 ` [PATCH u-boot 15/39] Makefile, Makefile.spl: cosmetic change Marek Behún
` (24 subsequent siblings)
38 siblings, 1 reply; 139+ messages in thread
From: Marek Behún @ 2021-03-07 4:25 UTC (permalink / raw)
To: u-boot
When compiling with LTO, the compiler fails with an error saying that
`crc_table` causes a section type conflict with `efi_var_buf`.
This is because both are declared to be in the same section (via macro
`__efi_runtime_data`), but one is const while the other is not.
Make this variable non-const in order to fix this.
Signed-off-by: Marek Beh?n <marek.behun@nic.cz>
---
lib/crc32.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/crc32.c b/lib/crc32.c
index e9be3bf386..c033449cff 100644
--- a/lib/crc32.c
+++ b/lib/crc32.c
@@ -88,7 +88,7 @@ static void __efi_runtime make_crc_table(void)
* Table of CRC-32's of all single-byte values (made by make_crc_table)
*/
-static const uint32_t __efi_runtime_data crc_table[256] = {
+static uint32_t __efi_runtime_data crc_table[256] = {
tole(0x00000000L), tole(0x77073096L), tole(0xee0e612cL), tole(0x990951baL),
tole(0x076dc419L), tole(0x706af48fL), tole(0xe963a535L), tole(0x9e6495a3L),
tole(0x0edb8832L), tole(0x79dcb8a4L), tole(0xe0d5e91eL), tole(0x97d2d988L),
--
2.26.2
^ permalink raw reply related [flat|nested] 139+ messages in thread* [PATCH u-boot 14/39] lib: crc32: make the crc_table variable non-const
2021-03-07 4:25 ` [PATCH u-boot 14/39] lib: crc32: make the crc_table variable non-const Marek Behún
@ 2021-03-07 4:46 ` Marek Vasut
2021-03-07 4:58 ` Marek Behun
0 siblings, 1 reply; 139+ messages in thread
From: Marek Vasut @ 2021-03-07 4:46 UTC (permalink / raw)
To: u-boot
On 3/7/21 5:25 AM, Marek Beh?n wrote:
> When compiling with LTO, the compiler fails with an error saying that
> `crc_table` causes a section type conflict with `efi_var_buf`.
>
> This is because both are declared to be in the same section (via macro
> `__efi_runtime_data`), but one is const while the other is not.
>
> Make this variable non-const in order to fix this.
This does not look right, the crc32 array is constant.
Maybe what you want to do instead if create some __efi_constant_data
section ?
[...]
> diff --git a/lib/crc32.c b/lib/crc32.c
> index e9be3bf386..c033449cff 100644
> --- a/lib/crc32.c
> +++ b/lib/crc32.c
> @@ -88,7 +88,7 @@ static void __efi_runtime make_crc_table(void)
> * Table of CRC-32's of all single-byte values (made by make_crc_table)
> */
>
> -static const uint32_t __efi_runtime_data crc_table[256] = {
> +static uint32_t __efi_runtime_data crc_table[256] = {
> tole(0x00000000L), tole(0x77073096L), tole(0xee0e612cL), tole(0x990951baL),
> tole(0x076dc419L), tole(0x706af48fL), tole(0xe963a535L), tole(0x9e6495a3L),
> tole(0x0edb8832L), tole(0x79dcb8a4L), tole(0xe0d5e91eL), tole(0x97d2d988L),
>
^ permalink raw reply [flat|nested] 139+ messages in thread* [PATCH u-boot 14/39] lib: crc32: make the crc_table variable non-const
2021-03-07 4:46 ` Marek Vasut
@ 2021-03-07 4:58 ` Marek Behun
2021-03-07 5:02 ` Marek Vasut
0 siblings, 1 reply; 139+ messages in thread
From: Marek Behun @ 2021-03-07 4:58 UTC (permalink / raw)
To: u-boot
On Sun, 7 Mar 2021 05:46:24 +0100
Marek Vasut <marex@denx.de> wrote:
> On 3/7/21 5:25 AM, Marek Beh?n wrote:
> > When compiling with LTO, the compiler fails with an error saying that
> > `crc_table` causes a section type conflict with `efi_var_buf`.
> >
> > This is because both are declared to be in the same section (via macro
> > `__efi_runtime_data`), but one is const while the other is not.
> >
> > Make this variable non-const in order to fix this.
>
> This does not look right, the crc32 array is constant.
> Maybe what you want to do instead if create some __efi_constant_data
> section ?
Yes, this was the easier solution, and maybe is not ideal.
I thought it would not be much of a problem since this array can be
nonconstant (generated after boot) if CONFIG_DYNAMIC_CRC_TABLE is
enabled.
Anyway I don't much understand the EFI code so I wanted to poke into it
as little as possible.
Marek
^ permalink raw reply [flat|nested] 139+ messages in thread
* [PATCH u-boot 14/39] lib: crc32: make the crc_table variable non-const
2021-03-07 4:58 ` Marek Behun
@ 2021-03-07 5:02 ` Marek Vasut
2021-03-07 12:26 ` Marek Behun
0 siblings, 1 reply; 139+ messages in thread
From: Marek Vasut @ 2021-03-07 5:02 UTC (permalink / raw)
To: u-boot
On 3/7/21 5:58 AM, Marek Behun wrote:
> On Sun, 7 Mar 2021 05:46:24 +0100
> Marek Vasut <marex@denx.de> wrote:
>
>> On 3/7/21 5:25 AM, Marek Beh?n wrote:
>>> When compiling with LTO, the compiler fails with an error saying that
>>> `crc_table` causes a section type conflict with `efi_var_buf`.
>>>
>>> This is because both are declared to be in the same section (via macro
>>> `__efi_runtime_data`), but one is const while the other is not.
>>>
>>> Make this variable non-const in order to fix this.
>>
>> This does not look right, the crc32 array is constant.
>> Maybe what you want to do instead if create some __efi_constant_data
>> section ?
>
> Yes, this was the easier solution, and maybe is not ideal.
>
> I thought it would not be much of a problem since this array can be
> nonconstant (generated after boot) if CONFIG_DYNAMIC_CRC_TABLE is
> enabled.
>
> Anyway I don't much understand the EFI code so I wanted to poke into it
> as little as possible.
Isn't the compiler capable of better optimization on constant stuff ?
That's pretty much what prompted my suggestion to add separate section.
^ permalink raw reply [flat|nested] 139+ messages in thread
* [PATCH u-boot 14/39] lib: crc32: make the crc_table variable non-const
2021-03-07 5:02 ` Marek Vasut
@ 2021-03-07 12:26 ` Marek Behun
2021-03-07 12:31 ` Pali Rohár
0 siblings, 1 reply; 139+ messages in thread
From: Marek Behun @ 2021-03-07 12:26 UTC (permalink / raw)
To: u-boot
On Sun, 7 Mar 2021 06:02:16 +0100
Marek Vasut <marex@denx.de> wrote:
> On 3/7/21 5:58 AM, Marek Behun wrote:
> > On Sun, 7 Mar 2021 05:46:24 +0100
> > Marek Vasut <marex@denx.de> wrote:
> >
> >> On 3/7/21 5:25 AM, Marek Beh?n wrote:
> >>> When compiling with LTO, the compiler fails with an error saying that
> >>> `crc_table` causes a section type conflict with `efi_var_buf`.
> >>>
> >>> This is because both are declared to be in the same section (via macro
> >>> `__efi_runtime_data`), but one is const while the other is not.
> >>>
> >>> Make this variable non-const in order to fix this.
> >>
> >> This does not look right, the crc32 array is constant.
> >> Maybe what you want to do instead if create some __efi_constant_data
> >> section ?
> >
> > Yes, this was the easier solution, and maybe is not ideal.
> >
> > I thought it would not be much of a problem since this array can be
> > nonconstant (generated after boot) if CONFIG_DYNAMIC_CRC_TABLE is
> > enabled.
> >
> > Anyway I don't much understand the EFI code so I wanted to poke into it
> > as little as possible.
>
> Isn't the compiler capable of better optimization on constant stuff ?
> That's pretty much what prompted my suggestion to add separate section.
Yes, but
- for this case I don't think the compiler actually can do any
significat optimizations when declaring the table const, since it has
to access
tab[(crc ^ (x)) & 255]
I tried with arm compiler just now, with -O2 and -Os, and it
generated the same code either way
- when using LTO, the compiler theoretically should be able to deduce
that the table is never written to
But if people insist on declaring the table const, I will look into
this...
^ permalink raw reply [flat|nested] 139+ messages in thread* [PATCH u-boot 14/39] lib: crc32: make the crc_table variable non-const
2021-03-07 12:26 ` Marek Behun
@ 2021-03-07 12:31 ` Pali Rohár
2021-03-07 12:42 ` Marek Behun
2021-03-07 12:52 ` [PATCH u-boot 14/39] lib: crc32: put the crc_table variable into efi_runtime_rodata section Marek Behún
0 siblings, 2 replies; 139+ messages in thread
From: Pali Rohár @ 2021-03-07 12:31 UTC (permalink / raw)
To: u-boot
On Sunday 07 March 2021 13:26:36 Marek Behun wrote:
> On Sun, 7 Mar 2021 06:02:16 +0100
> Marek Vasut <marex@denx.de> wrote:
>
> > On 3/7/21 5:58 AM, Marek Behun wrote:
> > > On Sun, 7 Mar 2021 05:46:24 +0100
> > > Marek Vasut <marex@denx.de> wrote:
> > >
> > >> On 3/7/21 5:25 AM, Marek Beh?n wrote:
> > >>> When compiling with LTO, the compiler fails with an error saying that
> > >>> `crc_table` causes a section type conflict with `efi_var_buf`.
> > >>>
> > >>> This is because both are declared to be in the same section (via macro
> > >>> `__efi_runtime_data`), but one is const while the other is not.
> > >>>
> > >>> Make this variable non-const in order to fix this.
> > >>
> > >> This does not look right, the crc32 array is constant.
> > >> Maybe what you want to do instead if create some __efi_constant_data
> > >> section ?
> > >
> > > Yes, this was the easier solution, and maybe is not ideal.
> > >
> > > I thought it would not be much of a problem since this array can be
> > > nonconstant (generated after boot) if CONFIG_DYNAMIC_CRC_TABLE is
> > > enabled.
> > >
> > > Anyway I don't much understand the EFI code so I wanted to poke into it
> > > as little as possible.
> >
> > Isn't the compiler capable of better optimization on constant stuff ?
> > That's pretty much what prompted my suggestion to add separate section.
>
> Yes, but
> - for this case I don't think the compiler actually can do any
> significat optimizations when declaring the table const, since it has
> to access
> tab[(crc ^ (x)) & 255]
> I tried with arm compiler just now, with -O2 and -Os, and it
> generated the same code either way
> - when using LTO, the compiler theoretically should be able to deduce
> that the table is never written to
>
> But if people insist on declaring the table const, I will look into
> this...
If you try to overwrite a const variable from the same code unit then
compiler throw an error. So declaring read-only variable as a const
could prevent people to unintentionally overwrite read-only variable.
And detect possible bad code.
^ permalink raw reply [flat|nested] 139+ messages in thread
* [PATCH u-boot 14/39] lib: crc32: make the crc_table variable non-const
2021-03-07 12:31 ` Pali Rohár
@ 2021-03-07 12:42 ` Marek Behun
2021-03-07 12:52 ` [PATCH u-boot 14/39] lib: crc32: put the crc_table variable into efi_runtime_rodata section Marek Behún
1 sibling, 0 replies; 139+ messages in thread
From: Marek Behun @ 2021-03-07 12:42 UTC (permalink / raw)
To: u-boot
On Sun, 7 Mar 2021 13:31:11 +0100
Pali Roh?r <pali@kernel.org> wrote:
> On Sunday 07 March 2021 13:26:36 Marek Behun wrote:
> > On Sun, 7 Mar 2021 06:02:16 +0100
> > Marek Vasut <marex@denx.de> wrote:
> >
> > > On 3/7/21 5:58 AM, Marek Behun wrote:
> > > > On Sun, 7 Mar 2021 05:46:24 +0100
> > > > Marek Vasut <marex@denx.de> wrote:
> > > >
> > > >> On 3/7/21 5:25 AM, Marek Beh?n wrote:
> > > >>> When compiling with LTO, the compiler fails with an error saying that
> > > >>> `crc_table` causes a section type conflict with `efi_var_buf`.
> > > >>>
> > > >>> This is because both are declared to be in the same section (via macro
> > > >>> `__efi_runtime_data`), but one is const while the other is not.
> > > >>>
> > > >>> Make this variable non-const in order to fix this.
> > > >>
> > > >> This does not look right, the crc32 array is constant.
> > > >> Maybe what you want to do instead if create some __efi_constant_data
> > > >> section ?
> > > >
> > > > Yes, this was the easier solution, and maybe is not ideal.
> > > >
> > > > I thought it would not be much of a problem since this array can be
> > > > nonconstant (generated after boot) if CONFIG_DYNAMIC_CRC_TABLE is
> > > > enabled.
> > > >
> > > > Anyway I don't much understand the EFI code so I wanted to poke into it
> > > > as little as possible.
> > >
> > > Isn't the compiler capable of better optimization on constant stuff ?
> > > That's pretty much what prompted my suggestion to add separate section.
> >
> > Yes, but
> > - for this case I don't think the compiler actually can do any
> > significat optimizations when declaring the table const, since it has
> > to access
> > tab[(crc ^ (x)) & 255]
> > I tried with arm compiler just now, with -O2 and -Os, and it
> > generated the same code either way
> > - when using LTO, the compiler theoretically should be able to deduce
> > that the table is never written to
> >
> > But if people insist on declaring the table const, I will look into
> > this...
>
> If you try to overwrite a const variable from the same code unit then
> compiler throw an error. So declaring read-only variable as a const
> could prevent people to unintentionally overwrite read-only variable.
> And detect possible bad code.
OK it seems all linker scripts also mention .rodata.efi_runtime*, not
just .data.efi_runtime*. I shall put it into the .rodata.efi_runtime
section.
Marek
^ permalink raw reply [flat|nested] 139+ messages in thread
* [PATCH u-boot 14/39] lib: crc32: put the crc_table variable into efi_runtime_rodata section
2021-03-07 12:31 ` Pali Rohár
2021-03-07 12:42 ` Marek Behun
@ 2021-03-07 12:52 ` Marek Behún
2021-03-07 13:04 ` Marek Behun
1 sibling, 1 reply; 139+ messages in thread
From: Marek Behún @ 2021-03-07 12:52 UTC (permalink / raw)
To: u-boot
When compiling with LTO, the compiler fails with an error saying that
`crc_table` causes a section type conflict with `efi_var_buf`.
This is because both are declared to be in the same section (via macro
`__efi_runtime_data`), but one is const while the other is not.
Put this variable into the section .rodata.efi_runtime, instead of
.data.efi_runtime.
Signed-off-by: Marek Beh?n <marek.behun@nic.cz>
---
include/efi_loader.h | 2 ++
lib/crc32.c | 3 ++-
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/include/efi_loader.h b/include/efi_loader.h
index a8281b3c95..b1e5d2e13e 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -671,6 +671,7 @@ ssize_t efi_dp_check_length(const struct efi_device_path *dp,
* section and thus still be available when the OS is running
*/
#define __efi_runtime_data __section(".data.efi_runtime")
+#define __efi_runtime_rodata __section(".rodata.efi_runtime")
#define __efi_runtime __section(".text.efi_runtime")
/* Indicate supported runtime services */
@@ -870,6 +871,7 @@ efi_status_t efi_launch_capsules(void);
/* Without CONFIG_EFI_LOADER we don't have a runtime section, stub it out */
#define __efi_runtime_data
+#define __efi_runtime_rodata
#define __efi_runtime
static inline efi_status_t efi_add_runtime_mmio(void *mmio_ptr, u64 len)
{
diff --git a/lib/crc32.c b/lib/crc32.c
index e9be3bf386..f2acc107fe 100644
--- a/lib/crc32.c
+++ b/lib/crc32.c
@@ -26,6 +26,7 @@
#ifdef USE_HOSTCC
#define __efi_runtime
#define __efi_runtime_data
+#define __efi_runtime_rodata
#endif
#define tole(x) cpu_to_le32(x)
@@ -88,7 +89,7 @@ static void __efi_runtime make_crc_table(void)
* Table of CRC-32's of all single-byte values (made by make_crc_table)
*/
-static const uint32_t __efi_runtime_data crc_table[256] = {
+static const uint32_t __efi_runtime_rodata crc_table[256] = {
tole(0x00000000L), tole(0x77073096L), tole(0xee0e612cL), tole(0x990951baL),
tole(0x076dc419L), tole(0x706af48fL), tole(0xe963a535L), tole(0x9e6495a3L),
tole(0x0edb8832L), tole(0x79dcb8a4L), tole(0xe0d5e91eL), tole(0x97d2d988L),
--
2.26.2
^ permalink raw reply related [flat|nested] 139+ messages in thread* [PATCH u-boot 14/39] lib: crc32: put the crc_table variable into efi_runtime_rodata section
2021-03-07 12:52 ` [PATCH u-boot 14/39] lib: crc32: put the crc_table variable into efi_runtime_rodata section Marek Behún
@ 2021-03-07 13:04 ` Marek Behun
2021-03-07 20:49 ` Marek Behun
` (2 more replies)
0 siblings, 3 replies; 139+ messages in thread
From: Marek Behun @ 2021-03-07 13:04 UTC (permalink / raw)
To: u-boot
Hmm, maybe this should be split into 2 commits.
^ permalink raw reply [flat|nested] 139+ messages in thread* [PATCH u-boot 14/39] lib: crc32: put the crc_table variable into efi_runtime_rodata section
2021-03-07 13:04 ` Marek Behun
@ 2021-03-07 20:49 ` Marek Behun
2021-03-08 7:01 ` [PATCH u-boot v1.1 14.1/39] efi_loader: add macro for const EFI runtime data Marek Behún
2021-03-08 7:01 ` [PATCH u-boot v1.1 14.2/39] " Marek Behún
2 siblings, 0 replies; 139+ messages in thread
From: Marek Behun @ 2021-03-07 20:49 UTC (permalink / raw)
To: u-boot
On Sun, 7 Mar 2021 14:04:35 +0100
Marek Behun <marek.behun@nic.cz> wrote:
> Hmm, maybe this should be split into 2 commits.
I have divided this into 2 commits and pushed into my github branch
^ permalink raw reply [flat|nested] 139+ messages in thread
* [PATCH u-boot v1.1 14.1/39] efi_loader: add macro for const EFI runtime data
2021-03-07 13:04 ` Marek Behun
2021-03-07 20:49 ` Marek Behun
@ 2021-03-08 7:01 ` Marek Behún
2021-03-08 7:36 ` Heinrich Schuchardt
2021-03-08 7:01 ` [PATCH u-boot v1.1 14.2/39] " Marek Behún
2 siblings, 1 reply; 139+ messages in thread
From: Marek Behún @ 2021-03-08 7:01 UTC (permalink / raw)
To: u-boot
Add macro __efi_runtime_rodata, for const variables with similar purpose
as those using __efi_runtime_data.
Signed-off-by: Marek Beh?n <marek.behun@nic.cz>
---
include/efi_loader.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/efi_loader.h b/include/efi_loader.h
index a8281b3c95..b1e5d2e13e 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -671,6 +671,7 @@ ssize_t efi_dp_check_length(const struct efi_device_path *dp,
* section and thus still be available when the OS is running
*/
#define __efi_runtime_data __section(".data.efi_runtime")
+#define __efi_runtime_rodata __section(".rodata.efi_runtime")
#define __efi_runtime __section(".text.efi_runtime")
/* Indicate supported runtime services */
@@ -870,6 +871,7 @@ efi_status_t efi_launch_capsules(void);
/* Without CONFIG_EFI_LOADER we don't have a runtime section, stub it out */
#define __efi_runtime_data
+#define __efi_runtime_rodata
#define __efi_runtime
static inline efi_status_t efi_add_runtime_mmio(void *mmio_ptr, u64 len)
{
--
2.26.2
^ permalink raw reply related [flat|nested] 139+ messages in thread* [PATCH u-boot v1.1 14.1/39] efi_loader: add macro for const EFI runtime data
2021-03-08 7:01 ` [PATCH u-boot v1.1 14.1/39] efi_loader: add macro for const EFI runtime data Marek Behún
@ 2021-03-08 7:36 ` Heinrich Schuchardt
2021-03-08 9:54 ` [PATCH u-boot v1.2 14.1/39] efi_loader: add Sphinx doc for __efi_runtime and __efi_runtime_data Marek Behún
` (2 more replies)
0 siblings, 3 replies; 139+ messages in thread
From: Heinrich Schuchardt @ 2021-03-08 7:36 UTC (permalink / raw)
To: u-boot
On 3/8/21 8:01 AM, Marek Beh?n wrote:
> Add macro __efi_runtime_rodata, for const variables with similar purpose
> as those using __efi_runtime_data.
>
> Signed-off-by: Marek Beh?n <marek.behun@nic.cz>
> ---
> include/efi_loader.h | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/include/efi_loader.h b/include/efi_loader.h
> index a8281b3c95..b1e5d2e13e 100644
> --- a/include/efi_loader.h
> +++ b/include/efi_loader.h
> @@ -671,6 +671,7 @@ ssize_t efi_dp_check_length(const struct efi_device_path *dp,
> * section and thus still be available when the OS is running
> */
> #define __efi_runtime_data __section(".data.efi_runtime")
> +#define __efi_runtime_rodata __section(".rodata.efi_runtime")
Please, add a Sphinx style comment describing what the attribute is to
be used for.
It is unclear for me if the relevant property of crc_table[] is the
const attribute or if it is that the array is initialized.
Can you please, check this by LTO compiling without initializing
crc_table[] and in a separate run without const so that we gain a clear
understanding.
Best regards
Heinrich
> #define __efi_runtime __section(".text.efi_runtime")
>
> /* Indicate supported runtime services */
> @@ -870,6 +871,7 @@ efi_status_t efi_launch_capsules(void);
>
> /* Without CONFIG_EFI_LOADER we don't have a runtime section, stub it out */
> #define __efi_runtime_data
> +#define __efi_runtime_rodata
> #define __efi_runtime
> static inline efi_status_t efi_add_runtime_mmio(void *mmio_ptr, u64 len)
> {
>
^ permalink raw reply [flat|nested] 139+ messages in thread* [PATCH u-boot v1.2 14.1/39] efi_loader: add Sphinx doc for __efi_runtime and __efi_runtime_data
2021-03-08 7:36 ` Heinrich Schuchardt
@ 2021-03-08 9:54 ` Marek Behún
2021-03-08 9:54 ` [PATCH u-boot v1.2 14.2/39] efi_loader: add macro for const EFI runtime data Marek Behún
2021-03-08 9:54 ` [PATCH u-boot v1.2 14.3/39] lib: crc32: put the crc_table variable into efi_runtime_rodata section Marek Behún
2 siblings, 0 replies; 139+ messages in thread
From: Marek Behún @ 2021-03-08 9:54 UTC (permalink / raw)
To: u-boot
Document the macros __efi_runtime and __efi_runtime_data in Sphinx
style.
Signed-off-by: Marek Beh?n <marek.behun@nic.cz>
---
include/efi_loader.h | 29 ++++++++++++++++++++++++++---
1 file changed, 26 insertions(+), 3 deletions(-)
diff --git a/include/efi_loader.h b/include/efi_loader.h
index a8281b3c95..696f80e9f3 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -666,11 +666,34 @@ ssize_t efi_dp_check_length(const struct efi_device_path *dp,
(((_dp)->type == DEVICE_PATH_TYPE_##_type) && \
((_dp)->sub_type == DEVICE_PATH_SUB_TYPE_##_subtype))
-/*
- * Use these to indicate that your code / data should go into the EFI runtime
- * section and thus still be available when the OS is running
+/**
+ * __efi_runtime_data - declares a non-const variable for EFI runtime section
+ *
+ * This macro indicates that a variable is non-const and should go into the
+ * EFI runtime section, and thus still be available when the OS is running.
+ *
+ * Only use on variables not declared const.
+ *
+ * Example:
+ *
+ * ::
+ *
+ * static __efi_runtime_data my_computed_table[256];
*/
#define __efi_runtime_data __section(".data.efi_runtime")
+
+/**
+ * __efi_runtime - declares a function for EFI runtime section
+ *
+ * This macro indicates that a function should go into the EFI runtime section,
+ * and thus still be available when the OS is running.
+ *
+ * Example:
+ *
+ * ::
+ *
+ * static __efi_runtime compute_my_table(void);
+ */
#define __efi_runtime __section(".text.efi_runtime")
/* Indicate supported runtime services */
--
2.26.2
^ permalink raw reply related [flat|nested] 139+ messages in thread* [PATCH u-boot v1.2 14.2/39] efi_loader: add macro for const EFI runtime data
2021-03-08 7:36 ` Heinrich Schuchardt
2021-03-08 9:54 ` [PATCH u-boot v1.2 14.1/39] efi_loader: add Sphinx doc for __efi_runtime and __efi_runtime_data Marek Behún
@ 2021-03-08 9:54 ` Marek Behún
2021-03-08 9:54 ` [PATCH u-boot v1.2 14.3/39] lib: crc32: put the crc_table variable into efi_runtime_rodata section Marek Behún
2 siblings, 0 replies; 139+ messages in thread
From: Marek Behún @ 2021-03-08 9:54 UTC (permalink / raw)
To: u-boot
Add macro __efi_runtime_rodata, for const variables with similar purpose
as those using __efi_runtime_data.
Signed-off-by: Marek Beh?n <marek.behun@nic.cz>
---
include/efi_loader.h | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/include/efi_loader.h b/include/efi_loader.h
index 696f80e9f3..d673ba12e3 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -682,6 +682,22 @@ ssize_t efi_dp_check_length(const struct efi_device_path *dp,
*/
#define __efi_runtime_data __section(".data.efi_runtime")
+/**
+ * __efi_runtime_rodata - declares a read-only variable for EFI runtime section
+ *
+ * This macro indicates that a variable is read-only (const) and should go into
+ * the EFI runtime section, and thus still be available when the OS is running.
+ *
+ * Only use on variables also declared const.
+ *
+ * Example:
+ *
+ * ::
+ *
+ * static const __efi_runtime_rodata my_const_table[] = { 1, 2, 3 };
+ */
+#define __efi_runtime_rodata __section(".rodata.efi_runtime")
+
/**
* __efi_runtime - declares a function for EFI runtime section
*
@@ -893,6 +909,7 @@ efi_status_t efi_launch_capsules(void);
/* Without CONFIG_EFI_LOADER we don't have a runtime section, stub it out */
#define __efi_runtime_data
+#define __efi_runtime_rodata
#define __efi_runtime
static inline efi_status_t efi_add_runtime_mmio(void *mmio_ptr, u64 len)
{
--
2.26.2
^ permalink raw reply related [flat|nested] 139+ messages in thread* [PATCH u-boot v1.2 14.3/39] lib: crc32: put the crc_table variable into efi_runtime_rodata section
2021-03-08 7:36 ` Heinrich Schuchardt
2021-03-08 9:54 ` [PATCH u-boot v1.2 14.1/39] efi_loader: add Sphinx doc for __efi_runtime and __efi_runtime_data Marek Behún
2021-03-08 9:54 ` [PATCH u-boot v1.2 14.2/39] efi_loader: add macro for const EFI runtime data Marek Behún
@ 2021-03-08 9:54 ` Marek Behún
2 siblings, 0 replies; 139+ messages in thread
From: Marek Behún @ 2021-03-08 9:54 UTC (permalink / raw)
To: u-boot
When compiling with LTO, the compiler fails with an error saying that
`crc_table` causes a section type conflict with `efi_var_buf`.
This is because both are declared to be in the same section (via macro
`__efi_runtime_data`), but one is const while the other is not.
Put this variable into the section .rodata.efi_runtime, instead of
.data.efi_runtime, via macro __efi_runtime_rodata.
Signed-off-by: Marek Beh?n <marek.behun@nic.cz>
Reviewed-by: Marek Vasut <marex@denx.de>
---
lib/crc32.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/lib/crc32.c b/lib/crc32.c
index e9be3bf386..f2acc107fe 100644
--- a/lib/crc32.c
+++ b/lib/crc32.c
@@ -26,6 +26,7 @@
#ifdef USE_HOSTCC
#define __efi_runtime
#define __efi_runtime_data
+#define __efi_runtime_rodata
#endif
#define tole(x) cpu_to_le32(x)
@@ -88,7 +89,7 @@ static void __efi_runtime make_crc_table(void)
* Table of CRC-32's of all single-byte values (made by make_crc_table)
*/
-static const uint32_t __efi_runtime_data crc_table[256] = {
+static const uint32_t __efi_runtime_rodata crc_table[256] = {
tole(0x00000000L), tole(0x77073096L), tole(0xee0e612cL), tole(0x990951baL),
tole(0x076dc419L), tole(0x706af48fL), tole(0xe963a535L), tole(0x9e6495a3L),
tole(0x0edb8832L), tole(0x79dcb8a4L), tole(0xe0d5e91eL), tole(0x97d2d988L),
--
2.26.2
^ permalink raw reply related [flat|nested] 139+ messages in thread
* [PATCH u-boot v1.1 14.2/39] lib: crc32: put the crc_table variable into efi_runtime_rodata section
2021-03-07 13:04 ` Marek Behun
2021-03-07 20:49 ` Marek Behun
2021-03-08 7:01 ` [PATCH u-boot v1.1 14.1/39] efi_loader: add macro for const EFI runtime data Marek Behún
@ 2021-03-08 7:01 ` Marek Behún
2021-03-08 8:43 ` Marek Vasut
2 siblings, 1 reply; 139+ messages in thread
From: Marek Behún @ 2021-03-08 7:01 UTC (permalink / raw)
To: u-boot
When compiling with LTO, the compiler fails with an error saying that
`crc_table` causes a section type conflict with `efi_var_buf`.
This is because both are declared to be in the same section (via macro
`__efi_runtime_data`), but one is const while the other is not.
Put this variable into the section .rodata.efi_runtime, instead of
.data.efi_runtime, via macro __efi_runtime_rodata.
Signed-off-by: Marek Beh?n <marek.behun@nic.cz>
---
lib/crc32.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/lib/crc32.c b/lib/crc32.c
index e9be3bf386..f2acc107fe 100644
--- a/lib/crc32.c
+++ b/lib/crc32.c
@@ -26,6 +26,7 @@
#ifdef USE_HOSTCC
#define __efi_runtime
#define __efi_runtime_data
+#define __efi_runtime_rodata
#endif
#define tole(x) cpu_to_le32(x)
@@ -88,7 +89,7 @@ static void __efi_runtime make_crc_table(void)
* Table of CRC-32's of all single-byte values (made by make_crc_table)
*/
-static const uint32_t __efi_runtime_data crc_table[256] = {
+static const uint32_t __efi_runtime_rodata crc_table[256] = {
tole(0x00000000L), tole(0x77073096L), tole(0xee0e612cL), tole(0x990951baL),
tole(0x076dc419L), tole(0x706af48fL), tole(0xe963a535L), tole(0x9e6495a3L),
tole(0x0edb8832L), tole(0x79dcb8a4L), tole(0xe0d5e91eL), tole(0x97d2d988L),
--
2.26.2
^ permalink raw reply related [flat|nested] 139+ messages in thread* [PATCH u-boot v1.1 14.2/39] lib: crc32: put the crc_table variable into efi_runtime_rodata section
2021-03-08 7:01 ` [PATCH u-boot v1.1 14.2/39] " Marek Behún
@ 2021-03-08 8:43 ` Marek Vasut
0 siblings, 0 replies; 139+ messages in thread
From: Marek Vasut @ 2021-03-08 8:43 UTC (permalink / raw)
To: u-boot
On 3/8/21 8:01 AM, Marek Beh?n wrote:
> When compiling with LTO, the compiler fails with an error saying that
> `crc_table` causes a section type conflict with `efi_var_buf`.
>
> This is because both are declared to be in the same section (via macro
> `__efi_runtime_data`), but one is const while the other is not.
>
> Put this variable into the section .rodata.efi_runtime, instead of
> .data.efi_runtime, via macro __efi_runtime_rodata.
>
I think this is much better, thanks.
Reviewed-by: Marek Vasut <marex@denx.de>
^ permalink raw reply [flat|nested] 139+ messages in thread
* [PATCH u-boot 15/39] Makefile, Makefile.spl: cosmetic change
2021-03-07 4:24 [PATCH u-boot 00/39] U-Boot LTO (Sandbox + Some ARM boards) Marek Behún
` (13 preceding siblings ...)
2021-03-07 4:25 ` [PATCH u-boot 14/39] lib: crc32: make the crc_table variable non-const Marek Behún
@ 2021-03-07 4:25 ` Marek Behún
2021-03-08 9:11 ` Bin Meng
2021-03-07 4:25 ` [PATCH u-boot 16/39] build: use thin archives instead of incremental linking Marek Behún
` (23 subsequent siblings)
38 siblings, 1 reply; 139+ messages in thread
From: Marek Behún @ 2021-03-07 4:25 UTC (permalink / raw)
To: u-boot
Indent the linking commands so that they look cosmetically better.
Signed-off-by: Marek Beh?n <marek.behun@nic.cz>
---
Makefile | 12 +++++++-----
scripts/Makefile.spl | 15 +++++++++------
2 files changed, 16 insertions(+), 11 deletions(-)
diff --git a/Makefile b/Makefile
index 68ce5195b2..7b0ba9df9a 100644
--- a/Makefile
+++ b/Makefile
@@ -1752,11 +1752,13 @@ ARCH_POSTLINK := $(wildcard $(srctree)/arch/$(ARCH)/Makefile.postlink)
# Rule to link u-boot
# May be overridden by arch/$(ARCH)/config.mk
quiet_cmd_u-boot__ ?= LD $@
- cmd_u-boot__ ?= $(LD) $(KBUILD_LDFLAGS) $(LDFLAGS_u-boot) -o $@ \
- -T u-boot.lds $(u-boot-init) \
- --start-group $(u-boot-main) --end-group \
- $(PLATFORM_LIBS) -Map u-boot.map; \
- $(if $(ARCH_POSTLINK), $(MAKE) -f $(ARCH_POSTLINK) $@, true)
+ cmd_u-boot__ ?= $(LD) $(KBUILD_LDFLAGS) $(LDFLAGS_u-boot) -o $@ \
+ -T u-boot.lds $(u-boot-init) \
+ --start-group \
+ $(u-boot-main) \
+ --end-group \
+ $(PLATFORM_LIBS) -Map u-boot.map; \
+ $(if $(ARCH_POSTLINK), $(MAKE) -f $(ARCH_POSTLINK) $@, true)
quiet_cmd_smap = GEN common/system_map.o
cmd_smap = \
diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl
index ea4e045769..3b5f5046c9 100644
--- a/scripts/Makefile.spl
+++ b/scripts/Makefile.spl
@@ -420,12 +420,15 @@ $(obj)/$(SPL_BIN).sym: $(obj)/$(SPL_BIN) FORCE
# Rule to link u-boot-spl
# May be overridden by arch/$(ARCH)/config.mk
quiet_cmd_u-boot-spl ?= LD $@
- cmd_u-boot-spl ?= (cd $(obj) && $(LD) $(KBUILD_LDFLAGS) $(LDFLAGS_$(@F)) \
- $(patsubst $(obj)/%,%,$(u-boot-spl-init)) --start-group \
- $(patsubst $(obj)/%,%,$(u-boot-spl-main)) \
- $(patsubst $(obj)/%,%,$(u-boot-spl-platdata)) \
- --end-group \
- $(PLATFORM_LIBS) -Map $(SPL_BIN).map -o $(SPL_BIN))
+ cmd_u-boot-spl ?= (cd $(obj) && \
+ $(LD) $(KBUILD_LDFLAGS) $(LDFLAGS_$(@F)) \
+ $(patsubst $(obj)/%,%,$(u-boot-spl-init)) \
+ --start-group \
+ $(patsubst $(obj)/%,%,$(u-boot-spl-main)) \
+ $(patsubst $(obj)/%,%,$(u-boot-spl-platdata)) \
+ --end-group \
+ $(PLATFORM_LIBS) -Map $(SPL_BIN).map -o $(SPL_BIN) \
+ )
$(obj)/$(SPL_BIN): $(u-boot-spl-platdata) $(u-boot-spl-init) \
$(u-boot-spl-main) $(obj)/u-boot-spl.lds FORCE
--
2.26.2
^ permalink raw reply related [flat|nested] 139+ messages in thread* [PATCH u-boot 15/39] Makefile, Makefile.spl: cosmetic change
2021-03-07 4:25 ` [PATCH u-boot 15/39] Makefile, Makefile.spl: cosmetic change Marek Behún
@ 2021-03-08 9:11 ` Bin Meng
2021-03-08 10:12 ` [PATCH u-boot v1.1 " Marek Behún
0 siblings, 1 reply; 139+ messages in thread
From: Bin Meng @ 2021-03-08 9:11 UTC (permalink / raw)
To: u-boot
On Sun, Mar 7, 2021 at 12:26 PM Marek Beh?n <marek.behun@nic.cz> wrote:
>
> Indent the linking commands so that they look cosmetically better.
>
> Signed-off-by: Marek Beh?n <marek.behun@nic.cz>
> ---
> Makefile | 12 +++++++-----
> scripts/Makefile.spl | 15 +++++++++------
> 2 files changed, 16 insertions(+), 11 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index 68ce5195b2..7b0ba9df9a 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1752,11 +1752,13 @@ ARCH_POSTLINK := $(wildcard $(srctree)/arch/$(ARCH)/Makefile.postlink)
> # Rule to link u-boot
> # May be overridden by arch/$(ARCH)/config.mk
> quiet_cmd_u-boot__ ?= LD $@
> - cmd_u-boot__ ?= $(LD) $(KBUILD_LDFLAGS) $(LDFLAGS_u-boot) -o $@ \
> - -T u-boot.lds $(u-boot-init) \
> - --start-group $(u-boot-main) --end-group \
> - $(PLATFORM_LIBS) -Map u-boot.map; \
> - $(if $(ARCH_POSTLINK), $(MAKE) -f $(ARCH_POSTLINK) $@, true)
> + cmd_u-boot__ ?= $(LD) $(KBUILD_LDFLAGS) $(LDFLAGS_u-boot) -o $@ \
> + -T u-boot.lds $(u-boot-init) \
> + --start-group \
> + $(u-boot-main) \
> + --end-group \
> + $(PLATFORM_LIBS) -Map u-boot.map; \
> + $(if $(ARCH_POSTLINK), $(MAKE) -f $(ARCH_POSTLINK) $@, true)
>
> quiet_cmd_smap = GEN common/system_map.o
> cmd_smap = \
> diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl
> index ea4e045769..3b5f5046c9 100644
> --- a/scripts/Makefile.spl
> +++ b/scripts/Makefile.spl
> @@ -420,12 +420,15 @@ $(obj)/$(SPL_BIN).sym: $(obj)/$(SPL_BIN) FORCE
> # Rule to link u-boot-spl
> # May be overridden by arch/$(ARCH)/config.mk
> quiet_cmd_u-boot-spl ?= LD $@
> - cmd_u-boot-spl ?= (cd $(obj) && $(LD) $(KBUILD_LDFLAGS) $(LDFLAGS_$(@F)) \
> - $(patsubst $(obj)/%,%,$(u-boot-spl-init)) --start-group \
> - $(patsubst $(obj)/%,%,$(u-boot-spl-main)) \
> - $(patsubst $(obj)/%,%,$(u-boot-spl-platdata)) \
> - --end-group \
> - $(PLATFORM_LIBS) -Map $(SPL_BIN).map -o $(SPL_BIN))
> + cmd_u-boot-spl ?= (cd $(obj) && \
nits: should we put ( in a single line?
> + $(LD) $(KBUILD_LDFLAGS) $(LDFLAGS_$(@F)) \
> + $(patsubst $(obj)/%,%,$(u-boot-spl-init)) \
> + --start-group \
> + $(patsubst $(obj)/%,%,$(u-boot-spl-main)) \
> + $(patsubst $(obj)/%,%,$(u-boot-spl-platdata)) \
> + --end-group \
> + $(PLATFORM_LIBS) -Map $(SPL_BIN).map -o $(SPL_BIN) \
> + )
>
> $(obj)/$(SPL_BIN): $(u-boot-spl-platdata) $(u-boot-spl-init) \
> $(u-boot-spl-main) $(obj)/u-boot-spl.lds FORCE
> --
Regards,
Bin
^ permalink raw reply [flat|nested] 139+ messages in thread
* [PATCH u-boot v1.1 15/39] Makefile, Makefile.spl: cosmetic change
2021-03-08 9:11 ` Bin Meng
@ 2021-03-08 10:12 ` Marek Behún
2021-03-08 10:42 ` Bin Meng
0 siblings, 1 reply; 139+ messages in thread
From: Marek Behún @ 2021-03-08 10:12 UTC (permalink / raw)
To: u-boot
Indent the linking commands so that they look cosmetically better.
Signed-off-by: Marek Beh?n <marek.behun@nic.cz>
---
Makefile | 12 +++++++-----
scripts/Makefile.spl | 17 +++++++++++------
2 files changed, 18 insertions(+), 11 deletions(-)
diff --git a/Makefile b/Makefile
index 68ce5195b2..7b0ba9df9a 100644
--- a/Makefile
+++ b/Makefile
@@ -1752,11 +1752,13 @@ ARCH_POSTLINK := $(wildcard $(srctree)/arch/$(ARCH)/Makefile.postlink)
# Rule to link u-boot
# May be overridden by arch/$(ARCH)/config.mk
quiet_cmd_u-boot__ ?= LD $@
- cmd_u-boot__ ?= $(LD) $(KBUILD_LDFLAGS) $(LDFLAGS_u-boot) -o $@ \
- -T u-boot.lds $(u-boot-init) \
- --start-group $(u-boot-main) --end-group \
- $(PLATFORM_LIBS) -Map u-boot.map; \
- $(if $(ARCH_POSTLINK), $(MAKE) -f $(ARCH_POSTLINK) $@, true)
+ cmd_u-boot__ ?= $(LD) $(KBUILD_LDFLAGS) $(LDFLAGS_u-boot) -o $@ \
+ -T u-boot.lds $(u-boot-init) \
+ --start-group \
+ $(u-boot-main) \
+ --end-group \
+ $(PLATFORM_LIBS) -Map u-boot.map; \
+ $(if $(ARCH_POSTLINK), $(MAKE) -f $(ARCH_POSTLINK) $@, true)
quiet_cmd_smap = GEN common/system_map.o
cmd_smap = \
diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl
index ea4e045769..81bab9951d 100644
--- a/scripts/Makefile.spl
+++ b/scripts/Makefile.spl
@@ -420,12 +420,17 @@ $(obj)/$(SPL_BIN).sym: $(obj)/$(SPL_BIN) FORCE
# Rule to link u-boot-spl
# May be overridden by arch/$(ARCH)/config.mk
quiet_cmd_u-boot-spl ?= LD $@
- cmd_u-boot-spl ?= (cd $(obj) && $(LD) $(KBUILD_LDFLAGS) $(LDFLAGS_$(@F)) \
- $(patsubst $(obj)/%,%,$(u-boot-spl-init)) --start-group \
- $(patsubst $(obj)/%,%,$(u-boot-spl-main)) \
- $(patsubst $(obj)/%,%,$(u-boot-spl-platdata)) \
- --end-group \
- $(PLATFORM_LIBS) -Map $(SPL_BIN).map -o $(SPL_BIN))
+ cmd_u-boot-spl ?= \
+ ( \
+ cd $(obj) && \
+ $(LD) $(KBUILD_LDFLAGS) $(LDFLAGS_$(@F)) \
+ $(patsubst $(obj)/%,%,$(u-boot-spl-init)) \
+ --start-group \
+ $(patsubst $(obj)/%,%,$(u-boot-spl-main)) \
+ $(patsubst $(obj)/%,%,$(u-boot-spl-platdata)) \
+ --end-group \
+ $(PLATFORM_LIBS) -Map $(SPL_BIN).map -o $(SPL_BIN) \
+ )
$(obj)/$(SPL_BIN): $(u-boot-spl-platdata) $(u-boot-spl-init) \
$(u-boot-spl-main) $(obj)/u-boot-spl.lds FORCE
--
2.26.2
^ permalink raw reply related [flat|nested] 139+ messages in thread
* [PATCH u-boot v1.1 15/39] Makefile, Makefile.spl: cosmetic change
2021-03-08 10:12 ` [PATCH u-boot v1.1 " Marek Behún
@ 2021-03-08 10:42 ` Bin Meng
0 siblings, 0 replies; 139+ messages in thread
From: Bin Meng @ 2021-03-08 10:42 UTC (permalink / raw)
To: u-boot
On Mon, Mar 8, 2021 at 6:12 PM Marek Beh?n <marek.behun@nic.cz> wrote:
>
> Indent the linking commands so that they look cosmetically better.
>
> Signed-off-by: Marek Beh?n <marek.behun@nic.cz>
> ---
> Makefile | 12 +++++++-----
> scripts/Makefile.spl | 17 +++++++++++------
> 2 files changed, 18 insertions(+), 11 deletions(-)
>
It's odd to have a version 1.1, but anyway:
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
^ permalink raw reply [flat|nested] 139+ messages in thread
* [PATCH u-boot 16/39] build: use thin archives instead of incremental linking
2021-03-07 4:24 [PATCH u-boot 00/39] U-Boot LTO (Sandbox + Some ARM boards) Marek Behún
` (14 preceding siblings ...)
2021-03-07 4:25 ` [PATCH u-boot 15/39] Makefile, Makefile.spl: cosmetic change Marek Behún
@ 2021-03-07 4:25 ` Marek Behún
2021-03-08 9:16 ` Bin Meng
2021-03-09 13:00 ` Bin Meng
2021-03-07 4:25 ` [PATCH u-boot 17/39] build: support building with Link Time Optimizations Marek Behún
` (22 subsequent siblings)
38 siblings, 2 replies; 139+ messages in thread
From: Marek Behún @ 2021-03-07 4:25 UTC (permalink / raw)
To: u-boot
Currently we use incremental linking (ld -r) to link several object
files from one directory into one built-in.o object file containing the
linked code from that directory (and its subdirectories).
Linux has, some time ago, moved to thin archives instead.
Thin archives are archives (.a) that do not really contain the object
files, only references to them.
Using thin archives instead of incremental linking
- saves disk space
- apparently works better with dead code elimination
- makes things easier for LTO
The third point is the important one for us. With incremental linking
there are several options how to do LTO, and that would unnecessarily
complicate things.
On the other hand, by using thin archives we can make (via the
--whole-archive use flag) the final linking behave as if we passed all
the object files from the archives to the linking program as arguments.
We also need to use the P flag for ar, otherwise final linking may fail.
Signed-off-by: Marek Beh?n <marek.behun@nic.cz>
---
Makefile | 4 ++--
arch/sandbox/config.mk | 10 +++++++---
scripts/Makefile.build | 16 ++++++++--------
scripts/Makefile.spl | 4 ++--
4 files changed, 19 insertions(+), 15 deletions(-)
diff --git a/Makefile b/Makefile
index 7b0ba9df9a..6dc47810ea 100644
--- a/Makefile
+++ b/Makefile
@@ -1754,9 +1754,9 @@ ARCH_POSTLINK := $(wildcard $(srctree)/arch/$(ARCH)/Makefile.postlink)
quiet_cmd_u-boot__ ?= LD $@
cmd_u-boot__ ?= $(LD) $(KBUILD_LDFLAGS) $(LDFLAGS_u-boot) -o $@ \
-T u-boot.lds $(u-boot-init) \
- --start-group \
+ --start-group --whole-archive \
$(u-boot-main) \
- --end-group \
+ --no-whole-archive --end-group \
$(PLATFORM_LIBS) -Map u-boot.map; \
$(if $(ARCH_POSTLINK), $(MAKE) -f $(ARCH_POSTLINK) $@, true)
diff --git a/arch/sandbox/config.mk b/arch/sandbox/config.mk
index 189e9c2b0c..d11b9c63c9 100644
--- a/arch/sandbox/config.mk
+++ b/arch/sandbox/config.mk
@@ -17,13 +17,17 @@ PLATFORM_CPPFLAGS += $(shell $(SDL_CONFIG) --cflags)
endif
cmd_u-boot__ = $(CC) -o $@ -Wl,-T u-boot.lds $(u-boot-init) \
- -Wl,--start-group $(u-boot-main) -Wl,--end-group \
+ -Wl,--start-group -Wl,--whole-archive \
+ $(u-boot-main) \
+ -Wl,--no-whole-archive -Wl,--end-group \
$(PLATFORM_LIBS) -Wl,-Map -Wl,u-boot.map
cmd_u-boot-spl = (cd $(obj) && $(CC) -o $(SPL_BIN) -Wl,-T u-boot-spl.lds \
$(patsubst $(obj)/%,%,$(u-boot-spl-init)) \
- -Wl,--start-group $(patsubst $(obj)/%,%,$(u-boot-spl-main)) \
- $(patsubst $(obj)/%,%,$(u-boot-spl-platdata)) -Wl,--end-group \
+ -Wl,--start-group -Wl,--whole-archive \
+ $(patsubst $(obj)/%,%,$(u-boot-spl-main)) \
+ $(patsubst $(obj)/%,%,$(u-boot-spl-platdata)) \
+ -Wl,--no-whole-archive -Wl,--end-group \
$(PLATFORM_LIBS) -Wl,-Map -Wl,u-boot-spl.map -Wl,--gc-sections)
CONFIG_ARCH_DEVICE_TREE := sandbox
diff --git a/scripts/Makefile.build b/scripts/Makefile.build
index 705a886cb9..a9a02d7d33 100644
--- a/scripts/Makefile.build
+++ b/scripts/Makefile.build
@@ -331,12 +331,11 @@ $(sort $(subdir-obj-y)): $(subdir-ym) ;
# Rule to compile a set of .o files into one .o file
#
ifdef builtin-target
-quiet_cmd_link_o_target = LD $@
+quiet_cmd_link_o_target = AR $@
# If the list of objects to link is empty, just create an empty built-in.o
cmd_link_o_target = $(if $(strip $(obj-y)),\
- $(LD) $(ld_flags) -r -o $@ $(filter $(obj-y), $^) \
- $(cmd_secanalysis),\
- rm -f $@; $(AR) rcs$(KBUILD_ARFLAGS) $@)
+ rm -f $@; $(AR) cDPrsT $@ $(filter $(obj-y), $^), \
+ rm -f $@; $(AR) cPrsT$(KBUILD_ARFLAGS) $@)
$(builtin-target): $(obj-y) FORCE
$(call if_changed,link_o_target)
@@ -362,7 +361,7 @@ $(modorder-target): $(subdir-ym) FORCE
#
ifdef lib-target
quiet_cmd_link_l_target = AR $@
-cmd_link_l_target = rm -f $@; $(AR) rcs$(KBUILD_ARFLAGS) $@ $(lib-y)
+cmd_link_l_target = rm -f $@; $(AR) cPrs$(KBUILD_ARFLAGS) $@ $(lib-y)
$(lib-target): $(lib-y) FORCE
$(call if_changed,link_l_target)
@@ -382,10 +381,11 @@ $(filter $(addprefix $(obj)/, \
$($(subst $(obj)/,,$(@:.o=-objs))) \
$($(subst $(obj)/,,$(@:.o=-y)))), $^)
-quiet_cmd_link_multi-y = LD $@
-cmd_link_multi-y = $(LD) $(ld_flags) -r -o $@ $(link_multi_deps) $(cmd_secanalysis)
-quiet_cmd_link_multi-m = LD [M] $@
+quiet_cmd_link_multi-y = AR $@
+cmd_link_multi-y = rm -f $@; $(AR) cDPrsT $@ $(link_multi_deps)
+
+quiet_cmd_link_multi-m = AR [M] $@
cmd_link_multi-m = $(cmd_link_multi-y)
$(multi-used-y): FORCE
diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl
index 3b5f5046c9..889debb93c 100644
--- a/scripts/Makefile.spl
+++ b/scripts/Makefile.spl
@@ -423,10 +423,10 @@ quiet_cmd_u-boot-spl ?= LD $@
cmd_u-boot-spl ?= (cd $(obj) && \
$(LD) $(KBUILD_LDFLAGS) $(LDFLAGS_$(@F)) \
$(patsubst $(obj)/%,%,$(u-boot-spl-init)) \
- --start-group \
+ --start-group --whole-archive \
$(patsubst $(obj)/%,%,$(u-boot-spl-main)) \
$(patsubst $(obj)/%,%,$(u-boot-spl-platdata)) \
- --end-group \
+ --no-whole-archive --end-group \
$(PLATFORM_LIBS) -Map $(SPL_BIN).map -o $(SPL_BIN) \
)
--
2.26.2
^ permalink raw reply related [flat|nested] 139+ messages in thread* [PATCH u-boot 16/39] build: use thin archives instead of incremental linking
2021-03-07 4:25 ` [PATCH u-boot 16/39] build: use thin archives instead of incremental linking Marek Behún
@ 2021-03-08 9:16 ` Bin Meng
2021-03-08 10:11 ` Marek Behun
2021-03-09 13:00 ` Bin Meng
1 sibling, 1 reply; 139+ messages in thread
From: Bin Meng @ 2021-03-08 9:16 UTC (permalink / raw)
To: u-boot
Hi Marek,
On Sun, Mar 7, 2021 at 12:26 PM Marek Beh?n <marek.behun@nic.cz> wrote:
>
> Currently we use incremental linking (ld -r) to link several object
> files from one directory into one built-in.o object file containing the
> linked code from that directory (and its subdirectories).
>
> Linux has, some time ago, moved to thin archives instead.
>
> Thin archives are archives (.a) that do not really contain the object
> files, only references to them.
>
> Using thin archives instead of incremental linking
> - saves disk space
> - apparently works better with dead code elimination
> - makes things easier for LTO
>
> The third point is the important one for us. With incremental linking
> there are several options how to do LTO, and that would unnecessarily
> complicate things.
>
> On the other hand, by using thin archives we can make (via the
> --whole-archive use flag) the final linking behave as if we passed all
> the object files from the archives to the linking program as arguments.
I don't think --whole-archive is required for LTO to work. Switching
to --whole-archive should be made conditionally when LTO is on,
otherwise for targets that don't have
-ffunction-sections/data-sections/--gc-sections specified, it will
create unnecessary bloat.
>
> We also need to use the P flag for ar, otherwise final linking may fail.
>
> Signed-off-by: Marek Beh?n <marek.behun@nic.cz>
> ---
> Makefile | 4 ++--
> arch/sandbox/config.mk | 10 +++++++---
> scripts/Makefile.build | 16 ++++++++--------
> scripts/Makefile.spl | 4 ++--
> 4 files changed, 19 insertions(+), 15 deletions(-)
>
Regards,
Bin
^ permalink raw reply [flat|nested] 139+ messages in thread
* [PATCH u-boot 16/39] build: use thin archives instead of incremental linking
2021-03-08 9:16 ` Bin Meng
@ 2021-03-08 10:11 ` Marek Behun
2021-03-08 10:44 ` Bin Meng
0 siblings, 1 reply; 139+ messages in thread
From: Marek Behun @ 2021-03-08 10:11 UTC (permalink / raw)
To: u-boot
On Mon, 8 Mar 2021 17:16:03 +0800
Bin Meng <bmeng.cn@gmail.com> wrote:
> Hi Marek,
>
> On Sun, Mar 7, 2021 at 12:26 PM Marek Beh?n <marek.behun@nic.cz> wrote:
> >
> > Currently we use incremental linking (ld -r) to link several object
> > files from one directory into one built-in.o object file containing the
> > linked code from that directory (and its subdirectories).
> >
> > Linux has, some time ago, moved to thin archives instead.
> >
> > Thin archives are archives (.a) that do not really contain the object
> > files, only references to them.
> >
> > Using thin archives instead of incremental linking
> > - saves disk space
> > - apparently works better with dead code elimination
> > - makes things easier for LTO
> >
> > The third point is the important one for us. With incremental linking
> > there are several options how to do LTO, and that would unnecessarily
> > complicate things.
> >
> > On the other hand, by using thin archives we can make (via the
> > --whole-archive use flag) the final linking behave as if we passed all
> > the object files from the archives to the linking program as arguments.
>
> I don't think --whole-archive is required for LTO to work.
It is. Linking fails if it is not used, for example for
nokia_rx51_defconfig.
> Switching to --whole-archive should be made conditionally when LTO is on,
> otherwise for targets that don't have
> -ffunction-sections/data-sections/--gc-sections specified, it will
> create unnecessary bloat.
OK I will push into CI without this flag for non-LTO and if it passes
all tests I shall remove this flag for non-LTO.
Marek
^ permalink raw reply [flat|nested] 139+ messages in thread
* [PATCH u-boot 16/39] build: use thin archives instead of incremental linking
2021-03-08 10:11 ` Marek Behun
@ 2021-03-08 10:44 ` Bin Meng
2021-03-08 11:00 ` Pali Rohár
2021-03-08 11:18 ` Marek Behun
0 siblings, 2 replies; 139+ messages in thread
From: Bin Meng @ 2021-03-08 10:44 UTC (permalink / raw)
To: u-boot
On Mon, Mar 8, 2021 at 6:11 PM Marek Behun <marek.behun@nic.cz> wrote:
>
> On Mon, 8 Mar 2021 17:16:03 +0800
> Bin Meng <bmeng.cn@gmail.com> wrote:
>
> > Hi Marek,
> >
> > On Sun, Mar 7, 2021 at 12:26 PM Marek Beh?n <marek.behun@nic.cz> wrote:
> > >
> > > Currently we use incremental linking (ld -r) to link several object
> > > files from one directory into one built-in.o object file containing the
> > > linked code from that directory (and its subdirectories).
> > >
> > > Linux has, some time ago, moved to thin archives instead.
> > >
> > > Thin archives are archives (.a) that do not really contain the object
> > > files, only references to them.
> > >
> > > Using thin archives instead of incremental linking
> > > - saves disk space
> > > - apparently works better with dead code elimination
> > > - makes things easier for LTO
> > >
> > > The third point is the important one for us. With incremental linking
> > > there are several options how to do LTO, and that would unnecessarily
> > > complicate things.
> > >
> > > On the other hand, by using thin archives we can make (via the
> > > --whole-archive use flag) the final linking behave as if we passed all
> > > the object files from the archives to the linking program as arguments.
> >
> > I don't think --whole-archive is required for LTO to work.
>
> It is. Linking fails if it is not used, for example for
> nokia_rx51_defconfig.
Could you investigate why? Is this due to missing marking some
variables/functions as __used?
>
> > Switching to --whole-archive should be made conditionally when LTO is on,
> > otherwise for targets that don't have
> > -ffunction-sections/data-sections/--gc-sections specified, it will
> > create unnecessary bloat.
>
> OK I will push into CI without this flag for non-LTO and if it passes
> all tests I shall remove this flag for non-LTO.
>
Regards,
Bin
^ permalink raw reply [flat|nested] 139+ messages in thread
* [PATCH u-boot 16/39] build: use thin archives instead of incremental linking
2021-03-08 10:44 ` Bin Meng
@ 2021-03-08 11:00 ` Pali Rohár
2021-03-08 11:41 ` Bin Meng
2021-03-08 11:18 ` Marek Behun
1 sibling, 1 reply; 139+ messages in thread
From: Pali Rohár @ 2021-03-08 11:00 UTC (permalink / raw)
To: u-boot
On Monday 08 March 2021 18:44:58 Bin Meng wrote:
> On Mon, Mar 8, 2021 at 6:11 PM Marek Behun <marek.behun@nic.cz> wrote:
> >
> > On Mon, 8 Mar 2021 17:16:03 +0800
> > Bin Meng <bmeng.cn@gmail.com> wrote:
> >
> > > Hi Marek,
> > >
> > > On Sun, Mar 7, 2021 at 12:26 PM Marek Beh?n <marek.behun@nic.cz> wrote:
> > > >
> > > > Currently we use incremental linking (ld -r) to link several object
> > > > files from one directory into one built-in.o object file containing the
> > > > linked code from that directory (and its subdirectories).
> > > >
> > > > Linux has, some time ago, moved to thin archives instead.
> > > >
> > > > Thin archives are archives (.a) that do not really contain the object
> > > > files, only references to them.
> > > >
> > > > Using thin archives instead of incremental linking
> > > > - saves disk space
> > > > - apparently works better with dead code elimination
> > > > - makes things easier for LTO
> > > >
> > > > The third point is the important one for us. With incremental linking
> > > > there are several options how to do LTO, and that would unnecessarily
> > > > complicate things.
> > > >
> > > > On the other hand, by using thin archives we can make (via the
> > > > --whole-archive use flag) the final linking behave as if we passed all
> > > > the object files from the archives to the linking program as arguments.
> > >
> > > I don't think --whole-archive is required for LTO to work.
> >
> > It is. Linking fails if it is not used, for example for
> > nokia_rx51_defconfig.
>
> Could you investigate why? Is this due to missing marking some
> variables/functions as __used?
See email Message-ID: <20210306210045.pn3vzuarh23poxuv@pali> for details.
> >
> > > Switching to --whole-archive should be made conditionally when LTO is on,
> > > otherwise for targets that don't have
> > > -ffunction-sections/data-sections/--gc-sections specified, it will
> > > create unnecessary bloat.
> >
> > OK I will push into CI without this flag for non-LTO and if it passes
> > all tests I shall remove this flag for non-LTO.
> >
>
> Regards,
> Bin
^ permalink raw reply [flat|nested] 139+ messages in thread
* [PATCH u-boot 16/39] build: use thin archives instead of incremental linking
2021-03-08 11:00 ` Pali Rohár
@ 2021-03-08 11:41 ` Bin Meng
0 siblings, 0 replies; 139+ messages in thread
From: Bin Meng @ 2021-03-08 11:41 UTC (permalink / raw)
To: u-boot
On Mon, Mar 8, 2021 at 7:00 PM Pali Roh?r <pali@kernel.org> wrote:
>
> On Monday 08 March 2021 18:44:58 Bin Meng wrote:
> > On Mon, Mar 8, 2021 at 6:11 PM Marek Behun <marek.behun@nic.cz> wrote:
> > >
> > > On Mon, 8 Mar 2021 17:16:03 +0800
> > > Bin Meng <bmeng.cn@gmail.com> wrote:
> > >
> > > > Hi Marek,
> > > >
> > > > On Sun, Mar 7, 2021 at 12:26 PM Marek Beh?n <marek.behun@nic.cz> wrote:
> > > > >
> > > > > Currently we use incremental linking (ld -r) to link several object
> > > > > files from one directory into one built-in.o object file containing the
> > > > > linked code from that directory (and its subdirectories).
> > > > >
> > > > > Linux has, some time ago, moved to thin archives instead.
> > > > >
> > > > > Thin archives are archives (.a) that do not really contain the object
> > > > > files, only references to them.
> > > > >
> > > > > Using thin archives instead of incremental linking
> > > > > - saves disk space
> > > > > - apparently works better with dead code elimination
> > > > > - makes things easier for LTO
> > > > >
> > > > > The third point is the important one for us. With incremental linking
> > > > > there are several options how to do LTO, and that would unnecessarily
> > > > > complicate things.
> > > > >
> > > > > On the other hand, by using thin archives we can make (via the
> > > > > --whole-archive use flag) the final linking behave as if we passed all
> > > > > the object files from the archives to the linking program as arguments.
> > > >
> > > > I don't think --whole-archive is required for LTO to work.
> > >
> > > It is. Linking fails if it is not used, for example for
> > > nokia_rx51_defconfig.
> >
> > Could you investigate why? Is this due to missing marking some
> > variables/functions as __used?
>
> See email Message-ID: <20210306210045.pn3vzuarh23poxuv@pali> for details.
>
Looking at <20210306210045.pn3vzuarh23poxuv@pali>, the error you
reported seemed to be caused by not passing P to ar, as Marek replied
to you.
Regards,
Bin
^ permalink raw reply [flat|nested] 139+ messages in thread
* [PATCH u-boot 16/39] build: use thin archives instead of incremental linking
2021-03-08 10:44 ` Bin Meng
2021-03-08 11:00 ` Pali Rohár
@ 2021-03-08 11:18 ` Marek Behun
2021-03-08 11:32 ` Bin Meng
1 sibling, 1 reply; 139+ messages in thread
From: Marek Behun @ 2021-03-08 11:18 UTC (permalink / raw)
To: u-boot
On Mon, 8 Mar 2021 18:44:58 +0800
Bin Meng <bmeng.cn@gmail.com> wrote:
> Could you investigate why?
I could, but I don't understand why exactly I should
- Linux is also using --whole-archive
- it is working
- I have other things I would like to work on
Maybe you could look into this? :)
Marek
^ permalink raw reply [flat|nested] 139+ messages in thread
* [PATCH u-boot 16/39] build: use thin archives instead of incremental linking
2021-03-08 11:18 ` Marek Behun
@ 2021-03-08 11:32 ` Bin Meng
2021-03-08 11:52 ` Marek Behun
2021-03-08 13:24 ` Marek Behún
0 siblings, 2 replies; 139+ messages in thread
From: Bin Meng @ 2021-03-08 11:32 UTC (permalink / raw)
To: u-boot
On Mon, Mar 8, 2021 at 7:18 PM Marek Behun <marek.behun@nic.cz> wrote:
>
> On Mon, 8 Mar 2021 18:44:58 +0800
> Bin Meng <bmeng.cn@gmail.com> wrote:
>
> > Could you investigate why?
>
> I could, but I don't understand why exactly I should
> - Linux is also using --whole-archive
> - it is working
> - I have other things I would like to work on
>
> Maybe you could look into this? :)
Yes, I can look into this. I wonder if you already knew this which
could save some time as this is a normal review process, asking for
clarifications if something isn't clear.
Regards,
Bin
^ permalink raw reply [flat|nested] 139+ messages in thread
* [PATCH u-boot 16/39] build: use thin archives instead of incremental linking
2021-03-08 11:32 ` Bin Meng
@ 2021-03-08 11:52 ` Marek Behun
2021-03-08 13:24 ` Marek Behún
1 sibling, 0 replies; 139+ messages in thread
From: Marek Behun @ 2021-03-08 11:52 UTC (permalink / raw)
To: u-boot
On Mon, 8 Mar 2021 19:32:10 +0800
Bin Meng <bmeng.cn@gmail.com> wrote:
> On Mon, Mar 8, 2021 at 7:18 PM Marek Behun <marek.behun@nic.cz> wrote:
> >
> > On Mon, 8 Mar 2021 18:44:58 +0800
> > Bin Meng <bmeng.cn@gmail.com> wrote:
> >
> > > Could you investigate why?
> >
> > I could, but I don't understand why exactly I should
> > - Linux is also using --whole-archive
> > - it is working
> > - I have other things I would like to work on
> >
> > Maybe you could look into this? :)
>
> Yes, I can look into this. I wonder if you already knew this which
> could save some time as this is a normal review process, asking for
> clarifications if something isn't clear.
If I knew what? Whether it is used in Linux also?
To be honest I wasn't sure, I looked into Linux' sources before
replying.
The thing is, when I first worked on these patches, I just started with
some old LTO patches for Linux (which were not even merged then), and
played with the options until LTO worked for sandbox. Then the things
started to get complicated and I rebased the series many times, so I
did not remember which came from where.
Marek
^ permalink raw reply [flat|nested] 139+ messages in thread
* [PATCH u-boot 16/39] build: use thin archives instead of incremental linking
2021-03-08 11:32 ` Bin Meng
2021-03-08 11:52 ` Marek Behun
@ 2021-03-08 13:24 ` Marek Behún
2021-03-08 14:30 ` Bin Meng
1 sibling, 1 reply; 139+ messages in thread
From: Marek Behún @ 2021-03-08 13:24 UTC (permalink / raw)
To: u-boot
On Mon, 8 Mar 2021 19:32:10 +0800
Bin Meng <bmeng.cn@gmail.com> wrote:
> On Mon, Mar 8, 2021 at 7:18 PM Marek Behun <marek.behun@nic.cz> wrote:
> >
> > On Mon, 8 Mar 2021 18:44:58 +0800
> > Bin Meng <bmeng.cn@gmail.com> wrote:
> >
> > > Could you investigate why?
> >
> > I could, but I don't understand why exactly I should
> > - Linux is also using --whole-archive
> > - it is working
> > - I have other things I would like to work on
> >
> > Maybe you could look into this? :)
>
> Yes, I can look into this. I wonder if you already knew this which
> could save some time as this is a normal review process, asking for
> clarifications if something isn't clear.
Bin, CI is failing without the --whole-archive option.
What is interesting is that the binaries build successfully, but
testing them fails :)
You can try this (with and without the --whole-archive options) (note
that this is without LTO)
make qemu_arm_defconfig
CROSS_COMPILE=arm-compiler- make -j8
qemu-system-arm -M virt -nographic \
-netdev user,id=net0,tftp=$(pwd) \
-device e1000,netdev=net0 -device virtio-rng-pci \
-bios u-boot.bin -serial mon:stdio
With --whole-archive option this boots successfully into U-Boot,
without --whole-archive it just hangs.
Marek
^ permalink raw reply [flat|nested] 139+ messages in thread* [PATCH u-boot 16/39] build: use thin archives instead of incremental linking
2021-03-08 13:24 ` Marek Behún
@ 2021-03-08 14:30 ` Bin Meng
2021-03-08 15:22 ` Marek Behún
0 siblings, 1 reply; 139+ messages in thread
From: Bin Meng @ 2021-03-08 14:30 UTC (permalink / raw)
To: u-boot
Hi Marek,
On Mon, Mar 8, 2021 at 9:24 PM Marek Beh?n <marek.behun@nic.cz> wrote:
>
> On Mon, 8 Mar 2021 19:32:10 +0800
> Bin Meng <bmeng.cn@gmail.com> wrote:
>
> > On Mon, Mar 8, 2021 at 7:18 PM Marek Behun <marek.behun@nic.cz> wrote:
> > >
> > > On Mon, 8 Mar 2021 18:44:58 +0800
> > > Bin Meng <bmeng.cn@gmail.com> wrote:
> > >
> > > > Could you investigate why?
> > >
> > > I could, but I don't understand why exactly I should
> > > - Linux is also using --whole-archive
> > > - it is working
> > > - I have other things I would like to work on
> > >
> > > Maybe you could look into this? :)
> >
> > Yes, I can look into this. I wonder if you already knew this which
> > could save some time as this is a normal review process, asking for
> > clarifications if something isn't clear.
>
> Bin, CI is failing without the --whole-archive option.
>
> What is interesting is that the binaries build successfully, but
> testing them fails :)
>
> You can try this (with and without the --whole-archive options) (note
> that this is without LTO)
> make qemu_arm_defconfig
> CROSS_COMPILE=arm-compiler- make -j8
> qemu-system-arm -M virt -nographic \
> -netdev user,id=net0,tftp=$(pwd) \
> -device e1000,netdev=net0 -device virtio-rng-pci \
> -bios u-boot.bin -serial mon:stdio
>
> With --whole-archive option this boots successfully into U-Boot,
> without --whole-archive it just hangs.
Thanks for reporting. My initnial build testing on qemu_arm_defconfig
with this series succeeded but there are some warnings:
/opt/armv7-linux/bin/arm-linux-ld.bfd:
lib/efi_selftest/efi_selftest_miniapp_exception.o: plugin needed to
handle lto object
/opt/armv7-linux/bin/arm-linux-ld.bfd:
examples/standalone/hello_world.o: plugin needed to handle lto object
/opt/armv7-linux/bin/arm-linux-ld.bfd: examples/standalone/libstubs.o:
plugin needed to handle lto object
/opt/armv7-linux/bin/arm-linux-ld.bfd: warning: cannot find entry
symbol hello_world; defaulting to 000000000c100000
It looks we should update the make rules to remove "-flto" for these targets.
Applying the following diff to remove --whole-archive, I got a build error:
diff --git a/Makefile b/Makefile
index 0f538270d7..127630e060 100644
--- a/Makefile
+++ b/Makefile
@@ -1780,7 +1780,7 @@ quiet_cmd_u-boot__ ?= LTO $@
$(LTO_FINAL_CFLAGS) $(c_flags)
\
$(KBUILD_LDFLAGS:%=-Wl,%) $(LDFLAGS_u-boot:%=-Wl,%) -o
$@ \
-T u-boot.lds $(u-boot-init)
\
- -Wl,--start-group -Wl,--whole-archive
\
+ -Wl,--start-group
\
$(u-boot-main)
\
$(PLATFORM_LIBS)
\
-Wl,--no-whole-archive -Wl,--end-group
\
@@ -1790,9 +1790,9 @@ else
quiet_cmd_u-boot__ ?= LD $@
cmd_u-boot__ ?= $(LD) $(KBUILD_LDFLAGS) $(LDFLAGS_u-boot) -o $@
\
-T u-boot.lds $(u-boot-init)
\
- --start-group --whole-archive
\
+ --start-group
\
$(u-boot-main)
\
- --no-whole-archive --end-group
\
+ --end-group
\
$(PLATFORM_LIBS) -Map u-boot.map;
\
$(if $(ARCH_POSTLINK), $(MAKE) -f $(ARCH_POSTLINK) $@, true)
endif
LTO u-boot
/opt/armv7-linux/bin/../lib/gcc/arm-buildroot-linux-gnueabihf/9.3.0/../../../../arm-buildroot-linux-gnueabihf/bin/ld:
arch/arm/lib/lib.a(lib1funcs.o): in function `Ldiv0':
arch/arm/lib/lib1funcs.S:360: undefined reference to `__div0'
I am using a pre-built armv7 toolchain from https://toolchains.bootlin.com/
Regards,
Bin
^ permalink raw reply related [flat|nested] 139+ messages in thread* [PATCH u-boot 16/39] build: use thin archives instead of incremental linking
2021-03-08 14:30 ` Bin Meng
@ 2021-03-08 15:22 ` Marek Behún
2021-03-09 1:24 ` Bin Meng
0 siblings, 1 reply; 139+ messages in thread
From: Marek Behún @ 2021-03-08 15:22 UTC (permalink / raw)
To: u-boot
On Mon, 8 Mar 2021 22:30:17 +0800
Bin Meng <bmeng.cn@gmail.com> wrote:
> Hi Marek,
>
> On Mon, Mar 8, 2021 at 9:24 PM Marek Beh?n <marek.behun@nic.cz> wrote:
> >
> > On Mon, 8 Mar 2021 19:32:10 +0800
> > Bin Meng <bmeng.cn@gmail.com> wrote:
> >
> > > On Mon, Mar 8, 2021 at 7:18 PM Marek Behun <marek.behun@nic.cz>
> > > wrote:
> > > >
> > > > On Mon, 8 Mar 2021 18:44:58 +0800
> > > > Bin Meng <bmeng.cn@gmail.com> wrote:
> > > >
> > > > > Could you investigate why?
> > > >
> > > > I could, but I don't understand why exactly I should
> > > > - Linux is also using --whole-archive
> > > > - it is working
> > > > - I have other things I would like to work on
> > > >
> > > > Maybe you could look into this? :)
> > >
> > > Yes, I can look into this. I wonder if you already knew this which
> > > could save some time as this is a normal review process, asking
> > > for clarifications if something isn't clear.
> >
> > Bin, CI is failing without the --whole-archive option.
> >
> > What is interesting is that the binaries build successfully, but
> > testing them fails :)
> >
> > You can try this (with and without the --whole-archive options)
> > (note that this is without LTO)
> > make qemu_arm_defconfig
> > CROSS_COMPILE=arm-compiler- make -j8
> > qemu-system-arm -M virt -nographic \
> > -netdev user,id=net0,tftp=$(pwd) \
> > -device e1000,netdev=net0 -device virtio-rng-pci \
> > -bios u-boot.bin -serial mon:stdio
> >
> > With --whole-archive option this boots successfully into U-Boot,
> > without --whole-archive it just hangs.
>
> Thanks for reporting. My initnial build testing on qemu_arm_defconfig
> with this series succeeded but there are some warnings:
>
> /opt/armv7-linux/bin/arm-linux-ld.bfd:
> lib/efi_selftest/efi_selftest_miniapp_exception.o: plugin needed to
> handle lto object
> /opt/armv7-linux/bin/arm-linux-ld.bfd:
> examples/standalone/hello_world.o: plugin needed to handle lto object
> /opt/armv7-linux/bin/arm-linux-ld.bfd: examples/standalone/libstubs.o:
> plugin needed to handle lto object
> /opt/armv7-linux/bin/arm-linux-ld.bfd: warning: cannot find entry
> symbol hello_world; defaulting to 000000000c100000
>
> It looks we should update the make rules to remove "-flto" for these
> targets.
>
> Applying the following diff to remove --whole-archive, I got a build
> error:
>
> diff --git a/Makefile b/Makefile
> index 0f538270d7..127630e060 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1780,7 +1780,7 @@ quiet_cmd_u-boot__ ?= LTO $@
> $(LTO_FINAL_CFLAGS) $(c_flags)
> \
> $(KBUILD_LDFLAGS:%=-Wl,%) $(LDFLAGS_u-boot:%=-Wl,%) -o
> $@ \
> -T u-boot.lds $(u-boot-init)
> \
> - -Wl,--start-group -Wl,--whole-archive
> \
> + -Wl,--start-group
> \
> $(u-boot-main)
> \
> $(PLATFORM_LIBS)
> \
> -Wl,--no-whole-archive -Wl,--end-group
> \
> @@ -1790,9 +1790,9 @@ else
> quiet_cmd_u-boot__ ?= LD $@
> cmd_u-boot__ ?= $(LD) $(KBUILD_LDFLAGS) $(LDFLAGS_u-boot) -o $@
> \
> -T u-boot.lds $(u-boot-init)
> \
> - --start-group --whole-archive
> \
> + --start-group
> \
> $(u-boot-main)
> \
> - --no-whole-archive --end-group
> \
> + --end-group
> \
> $(PLATFORM_LIBS) -Map u-boot.map;
> \
> $(if $(ARCH_POSTLINK), $(MAKE) -f $(ARCH_POSTLINK)
> $@, true) endif
>
> LTO u-boot
> /opt/armv7-linux/bin/../lib/gcc/arm-buildroot-linux-gnueabihf/9.3.0/../../../../arm-buildroot-linux-gnueabihf/bin/ld:
> arch/arm/lib/lib.a(lib1funcs.o): in function `Ldiv0':
> arch/arm/lib/lib1funcs.S:360: undefined reference to `__div0'
>
> I am using a pre-built armv7 toolchain from
> https://toolchains.bootlin.com/
The
plugin needed to handle lto object
need another change in Makefiles, I will look into this.
As for the __div0 availability, that happens when compiling with LTO
and not using the --whole-archive flag.
^ permalink raw reply [flat|nested] 139+ messages in thread
* [PATCH u-boot 16/39] build: use thin archives instead of incremental linking
2021-03-08 15:22 ` Marek Behún
@ 2021-03-09 1:24 ` Bin Meng
2021-03-09 3:42 ` Bin Meng
0 siblings, 1 reply; 139+ messages in thread
From: Bin Meng @ 2021-03-09 1:24 UTC (permalink / raw)
To: u-boot
Hi Marek,
On Mon, Mar 8, 2021 at 11:22 PM Marek Beh?n <marek.behun@nic.cz> wrote:
>
> On Mon, 8 Mar 2021 22:30:17 +0800
> Bin Meng <bmeng.cn@gmail.com> wrote:
>
> > Hi Marek,
> >
> > On Mon, Mar 8, 2021 at 9:24 PM Marek Beh?n <marek.behun@nic.cz> wrote:
> > >
> > > On Mon, 8 Mar 2021 19:32:10 +0800
> > > Bin Meng <bmeng.cn@gmail.com> wrote:
> > >
> > > > On Mon, Mar 8, 2021 at 7:18 PM Marek Behun <marek.behun@nic.cz>
> > > > wrote:
> > > > >
> > > > > On Mon, 8 Mar 2021 18:44:58 +0800
> > > > > Bin Meng <bmeng.cn@gmail.com> wrote:
> > > > >
> > > > > > Could you investigate why?
> > > > >
> > > > > I could, but I don't understand why exactly I should
> > > > > - Linux is also using --whole-archive
> > > > > - it is working
> > > > > - I have other things I would like to work on
> > > > >
> > > > > Maybe you could look into this? :)
> > > >
> > > > Yes, I can look into this. I wonder if you already knew this which
> > > > could save some time as this is a normal review process, asking
> > > > for clarifications if something isn't clear.
> > >
> > > Bin, CI is failing without the --whole-archive option.
> > >
> > > What is interesting is that the binaries build successfully, but
> > > testing them fails :)
> > >
> > > You can try this (with and without the --whole-archive options)
> > > (note that this is without LTO)
> > > make qemu_arm_defconfig
> > > CROSS_COMPILE=arm-compiler- make -j8
> > > qemu-system-arm -M virt -nographic \
> > > -netdev user,id=net0,tftp=$(pwd) \
> > > -device e1000,netdev=net0 -device virtio-rng-pci \
> > > -bios u-boot.bin -serial mon:stdio
> > >
> > > With --whole-archive option this boots successfully into U-Boot,
> > > without --whole-archive it just hangs.
> >
> > Thanks for reporting. My initnial build testing on qemu_arm_defconfig
> > with this series succeeded but there are some warnings:
> >
> > /opt/armv7-linux/bin/arm-linux-ld.bfd:
> > lib/efi_selftest/efi_selftest_miniapp_exception.o: plugin needed to
> > handle lto object
> > /opt/armv7-linux/bin/arm-linux-ld.bfd:
> > examples/standalone/hello_world.o: plugin needed to handle lto object
> > /opt/armv7-linux/bin/arm-linux-ld.bfd: examples/standalone/libstubs.o:
> > plugin needed to handle lto object
> > /opt/armv7-linux/bin/arm-linux-ld.bfd: warning: cannot find entry
> > symbol hello_world; defaulting to 000000000c100000
> >
> > It looks we should update the make rules to remove "-flto" for these
> > targets.
> >
> > Applying the following diff to remove --whole-archive, I got a build
> > error:
> >
> > diff --git a/Makefile b/Makefile
> > index 0f538270d7..127630e060 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -1780,7 +1780,7 @@ quiet_cmd_u-boot__ ?= LTO $@
> > $(LTO_FINAL_CFLAGS) $(c_flags)
> > \
> > $(KBUILD_LDFLAGS:%=-Wl,%) $(LDFLAGS_u-boot:%=-Wl,%) -o
> > $@ \
> > -T u-boot.lds $(u-boot-init)
> > \
> > - -Wl,--start-group -Wl,--whole-archive
> > \
> > + -Wl,--start-group
> > \
> > $(u-boot-main)
> > \
> > $(PLATFORM_LIBS)
> > \
> > -Wl,--no-whole-archive -Wl,--end-group
> > \
> > @@ -1790,9 +1790,9 @@ else
> > quiet_cmd_u-boot__ ?= LD $@
> > cmd_u-boot__ ?= $(LD) $(KBUILD_LDFLAGS) $(LDFLAGS_u-boot) -o $@
> > \
> > -T u-boot.lds $(u-boot-init)
> > \
> > - --start-group --whole-archive
> > \
> > + --start-group
> > \
> > $(u-boot-main)
> > \
> > - --no-whole-archive --end-group
> > \
> > + --end-group
> > \
> > $(PLATFORM_LIBS) -Map u-boot.map;
> > \
> > $(if $(ARCH_POSTLINK), $(MAKE) -f $(ARCH_POSTLINK)
> > $@, true) endif
> >
> > LTO u-boot
> > /opt/armv7-linux/bin/../lib/gcc/arm-buildroot-linux-gnueabihf/9.3.0/../../../../arm-buildroot-linux-gnueabihf/bin/ld:
> > arch/arm/lib/lib.a(lib1funcs.o): in function `Ldiv0':
> > arch/arm/lib/lib1funcs.S:360: undefined reference to `__div0'
> >
> > I am using a pre-built armv7 toolchain from
> > https://toolchains.bootlin.com/
>
> The
> plugin needed to handle lto object
> need another change in Makefiles, I will look into this.
>
> As for the __div0 availability, that happens when compiling with LTO
> and not using the --whole-archive flag.
Yes, that's something we need to investigate. Using "--whole-archive"
just masks the issue.
Regards,
Bin
^ permalink raw reply [flat|nested] 139+ messages in thread
* [PATCH u-boot 16/39] build: use thin archives instead of incremental linking
2021-03-09 1:24 ` Bin Meng
@ 2021-03-09 3:42 ` Bin Meng
2021-03-09 10:36 ` Marek Behun
0 siblings, 1 reply; 139+ messages in thread
From: Bin Meng @ 2021-03-09 3:42 UTC (permalink / raw)
To: u-boot
Hi Marek,
On Tue, Mar 9, 2021 at 9:24 AM Bin Meng <bmeng.cn@gmail.com> wrote:
>
> Hi Marek,
>
> On Mon, Mar 8, 2021 at 11:22 PM Marek Beh?n <marek.behun@nic.cz> wrote:
> >
> > On Mon, 8 Mar 2021 22:30:17 +0800
> > Bin Meng <bmeng.cn@gmail.com> wrote:
> >
> > > Hi Marek,
> > >
> > > On Mon, Mar 8, 2021 at 9:24 PM Marek Beh?n <marek.behun@nic.cz> wrote:
> > > >
> > > > On Mon, 8 Mar 2021 19:32:10 +0800
> > > > Bin Meng <bmeng.cn@gmail.com> wrote:
> > > >
> > > > > On Mon, Mar 8, 2021 at 7:18 PM Marek Behun <marek.behun@nic.cz>
> > > > > wrote:
> > > > > >
> > > > > > On Mon, 8 Mar 2021 18:44:58 +0800
> > > > > > Bin Meng <bmeng.cn@gmail.com> wrote:
> > > > > >
> > > > > > > Could you investigate why?
> > > > > >
> > > > > > I could, but I don't understand why exactly I should
> > > > > > - Linux is also using --whole-archive
> > > > > > - it is working
> > > > > > - I have other things I would like to work on
> > > > > >
> > > > > > Maybe you could look into this? :)
> > > > >
> > > > > Yes, I can look into this. I wonder if you already knew this which
> > > > > could save some time as this is a normal review process, asking
> > > > > for clarifications if something isn't clear.
> > > >
> > > > Bin, CI is failing without the --whole-archive option.
> > > >
> > > > What is interesting is that the binaries build successfully, but
> > > > testing them fails :)
> > > >
> > > > You can try this (with and without the --whole-archive options)
> > > > (note that this is without LTO)
> > > > make qemu_arm_defconfig
> > > > CROSS_COMPILE=arm-compiler- make -j8
> > > > qemu-system-arm -M virt -nographic \
> > > > -netdev user,id=net0,tftp=$(pwd) \
> > > > -device e1000,netdev=net0 -device virtio-rng-pci \
> > > > -bios u-boot.bin -serial mon:stdio
> > > >
> > > > With --whole-archive option this boots successfully into U-Boot,
> > > > without --whole-archive it just hangs.
> > >
> > > Thanks for reporting. My initnial build testing on qemu_arm_defconfig
> > > with this series succeeded but there are some warnings:
> > >
> > > /opt/armv7-linux/bin/arm-linux-ld.bfd:
> > > lib/efi_selftest/efi_selftest_miniapp_exception.o: plugin needed to
> > > handle lto object
> > > /opt/armv7-linux/bin/arm-linux-ld.bfd:
> > > examples/standalone/hello_world.o: plugin needed to handle lto object
> > > /opt/armv7-linux/bin/arm-linux-ld.bfd: examples/standalone/libstubs.o:
> > > plugin needed to handle lto object
> > > /opt/armv7-linux/bin/arm-linux-ld.bfd: warning: cannot find entry
> > > symbol hello_world; defaulting to 000000000c100000
> > >
> > > It looks we should update the make rules to remove "-flto" for these
> > > targets.
> > >
> > > Applying the following diff to remove --whole-archive, I got a build
> > > error:
> > >
> > > diff --git a/Makefile b/Makefile
> > > index 0f538270d7..127630e060 100644
> > > --- a/Makefile
> > > +++ b/Makefile
> > > @@ -1780,7 +1780,7 @@ quiet_cmd_u-boot__ ?= LTO $@
> > > $(LTO_FINAL_CFLAGS) $(c_flags)
> > > \
> > > $(KBUILD_LDFLAGS:%=-Wl,%) $(LDFLAGS_u-boot:%=-Wl,%) -o
> > > $@ \
> > > -T u-boot.lds $(u-boot-init)
> > > \
> > > - -Wl,--start-group -Wl,--whole-archive
> > > \
> > > + -Wl,--start-group
> > > \
> > > $(u-boot-main)
> > > \
> > > $(PLATFORM_LIBS)
> > > \
> > > -Wl,--no-whole-archive -Wl,--end-group
> > > \
> > > @@ -1790,9 +1790,9 @@ else
> > > quiet_cmd_u-boot__ ?= LD $@
> > > cmd_u-boot__ ?= $(LD) $(KBUILD_LDFLAGS) $(LDFLAGS_u-boot) -o $@
> > > \
> > > -T u-boot.lds $(u-boot-init)
> > > \
> > > - --start-group --whole-archive
> > > \
> > > + --start-group
> > > \
> > > $(u-boot-main)
> > > \
> > > - --no-whole-archive --end-group
> > > \
> > > + --end-group
> > > \
> > > $(PLATFORM_LIBS) -Map u-boot.map;
> > > \
> > > $(if $(ARCH_POSTLINK), $(MAKE) -f $(ARCH_POSTLINK)
> > > $@, true) endif
> > >
> > > LTO u-boot
> > > /opt/armv7-linux/bin/../lib/gcc/arm-buildroot-linux-gnueabihf/9.3.0/../../../../arm-buildroot-linux-gnueabihf/bin/ld:
> > > arch/arm/lib/lib.a(lib1funcs.o): in function `Ldiv0':
> > > arch/arm/lib/lib1funcs.S:360: undefined reference to `__div0'
> > >
> > > I am using a pre-built armv7 toolchain from
> > > https://toolchains.bootlin.com/
> >
> > The
> > plugin needed to handle lto object
> > need another change in Makefiles, I will look into this.
> >
> > As for the __div0 availability, that happens when compiling with LTO
> > and not using the --whole-archive flag.
>
> Yes, that's something we need to investigate. Using "--whole-archive"
> just masks the issue.
Please ignore this. I think "--whole-archive" is correct after
experimenting with the compiler.
Regards,
Bin
^ permalink raw reply [flat|nested] 139+ messages in thread
* [PATCH u-boot 16/39] build: use thin archives instead of incremental linking
2021-03-09 3:42 ` Bin Meng
@ 2021-03-09 10:36 ` Marek Behun
0 siblings, 0 replies; 139+ messages in thread
From: Marek Behun @ 2021-03-09 10:36 UTC (permalink / raw)
To: u-boot
On Tue, 9 Mar 2021 11:42:08 +0800
Bin Meng <bmeng.cn@gmail.com> wrote:
> Hi Marek,
>
> On Tue, Mar 9, 2021 at 9:24 AM Bin Meng <bmeng.cn@gmail.com> wrote:
> >
> > Hi Marek,
> >
> > On Mon, Mar 8, 2021 at 11:22 PM Marek Beh?n <marek.behun@nic.cz> wrote:
> > >
> > > On Mon, 8 Mar 2021 22:30:17 +0800
> > > Bin Meng <bmeng.cn@gmail.com> wrote:
> > >
> > > > Hi Marek,
> > > >
> > > > On Mon, Mar 8, 2021 at 9:24 PM Marek Beh?n <marek.behun@nic.cz> wrote:
> > > > >
> > > > > On Mon, 8 Mar 2021 19:32:10 +0800
> > > > > Bin Meng <bmeng.cn@gmail.com> wrote:
> > > > >
> > > > > > On Mon, Mar 8, 2021 at 7:18 PM Marek Behun <marek.behun@nic.cz>
> > > > > > wrote:
> > > > > > >
> > > > > > > On Mon, 8 Mar 2021 18:44:58 +0800
> > > > > > > Bin Meng <bmeng.cn@gmail.com> wrote:
> > > > > > >
> > > > > > > > Could you investigate why?
> > > > > > >
> > > > > > > I could, but I don't understand why exactly I should
> > > > > > > - Linux is also using --whole-archive
> > > > > > > - it is working
> > > > > > > - I have other things I would like to work on
> > > > > > >
> > > > > > > Maybe you could look into this? :)
> > > > > >
> > > > > > Yes, I can look into this. I wonder if you already knew this which
> > > > > > could save some time as this is a normal review process, asking
> > > > > > for clarifications if something isn't clear.
> > > > >
> > > > > Bin, CI is failing without the --whole-archive option.
> > > > >
> > > > > What is interesting is that the binaries build successfully, but
> > > > > testing them fails :)
> > > > >
> > > > > You can try this (with and without the --whole-archive options)
> > > > > (note that this is without LTO)
> > > > > make qemu_arm_defconfig
> > > > > CROSS_COMPILE=arm-compiler- make -j8
> > > > > qemu-system-arm -M virt -nographic \
> > > > > -netdev user,id=net0,tftp=$(pwd) \
> > > > > -device e1000,netdev=net0 -device virtio-rng-pci \
> > > > > -bios u-boot.bin -serial mon:stdio
> > > > >
> > > > > With --whole-archive option this boots successfully into U-Boot,
> > > > > without --whole-archive it just hangs.
> > > >
> > > > Thanks for reporting. My initnial build testing on qemu_arm_defconfig
> > > > with this series succeeded but there are some warnings:
> > > >
> > > > /opt/armv7-linux/bin/arm-linux-ld.bfd:
> > > > lib/efi_selftest/efi_selftest_miniapp_exception.o: plugin needed to
> > > > handle lto object
> > > > /opt/armv7-linux/bin/arm-linux-ld.bfd:
> > > > examples/standalone/hello_world.o: plugin needed to handle lto object
> > > > /opt/armv7-linux/bin/arm-linux-ld.bfd: examples/standalone/libstubs.o:
> > > > plugin needed to handle lto object
> > > > /opt/armv7-linux/bin/arm-linux-ld.bfd: warning: cannot find entry
> > > > symbol hello_world; defaulting to 000000000c100000
> > > >
> > > > It looks we should update the make rules to remove "-flto" for these
> > > > targets.
> > > >
> > > > Applying the following diff to remove --whole-archive, I got a build
> > > > error:
> > > >
> > > > diff --git a/Makefile b/Makefile
> > > > index 0f538270d7..127630e060 100644
> > > > --- a/Makefile
> > > > +++ b/Makefile
> > > > @@ -1780,7 +1780,7 @@ quiet_cmd_u-boot__ ?= LTO $@
> > > > $(LTO_FINAL_CFLAGS) $(c_flags)
> > > > \
> > > > $(KBUILD_LDFLAGS:%=-Wl,%) $(LDFLAGS_u-boot:%=-Wl,%) -o
> > > > $@ \
> > > > -T u-boot.lds $(u-boot-init)
> > > > \
> > > > - -Wl,--start-group -Wl,--whole-archive
> > > > \
> > > > + -Wl,--start-group
> > > > \
> > > > $(u-boot-main)
> > > > \
> > > > $(PLATFORM_LIBS)
> > > > \
> > > > -Wl,--no-whole-archive -Wl,--end-group
> > > > \
> > > > @@ -1790,9 +1790,9 @@ else
> > > > quiet_cmd_u-boot__ ?= LD $@
> > > > cmd_u-boot__ ?= $(LD) $(KBUILD_LDFLAGS) $(LDFLAGS_u-boot) -o $@
> > > > \
> > > > -T u-boot.lds $(u-boot-init)
> > > > \
> > > > - --start-group --whole-archive
> > > > \
> > > > + --start-group
> > > > \
> > > > $(u-boot-main)
> > > > \
> > > > - --no-whole-archive --end-group
> > > > \
> > > > + --end-group
> > > > \
> > > > $(PLATFORM_LIBS) -Map u-boot.map;
> > > > \
> > > > $(if $(ARCH_POSTLINK), $(MAKE) -f $(ARCH_POSTLINK)
> > > > $@, true) endif
> > > >
> > > > LTO u-boot
> > > > /opt/armv7-linux/bin/../lib/gcc/arm-buildroot-linux-gnueabihf/9.3.0/../../../../arm-buildroot-linux-gnueabihf/bin/ld:
> > > > arch/arm/lib/lib.a(lib1funcs.o): in function `Ldiv0':
> > > > arch/arm/lib/lib1funcs.S:360: undefined reference to `__div0'
> > > >
> > > > I am using a pre-built armv7 toolchain from
> > > > https://toolchains.bootlin.com/
> > >
> > > The
> > > plugin needed to handle lto object
> > > need another change in Makefiles, I will look into this.
> > >
> > > As for the __div0 availability, that happens when compiling with LTO
> > > and not using the --whole-archive flag.
> >
> > Yes, that's something we need to investigate. Using "--whole-archive"
> > just masks the issue.
>
> Please ignore this. I think "--whole-archive" is correct after
> experimenting with the compiler.
So do you agree with this patch? Can I consider having your
Reviewed-by tag? :)
^ permalink raw reply [flat|nested] 139+ messages in thread
* [PATCH u-boot 16/39] build: use thin archives instead of incremental linking
2021-03-07 4:25 ` [PATCH u-boot 16/39] build: use thin archives instead of incremental linking Marek Behún
2021-03-08 9:16 ` Bin Meng
@ 2021-03-09 13:00 ` Bin Meng
2021-03-11 12:42 ` Marek Behun
1 sibling, 1 reply; 139+ messages in thread
From: Bin Meng @ 2021-03-09 13:00 UTC (permalink / raw)
To: u-boot
On Sun, Mar 7, 2021 at 12:26 PM Marek Beh?n <marek.behun@nic.cz> wrote:
>
> Currently we use incremental linking (ld -r) to link several object
> files from one directory into one built-in.o object file containing the
> linked code from that directory (and its subdirectories).
>
> Linux has, some time ago, moved to thin archives instead.
>
> Thin archives are archives (.a) that do not really contain the object
> files, only references to them.
>
> Using thin archives instead of incremental linking
> - saves disk space
> - apparently works better with dead code elimination
> - makes things easier for LTO
>
> The third point is the important one for us. With incremental linking
> there are several options how to do LTO, and that would unnecessarily
> complicate things.
>
> On the other hand, by using thin archives we can make (via the
> --whole-archive use flag) the final linking behave as if we passed all
> the object files from the archives to the linking program as arguments.
>
> We also need to use the P flag for ar, otherwise final linking may fail.
>
> Signed-off-by: Marek Beh?n <marek.behun@nic.cz>
> ---
> Makefile | 4 ++--
> arch/sandbox/config.mk | 10 +++++++---
> scripts/Makefile.build | 16 ++++++++--------
> scripts/Makefile.spl | 4 ++--
> 4 files changed, 19 insertions(+), 15 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index 7b0ba9df9a..6dc47810ea 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1754,9 +1754,9 @@ ARCH_POSTLINK := $(wildcard $(srctree)/arch/$(ARCH)/Makefile.postlink)
> quiet_cmd_u-boot__ ?= LD $@
> cmd_u-boot__ ?= $(LD) $(KBUILD_LDFLAGS) $(LDFLAGS_u-boot) -o $@ \
> -T u-boot.lds $(u-boot-init) \
> - --start-group \
> + --start-group --whole-archive \
--start-group is useless now.
> $(u-boot-main) \
> - --end-group \
> + --no-whole-archive --end-group \
and --end-group
> $(PLATFORM_LIBS) -Map u-boot.map; \
> $(if $(ARCH_POSTLINK), $(MAKE) -f $(ARCH_POSTLINK) $@, true)
>
> diff --git a/arch/sandbox/config.mk b/arch/sandbox/config.mk
> index 189e9c2b0c..d11b9c63c9 100644
> --- a/arch/sandbox/config.mk
> +++ b/arch/sandbox/config.mk
> @@ -17,13 +17,17 @@ PLATFORM_CPPFLAGS += $(shell $(SDL_CONFIG) --cflags)
> endif
>
> cmd_u-boot__ = $(CC) -o $@ -Wl,-T u-boot.lds $(u-boot-init) \
> - -Wl,--start-group $(u-boot-main) -Wl,--end-group \
> + -Wl,--start-group -Wl,--whole-archive \
> + $(u-boot-main) \
> + -Wl,--no-whole-archive -Wl,--end-group \
> $(PLATFORM_LIBS) -Wl,-Map -Wl,u-boot.map
>
> cmd_u-boot-spl = (cd $(obj) && $(CC) -o $(SPL_BIN) -Wl,-T u-boot-spl.lds \
> $(patsubst $(obj)/%,%,$(u-boot-spl-init)) \
> - -Wl,--start-group $(patsubst $(obj)/%,%,$(u-boot-spl-main)) \
> - $(patsubst $(obj)/%,%,$(u-boot-spl-platdata)) -Wl,--end-group \
> + -Wl,--start-group -Wl,--whole-archive \
> + $(patsubst $(obj)/%,%,$(u-boot-spl-main)) \
> + $(patsubst $(obj)/%,%,$(u-boot-spl-platdata)) \
> + -Wl,--no-whole-archive -Wl,--end-group \
> $(PLATFORM_LIBS) -Wl,-Map -Wl,u-boot-spl.map -Wl,--gc-sections)
>
> CONFIG_ARCH_DEVICE_TREE := sandbox
> diff --git a/scripts/Makefile.build b/scripts/Makefile.build
> index 705a886cb9..a9a02d7d33 100644
> --- a/scripts/Makefile.build
> +++ b/scripts/Makefile.build
> @@ -331,12 +331,11 @@ $(sort $(subdir-obj-y)): $(subdir-ym) ;
> # Rule to compile a set of .o files into one .o file
> #
> ifdef builtin-target
> -quiet_cmd_link_o_target = LD $@
> +quiet_cmd_link_o_target = AR $@
> # If the list of objects to link is empty, just create an empty built-in.o
> cmd_link_o_target = $(if $(strip $(obj-y)),\
> - $(LD) $(ld_flags) -r -o $@ $(filter $(obj-y), $^) \
> - $(cmd_secanalysis),\
> - rm -f $@; $(AR) rcs$(KBUILD_ARFLAGS) $@)
> + rm -f $@; $(AR) cDPrsT $@ $(filter $(obj-y), $^), \
> + rm -f $@; $(AR) cPrsT$(KBUILD_ARFLAGS) $@)
nits: should we use D for the empty one for consistency?
>
> $(builtin-target): $(obj-y) FORCE
> $(call if_changed,link_o_target)
> @@ -362,7 +361,7 @@ $(modorder-target): $(subdir-ym) FORCE
> #
> ifdef lib-target
> quiet_cmd_link_l_target = AR $@
> -cmd_link_l_target = rm -f $@; $(AR) rcs$(KBUILD_ARFLAGS) $@ $(lib-y)
> +cmd_link_l_target = rm -f $@; $(AR) cPrs$(KBUILD_ARFLAGS) $@ $(lib-y)
It looks this line change is not needed
>
> $(lib-target): $(lib-y) FORCE
> $(call if_changed,link_l_target)
> @@ -382,10 +381,11 @@ $(filter $(addprefix $(obj)/, \
> $($(subst $(obj)/,,$(@:.o=-objs))) \
> $($(subst $(obj)/,,$(@:.o=-y)))), $^)
>
> -quiet_cmd_link_multi-y = LD $@
> -cmd_link_multi-y = $(LD) $(ld_flags) -r -o $@ $(link_multi_deps) $(cmd_secanalysis)
>
> -quiet_cmd_link_multi-m = LD [M] $@
> +quiet_cmd_link_multi-y = AR $@
> +cmd_link_multi-y = rm -f $@; $(AR) cDPrsT $@ $(link_multi_deps)
> +
> +quiet_cmd_link_multi-m = AR [M] $@
> cmd_link_multi-m = $(cmd_link_multi-y)
>
> $(multi-used-y): FORCE
> diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl
> index 3b5f5046c9..889debb93c 100644
> --- a/scripts/Makefile.spl
> +++ b/scripts/Makefile.spl
> @@ -423,10 +423,10 @@ quiet_cmd_u-boot-spl ?= LD $@
> cmd_u-boot-spl ?= (cd $(obj) && \
> $(LD) $(KBUILD_LDFLAGS) $(LDFLAGS_$(@F)) \
> $(patsubst $(obj)/%,%,$(u-boot-spl-init)) \
> - --start-group \
> + --start-group --whole-archive \
> $(patsubst $(obj)/%,%,$(u-boot-spl-main)) \
> $(patsubst $(obj)/%,%,$(u-boot-spl-platdata)) \
> - --end-group \
> + --no-whole-archive --end-group \
> $(PLATFORM_LIBS) -Map $(SPL_BIN).map -o $(SPL_BIN) \
> )
>
Otherwise LGTM:
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Regards,
Bin
^ permalink raw reply [flat|nested] 139+ messages in thread
* [PATCH u-boot 16/39] build: use thin archives instead of incremental linking
2021-03-09 13:00 ` Bin Meng
@ 2021-03-11 12:42 ` Marek Behun
0 siblings, 0 replies; 139+ messages in thread
From: Marek Behun @ 2021-03-11 12:42 UTC (permalink / raw)
To: u-boot
On Tue, 9 Mar 2021 21:00:00 +0800
Bin Meng <bmeng.cn@gmail.com> wrote:
>
> --start-group is useless now.
>
> > $(u-boot-main) \
> > - --end-group \
> > + --no-whole-archive --end-group \
>
> and --end-group
>
I will test this
> > - rm -f $@; $(AR) rcs$(KBUILD_ARFLAGS) $@)
> > + rm -f $@; $(AR) cDPrsT $@ $(filter $(obj-y), $^), \
> > + rm -f $@; $(AR) cPrsT$(KBUILD_ARFLAGS) $@)
>
> nits: should we use D for the empty one for consistency?
OK
> >
> > $(builtin-target): $(obj-y) FORCE
> > $(call if_changed,link_o_target)
> > @@ -362,7 +361,7 @@ $(modorder-target): $(subdir-ym) FORCE
> > #
> > ifdef lib-target
> > quiet_cmd_link_l_target = AR $@
> > -cmd_link_l_target = rm -f $@; $(AR) rcs$(KBUILD_ARFLAGS) $@ $(lib-y)
> > +cmd_link_l_target = rm -f $@; $(AR) cPrs$(KBUILD_ARFLAGS) $@ $(lib-y)
>
> It looks this line change is not needed
Hmm. I will look into this, maybe I added it just for consistency.
> Otherwise LGTM:
> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
THX
^ permalink raw reply [flat|nested] 139+ messages in thread
* [PATCH u-boot 17/39] build: support building with Link Time Optimizations
2021-03-07 4:24 [PATCH u-boot 00/39] U-Boot LTO (Sandbox + Some ARM boards) Marek Behún
` (15 preceding siblings ...)
2021-03-07 4:25 ` [PATCH u-boot 16/39] build: use thin archives instead of incremental linking Marek Behún
@ 2021-03-07 4:25 ` Marek Behún
2021-03-09 13:30 ` Bin Meng
2021-03-07 4:25 ` [PATCH u-boot 18/39] build: LTO: move platform libs into --start-group list Marek Behún
` (21 subsequent siblings)
38 siblings, 1 reply; 139+ messages in thread
From: Marek Behún @ 2021-03-07 4:25 UTC (permalink / raw)
To: u-boot
Add plumbing for building U-Boot with Link Time Optimizations.
Signed-off-by: Marek Beh?n <marek.behun@nic.cz>
---
Kbuild | 2 ++
Kconfig | 19 +++++++++++++++++++
Makefile | 36 ++++++++++++++++++++++++++++++++++++
scripts/Makefile.lib | 3 +++
scripts/Makefile.spl | 14 ++++++++++++++
5 files changed, 74 insertions(+)
diff --git a/Kbuild b/Kbuild
index 1eac091594..bf52e54051 100644
--- a/Kbuild
+++ b/Kbuild
@@ -10,6 +10,8 @@ generic-offsets-file := include/generated/generic-asm-offsets.h
always := $(generic-offsets-file)
targets := lib/asm-offsets.s
+CFLAGS_REMOVE_asm-offsets.o := $(LTO_CFLAGS)
+
$(obj)/$(generic-offsets-file): $(obj)/lib/asm-offsets.s FORCE
$(call filechk,offsets,__GENERIC_ASM_OFFSETS_H__)
diff --git a/Kconfig b/Kconfig
index 86f0a39bb0..ceba53926f 100644
--- a/Kconfig
+++ b/Kconfig
@@ -85,6 +85,25 @@ config SPL_OPTIMIZE_INLINING
do what it thinks is best, which is desirable in some cases for size
reasons.
+config ARCH_SUPPORTS_LTO
+ bool
+
+config LTO
+ bool "Enable Link Time Optimizations"
+ depends on ARCH_SUPPORTS_LTO
+ default n
+ help
+ This option enables Link Time Optimization (LTO), a mechanism which
+ allows the compiler to optimize between different compilation units.
+
+ This can optimize away dead code paths, resulting in smaller binary
+ size (if CC_OPTIMIZE_FOR_SIZE is enabled).
+
+ This option is not available for every architecture and may
+ introduce bugs.
+
+ If unsure, say n.
+
config TPL_OPTIMIZE_INLINING
bool "Allow compiler to uninline functions marked 'inline' in TPL"
depends on TPL
diff --git a/Makefile b/Makefile
index 6dc47810ea..4eee0c4196 100644
--- a/Makefile
+++ b/Makefile
@@ -677,6 +677,28 @@ else
KBUILD_CFLAGS += -O2
endif
+LTO_CFLAGS :=
+LTO_FINAL_LDFLAGS :=
+export LTO_CFLAGS LTO_FINAL_LDFLAGS
+ifdef CONFIG_LTO
+ LTO_CFLAGS := -flto
+ LTO_FINAL_LDFLAGS := -fwhole-program
+
+ CFLAGS_NON_EFI += $(LTO_CFLAGS)
+
+ ifeq ($(cc-name),clang)
+ LTO_FINAL_LDFLAGS += -flto
+ else
+ LTO_FINAL_LDFLAGS += -fuse-linker-plugin -flto=jobserver
+
+ # use plugin aware tools
+ AR = $(CROSS_COMPILE)gcc-ar
+ NM = $(CROSS_COMPILE)gcc-nm
+ endif
+
+ KBUILD_CFLAGS += $(LTO_CFLAGS)
+endif
+
KBUILD_CFLAGS += $(call cc-option,-fno-stack-protector)
KBUILD_CFLAGS += $(call cc-option,-fno-delete-null-pointer-checks)
@@ -1751,6 +1773,19 @@ ARCH_POSTLINK := $(wildcard $(srctree)/arch/$(ARCH)/Makefile.postlink)
# Rule to link u-boot
# May be overridden by arch/$(ARCH)/config.mk
+ifdef CONFIG_LTO
+quiet_cmd_u-boot__ ?= LTO $@
+ cmd_u-boot__ ?= \
+ $(CC) -nostdlib -nostartfiles \
+ $(LTO_FINAL_CFLAGS) $(c_flags) \
+ $(KBUILD_LDFLAGS:%=-Wl,%) $(LDFLAGS_u-boot:%=-Wl,%) -o $@ \
+ -T u-boot.lds $(u-boot-init) \
+ -Wl,--start-group -Wl,--whole-archive \
+ $(u-boot-main) \
+ -Wl,--no-whole-archive -Wl,--end-group \
+ $(PLATFORM_LIBS) -Wl,-Map,u-boot.map; \
+ $(if $(ARCH_POSTLINK), $(MAKE) -f $(ARCH_POSTLINK) $@, true)
+else
quiet_cmd_u-boot__ ?= LD $@
cmd_u-boot__ ?= $(LD) $(KBUILD_LDFLAGS) $(LDFLAGS_u-boot) -o $@ \
-T u-boot.lds $(u-boot-init) \
@@ -1759,6 +1794,7 @@ quiet_cmd_u-boot__ ?= LD $@
--no-whole-archive --end-group \
$(PLATFORM_LIBS) -Map u-boot.map; \
$(if $(ARCH_POSTLINK), $(MAKE) -f $(ARCH_POSTLINK) $@, true)
+endif
quiet_cmd_smap = GEN common/system_map.o
cmd_smap = \
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index 78543c6dd1..78bbebe7e9 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -419,6 +419,9 @@ $(obj)/%_efi.so: $(obj)/%.o $(obj)/efi_crt0.o $(obj)/efi_reloc.o $(obj)/efi_free
targets += $(obj)/efi_crt0.o $(obj)/efi_reloc.o $(obj)/efi_freestanding.o
+CFLAGS_REMOVE_efi_reloc.o := $(LTO_CFLAGS)
+CFLAGS_REMOVE_efi_freestanding.o := $(LTO_CFLAGS)
+
# ACPI
# ---------------------------------------------------------------------------
#
diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl
index 889debb93c..6da5883442 100644
--- a/scripts/Makefile.spl
+++ b/scripts/Makefile.spl
@@ -419,6 +419,19 @@ $(obj)/$(SPL_BIN).sym: $(obj)/$(SPL_BIN) FORCE
# Rule to link u-boot-spl
# May be overridden by arch/$(ARCH)/config.mk
+ifdef CONFIG_LTO
+quiet_cmd_u-boot-spl ?= LTO $@
+ cmd_u-boot-spl ?= (cd $(obj) && \
+ $(CC) -nostdlib -nostartfiles $(LTO_FINAL_LDFLAGS) $(c_flags) \
+ $(KBUILD_LDFLAGS:%=-Wl,%) $(LDFLAGS_$(@F):%=-Wl,%) \
+ $(patsubst $(obj)/%,%,$(u-boot-spl-init)) \
+ -Wl,--start-group -Wl,--whole-archive \
+ $(patsubst $(obj)/%,%,$(u-boot-spl-main)) \
+ $(patsubst $(obj)/%,%,$(u-boot-spl-platdata)) \
+ -Wl,--no-whole-archive -Wl,--end-group \
+ $(PLATFORM_LIBS) -Wl,-Map,$(SPL_BIN).map -o $(SPL_BIN) \
+ )
+else
quiet_cmd_u-boot-spl ?= LD $@
cmd_u-boot-spl ?= (cd $(obj) && \
$(LD) $(KBUILD_LDFLAGS) $(LDFLAGS_$(@F)) \
@@ -429,6 +442,7 @@ quiet_cmd_u-boot-spl ?= LD $@
--no-whole-archive --end-group \
$(PLATFORM_LIBS) -Map $(SPL_BIN).map -o $(SPL_BIN) \
)
+endif
$(obj)/$(SPL_BIN): $(u-boot-spl-platdata) $(u-boot-spl-init) \
$(u-boot-spl-main) $(obj)/u-boot-spl.lds FORCE
--
2.26.2
^ permalink raw reply related [flat|nested] 139+ messages in thread* [PATCH u-boot 17/39] build: support building with Link Time Optimizations
2021-03-07 4:25 ` [PATCH u-boot 17/39] build: support building with Link Time Optimizations Marek Behún
@ 2021-03-09 13:30 ` Bin Meng
2021-03-11 12:45 ` Marek Behun
0 siblings, 1 reply; 139+ messages in thread
From: Bin Meng @ 2021-03-09 13:30 UTC (permalink / raw)
To: u-boot
On Sun, Mar 7, 2021 at 12:26 PM Marek Beh?n <marek.behun@nic.cz> wrote:
>
> Add plumbing for building U-Boot with Link Time Optimizations.
>
> Signed-off-by: Marek Beh?n <marek.behun@nic.cz>
> ---
> Kbuild | 2 ++
> Kconfig | 19 +++++++++++++++++++
> Makefile | 36 ++++++++++++++++++++++++++++++++++++
> scripts/Makefile.lib | 3 +++
> scripts/Makefile.spl | 14 ++++++++++++++
> 5 files changed, 74 insertions(+)
>
> diff --git a/Kbuild b/Kbuild
> index 1eac091594..bf52e54051 100644
> --- a/Kbuild
> +++ b/Kbuild
> @@ -10,6 +10,8 @@ generic-offsets-file := include/generated/generic-asm-offsets.h
> always := $(generic-offsets-file)
> targets := lib/asm-offsets.s
>
> +CFLAGS_REMOVE_asm-offsets.o := $(LTO_CFLAGS)
> +
> $(obj)/$(generic-offsets-file): $(obj)/lib/asm-offsets.s FORCE
> $(call filechk,offsets,__GENERIC_ASM_OFFSETS_H__)
>
> diff --git a/Kconfig b/Kconfig
> index 86f0a39bb0..ceba53926f 100644
> --- a/Kconfig
> +++ b/Kconfig
> @@ -85,6 +85,25 @@ config SPL_OPTIMIZE_INLINING
> do what it thinks is best, which is desirable in some cases for size
> reasons.
>
> +config ARCH_SUPPORTS_LTO
> + bool
> +
> +config LTO
> + bool "Enable Link Time Optimizations"
> + depends on ARCH_SUPPORTS_LTO
> + default n
nits: this line is not needed as the default value is n if omitted
> + help
> + This option enables Link Time Optimization (LTO), a mechanism which
> + allows the compiler to optimize between different compilation units.
> +
> + This can optimize away dead code paths, resulting in smaller binary
> + size (if CC_OPTIMIZE_FOR_SIZE is enabled).
> +
> + This option is not available for every architecture and may
> + introduce bugs.
> +
> + If unsure, say n.
> +
> config TPL_OPTIMIZE_INLINING
> bool "Allow compiler to uninline functions marked 'inline' in TPL"
> depends on TPL
> diff --git a/Makefile b/Makefile
> index 6dc47810ea..4eee0c4196 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -677,6 +677,28 @@ else
> KBUILD_CFLAGS += -O2
> endif
>
> +LTO_CFLAGS :=
> +LTO_FINAL_LDFLAGS :=
> +export LTO_CFLAGS LTO_FINAL_LDFLAGS
> +ifdef CONFIG_LTO
> + LTO_CFLAGS := -flto
> + LTO_FINAL_LDFLAGS := -fwhole-program
This one should not be necessary per my read of the GCC doc. Also in
your patch, it is only used in the SPL build.
> +
> + CFLAGS_NON_EFI += $(LTO_CFLAGS)
> +
> + ifeq ($(cc-name),clang)
> + LTO_FINAL_LDFLAGS += -flto
> + else
> + LTO_FINAL_LDFLAGS += -fuse-linker-plugin -flto=jobserver
> +
> + # use plugin aware tools
> + AR = $(CROSS_COMPILE)gcc-ar
> + NM = $(CROSS_COMPILE)gcc-nm
> + endif
> +
> + KBUILD_CFLAGS += $(LTO_CFLAGS)
> +endif
> +
> KBUILD_CFLAGS += $(call cc-option,-fno-stack-protector)
> KBUILD_CFLAGS += $(call cc-option,-fno-delete-null-pointer-checks)
>
> @@ -1751,6 +1773,19 @@ ARCH_POSTLINK := $(wildcard $(srctree)/arch/$(ARCH)/Makefile.postlink)
>
> # Rule to link u-boot
> # May be overridden by arch/$(ARCH)/config.mk
> +ifdef CONFIG_LTO
> +quiet_cmd_u-boot__ ?= LTO $@
> + cmd_u-boot__ ?= \
> + $(CC) -nostdlib -nostartfiles \
> + $(LTO_FINAL_CFLAGS) $(c_flags) \
LTO_FINAL_CFLAGS is not defined anywhere. I guess you wanted to use
LTO_FINAL_LDFLAGS?
> + $(KBUILD_LDFLAGS:%=-Wl,%) $(LDFLAGS_u-boot:%=-Wl,%) -o $@ \
> + -T u-boot.lds $(u-boot-init) \
> + -Wl,--start-group -Wl,--whole-archive \
--start-group should be dropped
> + $(u-boot-main) \
> + -Wl,--no-whole-archive -Wl,--end-group \
> + $(PLATFORM_LIBS) -Wl,-Map,u-boot.map; \
> + $(if $(ARCH_POSTLINK), $(MAKE) -f $(ARCH_POSTLINK) $@, true)
> +else
> quiet_cmd_u-boot__ ?= LD $@
> cmd_u-boot__ ?= $(LD) $(KBUILD_LDFLAGS) $(LDFLAGS_u-boot) -o $@ \
> -T u-boot.lds $(u-boot-init) \
> @@ -1759,6 +1794,7 @@ quiet_cmd_u-boot__ ?= LD $@
> --no-whole-archive --end-group \
> $(PLATFORM_LIBS) -Map u-boot.map; \
> $(if $(ARCH_POSTLINK), $(MAKE) -f $(ARCH_POSTLINK) $@, true)
> +endif
>
> quiet_cmd_smap = GEN common/system_map.o
> cmd_smap = \
> diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
> index 78543c6dd1..78bbebe7e9 100644
> --- a/scripts/Makefile.lib
> +++ b/scripts/Makefile.lib
> @@ -419,6 +419,9 @@ $(obj)/%_efi.so: $(obj)/%.o $(obj)/efi_crt0.o $(obj)/efi_reloc.o $(obj)/efi_free
>
> targets += $(obj)/efi_crt0.o $(obj)/efi_reloc.o $(obj)/efi_freestanding.o
>
> +CFLAGS_REMOVE_efi_reloc.o := $(LTO_CFLAGS)
> +CFLAGS_REMOVE_efi_freestanding.o := $(LTO_CFLAGS)
> +
> # ACPI
> # ---------------------------------------------------------------------------
> #
> diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl
> index 889debb93c..6da5883442 100644
> --- a/scripts/Makefile.spl
> +++ b/scripts/Makefile.spl
> @@ -419,6 +419,19 @@ $(obj)/$(SPL_BIN).sym: $(obj)/$(SPL_BIN) FORCE
>
> # Rule to link u-boot-spl
> # May be overridden by arch/$(ARCH)/config.mk
> +ifdef CONFIG_LTO
> +quiet_cmd_u-boot-spl ?= LTO $@
> + cmd_u-boot-spl ?= (cd $(obj) && \
> + $(CC) -nostdlib -nostartfiles $(LTO_FINAL_LDFLAGS) $(c_flags) \
> + $(KBUILD_LDFLAGS:%=-Wl,%) $(LDFLAGS_$(@F):%=-Wl,%) \
> + $(patsubst $(obj)/%,%,$(u-boot-spl-init)) \
> + -Wl,--start-group -Wl,--whole-archive \
> + $(patsubst $(obj)/%,%,$(u-boot-spl-main)) \
> + $(patsubst $(obj)/%,%,$(u-boot-spl-platdata)) \
> + -Wl,--no-whole-archive -Wl,--end-group \
> + $(PLATFORM_LIBS) -Wl,-Map,$(SPL_BIN).map -o $(SPL_BIN) \
> + )
> +else
> quiet_cmd_u-boot-spl ?= LD $@
> cmd_u-boot-spl ?= (cd $(obj) && \
> $(LD) $(KBUILD_LDFLAGS) $(LDFLAGS_$(@F)) \
> @@ -429,6 +442,7 @@ quiet_cmd_u-boot-spl ?= LD $@
> --no-whole-archive --end-group \
> $(PLATFORM_LIBS) -Map $(SPL_BIN).map -o $(SPL_BIN) \
> )
> +endif
>
> $(obj)/$(SPL_BIN): $(u-boot-spl-platdata) $(u-boot-spl-init) \
> $(u-boot-spl-main) $(obj)/u-boot-spl.lds FORCE
> --
Regards,
Bin
^ permalink raw reply [flat|nested] 139+ messages in thread
* [PATCH u-boot 17/39] build: support building with Link Time Optimizations
2021-03-09 13:30 ` Bin Meng
@ 2021-03-11 12:45 ` Marek Behun
0 siblings, 0 replies; 139+ messages in thread
From: Marek Behun @ 2021-03-11 12:45 UTC (permalink / raw)
To: u-boot
On Tue, 9 Mar 2021 21:30:26 +0800
Bin Meng <bmeng.cn@gmail.com> wrote:
> > +config LTO
> > + bool "Enable Link Time Optimizations"
> > + depends on ARCH_SUPPORTS_LTO
> > + default n
>
> nits: this line is not needed as the default value is n if omitted
This is for consistency. The other options in this file also use
"default n"
> > +ifdef CONFIG_LTO
> > + LTO_CFLAGS := -flto
> > + LTO_FINAL_LDFLAGS := -fwhole-program
>
> This one should not be necessary per my read of the GCC doc. Also in
> your patch, it is only used in the SPL build.
I shall do some tests.
> > +ifdef CONFIG_LTO
> > +quiet_cmd_u-boot__ ?= LTO $@
> > + cmd_u-boot__ ?= \
> > + $(CC) -nostdlib -nostartfiles \
> > + $(LTO_FINAL_CFLAGS) $(c_flags) \
>
> LTO_FINAL_CFLAGS is not defined anywhere. I guess you wanted to use
> LTO_FINAL_LDFLAGS?
THX, I forgot to change it here. We will see if this variable is needed
(since it only contains -fwhole-program, which may be dropped)
>
> > + $(KBUILD_LDFLAGS:%=-Wl,%) $(LDFLAGS_u-boot:%=-Wl,%) -o $@ \
> > + -T u-boot.lds $(u-boot-init) \
> > + -Wl,--start-group -Wl,--whole-archive \
>
> --start-group should be dropped
Will test
^ permalink raw reply [flat|nested] 139+ messages in thread
* [PATCH u-boot 18/39] build: LTO: move platform libs into --start-group list
2021-03-07 4:24 [PATCH u-boot 00/39] U-Boot LTO (Sandbox + Some ARM boards) Marek Behún
` (16 preceding siblings ...)
2021-03-07 4:25 ` [PATCH u-boot 17/39] build: support building with Link Time Optimizations Marek Behún
@ 2021-03-07 4:25 ` Marek Behún
2021-03-09 15:24 ` Bin Meng
2021-03-07 4:25 ` [PATCH u-boot 19/39] sandbox: errno: avoid conflict with libc's errno Marek Behún
` (20 subsequent siblings)
38 siblings, 1 reply; 139+ messages in thread
From: Marek Behún @ 2021-03-07 4:25 UTC (permalink / raw)
To: u-boot
When building with LTO, move $(PLATFORM_LIBS) into the --start-group /
--end-group list.
Otherwise some functions declared in assembly may not be resolved and
linking may fail.
Signed-off-by: Marek Beh?n <marek.behun@nic.cz>
---
Makefile | 3 ++-
scripts/Makefile.spl | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/Makefile b/Makefile
index 4eee0c4196..0f538270d7 100644
--- a/Makefile
+++ b/Makefile
@@ -1782,8 +1782,9 @@ quiet_cmd_u-boot__ ?= LTO $@
-T u-boot.lds $(u-boot-init) \
-Wl,--start-group -Wl,--whole-archive \
$(u-boot-main) \
+ $(PLATFORM_LIBS) \
-Wl,--no-whole-archive -Wl,--end-group \
- $(PLATFORM_LIBS) -Wl,-Map,u-boot.map; \
+ -Wl,-Map,u-boot.map; \
$(if $(ARCH_POSTLINK), $(MAKE) -f $(ARCH_POSTLINK) $@, true)
else
quiet_cmd_u-boot__ ?= LD $@
diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl
index 6da5883442..d89917ca8e 100644
--- a/scripts/Makefile.spl
+++ b/scripts/Makefile.spl
@@ -428,8 +428,9 @@ quiet_cmd_u-boot-spl ?= LTO $@
-Wl,--start-group -Wl,--whole-archive \
$(patsubst $(obj)/%,%,$(u-boot-spl-main)) \
$(patsubst $(obj)/%,%,$(u-boot-spl-platdata)) \
+ $(PLATFORM_LIBS) \
-Wl,--no-whole-archive -Wl,--end-group \
- $(PLATFORM_LIBS) -Wl,-Map,$(SPL_BIN).map -o $(SPL_BIN) \
+ -Wl,-Map,$(SPL_BIN).map -o $(SPL_BIN) \
)
else
quiet_cmd_u-boot-spl ?= LD $@
--
2.26.2
^ permalink raw reply related [flat|nested] 139+ messages in thread* [PATCH u-boot 18/39] build: LTO: move platform libs into --start-group list
2021-03-07 4:25 ` [PATCH u-boot 18/39] build: LTO: move platform libs into --start-group list Marek Behún
@ 2021-03-09 15:24 ` Bin Meng
2021-03-11 19:41 ` Marek Behun
0 siblings, 1 reply; 139+ messages in thread
From: Bin Meng @ 2021-03-09 15:24 UTC (permalink / raw)
To: u-boot
On Sun, Mar 7, 2021 at 12:26 PM Marek Beh?n <marek.behun@nic.cz> wrote:
>
> When building with LTO, move $(PLATFORM_LIBS) into the --start-group /
> --end-group list.
This should be --whole-archive
> Otherwise some functions declared in assembly may not be resolved and
> linking may fail.
I am not sure if this is caused by we build these lib functions with -flto?
>
> Signed-off-by: Marek Beh?n <marek.behun@nic.cz>
> ---
> Makefile | 3 ++-
> scripts/Makefile.spl | 3 ++-
> 2 files changed, 4 insertions(+), 2 deletions(-)
>
Regards,
Bin
^ permalink raw reply [flat|nested] 139+ messages in thread
* [PATCH u-boot 18/39] build: LTO: move platform libs into --start-group list
2021-03-09 15:24 ` Bin Meng
@ 2021-03-11 19:41 ` Marek Behun
0 siblings, 0 replies; 139+ messages in thread
From: Marek Behun @ 2021-03-11 19:41 UTC (permalink / raw)
To: u-boot
On Tue, 9 Mar 2021 23:24:01 +0800
Bin Meng <bmeng.cn@gmail.com> wrote:
> On Sun, Mar 7, 2021 at 12:26 PM Marek Beh?n <marek.behun@nic.cz> wrote:
> >
> > When building with LTO, move $(PLATFORM_LIBS) into the --start-group /
> > --end-group list.
>
> This should be --whole-archive
>
> > Otherwise some functions declared in assembly may not be resolved and
> > linking may fail.
>
> I am not sure if this is caused by we build these lib functions with -flto?
It is caused by using thin archives, not LTO
^ permalink raw reply [flat|nested] 139+ messages in thread
* [PATCH u-boot 19/39] sandbox: errno: avoid conflict with libc's errno
2021-03-07 4:24 [PATCH u-boot 00/39] U-Boot LTO (Sandbox + Some ARM boards) Marek Behún
` (17 preceding siblings ...)
2021-03-07 4:25 ` [PATCH u-boot 18/39] build: LTO: move platform libs into --start-group list Marek Behún
@ 2021-03-07 4:25 ` Marek Behún
2021-03-09 15:28 ` Bin Meng
2021-03-07 4:25 ` [PATCH u-boot 20/39] sandbox: use sections instead of symbols for getopt array boundaries Marek Behún
` (19 subsequent siblings)
38 siblings, 1 reply; 139+ messages in thread
From: Marek Behún @ 2021-03-07 4:25 UTC (permalink / raw)
To: u-boot
When building with LTO, the system libc's `errno` variable used in
arch/sandbox/cpu/os.c conflicts with U-Boot's `errno` (defined in
lib/errno.c) with the following error:
.../ld: errno@@GLIBC_PRIVATE: TLS definition in /lib64/libc.so.6
section .tbss mismatches non-TLS reference in
/tmp/u-boot.EQlEXz.ltrans0.ltrans.o
To avoid this conflict use different asm label for this variable when
CONFIG_SANDBOX is enabled.
Signed-off-by: Marek Beh?n <marek.behun@nic.cz>
---
include/errno.h | 8 +++++++-
lib/errno.c | 4 +++-
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/include/errno.h b/include/errno.h
index 3af539b9e9..652ad67306 100644
--- a/include/errno.h
+++ b/include/errno.h
@@ -8,7 +8,13 @@
#include <linux/errno.h>
-extern int errno;
+#ifdef __SANDBOX__
+#define __errno_asm_label asm("__u_boot_errno")
+#else
+#define __errno_asm_label
+#endif
+
+extern int errno __errno_asm_label;
#define __set_errno(val) do { errno = val; } while (0)
diff --git a/lib/errno.c b/lib/errno.c
index 8330a8fd14..ca0c756bd9 100644
--- a/lib/errno.c
+++ b/lib/errno.c
@@ -1 +1,3 @@
-int errno = 0;
+#include <errno.h>
+
+int errno __errno_asm_label = 0;
--
2.26.2
^ permalink raw reply related [flat|nested] 139+ messages in thread* [PATCH u-boot 19/39] sandbox: errno: avoid conflict with libc's errno
2021-03-07 4:25 ` [PATCH u-boot 19/39] sandbox: errno: avoid conflict with libc's errno Marek Behún
@ 2021-03-09 15:28 ` Bin Meng
0 siblings, 0 replies; 139+ messages in thread
From: Bin Meng @ 2021-03-09 15:28 UTC (permalink / raw)
To: u-boot
On Sun, Mar 7, 2021 at 12:26 PM Marek Beh?n <marek.behun@nic.cz> wrote:
>
> When building with LTO, the system libc's `errno` variable used in
> arch/sandbox/cpu/os.c conflicts with U-Boot's `errno` (defined in
> lib/errno.c) with the following error:
> .../ld: errno@@GLIBC_PRIVATE: TLS definition in /lib64/libc.so.6
> section .tbss mismatches non-TLS reference in
> /tmp/u-boot.EQlEXz.ltrans0.ltrans.o
>
> To avoid this conflict use different asm label for this variable when
> CONFIG_SANDBOX is enabled.
>
> Signed-off-by: Marek Beh?n <marek.behun@nic.cz>
> ---
> include/errno.h | 8 +++++++-
> lib/errno.c | 4 +++-
> 2 files changed, 10 insertions(+), 2 deletions(-)
>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
^ permalink raw reply [flat|nested] 139+ messages in thread
* [PATCH u-boot 20/39] sandbox: use sections instead of symbols for getopt array boundaries
2021-03-07 4:24 [PATCH u-boot 00/39] U-Boot LTO (Sandbox + Some ARM boards) Marek Behún
` (18 preceding siblings ...)
2021-03-07 4:25 ` [PATCH u-boot 19/39] sandbox: errno: avoid conflict with libc's errno Marek Behún
@ 2021-03-07 4:25 ` Marek Behún
2021-03-07 4:25 ` [PATCH u-boot 21/39] sandbox: make LTO available Marek Behún
` (18 subsequent siblings)
38 siblings, 0 replies; 139+ messages in thread
From: Marek Behún @ 2021-03-07 4:25 UTC (permalink / raw)
To: u-boot
In style of linked lists, instead of declaring symbols for boundaries
of getopt options array in the linker script, declare corresponding
sections and retrieve the boundaries via static inline functions.
Without this clang's LTO produces binary without any getopt options,
because for some reason it thinks that array is empty (start and end
symbols are at the same address).
Signed-off-by: Marek Beh?n <marek.behun@nic.cz>
---
arch/sandbox/cpu/os.c | 3 ++-
arch/sandbox/cpu/start.c | 3 ++-
arch/sandbox/cpu/u-boot-spl.lds | 8 +++++---
arch/sandbox/cpu/u-boot.lds | 8 +++++---
arch/sandbox/include/asm/sections.h | 21 ++++++++++++++++++---
5 files changed, 32 insertions(+), 11 deletions(-)
diff --git a/arch/sandbox/cpu/os.c b/arch/sandbox/cpu/os.c
index 3d8af0a52b..6d4fecee1d 100644
--- a/arch/sandbox/cpu/os.c
+++ b/arch/sandbox/cpu/os.c
@@ -327,7 +327,8 @@ static struct option *long_opts;
int os_parse_args(struct sandbox_state *state, int argc, char *argv[])
{
- struct sandbox_cmdline_option **sb_opt = __u_boot_sandbox_option_start;
+ struct sandbox_cmdline_option **sb_opt =
+ __u_boot_sandbox_option_start();
size_t num_options = __u_boot_sandbox_option_count();
size_t i;
diff --git a/arch/sandbox/cpu/start.c b/arch/sandbox/cpu/start.c
index 483a264040..05dc04d43a 100644
--- a/arch/sandbox/cpu/start.c
+++ b/arch/sandbox/cpu/start.c
@@ -58,7 +58,8 @@ static int h_compare_opt(const void *p1, const void *p2)
int sandbox_early_getopt_check(void)
{
struct sandbox_state *state = state_get_current();
- struct sandbox_cmdline_option **sb_opt = __u_boot_sandbox_option_start;
+ struct sandbox_cmdline_option **sb_opt =
+ __u_boot_sandbox_option_start();
size_t num_options = __u_boot_sandbox_option_count();
size_t i;
int max_arg_len, max_noarg_len;
diff --git a/arch/sandbox/cpu/u-boot-spl.lds b/arch/sandbox/cpu/u-boot-spl.lds
index 649abeb5ee..3a86595e85 100644
--- a/arch/sandbox/cpu/u-boot-spl.lds
+++ b/arch/sandbox/cpu/u-boot-spl.lds
@@ -13,9 +13,11 @@ SECTIONS
KEEP(*(SORT(.u_boot_list*)));
}
- __u_boot_sandbox_option_start = .;
- _u_boot_sandbox_getopt : { KEEP(*(.u_boot_sandbox_getopt)) }
- __u_boot_sandbox_option_end = .;
+ _u_boot_sandbox_getopt : {
+ *(.u_boot_sandbox_getopt_start)
+ KEEP(*(.u_boot_sandbox_getopt))
+ *(.u_boot_sandbox_getopt_end)
+ }
}
INSERT AFTER .data;
diff --git a/arch/sandbox/cpu/u-boot.lds b/arch/sandbox/cpu/u-boot.lds
index 936da5e140..1d917a3244 100644
--- a/arch/sandbox/cpu/u-boot.lds
+++ b/arch/sandbox/cpu/u-boot.lds
@@ -13,9 +13,11 @@ SECTIONS
KEEP(*(SORT(.u_boot_list*)));
}
- __u_boot_sandbox_option_start = .;
- _u_boot_sandbox_getopt : { *(.u_boot_sandbox_getopt) }
- __u_boot_sandbox_option_end = .;
+ _u_boot_sandbox_getopt : {
+ *(.u_boot_sandbox_getopt_start)
+ *(.u_boot_sandbox_getopt)
+ *(.u_boot_sandbox_getopt_end)
+ }
.__efi_runtime_start : {
*(.__efi_runtime_start)
diff --git a/arch/sandbox/include/asm/sections.h b/arch/sandbox/include/asm/sections.h
index fbc1bd11a3..f4351ae7db 100644
--- a/arch/sandbox/include/asm/sections.h
+++ b/arch/sandbox/include/asm/sections.h
@@ -13,12 +13,27 @@
struct sandbox_cmdline_option;
-extern struct sandbox_cmdline_option *__u_boot_sandbox_option_start[],
- *__u_boot_sandbox_option_end[];
+static inline struct sandbox_cmdline_option **
+__u_boot_sandbox_option_start(void)
+{
+ static char start[0] __aligned(4) __attribute__((unused))
+ __section(".u_boot_sandbox_getopt_start");
+
+ return (struct sandbox_cmdline_option **)&start;
+}
+
+static inline struct sandbox_cmdline_option **
+__u_boot_sandbox_option_end(void)
+{
+ static char end[0] __aligned(4) __attribute__((unused))
+ __section(".u_boot_sandbox_getopt_end");
+
+ return (struct sandbox_cmdline_option **)&end;
+}
static inline size_t __u_boot_sandbox_option_count(void)
{
- return __u_boot_sandbox_option_end - __u_boot_sandbox_option_start;
+ return __u_boot_sandbox_option_end() - __u_boot_sandbox_option_start();
}
#endif
--
2.26.2
^ permalink raw reply related [flat|nested] 139+ messages in thread* [PATCH u-boot 21/39] sandbox: make LTO available
2021-03-07 4:24 [PATCH u-boot 00/39] U-Boot LTO (Sandbox + Some ARM boards) Marek Behún
` (19 preceding siblings ...)
2021-03-07 4:25 ` [PATCH u-boot 20/39] sandbox: use sections instead of symbols for getopt array boundaries Marek Behún
@ 2021-03-07 4:25 ` Marek Behún
2021-03-10 5:36 ` Bin Meng
2021-03-07 4:25 ` [PATCH u-boot 22/39] sandbox: enable LTO by default Marek Behún
` (17 subsequent siblings)
38 siblings, 1 reply; 139+ messages in thread
From: Marek Behún @ 2021-03-07 4:25 UTC (permalink / raw)
To: u-boot
Make LTO available for sandbox architecture.
Signed-off-by: Marek Beh?n <marek.behun@nic.cz>
---
arch/Kconfig | 1 +
arch/sandbox/config.mk | 2 ++
2 files changed, 3 insertions(+)
diff --git a/arch/Kconfig b/arch/Kconfig
index 27843cd79c..a6dab3e56d 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -101,6 +101,7 @@ config RISCV
config SANDBOX
bool "Sandbox"
+ select ARCH_SUPPORTS_LTO
select BOARD_LATE_INIT
select BZIP2
select CMD_POWEROFF
diff --git a/arch/sandbox/config.mk b/arch/sandbox/config.mk
index d11b9c63c9..acf0a19dc4 100644
--- a/arch/sandbox/config.mk
+++ b/arch/sandbox/config.mk
@@ -17,12 +17,14 @@ PLATFORM_CPPFLAGS += $(shell $(SDL_CONFIG) --cflags)
endif
cmd_u-boot__ = $(CC) -o $@ -Wl,-T u-boot.lds $(u-boot-init) \
+ $(LTO_FINAL_LDFLAGS) \
-Wl,--start-group -Wl,--whole-archive \
$(u-boot-main) \
-Wl,--no-whole-archive -Wl,--end-group \
$(PLATFORM_LIBS) -Wl,-Map -Wl,u-boot.map
cmd_u-boot-spl = (cd $(obj) && $(CC) -o $(SPL_BIN) -Wl,-T u-boot-spl.lds \
+ $(LTO_FINAL_LDFLAGS) \
$(patsubst $(obj)/%,%,$(u-boot-spl-init)) \
-Wl,--start-group -Wl,--whole-archive \
$(patsubst $(obj)/%,%,$(u-boot-spl-main)) \
--
2.26.2
^ permalink raw reply related [flat|nested] 139+ messages in thread* [PATCH u-boot 22/39] sandbox: enable LTO by default
2021-03-07 4:24 [PATCH u-boot 00/39] U-Boot LTO (Sandbox + Some ARM boards) Marek Behún
` (20 preceding siblings ...)
2021-03-07 4:25 ` [PATCH u-boot 21/39] sandbox: make LTO available Marek Behún
@ 2021-03-07 4:25 ` Marek Behún
2021-03-10 5:33 ` Bin Meng
2021-03-07 4:25 ` [PATCH u-boot 23/39] ARM: global_data: make set_gd() work for armv5 and armv6 Marek Behún
` (16 subsequent siblings)
38 siblings, 1 reply; 139+ messages in thread
From: Marek Behún @ 2021-03-07 4:25 UTC (permalink / raw)
To: u-boot
Build sandbox targets with LTO by default.
Signed-off-by: Marek Beh?n <marek.behun@nic.cz>
---
arch/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/Kconfig b/arch/Kconfig
index a6dab3e56d..b884b7b248 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -123,6 +123,7 @@ config SANDBOX
select SYSRESET_CMD_POWEROFF
imply BITREVERSE
select BLOBLIST
+ imply LTO
imply CMD_DM
imply CMD_EXCEPTION
imply CMD_GETTIME
--
2.26.2
^ permalink raw reply related [flat|nested] 139+ messages in thread* [PATCH u-boot 23/39] ARM: global_data: make set_gd() work for armv5 and armv6
2021-03-07 4:24 [PATCH u-boot 00/39] U-Boot LTO (Sandbox + Some ARM boards) Marek Behún
` (21 preceding siblings ...)
2021-03-07 4:25 ` [PATCH u-boot 22/39] sandbox: enable LTO by default Marek Behún
@ 2021-03-07 4:25 ` Marek Behún
2021-03-07 4:25 ` [PATCH u-boot 24/39] ARM: make gd a function call for LTO and set via set_gd() Marek Behún
` (15 subsequent siblings)
38 siblings, 0 replies; 139+ messages in thread
From: Marek Behún @ 2021-03-07 4:25 UTC (permalink / raw)
To: u-boot
The Thumb instruction `ldr` is able to move high registers only from
armv7. For armv5 and armv6 we have to use `mov`.
Signed-off-by: Marek Beh?n <marek.behun@nic.cz>
---
arch/arm/include/asm/global_data.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm/include/asm/global_data.h b/arch/arm/include/asm/global_data.h
index fba655f3b9..bb82efafa6 100644
--- a/arch/arm/include/asm/global_data.h
+++ b/arch/arm/include/asm/global_data.h
@@ -122,8 +122,10 @@ static inline void set_gd(volatile gd_t *gd_ptr)
{
#ifdef CONFIG_ARM64
__asm__ volatile("ldr x18, %0\n" : : "m"(gd_ptr));
-#else
+#elif __ARM_ARCH >= 7
__asm__ volatile("ldr r9, %0\n" : : "m"(gd_ptr));
+#else
+ __asm__ volatile("mov r9, %0\n" : : "r"(gd_ptr));
#endif
}
--
2.26.2
^ permalink raw reply related [flat|nested] 139+ messages in thread* [PATCH u-boot 24/39] ARM: make gd a function call for LTO and set via set_gd()
2021-03-07 4:24 [PATCH u-boot 00/39] U-Boot LTO (Sandbox + Some ARM boards) Marek Behún
` (22 preceding siblings ...)
2021-03-07 4:25 ` [PATCH u-boot 23/39] ARM: global_data: make set_gd() work for armv5 and armv6 Marek Behún
@ 2021-03-07 4:25 ` Marek Behún
2021-03-07 4:25 ` [PATCH u-boot 25/39] ARM: fix LTO build for some thumb-interwork cases Marek Behún
` (14 subsequent siblings)
38 siblings, 0 replies; 139+ messages in thread
From: Marek Behún @ 2021-03-07 4:25 UTC (permalink / raw)
To: u-boot
On ARM, the gd pointer is stored in registers r9 / x18. For this the
-ffixed-r9 / -ffixed-x18 flag is used when compiling, but using global
register variables causes errors when building with LTO, and these
errors are very difficult to overcome.
Richard Biener says [1]:
Note that global register vars shouldn't be used with LTO and if they
are restricted to just a few compilation units the recommended fix is
to build those CUs without -flto.
We cannot do this for U-Boot since all CUs use -ffixed-reg flag.
It seems that with LTO we could in fact store the gd pointer differently
and gain performance or size benefit by allowing the compiler to use
r9 / x18. But this would need more work.
So for now, when building with LTO, go the clang way, and instead of
declaring gd a global register variable, we make it a function call via
macro.
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68384
Signed-off-by: Marek Beh?n <marek.behun@nic.cz>
---
arch/arm/cpu/arm926ejs/mxs/spl_boot.c | 2 +-
arch/arm/include/asm/global_data.h | 2 +-
arch/arm/mach-exynos/spl_boot.c | 2 +-
arch/arm/mach-imx/imx8m/soc.c | 2 +-
arch/arm/mach-imx/spl_imx_romapi.c | 16 ++++++++--------
5 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_boot.c b/arch/arm/cpu/arm926ejs/mxs/spl_boot.c
index a16a15e79d..66406cc857 100644
--- a/arch/arm/cpu/arm926ejs/mxs/spl_boot.c
+++ b/arch/arm/cpu/arm926ejs/mxs/spl_boot.c
@@ -122,7 +122,7 @@ void mxs_common_spl_init(const uint32_t arg, const uint32_t *resptr,
{
struct mxs_spl_data *data = MXS_SPL_DATA;
uint8_t bootmode = mxs_get_bootmode_index();
- gd = &gdata;
+ set_gd(&gdata);
mxs_spl_fixup_vectors();
diff --git a/arch/arm/include/asm/global_data.h b/arch/arm/include/asm/global_data.h
index bb82efafa6..2aff1c467c 100644
--- a/arch/arm/include/asm/global_data.h
+++ b/arch/arm/include/asm/global_data.h
@@ -91,7 +91,7 @@ struct arch_global_data {
#include <asm-generic/global_data.h>
-#ifdef __clang__
+#if defined(__clang__) || defined(CONFIG_LTO)
#define DECLARE_GLOBAL_DATA_PTR
#define gd get_gd()
diff --git a/arch/arm/mach-exynos/spl_boot.c b/arch/arm/mach-exynos/spl_boot.c
index 27f0dac182..722449881a 100644
--- a/arch/arm/mach-exynos/spl_boot.c
+++ b/arch/arm/mach-exynos/spl_boot.c
@@ -279,7 +279,7 @@ void memzero(void *s, size_t n)
*/
static void setup_global_data(gd_t *gdp)
{
- gd = gdp;
+ set_gd(gdp);
memzero((void *)gd, sizeof(gd_t));
gd->flags |= GD_FLG_RELOC;
gd->baudrate = CONFIG_BAUDRATE;
diff --git a/arch/arm/mach-imx/imx8m/soc.c b/arch/arm/mach-imx/imx8m/soc.c
index 5f37282ff1..15d0da7060 100644
--- a/arch/arm/mach-imx/imx8m/soc.c
+++ b/arch/arm/mach-imx/imx8m/soc.c
@@ -509,7 +509,7 @@ enum boot_device get_boot_device(void)
ret = g_rom_api->query_boot_infor(QUERY_BT_DEV, &boot,
((uintptr_t)&boot) ^ QUERY_BT_DEV);
- gd = pgd;
+ set_gd(pgd);
if (ret != ROM_API_OKAY) {
puts("ROMAPI: failure at query_boot_info\n");
diff --git a/arch/arm/mach-imx/spl_imx_romapi.c b/arch/arm/mach-imx/spl_imx_romapi.c
index 9f4d95982e..d2085dabd3 100644
--- a/arch/arm/mach-imx/spl_imx_romapi.c
+++ b/arch/arm/mach-imx/spl_imx_romapi.c
@@ -45,7 +45,7 @@ static ulong spl_romapi_read_seekable(struct spl_load_info *load,
ret = g_rom_api->download_image(buf, offset, byte,
((uintptr_t)buf) ^ offset ^ byte);
- gd = pgd;
+ set_gd(pgd);
if (ret == ROM_API_OKAY)
return count;
@@ -73,7 +73,7 @@ static int spl_romapi_load_image_seekable(struct spl_image_info *spl_image,
ret |= g_rom_api->query_boot_infor(QUERY_IMG_OFF, &image_offset,
((uintptr_t)&image_offset) ^ QUERY_IMG_OFF);
- gd = pgd;
+ set_gd(pgd);
if (ret != ROM_API_OKAY) {
puts("ROMAPI: Failure query boot infor pagesize/offset\n");
@@ -94,7 +94,7 @@ static int spl_romapi_load_image_seekable(struct spl_image_info *spl_image,
size = ALIGN(sizeof(struct image_header), pagesize);
ret = g_rom_api->download_image((u8 *)header, offset, size,
((uintptr_t)header) ^ offset ^ size);
- gd = pgd;
+ set_gd(pgd);
if (ret != ROM_API_OKAY) {
printf("ROMAPI: download failure offset 0x%x size 0x%x\n",
@@ -180,7 +180,7 @@ static int spl_romapi_load_image_stream(struct spl_image_info *spl_image,
ret = g_rom_api->query_boot_infor(QUERY_PAGE_SZ, &pagesize,
((uintptr_t)&pagesize) ^ QUERY_PAGE_SZ);
- gd = pgd;
+ set_gd(pgd);
if (ret != ROM_API_OKAY)
puts("failure at query_boot_info\n");
@@ -192,7 +192,7 @@ static int spl_romapi_load_image_stream(struct spl_image_info *spl_image,
for (i = 0; i < 640; i++) {
ret = g_rom_api->download_image(p, 0, pg,
((uintptr_t)p) ^ pg);
- gd = pgd;
+ set_gd(pgd);
if (ret != ROM_API_OKAY) {
puts("Steam(USB) download failure\n");
@@ -213,7 +213,7 @@ static int spl_romapi_load_image_stream(struct spl_image_info *spl_image,
if (p - pfit < sizeof(struct fdt_header)) {
ret = g_rom_api->download_image(p, 0, pg, ((uintptr_t)p) ^ pg);
- gd = pgd;
+ set_gd(pgd);
if (ret != ROM_API_OKAY) {
puts("Steam(USB) download failure\n");
@@ -237,7 +237,7 @@ static int spl_romapi_load_image_stream(struct spl_image_info *spl_image,
ret = g_rom_api->download_image(p, 0, imagesize,
((uintptr_t)p) ^ imagesize);
- gd = pgd;
+ set_gd(pgd);
p += imagesize;
@@ -280,7 +280,7 @@ int board_return_to_bootrom(struct spl_image_info *spl_image,
ret = g_rom_api->query_boot_infor(QUERY_BT_DEV, &boot,
((uintptr_t)&boot) ^ QUERY_BT_DEV);
- gd = pgd;
+ set_gd(pgd);
if (ret != ROM_API_OKAY) {
puts("ROMAPI: failure at query_boot_info\n");
--
2.26.2
^ permalink raw reply related [flat|nested] 139+ messages in thread* [PATCH u-boot 25/39] ARM: fix LTO build for some thumb-interwork cases
2021-03-07 4:24 [PATCH u-boot 00/39] U-Boot LTO (Sandbox + Some ARM boards) Marek Behún
` (23 preceding siblings ...)
2021-03-07 4:25 ` [PATCH u-boot 24/39] ARM: make gd a function call for LTO and set via set_gd() Marek Behún
@ 2021-03-07 4:25 ` Marek Behún
2021-03-07 4:25 ` [PATCH u-boot 26/39] ARM: fix LTO for imx28_xea Marek Behún
` (13 subsequent siblings)
38 siblings, 0 replies; 139+ messages in thread
From: Marek Behún @ 2021-03-07 4:25 UTC (permalink / raw)
To: u-boot
Fix LTO build for some thumb-interwork usecases (such as for
da850evm_defconfig), where inline assmebly such as
mrc p15,0,r2,c1,c0,0
causes the compiler to fail during LTO linking with
Error: selected processor does not support `mrc p15,0,r2,c1,c0,0'
in Thumb mode
Signed-off-by: Marek Beh?n <marek.behun@nic.cz>
---
arch/arm/cpu/arm926ejs/Makefile | 2 ++
arch/arm/lib/Makefile | 1 +
2 files changed, 3 insertions(+)
diff --git a/arch/arm/cpu/arm926ejs/Makefile b/arch/arm/cpu/arm926ejs/Makefile
index af63d5cc5e..98aafe805a 100644
--- a/arch/arm/cpu/arm926ejs/Makefile
+++ b/arch/arm/cpu/arm926ejs/Makefile
@@ -25,6 +25,8 @@ ifndef CONFIG_HAS_THUMB2
CFLAGS_cpu.o := -marm
CFLAGS_cache.o := -marm
+CFLAGS_REMOVE_cpu.o := $(LTO_CFLAGS)
+CFLAGS_REMOVE_cache.o := $(LTO_CFLAGS)
endif
endif
diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile
index 27b12e7f2b..61bef1d5af 100644
--- a/arch/arm/lib/Makefile
+++ b/arch/arm/lib/Makefile
@@ -64,6 +64,7 @@ endif
obj-y += cache.o
obj-$(CONFIG_SYS_ARM_CACHE_CP15) += cache-cp15.o
+CFLAGS_REMOVE_cache-cp15.o := $(LTO_CFLAGS)
obj-y += psci-dt.o
--
2.26.2
^ permalink raw reply related [flat|nested] 139+ messages in thread* [PATCH u-boot 26/39] ARM: fix LTO for imx28_xea
2021-03-07 4:24 [PATCH u-boot 00/39] U-Boot LTO (Sandbox + Some ARM boards) Marek Behún
` (24 preceding siblings ...)
2021-03-07 4:25 ` [PATCH u-boot 25/39] ARM: fix LTO build for some thumb-interwork cases Marek Behún
@ 2021-03-07 4:25 ` Marek Behún
2021-03-10 5:31 ` Bin Meng
2021-03-07 4:25 ` [PATCH u-boot 27/39] ARM: fix LTO for apf27 Marek Behún
` (12 subsequent siblings)
38 siblings, 1 reply; 139+ messages in thread
From: Marek Behún @ 2021-03-07 4:25 UTC (permalink / raw)
To: u-boot
When imx28_xea_defconfig is built with LTO, the compiler complains about
the two different declarations of _start:
include/asm-generic/sections.h as extern void _start(void);
arch/arm/cpu/arm926ejs/mxs/mxs.c as extern uint32_t _start;
Fix this.
Signed-off-by: Marek Beh?n <marek.behun@nic.cz>
---
arch/arm/cpu/arm926ejs/mxs/mxs.c | 2 +-
arch/arm/cpu/arm926ejs/mxs/spl_boot.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/mxs/mxs.c b/arch/arm/cpu/arm926ejs/mxs/mxs.c
index c9362136fb..81805e1955 100644
--- a/arch/arm/cpu/arm926ejs/mxs/mxs.c
+++ b/arch/arm/cpu/arm926ejs/mxs/mxs.c
@@ -25,6 +25,7 @@
#include <asm/arch/iomux.h>
#include <asm/arch/imx-regs.h>
#include <asm/arch/sys_proto.h>
+#include <asm/sections.h>
#include <linux/compiler.h>
DECLARE_GLOBAL_DATA_PTR;
@@ -98,7 +99,6 @@ int arch_cpu_init(void)
{
struct mxs_clkctrl_regs *clkctrl_regs =
(struct mxs_clkctrl_regs *)MXS_CLKCTRL_BASE;
- extern uint32_t _start;
mx28_fixup_vt((uint32_t)&_start);
diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_boot.c b/arch/arm/cpu/arm926ejs/mxs/spl_boot.c
index 66406cc857..0a8985b90a 100644
--- a/arch/arm/cpu/arm926ejs/mxs/spl_boot.c
+++ b/arch/arm/cpu/arm926ejs/mxs/spl_boot.c
@@ -16,6 +16,7 @@
#include <asm/arch/imx-regs.h>
#include <asm/arch/sys_proto.h>
#include <asm/gpio.h>
+#include <asm/sections.h>
#include <linux/compiler.h>
#include "mxs_init.h"
@@ -100,7 +101,6 @@ static void mxs_spl_fixup_vectors(void)
* thus this fixup. Our vectoring table is PIC, so copying is
* fine.
*/
- extern uint32_t _start;
/* cppcheck-suppress nullPointer */
memcpy(0x0, &_start, 0x60);
--
2.26.2
^ permalink raw reply related [flat|nested] 139+ messages in thread* [PATCH u-boot 26/39] ARM: fix LTO for imx28_xea
2021-03-07 4:25 ` [PATCH u-boot 26/39] ARM: fix LTO for imx28_xea Marek Behún
@ 2021-03-10 5:31 ` Bin Meng
0 siblings, 0 replies; 139+ messages in thread
From: Bin Meng @ 2021-03-10 5:31 UTC (permalink / raw)
To: u-boot
On Sun, Mar 7, 2021 at 12:26 PM Marek Beh?n <marek.behun@nic.cz> wrote:
>
> When imx28_xea_defconfig is built with LTO, the compiler complains about
> the two different declarations of _start:
> include/asm-generic/sections.h as extern void _start(void);
> arch/arm/cpu/arm926ejs/mxs/mxs.c as extern uint32_t _start;
>
> Fix this.
>
> Signed-off-by: Marek Beh?n <marek.behun@nic.cz>
> ---
> arch/arm/cpu/arm926ejs/mxs/mxs.c | 2 +-
> arch/arm/cpu/arm926ejs/mxs/spl_boot.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
^ permalink raw reply [flat|nested] 139+ messages in thread
* [PATCH u-boot 27/39] ARM: fix LTO for apf27
2021-03-07 4:24 [PATCH u-boot 00/39] U-Boot LTO (Sandbox + Some ARM boards) Marek Behún
` (25 preceding siblings ...)
2021-03-07 4:25 ` [PATCH u-boot 26/39] ARM: fix LTO for imx28_xea Marek Behún
@ 2021-03-07 4:25 ` Marek Behún
2021-03-07 4:25 ` [PATCH u-boot 28/39] ARM: fix LTO for keystone Marek Behún
` (11 subsequent siblings)
38 siblings, 0 replies; 139+ messages in thread
From: Marek Behún @ 2021-03-07 4:25 UTC (permalink / raw)
To: u-boot
When apf27_defconfig is built with LTO, linking complains about
undefined reference to `nand_boot`. This is because it is referenced
from inline assembly. Make it visible.
Signed-off-by: Marek Beh?n <marek.behun@nic.cz>
---
drivers/mtd/nand/raw/mxc_nand_spl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mtd/nand/raw/mxc_nand_spl.c b/drivers/mtd/nand/raw/mxc_nand_spl.c
index e1e542519d..2f054b60ed 100644
--- a/drivers/mtd/nand/raw/mxc_nand_spl.c
+++ b/drivers/mtd/nand/raw/mxc_nand_spl.c
@@ -326,7 +326,7 @@ int nand_spl_load_image(uint32_t from, unsigned int size, void *buf)
* configured and available since this code loads the main U-Boot image
* from NAND into SDRAM and starts it from there.
*/
-void nand_boot(void)
+__used void nand_boot(void)
{
__attribute__((noreturn)) void (*uboot)(void);
--
2.26.2
^ permalink raw reply related [flat|nested] 139+ messages in thread* [PATCH u-boot 28/39] ARM: fix LTO for keystone
2021-03-07 4:24 [PATCH u-boot 00/39] U-Boot LTO (Sandbox + Some ARM boards) Marek Behún
` (26 preceding siblings ...)
2021-03-07 4:25 ` [PATCH u-boot 27/39] ARM: fix LTO for apf27 Marek Behún
@ 2021-03-07 4:25 ` Marek Behún
2021-03-07 4:25 ` [PATCH u-boot 29/39] ARM: kona: fix clk_bsc_enable() type mismatch for LTO Marek Behún
` (10 subsequent siblings)
38 siblings, 0 replies; 139+ messages in thread
From: Marek Behún @ 2021-03-07 4:25 UTC (permalink / raw)
To: u-boot
When building keystone with LTO the compiler complains:
Error: selected processor does not support `smc #0' in Thumb mode
Fix this by removing -flto for the file implementing these SMC calls.
Signed-off-by: Marek Beh?n <marek.behun@nic.cz>
---
arch/arm/mach-keystone/Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-keystone/Makefile b/arch/arm/mach-keystone/Makefile
index 3e076e12ec..6c7c25090a 100644
--- a/arch/arm/mach-keystone/Makefile
+++ b/arch/arm/mach-keystone/Makefile
@@ -9,6 +9,7 @@ obj-y += init.o
obj-y += psc.o
obj-y += clock.o
obj-y += mon.o
+CFLAGS_REMOVE_mon.o := $(LTO_CFLAGS)
ifndef CONFIG_SPL_BUILD
obj-y += cmd_clock.o
obj-y += cmd_mon.o
--
2.26.2
^ permalink raw reply related [flat|nested] 139+ messages in thread* [PATCH u-boot 29/39] ARM: kona: fix clk_bsc_enable() type mismatch for LTO
2021-03-07 4:24 [PATCH u-boot 00/39] U-Boot LTO (Sandbox + Some ARM boards) Marek Behún
` (27 preceding siblings ...)
2021-03-07 4:25 ` [PATCH u-boot 28/39] ARM: fix LTO for keystone Marek Behún
@ 2021-03-07 4:25 ` Marek Behún
2021-03-10 5:29 ` Bin Meng
2021-03-07 4:25 ` [PATCH u-boot 30/39] ARM: imx6m: fix imx_eqos_txclk_set_rate() " Marek Behún
` (9 subsequent siblings)
38 siblings, 1 reply; 139+ messages in thread
From: Marek Behún @ 2021-03-07 4:25 UTC (permalink / raw)
To: u-boot
When building with LTO, the compiler complains about type mismatch of
function clk_bsc_enable() in file:
arch/arm/cpu/armv7/kona-common/clk-stubs.c
vs other files that define or use this function:
warning: type of ?clk_bsc_enable? does not match original declaration.
Change the type of this function to that of the other usages.
Signed-off-by: Marek Beh?n <marek.behun@nic.cz>
---
arch/arm/cpu/armv7/kona-common/clk-stubs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/cpu/armv7/kona-common/clk-stubs.c b/arch/arm/cpu/armv7/kona-common/clk-stubs.c
index 2dfa3f7e73..4eddaca887 100644
--- a/arch/arm/cpu/armv7/kona-common/clk-stubs.c
+++ b/arch/arm/cpu/armv7/kona-common/clk-stubs.c
@@ -14,7 +14,7 @@ int __weak clk_sdio_enable(void *base, u32 rate, u32 *actual_ratep)
return 0;
}
-int __weak clk_bsc_enable(void *base, u32 rate, u32 *actual_ratep)
+int __weak clk_bsc_enable(void *base)
{
return 0;
}
--
2.26.2
^ permalink raw reply related [flat|nested] 139+ messages in thread* [PATCH u-boot 29/39] ARM: kona: fix clk_bsc_enable() type mismatch for LTO
2021-03-07 4:25 ` [PATCH u-boot 29/39] ARM: kona: fix clk_bsc_enable() type mismatch for LTO Marek Behún
@ 2021-03-10 5:29 ` Bin Meng
0 siblings, 0 replies; 139+ messages in thread
From: Bin Meng @ 2021-03-10 5:29 UTC (permalink / raw)
To: u-boot
On Sun, Mar 7, 2021 at 12:26 PM Marek Beh?n <marek.behun@nic.cz> wrote:
>
> When building with LTO, the compiler complains about type mismatch of
> function clk_bsc_enable() in file:
> arch/arm/cpu/armv7/kona-common/clk-stubs.c
> vs other files that define or use this function:
> warning: type of ?clk_bsc_enable? does not match original declaration.
>
> Change the type of this function to that of the other usages.
>
> Signed-off-by: Marek Beh?n <marek.behun@nic.cz>
> ---
> arch/arm/cpu/armv7/kona-common/clk-stubs.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
^ permalink raw reply [flat|nested] 139+ messages in thread
* [PATCH u-boot 30/39] ARM: imx6m: fix imx_eqos_txclk_set_rate() type mismatch for LTO
2021-03-07 4:24 [PATCH u-boot 00/39] U-Boot LTO (Sandbox + Some ARM boards) Marek Behún
` (28 preceding siblings ...)
2021-03-07 4:25 ` [PATCH u-boot 29/39] ARM: kona: fix clk_bsc_enable() type mismatch for LTO Marek Behún
@ 2021-03-07 4:25 ` Marek Behún
2021-03-07 5:33 ` Sean Anderson
2021-03-10 5:27 ` Bin Meng
2021-03-07 4:25 ` [PATCH u-boot 31/39] ARM: fix LTO for seaboard Marek Behún
` (8 subsequent siblings)
38 siblings, 2 replies; 139+ messages in thread
From: Marek Behún @ 2021-03-07 4:25 UTC (permalink / raw)
To: u-boot
When building imx8mp_evk_defconfig with LTO, the compiler complains
about type mismatch of function imx_eqos_txclk_set_rate() in file
drivers/net/dwc_eth_qos.c:845:12
which contains a weak definition of this function, vs file
arch/arm/mach-imx/imx8m/clock_imx8mm.c
which contains an implementation.
Change the type of this function in the implementation to fix this.
Signed-off-by: Marek Beh?n <marek.behun@nic.cz>
---
arch/arm/mach-imx/imx8m/clock_imx8mm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-imx/imx8m/clock_imx8mm.c b/arch/arm/mach-imx/imx8m/clock_imx8mm.c
index 4024dafca1..554ff0eaca 100644
--- a/arch/arm/mach-imx/imx8m/clock_imx8mm.c
+++ b/arch/arm/mach-imx/imx8m/clock_imx8mm.c
@@ -838,7 +838,7 @@ int set_clk_eqos(enum enet_freq type)
return 0;
}
-int imx_eqos_txclk_set_rate(u32 rate)
+int imx_eqos_txclk_set_rate(ulong rate)
{
u32 val;
u32 eqos_post_div;
--
2.26.2
^ permalink raw reply related [flat|nested] 139+ messages in thread* [PATCH u-boot 30/39] ARM: imx6m: fix imx_eqos_txclk_set_rate() type mismatch for LTO
2021-03-07 4:25 ` [PATCH u-boot 30/39] ARM: imx6m: fix imx_eqos_txclk_set_rate() " Marek Behún
@ 2021-03-07 5:33 ` Sean Anderson
2021-03-07 12:13 ` Marek Behun
2021-03-10 5:27 ` Bin Meng
1 sibling, 1 reply; 139+ messages in thread
From: Sean Anderson @ 2021-03-07 5:33 UTC (permalink / raw)
To: u-boot
> Re: [PATCH u-boot 30/39] ARM: imx6m: fix imx_eqos_txclk_set_rate() type mismatch for LTO
imx8m?
On 3/6/21 11:25 PM, Marek Beh?n wrote:
> When building imx8mp_evk_defconfig with LTO, the compiler complains
> about type mismatch of function imx_eqos_txclk_set_rate() in file
> drivers/net/dwc_eth_qos.c:845:12
> which contains a weak definition of this function, vs file
> arch/arm/mach-imx/imx8m/clock_imx8mm.c
> which contains an implementation.
>
> Change the type of this function in the implementation to fix this.
>
> Signed-off-by: Marek Beh?n <marek.behun@nic.cz>
> ---
> arch/arm/mach-imx/imx8m/clock_imx8mm.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-imx/imx8m/clock_imx8mm.c b/arch/arm/mach-imx/imx8m/clock_imx8mm.c
> index 4024dafca1..554ff0eaca 100644
> --- a/arch/arm/mach-imx/imx8m/clock_imx8mm.c
> +++ b/arch/arm/mach-imx/imx8m/clock_imx8mm.c
> @@ -838,7 +838,7 @@ int set_clk_eqos(enum enet_freq type)
> return 0;
> }
>
> -int imx_eqos_txclk_set_rate(u32 rate)
> +int imx_eqos_txclk_set_rate(ulong rate)
> {
> u32 val;
> u32 eqos_post_div;
>
^ permalink raw reply [flat|nested] 139+ messages in thread* [PATCH u-boot 30/39] ARM: imx6m: fix imx_eqos_txclk_set_rate() type mismatch for LTO
2021-03-07 4:25 ` [PATCH u-boot 30/39] ARM: imx6m: fix imx_eqos_txclk_set_rate() " Marek Behún
2021-03-07 5:33 ` Sean Anderson
@ 2021-03-10 5:27 ` Bin Meng
1 sibling, 0 replies; 139+ messages in thread
From: Bin Meng @ 2021-03-10 5:27 UTC (permalink / raw)
To: u-boot
On Sun, Mar 7, 2021 at 12:26 PM Marek Beh?n <marek.behun@nic.cz> wrote:
>
> When building imx8mp_evk_defconfig with LTO, the compiler complains
> about type mismatch of function imx_eqos_txclk_set_rate() in file
> drivers/net/dwc_eth_qos.c:845:12
> which contains a weak definition of this function, vs file
> arch/arm/mach-imx/imx8m/clock_imx8mm.c
> which contains an implementation.
>
> Change the type of this function in the implementation to fix this.
>
> Signed-off-by: Marek Beh?n <marek.behun@nic.cz>
> ---
> arch/arm/mach-imx/imx8m/clock_imx8mm.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
^ permalink raw reply [flat|nested] 139+ messages in thread
* [PATCH u-boot 31/39] ARM: fix LTO for seaboard
2021-03-07 4:24 [PATCH u-boot 00/39] U-Boot LTO (Sandbox + Some ARM boards) Marek Behún
` (29 preceding siblings ...)
2021-03-07 4:25 ` [PATCH u-boot 30/39] ARM: imx6m: fix imx_eqos_txclk_set_rate() " Marek Behún
@ 2021-03-07 4:25 ` Marek Behún
2021-03-07 4:25 ` [PATCH u-boot 32/39] ARM: fix LTO for rockchip and samsung Marek Behún
` (7 subsequent siblings)
38 siblings, 0 replies; 139+ messages in thread
From: Marek Behún @ 2021-03-07 4:25 UTC (permalink / raw)
To: u-boot
When seaboard_defconfig is compiled with LTO, the compiler complains
about some instructions not being supported in ARM mode.
This is caused by arch/arm/mach-tegra/tegra20/warmboot_avp.c having
different CFLAGS declared in Makefile. This file needs to be compiled
without LTO.
Fix this by removing -flto for this file.
Signed-off-by: Marek Beh?n <marek.behun@nic.cz>
---
arch/arm/mach-tegra/tegra20/Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-tegra/tegra20/Makefile b/arch/arm/mach-tegra/tegra20/Makefile
index faaf30d068..bb17c90cca 100644
--- a/arch/arm/mach-tegra/tegra20/Makefile
+++ b/arch/arm/mach-tegra/tegra20/Makefile
@@ -10,6 +10,7 @@ endif
# flags for any startup files it might use.
CFLAGS_warmboot_avp.o = -march=armv4t -U__LINUX_ARM_ARCH__ \
-D__LINUX_ARM_ARCH__=4
+CFLAGS_REMOVE_warmboot_avp.o := $(LTO_CFLAGS)
obj-y += clock.o funcmux.o pinmux.o
obj-$(CONFIG_TEGRA_LP0) += warmboot.o crypto.o warmboot_avp.o
--
2.26.2
^ permalink raw reply related [flat|nested] 139+ messages in thread* [PATCH u-boot 32/39] ARM: fix LTO for rockchip and samsung
2021-03-07 4:24 [PATCH u-boot 00/39] U-Boot LTO (Sandbox + Some ARM boards) Marek Behún
` (30 preceding siblings ...)
2021-03-07 4:25 ` [PATCH u-boot 31/39] ARM: fix LTO for seaboard Marek Behún
@ 2021-03-07 4:25 ` Marek Behún
2021-03-10 5:25 ` Bin Meng
2021-03-07 4:25 ` [PATCH u-boot 33/39] ARM: omap3: fix LTO for DM3730 (and possibly other omap3 boards) Marek Behún
` (6 subsequent siblings)
38 siblings, 1 reply; 139+ messages in thread
From: Marek Behún @ 2021-03-07 4:25 UTC (permalink / raw)
To: u-boot
When building with LTO, the compiler complains about type mismatch of
function usb_gadget_handle_interrupts(). This function is defined
without parameters in files
arch/arm/mach-rockchip/board.c
board/samsung/common/exynos5-dt.c
but it should have one parameter, int index.
Fix this.
Signed-off-by: Marek Beh?n <marek.behun@nic.cz>
---
arch/arm/mach-rockchip/board.c | 2 +-
board/samsung/common/exynos5-dt.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-rockchip/board.c b/arch/arm/mach-rockchip/board.c
index c386b52987..5304eb055c 100644
--- a/arch/arm/mach-rockchip/board.c
+++ b/arch/arm/mach-rockchip/board.c
@@ -139,7 +139,7 @@ static struct dwc3_device dwc3_device_data = {
.hsphy_mode = USBPHY_INTERFACE_MODE_UTMIW,
};
-int usb_gadget_handle_interrupts(void)
+int usb_gadget_handle_interrupts(int index)
{
dwc3_uboot_handle_interrupt(0);
return 0;
diff --git a/board/samsung/common/exynos5-dt.c b/board/samsung/common/exynos5-dt.c
index 4463cdcb87..1318ea716a 100644
--- a/board/samsung/common/exynos5-dt.c
+++ b/board/samsung/common/exynos5-dt.c
@@ -126,7 +126,7 @@ static struct dwc3_device dwc3_device_data = {
.index = 0,
};
-int usb_gadget_handle_interrupts(void)
+int usb_gadget_handle_interrupts(int index)
{
dwc3_uboot_handle_interrupt(0);
return 0;
--
2.26.2
^ permalink raw reply related [flat|nested] 139+ messages in thread* [PATCH u-boot 32/39] ARM: fix LTO for rockchip and samsung
2021-03-07 4:25 ` [PATCH u-boot 32/39] ARM: fix LTO for rockchip and samsung Marek Behún
@ 2021-03-10 5:25 ` Bin Meng
0 siblings, 0 replies; 139+ messages in thread
From: Bin Meng @ 2021-03-10 5:25 UTC (permalink / raw)
To: u-boot
On Sun, Mar 7, 2021 at 12:26 PM Marek Beh?n <marek.behun@nic.cz> wrote:
>
> When building with LTO, the compiler complains about type mismatch of
> function usb_gadget_handle_interrupts(). This function is defined
> without parameters in files
> arch/arm/mach-rockchip/board.c
> board/samsung/common/exynos5-dt.c
> but it should have one parameter, int index.
>
> Fix this.
>
> Signed-off-by: Marek Beh?n <marek.behun@nic.cz>
> ---
> arch/arm/mach-rockchip/board.c | 2 +-
> board/samsung/common/exynos5-dt.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
^ permalink raw reply [flat|nested] 139+ messages in thread
* [PATCH u-boot 33/39] ARM: omap3: fix LTO for DM3730 (and possibly other omap3 boards)
2021-03-07 4:24 [PATCH u-boot 00/39] U-Boot LTO (Sandbox + Some ARM boards) Marek Behún
` (31 preceding siblings ...)
2021-03-07 4:25 ` [PATCH u-boot 32/39] ARM: fix LTO for rockchip and samsung Marek Behún
@ 2021-03-07 4:25 ` Marek Behún
2021-03-07 10:40 ` Adam Ford
2021-03-07 4:25 ` [PATCH u-boot 34/39] armv8: SPL: discard relocation information Marek Behún
` (5 subsequent siblings)
38 siblings, 1 reply; 139+ messages in thread
From: Marek Behún @ 2021-03-07 4:25 UTC (permalink / raw)
To: u-boot
Adam Ford says that DM3730 needs board.c compiled without LTO flags.
Also add clock.c, since it says in Makefile that it need different
flags.
Signed-off-by: Marek Beh?n <marek.behun@nic.cz>
Suggested-by: Adam Ford <aford173@gmail.com>
---
arch/arm/mach-omap2/omap3/Makefile | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/mach-omap2/omap3/Makefile b/arch/arm/mach-omap2/omap3/Makefile
index 91ed8ebc9f..7d22f04bbf 100644
--- a/arch/arm/mach-omap2/omap3/Makefile
+++ b/arch/arm/mach-omap2/omap3/Makefile
@@ -5,10 +5,12 @@
# If clock.c is compiled for Thumb2, then it fails on OMAP3530
CFLAGS_clock.o += -marm
+CFLAGS_REMOVE_clock.o := $(LTO_CFLAGS)
obj-y := lowlevel_init.o
obj-y += board.o
+CFLAGS_REMOVE_board.o := $(LTO_CFLAGS)
obj-y += boot.o
obj-y += clock.o
obj-y += sys_info.o
--
2.26.2
^ permalink raw reply related [flat|nested] 139+ messages in thread* [PATCH u-boot 33/39] ARM: omap3: fix LTO for DM3730 (and possibly other omap3 boards)
2021-03-07 4:25 ` [PATCH u-boot 33/39] ARM: omap3: fix LTO for DM3730 (and possibly other omap3 boards) Marek Behún
@ 2021-03-07 10:40 ` Adam Ford
0 siblings, 0 replies; 139+ messages in thread
From: Adam Ford @ 2021-03-07 10:40 UTC (permalink / raw)
To: u-boot
On Sat, Mar 6, 2021 at 10:26 PM Marek Beh?n <marek.behun@nic.cz> wrote:
>
> Adam Ford says that DM3730 needs board.c compiled without LTO flags.
>
> Also add clock.c, since it says in Makefile that it need different
> flags.
>
I managed to get the am3517_evm tested with the latest series, and it
boots just fine.
am3517_evm
Without LTO:
SPL 57255
U-Boot 664922
With LTO:
SPL 51497
U-Boot 642058
For a reduction in size of:
SPL -5758 (-10.06%)
U-Boot -22864 (-3.44%)
Tested-by: Adam Ford <aford173@gmail.com> #omap3_logic & am3517_evm
> Signed-off-by: Marek Beh?n <marek.behun@nic.cz>
> Suggested-by: Adam Ford <aford173@gmail.com>
> ---
> arch/arm/mach-omap2/omap3/Makefile | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm/mach-omap2/omap3/Makefile b/arch/arm/mach-omap2/omap3/Makefile
> index 91ed8ebc9f..7d22f04bbf 100644
> --- a/arch/arm/mach-omap2/omap3/Makefile
> +++ b/arch/arm/mach-omap2/omap3/Makefile
> @@ -5,10 +5,12 @@
>
> # If clock.c is compiled for Thumb2, then it fails on OMAP3530
> CFLAGS_clock.o += -marm
> +CFLAGS_REMOVE_clock.o := $(LTO_CFLAGS)
>
> obj-y := lowlevel_init.o
>
> obj-y += board.o
> +CFLAGS_REMOVE_board.o := $(LTO_CFLAGS)
> obj-y += boot.o
> obj-y += clock.o
> obj-y += sys_info.o
> --
> 2.26.2
>
^ permalink raw reply [flat|nested] 139+ messages in thread
* [PATCH u-boot 34/39] armv8: SPL: discard relocation information
2021-03-07 4:24 [PATCH u-boot 00/39] U-Boot LTO (Sandbox + Some ARM boards) Marek Behún
` (32 preceding siblings ...)
2021-03-07 4:25 ` [PATCH u-boot 33/39] ARM: omap3: fix LTO for DM3730 (and possibly other omap3 boards) Marek Behún
@ 2021-03-07 4:25 ` Marek Behún
2021-03-07 4:25 ` [PATCH u-boot 35/39] ata: ahci: fix ahci_link_up() type mismatch for LTO Marek Behún
` (4 subsequent siblings)
38 siblings, 0 replies; 139+ messages in thread
From: Marek Behún @ 2021-03-07 4:25 UTC (permalink / raw)
To: u-boot
For some reason when building SPL for ARMv8 with LTO, the relocation
information is not discarded.
Discard it explicitly in the linker script.
This fixes LTO build for imx8mm_venice_defconfig.
Signed-off-by: Marek Beh?n <marek.behun@nic.cz>
---
arch/arm/cpu/armv8/u-boot-spl.lds | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/cpu/armv8/u-boot-spl.lds b/arch/arm/cpu/armv8/u-boot-spl.lds
index 0e67ab09d7..9edb662b09 100644
--- a/arch/arm/cpu/armv8/u-boot-spl.lds
+++ b/arch/arm/cpu/armv8/u-boot-spl.lds
@@ -77,6 +77,7 @@ SECTIONS
KEEP(*(.__bss_end));
} >.sdram
+ /DISCARD/ : { *(.rela*) }
/DISCARD/ : { *(.dynsym) }
/DISCARD/ : { *(.dynstr*) }
/DISCARD/ : { *(.dynamic*) }
--
2.26.2
^ permalink raw reply related [flat|nested] 139+ messages in thread* [PATCH u-boot 35/39] ata: ahci: fix ahci_link_up() type mismatch for LTO
2021-03-07 4:24 [PATCH u-boot 00/39] U-Boot LTO (Sandbox + Some ARM boards) Marek Behún
` (33 preceding siblings ...)
2021-03-07 4:25 ` [PATCH u-boot 34/39] armv8: SPL: discard relocation information Marek Behún
@ 2021-03-07 4:25 ` Marek Behún
2021-03-10 5:23 ` Bin Meng
2021-03-07 4:25 ` [PATCH u-boot 36/39] ARM: make LTO available Marek Behún
` (3 subsequent siblings)
38 siblings, 1 reply; 139+ messages in thread
From: Marek Behún @ 2021-03-07 4:25 UTC (permalink / raw)
To: u-boot
When building highbank_defconfig with LTO, the compiler complains about
type mismatch of function ahci_link_up().
The third parameter of this function is of type u8 in
drivers/ata/ahci.c, but of type int in board/highbank/ahci.c.
There is no reason in using u8, and the code using this function
actually passes an int variable into the function (so it is implicitly
converted to u8).
Change the type of this parameter to int in drivers/ata/ahci.c.
Signed-off-by: Marek Beh?n <marek.behun@nic.cz>
---
drivers/ata/ahci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index 2ef21ec508..3d16bc21a8 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -110,7 +110,7 @@ static int waiting_for_cmd_completed(void __iomem *offset,
return (i < timeout_msec) ? 0 : -1;
}
-int __weak ahci_link_up(struct ahci_uc_priv *uc_priv, u8 port)
+int __weak ahci_link_up(struct ahci_uc_priv *uc_priv, int port)
{
u32 tmp;
int j = 0;
--
2.26.2
^ permalink raw reply related [flat|nested] 139+ messages in thread* [PATCH u-boot 35/39] ata: ahci: fix ahci_link_up() type mismatch for LTO
2021-03-07 4:25 ` [PATCH u-boot 35/39] ata: ahci: fix ahci_link_up() type mismatch for LTO Marek Behún
@ 2021-03-10 5:23 ` Bin Meng
0 siblings, 0 replies; 139+ messages in thread
From: Bin Meng @ 2021-03-10 5:23 UTC (permalink / raw)
To: u-boot
On Sun, Mar 7, 2021 at 12:26 PM Marek Beh?n <marek.behun@nic.cz> wrote:
>
> When building highbank_defconfig with LTO, the compiler complains about
> type mismatch of function ahci_link_up().
>
> The third parameter of this function is of type u8 in
> drivers/ata/ahci.c, but of type int in board/highbank/ahci.c.
>
> There is no reason in using u8, and the code using this function
> actually passes an int variable into the function (so it is implicitly
> converted to u8).
>
> Change the type of this parameter to int in drivers/ata/ahci.c.
>
> Signed-off-by: Marek Beh?n <marek.behun@nic.cz>
> ---
> drivers/ata/ahci.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
^ permalink raw reply [flat|nested] 139+ messages in thread
* [PATCH u-boot 36/39] ARM: make LTO available
2021-03-07 4:24 [PATCH u-boot 00/39] U-Boot LTO (Sandbox + Some ARM boards) Marek Behún
` (34 preceding siblings ...)
2021-03-07 4:25 ` [PATCH u-boot 35/39] ata: ahci: fix ahci_link_up() type mismatch for LTO Marek Behún
@ 2021-03-07 4:25 ` Marek Behún
2021-03-07 4:25 ` [PATCH u-boot 37/39] ARM: don't use -ffunction-sections/-fdata-sections with LTO build Marek Behún
` (2 subsequent siblings)
38 siblings, 0 replies; 139+ messages in thread
From: Marek Behún @ 2021-03-07 4:25 UTC (permalink / raw)
To: u-boot
Make LTO available for ARM architecture.
Signed-off-by: Marek Beh?n <marek.behun@nic.cz>
---
arch/Kconfig | 1 +
arch/arm/lib/Makefile | 2 ++
2 files changed, 3 insertions(+)
diff --git a/arch/Kconfig b/arch/Kconfig
index b884b7b248..bf4b8afcb4 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -33,6 +33,7 @@ config ARC
config ARM
bool "ARM architecture"
+ select ARCH_SUPPORTS_LTO
select CREATE_ARCH_SYMLINK
select HAVE_PRIVATE_LIBGCC if !ARM64
select SUPPORT_OF_CONTROL
diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile
index 61bef1d5af..7f66332715 100644
--- a/arch/arm/lib/Makefile
+++ b/arch/arm/lib/Makefile
@@ -45,6 +45,8 @@ obj-$(CONFIG_SEMIHOSTING) += semihosting.o
obj-y += bdinfo.o
obj-y += sections.o
+CFLAGS_REMOVE_sections.o := $(LTO_CFLAGS)
+
obj-y += stack.o
ifdef CONFIG_CPU_V7M
obj-y += interrupts_m.o
--
2.26.2
^ permalink raw reply related [flat|nested] 139+ messages in thread* [PATCH u-boot 37/39] ARM: don't use -ffunction-sections/-fdata-sections with LTO build
2021-03-07 4:24 [PATCH u-boot 00/39] U-Boot LTO (Sandbox + Some ARM boards) Marek Behún
` (35 preceding siblings ...)
2021-03-07 4:25 ` [PATCH u-boot 36/39] ARM: make LTO available Marek Behún
@ 2021-03-07 4:25 ` Marek Behún
2021-03-10 3:40 ` Bin Meng
2021-03-07 4:25 ` [PATCH u-boot 38/39] ARM: enable LTO for some boards Marek Behún
2021-03-07 4:25 ` [PATCH u-boot 39/39] DO NOT MERGE! ARM: enable LTO by default Marek Behún
38 siblings, 1 reply; 139+ messages in thread
From: Marek Behún @ 2021-03-07 4:25 UTC (permalink / raw)
To: u-boot
When building with LTO, using -ffunction-sections/-fdata-sections is not
useful anymore.
Signed-off-by: Marek Beh?n <marek.behun@nic.cz>
---
arch/arm/config.mk | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/arm/config.mk b/arch/arm/config.mk
index 4153f7e371..2b2c6ad2e5 100644
--- a/arch/arm/config.mk
+++ b/arch/arm/config.mk
@@ -15,8 +15,12 @@ CFLAGS_NON_EFI := -fno-pic -ffixed-r9 -ffunction-sections -fdata-sections
CFLAGS_EFI := -fpic -fshort-wchar
LDFLAGS_FINAL += --gc-sections
-PLATFORM_RELFLAGS += -ffunction-sections -fdata-sections \
- -fno-common -ffixed-r9
+
+ifndef CONFIG_LTO
+PLATFORM_RELFLAGS += -ffunction-sections -fdata-sections
+endif
+
+PLATFORM_RELFLAGS += -fno-common -ffixed-r9
PLATFORM_RELFLAGS += $(call cc-option, -msoft-float) \
$(call cc-option,-mshort-load-bytes,$(call cc-option,-malignment-traps,))
--
2.26.2
^ permalink raw reply related [flat|nested] 139+ messages in thread* [PATCH u-boot 37/39] ARM: don't use -ffunction-sections/-fdata-sections with LTO build
2021-03-07 4:25 ` [PATCH u-boot 37/39] ARM: don't use -ffunction-sections/-fdata-sections with LTO build Marek Behún
@ 2021-03-10 3:40 ` Bin Meng
2021-03-12 6:45 ` Marek Behun
0 siblings, 1 reply; 139+ messages in thread
From: Bin Meng @ 2021-03-10 3:40 UTC (permalink / raw)
To: u-boot
On Sun, Mar 7, 2021 at 12:26 PM Marek Beh?n <marek.behun@nic.cz> wrote:
>
> When building with LTO, using -ffunction-sections/-fdata-sections is not
> useful anymore.
>
> Signed-off-by: Marek Beh?n <marek.behun@nic.cz>
> ---
> arch/arm/config.mk | 8 ++++++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
I believe we should also remove --gc-sections.
Regards,
Bin
^ permalink raw reply [flat|nested] 139+ messages in thread
* [PATCH u-boot 37/39] ARM: don't use -ffunction-sections/-fdata-sections with LTO build
2021-03-10 3:40 ` Bin Meng
@ 2021-03-12 6:45 ` Marek Behun
2021-03-12 6:48 ` Bin Meng
0 siblings, 1 reply; 139+ messages in thread
From: Marek Behun @ 2021-03-12 6:45 UTC (permalink / raw)
To: u-boot
On Wed, 10 Mar 2021 11:40:42 +0800
Bin Meng <bmeng.cn@gmail.com> wrote:
> On Sun, Mar 7, 2021 at 12:26 PM Marek Beh?n <marek.behun@nic.cz> wrote:
> >
> > When building with LTO, using -ffunction-sections/-fdata-sections is not
> > useful anymore.
> >
> > Signed-off-by: Marek Beh?n <marek.behun@nic.cz>
> > ---
> > arch/arm/config.mk | 8 ++++++--
> > 1 file changed, 6 insertions(+), 2 deletions(-)
> >
>
> I believe we should also remove --gc-sections.
It seems that --gc-sections cannot be removed, otherwise some builds,
for example turris_mox_defconfig, fail with
LTO u-boot
/usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(lse-init.o): in function `init_have_lse_atomics':
/var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/config/aarch64/lse-init.c:44: undefined reference to `__getauxval'
/usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_absvsi2.o): in function `__absvdi2':
/var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:228: undefined reference to `abort'
/usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_absvsi2.o): in function `__absvsi2':
/var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:246: undefined reference to `abort'
/usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_absvdi2.o): in function `__absvti2':
/var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:267: undefined reference to `abort'
/usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_addvsi3.o): in function `__addvdi3':
/var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:81: undefined reference to `abort'
/usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_addvsi3.o): in function `__addvsi3':
/var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:92: undefined reference to `abort'
/usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_addvdi3.o):/var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:106: more undefined references to `abort' follow
/usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_eprintf.o): in function `__eprintf':
/var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:2152: undefined reference to `stderr'
/usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:2152: undefined reference to `stderr'
/usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_eprintf.o): in function `fprintf':
/usr/aarch64-unknown-linux-gnu/sys-include/bits/stdio2.h:103: undefined reference to `__fprintf_chk'
/usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_eprintf.o): in function `__eprintf':
/var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:2153: undefined reference to `fflush'
/usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:2154: undefined reference to `abort'
^ permalink raw reply [flat|nested] 139+ messages in thread
* [PATCH u-boot 37/39] ARM: don't use -ffunction-sections/-fdata-sections with LTO build
2021-03-12 6:45 ` Marek Behun
@ 2021-03-12 6:48 ` Bin Meng
2021-03-12 7:00 ` Marek Behun
2021-03-12 7:11 ` Marek Behun
0 siblings, 2 replies; 139+ messages in thread
From: Bin Meng @ 2021-03-12 6:48 UTC (permalink / raw)
To: u-boot
On Fri, Mar 12, 2021 at 2:45 PM Marek Behun <marek.behun@nic.cz> wrote:
>
> On Wed, 10 Mar 2021 11:40:42 +0800
> Bin Meng <bmeng.cn@gmail.com> wrote:
>
> > On Sun, Mar 7, 2021 at 12:26 PM Marek Beh?n <marek.behun@nic.cz> wrote:
> > >
> > > When building with LTO, using -ffunction-sections/-fdata-sections is not
> > > useful anymore.
> > >
> > > Signed-off-by: Marek Beh?n <marek.behun@nic.cz>
> > > ---
> > > arch/arm/config.mk | 8 ++++++--
> > > 1 file changed, 6 insertions(+), 2 deletions(-)
> > >
> >
> > I believe we should also remove --gc-sections.
>
> It seems that --gc-sections cannot be removed, otherwise some builds,
> for example turris_mox_defconfig, fail with
>
> LTO u-boot
> /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(lse-init.o): in function `init_have_lse_atomics':
> /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/config/aarch64/lse-init.c:44: undefined reference to `__getauxval'
> /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_absvsi2.o): in function `__absvdi2':
> /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:228: undefined reference to `abort'
> /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_absvsi2.o): in function `__absvsi2':
> /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:246: undefined reference to `abort'
> /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_absvdi2.o): in function `__absvti2':
> /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:267: undefined reference to `abort'
> /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_addvsi3.o): in function `__addvdi3':
> /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:81: undefined reference to `abort'
> /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_addvsi3.o): in function `__addvsi3':
> /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:92: undefined reference to `abort'
> /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_addvdi3.o):/var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:106: more undefined references to `abort' follow
> /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_eprintf.o): in function `__eprintf':
> /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:2152: undefined reference to `stderr'
> /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:2152: undefined reference to `stderr'
> /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_eprintf.o): in function `fprintf':
> /usr/aarch64-unknown-linux-gnu/sys-include/bits/stdio2.h:103: undefined reference to `__fprintf_chk'
> /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_eprintf.o): in function `__eprintf':
> /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:2153: undefined reference to `fflush'
> /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:2154: undefined reference to `abort'
Ouch! How compiler behaves when it comes to LTO and works with all
these compiler/linker options is really a mystery ...
Regards,
Bin
^ permalink raw reply [flat|nested] 139+ messages in thread
* [PATCH u-boot 37/39] ARM: don't use -ffunction-sections/-fdata-sections with LTO build
2021-03-12 6:48 ` Bin Meng
@ 2021-03-12 7:00 ` Marek Behun
2021-03-12 7:11 ` Marek Behun
1 sibling, 0 replies; 139+ messages in thread
From: Marek Behun @ 2021-03-12 7:00 UTC (permalink / raw)
To: u-boot
On Fri, 12 Mar 2021 14:48:04 +0800
Bin Meng <bmeng.cn@gmail.com> wrote:
> On Fri, Mar 12, 2021 at 2:45 PM Marek Behun <marek.behun@nic.cz> wrote:
> >
> > On Wed, 10 Mar 2021 11:40:42 +0800
> > Bin Meng <bmeng.cn@gmail.com> wrote:
> >
> > > On Sun, Mar 7, 2021 at 12:26 PM Marek Beh?n <marek.behun@nic.cz> wrote:
> > > >
> > > > When building with LTO, using -ffunction-sections/-fdata-sections is not
> > > > useful anymore.
> > > >
> > > > Signed-off-by: Marek Beh?n <marek.behun@nic.cz>
> > > > ---
> > > > arch/arm/config.mk | 8 ++++++--
> > > > 1 file changed, 6 insertions(+), 2 deletions(-)
> > > >
> > >
> > > I believe we should also remove --gc-sections.
> >
> > It seems that --gc-sections cannot be removed, otherwise some builds,
> > for example turris_mox_defconfig, fail with
> >
> > LTO u-boot
> > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(lse-init.o): in function `init_have_lse_atomics':
> > /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/config/aarch64/lse-init.c:44: undefined reference to `__getauxval'
> > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_absvsi2.o): in function `__absvdi2':
> > /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:228: undefined reference to `abort'
> > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_absvsi2.o): in function `__absvsi2':
> > /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:246: undefined reference to `abort'
> > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_absvdi2.o): in function `__absvti2':
> > /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:267: undefined reference to `abort'
> > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_addvsi3.o): in function `__addvdi3':
> > /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:81: undefined reference to `abort'
> > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_addvsi3.o): in function `__addvsi3':
> > /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:92: undefined reference to `abort'
> > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_addvdi3.o):/var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:106: more undefined references to `abort' follow
> > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_eprintf.o): in function `__eprintf':
> > /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:2152: undefined reference to `stderr'
> > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:2152: undefined reference to `stderr'
> > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_eprintf.o): in function `fprintf':
> > /usr/aarch64-unknown-linux-gnu/sys-include/bits/stdio2.h:103: undefined reference to `__fprintf_chk'
> > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_eprintf.o): in function `__eprintf':
> > /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:2153: undefined reference to `fflush'
> > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:2154: undefined reference to `abort'
>
> Ouch! How compiler behaves when it comes to LTO and works with all
> these compiler/linker options is really a mystery ...
Anyway this is weird. __fprintf_chk is a glibc function, so how it
ended here I don't know... I am going to investigate this
^ permalink raw reply [flat|nested] 139+ messages in thread
* [PATCH u-boot 37/39] ARM: don't use -ffunction-sections/-fdata-sections with LTO build
2021-03-12 6:48 ` Bin Meng
2021-03-12 7:00 ` Marek Behun
@ 2021-03-12 7:11 ` Marek Behun
2021-03-12 7:19 ` Bin Meng
1 sibling, 1 reply; 139+ messages in thread
From: Marek Behun @ 2021-03-12 7:11 UTC (permalink / raw)
To: u-boot
On Fri, 12 Mar 2021 14:48:04 +0800
Bin Meng <bmeng.cn@gmail.com> wrote:
> On Fri, Mar 12, 2021 at 2:45 PM Marek Behun <marek.behun@nic.cz> wrote:
> >
> > On Wed, 10 Mar 2021 11:40:42 +0800
> > Bin Meng <bmeng.cn@gmail.com> wrote:
> >
> > > On Sun, Mar 7, 2021 at 12:26 PM Marek Beh?n <marek.behun@nic.cz> wrote:
> > > >
> > > > When building with LTO, using -ffunction-sections/-fdata-sections is not
> > > > useful anymore.
> > > >
> > > > Signed-off-by: Marek Beh?n <marek.behun@nic.cz>
> > > > ---
> > > > arch/arm/config.mk | 8 ++++++--
> > > > 1 file changed, 6 insertions(+), 2 deletions(-)
> > > >
> > >
> > > I believe we should also remove --gc-sections.
> >
> > It seems that --gc-sections cannot be removed, otherwise some builds,
> > for example turris_mox_defconfig, fail with
> >
> > LTO u-boot
> > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(lse-init.o): in function `init_have_lse_atomics':
> > /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/config/aarch64/lse-init.c:44: undefined reference to `__getauxval'
> > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_absvsi2.o): in function `__absvdi2':
> > /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:228: undefined reference to `abort'
> > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_absvsi2.o): in function `__absvsi2':
> > /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:246: undefined reference to `abort'
> > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_absvdi2.o): in function `__absvti2':
> > /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:267: undefined reference to `abort'
> > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_addvsi3.o): in function `__addvdi3':
> > /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:81: undefined reference to `abort'
> > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_addvsi3.o): in function `__addvsi3':
> > /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:92: undefined reference to `abort'
> > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_addvdi3.o):/var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:106: more undefined references to `abort' follow
> > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_eprintf.o): in function `__eprintf':
> > /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:2152: undefined reference to `stderr'
> > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:2152: undefined reference to `stderr'
> > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_eprintf.o): in function `fprintf':
> > /usr/aarch64-unknown-linux-gnu/sys-include/bits/stdio2.h:103: undefined reference to `__fprintf_chk'
> > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_eprintf.o): in function `__eprintf':
> > /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:2153: undefined reference to `fflush'
> > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:2154: undefined reference to `abort'
>
> Ouch! How compiler behaves when it comes to LTO and works with all
> these compiler/linker options is really a mystery ...
OK, it seems that on aarch64 we are actually using system's libgcc :)
Not the internal one. So it seems we need --gc-sections to throw away
garbade that is not used.
Marek
^ permalink raw reply [flat|nested] 139+ messages in thread
* [PATCH u-boot 37/39] ARM: don't use -ffunction-sections/-fdata-sections with LTO build
2021-03-12 7:11 ` Marek Behun
@ 2021-03-12 7:19 ` Bin Meng
2021-03-12 7:29 ` Marek Behun
0 siblings, 1 reply; 139+ messages in thread
From: Bin Meng @ 2021-03-12 7:19 UTC (permalink / raw)
To: u-boot
On Fri, Mar 12, 2021 at 3:11 PM Marek Behun <marek.behun@nic.cz> wrote:
>
> On Fri, 12 Mar 2021 14:48:04 +0800
> Bin Meng <bmeng.cn@gmail.com> wrote:
>
> > On Fri, Mar 12, 2021 at 2:45 PM Marek Behun <marek.behun@nic.cz> wrote:
> > >
> > > On Wed, 10 Mar 2021 11:40:42 +0800
> > > Bin Meng <bmeng.cn@gmail.com> wrote:
> > >
> > > > On Sun, Mar 7, 2021 at 12:26 PM Marek Beh?n <marek.behun@nic.cz> wrote:
> > > > >
> > > > > When building with LTO, using -ffunction-sections/-fdata-sections is not
> > > > > useful anymore.
> > > > >
> > > > > Signed-off-by: Marek Beh?n <marek.behun@nic.cz>
> > > > > ---
> > > > > arch/arm/config.mk | 8 ++++++--
> > > > > 1 file changed, 6 insertions(+), 2 deletions(-)
> > > > >
> > > >
> > > > I believe we should also remove --gc-sections.
> > >
> > > It seems that --gc-sections cannot be removed, otherwise some builds,
> > > for example turris_mox_defconfig, fail with
> > >
> > > LTO u-boot
> > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(lse-init.o): in function `init_have_lse_atomics':
> > > /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/config/aarch64/lse-init.c:44: undefined reference to `__getauxval'
> > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_absvsi2.o): in function `__absvdi2':
> > > /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:228: undefined reference to `abort'
> > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_absvsi2.o): in function `__absvsi2':
> > > /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:246: undefined reference to `abort'
> > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_absvdi2.o): in function `__absvti2':
> > > /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:267: undefined reference to `abort'
> > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_addvsi3.o): in function `__addvdi3':
> > > /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:81: undefined reference to `abort'
> > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_addvsi3.o): in function `__addvsi3':
> > > /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:92: undefined reference to `abort'
> > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_addvdi3.o):/var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:106: more undefined references to `abort' follow
> > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_eprintf.o): in function `__eprintf':
> > > /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:2152: undefined reference to `stderr'
> > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:2152: undefined reference to `stderr'
> > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_eprintf.o): in function `fprintf':
> > > /usr/aarch64-unknown-linux-gnu/sys-include/bits/stdio2.h:103: undefined reference to `__fprintf_chk'
> > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_eprintf.o): in function `__eprintf':
> > > /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:2153: undefined reference to `fflush'
> > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:2154: undefined reference to `abort'
> >
> > Ouch! How compiler behaves when it comes to LTO and works with all
> > these compiler/linker options is really a mystery ...
>
> OK, it seems that on aarch64 we are actually using system's libgcc :)
Thanks.
> Not the internal one. So it seems we need --gc-sections to throw away
> garbade that is not used.
Needed only when CONFIG_USE_PRIVATE_LIBGCC is off?
Regards,
Bin
^ permalink raw reply [flat|nested] 139+ messages in thread
* [PATCH u-boot 37/39] ARM: don't use -ffunction-sections/-fdata-sections with LTO build
2021-03-12 7:19 ` Bin Meng
@ 2021-03-12 7:29 ` Marek Behun
2021-03-12 13:18 ` Tom Rini
0 siblings, 1 reply; 139+ messages in thread
From: Marek Behun @ 2021-03-12 7:29 UTC (permalink / raw)
To: u-boot
On Fri, 12 Mar 2021 15:19:26 +0800
Bin Meng <bmeng.cn@gmail.com> wrote:
> On Fri, Mar 12, 2021 at 3:11 PM Marek Behun <marek.behun@nic.cz> wrote:
> >
> > On Fri, 12 Mar 2021 14:48:04 +0800
> > Bin Meng <bmeng.cn@gmail.com> wrote:
> >
> > > On Fri, Mar 12, 2021 at 2:45 PM Marek Behun <marek.behun@nic.cz> wrote:
> > > >
> > > > On Wed, 10 Mar 2021 11:40:42 +0800
> > > > Bin Meng <bmeng.cn@gmail.com> wrote:
> > > >
> > > > > On Sun, Mar 7, 2021 at 12:26 PM Marek Beh?n <marek.behun@nic.cz> wrote:
> > > > > >
> > > > > > When building with LTO, using -ffunction-sections/-fdata-sections is not
> > > > > > useful anymore.
> > > > > >
> > > > > > Signed-off-by: Marek Beh?n <marek.behun@nic.cz>
> > > > > > ---
> > > > > > arch/arm/config.mk | 8 ++++++--
> > > > > > 1 file changed, 6 insertions(+), 2 deletions(-)
> > > > > >
> > > > >
> > > > > I believe we should also remove --gc-sections.
> > > >
> > > > It seems that --gc-sections cannot be removed, otherwise some builds,
> > > > for example turris_mox_defconfig, fail with
> > > >
> > > > LTO u-boot
> > > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(lse-init.o): in function `init_have_lse_atomics':
> > > > /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/config/aarch64/lse-init.c:44: undefined reference to `__getauxval'
> > > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_absvsi2.o): in function `__absvdi2':
> > > > /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:228: undefined reference to `abort'
> > > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_absvsi2.o): in function `__absvsi2':
> > > > /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:246: undefined reference to `abort'
> > > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_absvdi2.o): in function `__absvti2':
> > > > /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:267: undefined reference to `abort'
> > > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_addvsi3.o): in function `__addvdi3':
> > > > /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:81: undefined reference to `abort'
> > > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_addvsi3.o): in function `__addvsi3':
> > > > /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:92: undefined reference to `abort'
> > > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_addvdi3.o):/var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:106: more undefined references to `abort' follow
> > > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_eprintf.o): in function `__eprintf':
> > > > /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:2152: undefined reference to `stderr'
> > > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:2152: undefined reference to `stderr'
> > > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_eprintf.o): in function `fprintf':
> > > > /usr/aarch64-unknown-linux-gnu/sys-include/bits/stdio2.h:103: undefined reference to `__fprintf_chk'
> > > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_eprintf.o): in function `__eprintf':
> > > > /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:2153: undefined reference to `fflush'
> > > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:2154: undefined reference to `abort'
> > >
> > > Ouch! How compiler behaves when it comes to LTO and works with all
> > > these compiler/linker options is really a mystery ...
> >
> > OK, it seems that on aarch64 we are actually using system's libgcc :)
>
> Thanks.
>
> > Not the internal one. So it seems we need --gc-sections to throw away
> > garbade that is not used.
>
> Needed only when CONFIG_USE_PRIVATE_LIBGCC is off?
Seems that way.
^ permalink raw reply [flat|nested] 139+ messages in thread
* [PATCH u-boot 37/39] ARM: don't use -ffunction-sections/-fdata-sections with LTO build
2021-03-12 7:29 ` Marek Behun
@ 2021-03-12 13:18 ` Tom Rini
2021-03-12 13:44 ` Marek Behun
0 siblings, 1 reply; 139+ messages in thread
From: Tom Rini @ 2021-03-12 13:18 UTC (permalink / raw)
To: u-boot
On Fri, Mar 12, 2021 at 08:29:05AM +0100, Marek Behun wrote:
> On Fri, 12 Mar 2021 15:19:26 +0800
> Bin Meng <bmeng.cn@gmail.com> wrote:
>
> > On Fri, Mar 12, 2021 at 3:11 PM Marek Behun <marek.behun@nic.cz> wrote:
> > >
> > > On Fri, 12 Mar 2021 14:48:04 +0800
> > > Bin Meng <bmeng.cn@gmail.com> wrote:
> > >
> > > > On Fri, Mar 12, 2021 at 2:45 PM Marek Behun <marek.behun@nic.cz> wrote:
> > > > >
> > > > > On Wed, 10 Mar 2021 11:40:42 +0800
> > > > > Bin Meng <bmeng.cn@gmail.com> wrote:
> > > > >
> > > > > > On Sun, Mar 7, 2021 at 12:26 PM Marek Beh?n <marek.behun@nic.cz> wrote:
> > > > > > >
> > > > > > > When building with LTO, using -ffunction-sections/-fdata-sections is not
> > > > > > > useful anymore.
> > > > > > >
> > > > > > > Signed-off-by: Marek Beh?n <marek.behun@nic.cz>
> > > > > > > ---
> > > > > > > arch/arm/config.mk | 8 ++++++--
> > > > > > > 1 file changed, 6 insertions(+), 2 deletions(-)
> > > > > > >
> > > > > >
> > > > > > I believe we should also remove --gc-sections.
> > > > >
> > > > > It seems that --gc-sections cannot be removed, otherwise some builds,
> > > > > for example turris_mox_defconfig, fail with
> > > > >
> > > > > LTO u-boot
> > > > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(lse-init.o): in function `init_have_lse_atomics':
> > > > > /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/config/aarch64/lse-init.c:44: undefined reference to `__getauxval'
> > > > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_absvsi2.o): in function `__absvdi2':
> > > > > /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:228: undefined reference to `abort'
> > > > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_absvsi2.o): in function `__absvsi2':
> > > > > /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:246: undefined reference to `abort'
> > > > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_absvdi2.o): in function `__absvti2':
> > > > > /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:267: undefined reference to `abort'
> > > > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_addvsi3.o): in function `__addvdi3':
> > > > > /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:81: undefined reference to `abort'
> > > > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_addvsi3.o): in function `__addvsi3':
> > > > > /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:92: undefined reference to `abort'
> > > > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_addvdi3.o):/var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:106: more undefined references to `abort' follow
> > > > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_eprintf.o): in function `__eprintf':
> > > > > /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:2152: undefined reference to `stderr'
> > > > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:2152: undefined reference to `stderr'
> > > > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_eprintf.o): in function `fprintf':
> > > > > /usr/aarch64-unknown-linux-gnu/sys-include/bits/stdio2.h:103: undefined reference to `__fprintf_chk'
> > > > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_eprintf.o): in function `__eprintf':
> > > > > /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:2153: undefined reference to `fflush'
> > > > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:2154: undefined reference to `abort'
> > > >
> > > > Ouch! How compiler behaves when it comes to LTO and works with all
> > > > these compiler/linker options is really a mystery ...
> > >
> > > OK, it seems that on aarch64 we are actually using system's libgcc :)
> >
> > Thanks.
> >
> > > Not the internal one. So it seems we need --gc-sections to throw away
> > > garbade that is not used.
> >
> > Needed only when CONFIG_USE_PRIVATE_LIBGCC is off?
>
> Seems that way.
Well, _and_ we need libgcc for anything too. A quick set of hacks:
diff --git a/Makefile b/Makefile
index d6eda45385c3..af3e03ac9fa0 100644
--- a/Makefile
+++ b/Makefile
@@ -830,8 +830,6 @@ u-boot-main := $(libs-y)
# Add GCC lib
ifeq ($(CONFIG_USE_PRIVATE_LIBGCC),y)
PLATFORM_LIBGCC = arch/$(ARCH)/lib/lib.a
-else
-PLATFORM_LIBGCC := -L $(shell dirname `$(CC) $(c_flags) -print-libgcc-file-name`) -lgcc
endif
PLATFORM_LIBS += $(PLATFORM_LIBGCC)
Shows that turris_mox links just fine without the main gcc, because I
probably misunderstood something a bit ages back when dealing with the
libgcc fun we have. So I'm gonna see if that hack above is actually
just correct for all the other cases.
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20210312/29f921cd/attachment.sig>
^ permalink raw reply related [flat|nested] 139+ messages in thread
* [PATCH u-boot 37/39] ARM: don't use -ffunction-sections/-fdata-sections with LTO build
2021-03-12 13:18 ` Tom Rini
@ 2021-03-12 13:44 ` Marek Behun
2021-03-12 13:52 ` Tom Rini
0 siblings, 1 reply; 139+ messages in thread
From: Marek Behun @ 2021-03-12 13:44 UTC (permalink / raw)
To: u-boot
On Fri, 12 Mar 2021 08:18:44 -0500
Tom Rini <trini@konsulko.com> wrote:
> On Fri, Mar 12, 2021 at 08:29:05AM +0100, Marek Behun wrote:
> > On Fri, 12 Mar 2021 15:19:26 +0800
> > Bin Meng <bmeng.cn@gmail.com> wrote:
> >
> > > On Fri, Mar 12, 2021 at 3:11 PM Marek Behun <marek.behun@nic.cz> wrote:
> > > >
> > > > On Fri, 12 Mar 2021 14:48:04 +0800
> > > > Bin Meng <bmeng.cn@gmail.com> wrote:
> > > >
> > > > > On Fri, Mar 12, 2021 at 2:45 PM Marek Behun <marek.behun@nic.cz> wrote:
> > > > > >
> > > > > > On Wed, 10 Mar 2021 11:40:42 +0800
> > > > > > Bin Meng <bmeng.cn@gmail.com> wrote:
> > > > > >
> > > > > > > On Sun, Mar 7, 2021 at 12:26 PM Marek Beh?n <marek.behun@nic.cz> wrote:
> > > > > > > >
> > > > > > > > When building with LTO, using -ffunction-sections/-fdata-sections is not
> > > > > > > > useful anymore.
> > > > > > > >
> > > > > > > > Signed-off-by: Marek Beh?n <marek.behun@nic.cz>
> > > > > > > > ---
> > > > > > > > arch/arm/config.mk | 8 ++++++--
> > > > > > > > 1 file changed, 6 insertions(+), 2 deletions(-)
> > > > > > > >
> > > > > > >
> > > > > > > I believe we should also remove --gc-sections.
> > > > > >
> > > > > > It seems that --gc-sections cannot be removed, otherwise some builds,
> > > > > > for example turris_mox_defconfig, fail with
> > > > > >
> > > > > > LTO u-boot
> > > > > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(lse-init.o): in function `init_have_lse_atomics':
> > > > > > /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/config/aarch64/lse-init.c:44: undefined reference to `__getauxval'
> > > > > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_absvsi2.o): in function `__absvdi2':
> > > > > > /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:228: undefined reference to `abort'
> > > > > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_absvsi2.o): in function `__absvsi2':
> > > > > > /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:246: undefined reference to `abort'
> > > > > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_absvdi2.o): in function `__absvti2':
> > > > > > /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:267: undefined reference to `abort'
> > > > > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_addvsi3.o): in function `__addvdi3':
> > > > > > /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:81: undefined reference to `abort'
> > > > > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_addvsi3.o): in function `__addvsi3':
> > > > > > /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:92: undefined reference to `abort'
> > > > > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_addvdi3.o):/var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:106: more undefined references to `abort' follow
> > > > > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_eprintf.o): in function `__eprintf':
> > > > > > /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:2152: undefined reference to `stderr'
> > > > > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:2152: undefined reference to `stderr'
> > > > > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_eprintf.o): in function `fprintf':
> > > > > > /usr/aarch64-unknown-linux-gnu/sys-include/bits/stdio2.h:103: undefined reference to `__fprintf_chk'
> > > > > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_eprintf.o): in function `__eprintf':
> > > > > > /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:2153: undefined reference to `fflush'
> > > > > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:2154: undefined reference to `abort'
> > > > >
> > > > > Ouch! How compiler behaves when it comes to LTO and works with all
> > > > > these compiler/linker options is really a mystery ...
> > > >
> > > > OK, it seems that on aarch64 we are actually using system's libgcc :)
> > >
> > > Thanks.
> > >
> > > > Not the internal one. So it seems we need --gc-sections to throw away
> > > > garbade that is not used.
> > >
> > > Needed only when CONFIG_USE_PRIVATE_LIBGCC is off?
> >
> > Seems that way.
>
> Well, _and_ we need libgcc for anything too. A quick set of hacks:
> diff --git a/Makefile b/Makefile
> index d6eda45385c3..af3e03ac9fa0 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -830,8 +830,6 @@ u-boot-main := $(libs-y)
> # Add GCC lib
> ifeq ($(CONFIG_USE_PRIVATE_LIBGCC),y)
> PLATFORM_LIBGCC = arch/$(ARCH)/lib/lib.a
> -else
> -PLATFORM_LIBGCC := -L $(shell dirname `$(CC) $(c_flags) -print-libgcc-file-name`) -lgcc
> endif
> PLATFORM_LIBS += $(PLATFORM_LIBGCC)
>
> Shows that turris_mox links just fine without the main gcc, because I
> probably misunderstood something a bit ages back when dealing with the
> libgcc fun we have. So I'm gonna see if that hack above is actually
> just correct for all the other cases.
>
It depends on whether arch/arm/lib provides all necessary functions for
aarch64 as well. lib1funcs.S implements stuff only for 32bit arm.
But looking at libgcc for aarch64, it does not seem that it contains
things that may be needed for u-boot. Maybe floating point operations
with -fsoft-float, but I guess nobody uses this in U-Boot.
Although recently I was working on driver for Armada 3720 UART baudrate
generator, and the computation may need floating point operations
to compute best prescaler parameters. But if we limit ourselves to a
predefined set of available baudrates, we can just prepare a table with
the needed parameters.
Marek
^ permalink raw reply [flat|nested] 139+ messages in thread
* [PATCH u-boot 37/39] ARM: don't use -ffunction-sections/-fdata-sections with LTO build
2021-03-12 13:44 ` Marek Behun
@ 2021-03-12 13:52 ` Tom Rini
0 siblings, 0 replies; 139+ messages in thread
From: Tom Rini @ 2021-03-12 13:52 UTC (permalink / raw)
To: u-boot
On Fri, Mar 12, 2021 at 02:44:19PM +0100, Marek Behun wrote:
> On Fri, 12 Mar 2021 08:18:44 -0500
> Tom Rini <trini@konsulko.com> wrote:
>
> > On Fri, Mar 12, 2021 at 08:29:05AM +0100, Marek Behun wrote:
> > > On Fri, 12 Mar 2021 15:19:26 +0800
> > > Bin Meng <bmeng.cn@gmail.com> wrote:
> > >
> > > > On Fri, Mar 12, 2021 at 3:11 PM Marek Behun <marek.behun@nic.cz> wrote:
> > > > >
> > > > > On Fri, 12 Mar 2021 14:48:04 +0800
> > > > > Bin Meng <bmeng.cn@gmail.com> wrote:
> > > > >
> > > > > > On Fri, Mar 12, 2021 at 2:45 PM Marek Behun <marek.behun@nic.cz> wrote:
> > > > > > >
> > > > > > > On Wed, 10 Mar 2021 11:40:42 +0800
> > > > > > > Bin Meng <bmeng.cn@gmail.com> wrote:
> > > > > > >
> > > > > > > > On Sun, Mar 7, 2021 at 12:26 PM Marek Beh?n <marek.behun@nic.cz> wrote:
> > > > > > > > >
> > > > > > > > > When building with LTO, using -ffunction-sections/-fdata-sections is not
> > > > > > > > > useful anymore.
> > > > > > > > >
> > > > > > > > > Signed-off-by: Marek Beh?n <marek.behun@nic.cz>
> > > > > > > > > ---
> > > > > > > > > arch/arm/config.mk | 8 ++++++--
> > > > > > > > > 1 file changed, 6 insertions(+), 2 deletions(-)
> > > > > > > > >
> > > > > > > >
> > > > > > > > I believe we should also remove --gc-sections.
> > > > > > >
> > > > > > > It seems that --gc-sections cannot be removed, otherwise some builds,
> > > > > > > for example turris_mox_defconfig, fail with
> > > > > > >
> > > > > > > LTO u-boot
> > > > > > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(lse-init.o): in function `init_have_lse_atomics':
> > > > > > > /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/config/aarch64/lse-init.c:44: undefined reference to `__getauxval'
> > > > > > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_absvsi2.o): in function `__absvdi2':
> > > > > > > /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:228: undefined reference to `abort'
> > > > > > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_absvsi2.o): in function `__absvsi2':
> > > > > > > /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:246: undefined reference to `abort'
> > > > > > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_absvdi2.o): in function `__absvti2':
> > > > > > > /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:267: undefined reference to `abort'
> > > > > > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_addvsi3.o): in function `__addvdi3':
> > > > > > > /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:81: undefined reference to `abort'
> > > > > > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_addvsi3.o): in function `__addvsi3':
> > > > > > > /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:92: undefined reference to `abort'
> > > > > > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_addvdi3.o):/var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:106: more undefined references to `abort' follow
> > > > > > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_eprintf.o): in function `__eprintf':
> > > > > > > /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:2152: undefined reference to `stderr'
> > > > > > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:2152: undefined reference to `stderr'
> > > > > > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_eprintf.o): in function `fprintf':
> > > > > > > /usr/aarch64-unknown-linux-gnu/sys-include/bits/stdio2.h:103: undefined reference to `__fprintf_chk'
> > > > > > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_eprintf.o): in function `__eprintf':
> > > > > > > /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:2153: undefined reference to `fflush'
> > > > > > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:2154: undefined reference to `abort'
> > > > > >
> > > > > > Ouch! How compiler behaves when it comes to LTO and works with all
> > > > > > these compiler/linker options is really a mystery ...
> > > > >
> > > > > OK, it seems that on aarch64 we are actually using system's libgcc :)
> > > >
> > > > Thanks.
> > > >
> > > > > Not the internal one. So it seems we need --gc-sections to throw away
> > > > > garbade that is not used.
> > > >
> > > > Needed only when CONFIG_USE_PRIVATE_LIBGCC is off?
> > >
> > > Seems that way.
> >
> > Well, _and_ we need libgcc for anything too. A quick set of hacks:
> > diff --git a/Makefile b/Makefile
> > index d6eda45385c3..af3e03ac9fa0 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -830,8 +830,6 @@ u-boot-main := $(libs-y)
> > # Add GCC lib
> > ifeq ($(CONFIG_USE_PRIVATE_LIBGCC),y)
> > PLATFORM_LIBGCC = arch/$(ARCH)/lib/lib.a
> > -else
> > -PLATFORM_LIBGCC := -L $(shell dirname `$(CC) $(c_flags) -print-libgcc-file-name`) -lgcc
> > endif
> > PLATFORM_LIBS += $(PLATFORM_LIBGCC)
> >
> > Shows that turris_mox links just fine without the main gcc, because I
> > probably misunderstood something a bit ages back when dealing with the
> > libgcc fun we have. So I'm gonna see if that hack above is actually
> > just correct for all the other cases.
> >
>
> It depends on whether arch/arm/lib provides all necessary functions for
> aarch64 as well. lib1funcs.S implements stuff only for 32bit arm.
>
> But looking at libgcc for aarch64, it does not seem that it contains
> things that may be needed for u-boot. Maybe floating point operations
> with -fsoft-float, but I guess nobody uses this in U-Boot.
>
> Although recently I was working on driver for Armada 3720 UART baudrate
> generator, and the computation may need floating point operations
> to compute best prescaler parameters. But if we limit ourselves to a
> predefined set of available baudrates, we can just prepare a table with
> the needed parameters.
Right, so we have to things related to floating point right. I think
the high level problem/answer is hat on 32bit ARM we followed in the
Linux kernel's footsteps and so we have lib1funcs, etc. We don't do
what I think of as actual floating point math (ie float foo), but
whatever we can do in shifts we do.
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20210312/4db65cc6/attachment.sig>
^ permalink raw reply [flat|nested] 139+ messages in thread
* [PATCH u-boot 38/39] ARM: enable LTO for some boards
2021-03-07 4:24 [PATCH u-boot 00/39] U-Boot LTO (Sandbox + Some ARM boards) Marek Behún
` (36 preceding siblings ...)
2021-03-07 4:25 ` [PATCH u-boot 37/39] ARM: don't use -ffunction-sections/-fdata-sections with LTO build Marek Behún
@ 2021-03-07 4:25 ` Marek Behún
2021-03-07 16:14 ` Adam Ford
2021-03-07 4:25 ` [PATCH u-boot 39/39] DO NOT MERGE! ARM: enable LTO by default Marek Behún
38 siblings, 1 reply; 139+ messages in thread
From: Marek Behún @ 2021-03-07 4:25 UTC (permalink / raw)
To: u-boot
Enable LTO for some boards that were tested by people on U-Boot Mailing
List.
Signed-off-by: Marek Beh?n <marek.behun@nic.cz>
Tested-by: Adam Ford <aford173@gmail.com>
Tested-by: Pali Roh?r <pali@kernel.org>
---
configs/da850evm_defconfig | 1 +
configs/da850evm_direct_nor_defconfig | 1 +
configs/da850evm_nand_defconfig | 1 +
configs/imx6q_logic_defconfig | 1 +
configs/imx8mn_beacon_2g_defconfig | 1 +
configs/imx8mn_beacon_defconfig | 1 +
configs/nokia_rx51_defconfig | 1 +
configs/turris_mox_defconfig | 1 +
configs/turris_omnia_defconfig | 1 +
9 files changed, 9 insertions(+)
diff --git a/configs/da850evm_defconfig b/configs/da850evm_defconfig
index 26e76a2929..6ff5e21bc6 100644
--- a/configs/da850evm_defconfig
+++ b/configs/da850evm_defconfig
@@ -1,3 +1,4 @@
+CONFIG_LTO=y
CONFIG_ARM=y
CONFIG_SYS_THUMB_BUILD=y
CONFIG_ARCH_DAVINCI=y
diff --git a/configs/da850evm_direct_nor_defconfig b/configs/da850evm_direct_nor_defconfig
index d3860a963d..06c7ce7c47 100644
--- a/configs/da850evm_direct_nor_defconfig
+++ b/configs/da850evm_direct_nor_defconfig
@@ -1,3 +1,4 @@
+CONFIG_LTO=y
CONFIG_ARM=y
CONFIG_ARCH_CPU_INIT=y
CONFIG_ARCH_DAVINCI=y
diff --git a/configs/da850evm_nand_defconfig b/configs/da850evm_nand_defconfig
index 0d0e9a148d..be737564e1 100644
--- a/configs/da850evm_nand_defconfig
+++ b/configs/da850evm_nand_defconfig
@@ -1,3 +1,4 @@
+CONFIG_LTO=y
CONFIG_ARM=y
CONFIG_SYS_THUMB_BUILD=y
CONFIG_ARCH_DAVINCI=y
diff --git a/configs/imx6q_logic_defconfig b/configs/imx6q_logic_defconfig
index 36dc24d080..0f8aea6983 100644
--- a/configs/imx6q_logic_defconfig
+++ b/configs/imx6q_logic_defconfig
@@ -1,3 +1,4 @@
+CONFIG_LTO=y
CONFIG_ARM=y
CONFIG_ARCH_MX6=y
CONFIG_SYS_TEXT_BASE=0x17800000
diff --git a/configs/imx8mn_beacon_2g_defconfig b/configs/imx8mn_beacon_2g_defconfig
index 58b8e49486..1c8cbc2c89 100644
--- a/configs/imx8mn_beacon_2g_defconfig
+++ b/configs/imx8mn_beacon_2g_defconfig
@@ -1,3 +1,4 @@
+CONFIG_LTO=y
CONFIG_ARM=y
CONFIG_ARCH_IMX8M=y
CONFIG_SYS_TEXT_BASE=0x40200000
diff --git a/configs/imx8mn_beacon_defconfig b/configs/imx8mn_beacon_defconfig
index d6a3385d8d..6457b9409a 100644
--- a/configs/imx8mn_beacon_defconfig
+++ b/configs/imx8mn_beacon_defconfig
@@ -1,3 +1,4 @@
+CONFIG_LTO=y
CONFIG_ARM=y
CONFIG_ARCH_IMX8M=y
CONFIG_SYS_TEXT_BASE=0x40200000
diff --git a/configs/nokia_rx51_defconfig b/configs/nokia_rx51_defconfig
index 312ca3a1a9..85ca627790 100644
--- a/configs/nokia_rx51_defconfig
+++ b/configs/nokia_rx51_defconfig
@@ -1,3 +1,4 @@
+CONFIG_LTO=y
CONFIG_ARM=y
# CONFIG_SYS_THUMB_BUILD is not set
CONFIG_ARCH_OMAP2PLUS=y
diff --git a/configs/turris_mox_defconfig b/configs/turris_mox_defconfig
index f938fbb475..2a351d9180 100644
--- a/configs/turris_mox_defconfig
+++ b/configs/turris_mox_defconfig
@@ -1,3 +1,4 @@
+CONFIG_LTO=y
CONFIG_ARM=y
CONFIG_ARCH_CPU_INIT=y
CONFIG_ARCH_MVEBU=y
diff --git a/configs/turris_omnia_defconfig b/configs/turris_omnia_defconfig
index 4b8843d7be..d7a2ec3592 100644
--- a/configs/turris_omnia_defconfig
+++ b/configs/turris_omnia_defconfig
@@ -1,3 +1,4 @@
+CONFIG_LTO=y
CONFIG_ARM=y
CONFIG_ARCH_CPU_INIT=y
CONFIG_SPL_SYS_THUMB_BUILD=y
--
2.26.2
^ permalink raw reply related [flat|nested] 139+ messages in thread* [PATCH u-boot 38/39] ARM: enable LTO for some boards
2021-03-07 4:25 ` [PATCH u-boot 38/39] ARM: enable LTO for some boards Marek Behún
@ 2021-03-07 16:14 ` Adam Ford
2021-03-07 20:49 ` Marek Behun
0 siblings, 1 reply; 139+ messages in thread
From: Adam Ford @ 2021-03-07 16:14 UTC (permalink / raw)
To: u-boot
On Sat, Mar 6, 2021 at 10:26 PM Marek Beh?n <marek.behun@nic.cz> wrote:
>
> Enable LTO for some boards that were tested by people on U-Boot Mailing
> List.
>
I have also confirmed this works on the r8a774a1_beacon board as well
and boots without issues. The r8a774b1_beacon and r8a774e1_beacon
should be safe since the only real difference between them is the
device tree reference.
The RZ/G2 boards from Beacon don't use SPL, but wIthout LTO:
U-Boot 784324
With LTO:
U-Boot 757202
For a reduction of:
-27122 (-3.46%)
> Signed-off-by: Marek Beh?n <marek.behun@nic.cz>
> Tested-by: Adam Ford <aford173@gmail.com>
> Tested-by: Pali Roh?r <pali@kernel.org>
> ---
> configs/da850evm_defconfig | 1 +
> configs/da850evm_direct_nor_defconfig | 1 +
> configs/da850evm_nand_defconfig | 1 +
> configs/imx6q_logic_defconfig | 1 +
> configs/imx8mn_beacon_2g_defconfig | 1 +
> configs/imx8mn_beacon_defconfig | 1 +
> configs/nokia_rx51_defconfig | 1 +
> configs/turris_mox_defconfig | 1 +
> configs/turris_omnia_defconfig | 1 +
> 9 files changed, 9 insertions(+)
>
> diff --git a/configs/da850evm_defconfig b/configs/da850evm_defconfig
> index 26e76a2929..6ff5e21bc6 100644
> --- a/configs/da850evm_defconfig
> +++ b/configs/da850evm_defconfig
> @@ -1,3 +1,4 @@
> +CONFIG_LTO=y
> CONFIG_ARM=y
> CONFIG_SYS_THUMB_BUILD=y
> CONFIG_ARCH_DAVINCI=y
> diff --git a/configs/da850evm_direct_nor_defconfig b/configs/da850evm_direct_nor_defconfig
> index d3860a963d..06c7ce7c47 100644
> --- a/configs/da850evm_direct_nor_defconfig
> +++ b/configs/da850evm_direct_nor_defconfig
> @@ -1,3 +1,4 @@
> +CONFIG_LTO=y
> CONFIG_ARM=y
> CONFIG_ARCH_CPU_INIT=y
> CONFIG_ARCH_DAVINCI=y
> diff --git a/configs/da850evm_nand_defconfig b/configs/da850evm_nand_defconfig
> index 0d0e9a148d..be737564e1 100644
> --- a/configs/da850evm_nand_defconfig
> +++ b/configs/da850evm_nand_defconfig
> @@ -1,3 +1,4 @@
> +CONFIG_LTO=y
> CONFIG_ARM=y
> CONFIG_SYS_THUMB_BUILD=y
> CONFIG_ARCH_DAVINCI=y
> diff --git a/configs/imx6q_logic_defconfig b/configs/imx6q_logic_defconfig
> index 36dc24d080..0f8aea6983 100644
> --- a/configs/imx6q_logic_defconfig
> +++ b/configs/imx6q_logic_defconfig
> @@ -1,3 +1,4 @@
> +CONFIG_LTO=y
> CONFIG_ARM=y
> CONFIG_ARCH_MX6=y
> CONFIG_SYS_TEXT_BASE=0x17800000
> diff --git a/configs/imx8mn_beacon_2g_defconfig b/configs/imx8mn_beacon_2g_defconfig
> index 58b8e49486..1c8cbc2c89 100644
> --- a/configs/imx8mn_beacon_2g_defconfig
> +++ b/configs/imx8mn_beacon_2g_defconfig
> @@ -1,3 +1,4 @@
> +CONFIG_LTO=y
> CONFIG_ARM=y
> CONFIG_ARCH_IMX8M=y
> CONFIG_SYS_TEXT_BASE=0x40200000
> diff --git a/configs/imx8mn_beacon_defconfig b/configs/imx8mn_beacon_defconfig
> index d6a3385d8d..6457b9409a 100644
> --- a/configs/imx8mn_beacon_defconfig
> +++ b/configs/imx8mn_beacon_defconfig
> @@ -1,3 +1,4 @@
> +CONFIG_LTO=y
> CONFIG_ARM=y
> CONFIG_ARCH_IMX8M=y
> CONFIG_SYS_TEXT_BASE=0x40200000
> diff --git a/configs/nokia_rx51_defconfig b/configs/nokia_rx51_defconfig
> index 312ca3a1a9..85ca627790 100644
> --- a/configs/nokia_rx51_defconfig
> +++ b/configs/nokia_rx51_defconfig
> @@ -1,3 +1,4 @@
> +CONFIG_LTO=y
> CONFIG_ARM=y
> # CONFIG_SYS_THUMB_BUILD is not set
> CONFIG_ARCH_OMAP2PLUS=y
> diff --git a/configs/turris_mox_defconfig b/configs/turris_mox_defconfig
> index f938fbb475..2a351d9180 100644
> --- a/configs/turris_mox_defconfig
> +++ b/configs/turris_mox_defconfig
> @@ -1,3 +1,4 @@
> +CONFIG_LTO=y
> CONFIG_ARM=y
> CONFIG_ARCH_CPU_INIT=y
> CONFIG_ARCH_MVEBU=y
> diff --git a/configs/turris_omnia_defconfig b/configs/turris_omnia_defconfig
> index 4b8843d7be..d7a2ec3592 100644
> --- a/configs/turris_omnia_defconfig
> +++ b/configs/turris_omnia_defconfig
> @@ -1,3 +1,4 @@
> +CONFIG_LTO=y
> CONFIG_ARM=y
> CONFIG_ARCH_CPU_INIT=y
> CONFIG_SPL_SYS_THUMB_BUILD=y
> --
> 2.26.2
>
^ permalink raw reply [flat|nested] 139+ messages in thread
* [PATCH u-boot 38/39] ARM: enable LTO for some boards
2021-03-07 16:14 ` Adam Ford
@ 2021-03-07 20:49 ` Marek Behun
0 siblings, 0 replies; 139+ messages in thread
From: Marek Behun @ 2021-03-07 20:49 UTC (permalink / raw)
To: u-boot
On Sun, 7 Mar 2021 10:14:07 -0600
Adam Ford <aford173@gmail.com> wrote:
> On Sat, Mar 6, 2021 at 10:26 PM Marek Beh?n <marek.behun@nic.cz> wrote:
> >
> > Enable LTO for some boards that were tested by people on U-Boot Mailing
> > List.
> >
>
> I have also confirmed this works on the r8a774a1_beacon board as well
> and boots without issues. The r8a774b1_beacon and r8a774e1_beacon
> should be safe since the only real difference between them is the
> device tree reference.
pushed into my github branch
^ permalink raw reply [flat|nested] 139+ messages in thread
* [PATCH u-boot 39/39] DO NOT MERGE! ARM: enable LTO by default
2021-03-07 4:24 [PATCH u-boot 00/39] U-Boot LTO (Sandbox + Some ARM boards) Marek Behún
` (37 preceding siblings ...)
2021-03-07 4:25 ` [PATCH u-boot 38/39] ARM: enable LTO for some boards Marek Behún
@ 2021-03-07 4:25 ` Marek Behún
38 siblings, 0 replies; 139+ messages in thread
From: Marek Behún @ 2021-03-07 4:25 UTC (permalink / raw)
To: u-boot
Build ARM targets with LTO by default.
Signed-off-by: Marek Beh?n <marek.behun@nic.cz>
---
arch/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/Kconfig b/arch/Kconfig
index bf4b8afcb4..d0f5a16b95 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -37,6 +37,7 @@ config ARM
select CREATE_ARCH_SYMLINK
select HAVE_PRIVATE_LIBGCC if !ARM64
select SUPPORT_OF_CONTROL
+ imply LTO
config M68K
bool "M68000 architecture"
--
2.26.2
^ permalink raw reply related [flat|nested] 139+ messages in thread