public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: Mark Rutland <mark.rutland@arm.com>
To: Robin Murphy <robin.murphy@arm.com>
Cc: Andre Przywara <andre.przywara@arm.com>,
	linux-arm-kernel@lists.infradead.org, Jaxson.Han@arm.com,
	vladimir.murzin@arm.com, Wei.Chen@arm.com
Subject: Re: [bootwrapper PATCH v2 11/13] Announce locations of memory objects
Date: Fri, 14 Jan 2022 16:30:47 +0000	[thread overview]
Message-ID: <YeGlN6SwomrURO46@FVFF77S0Q05N> (raw)
In-Reply-To: <f160d7ba-fbd8-8786-9c59-1add009ac5f3@arm.com>

On Fri, Jan 14, 2022 at 04:04:19PM +0000, Robin Murphy wrote:
> On 2022-01-14 15:30, Andre Przywara wrote:
> > On Fri, 14 Jan 2022 10:56:51 +0000
> > Mark Rutland <mark.rutland@arm.com> wrote:
> > > +void print_ulong_hex(unsigned long val)
> > > +{
> > > +	const char hex_chars[16] = "0123456789abcdef";
> > 
> > This breaks the build for me (I guess because of the const?):
> > -------------------
> > ld --gc-sections arch/aarch64/boot.o arch/aarch64/stack.o arch/aarch64/utils.o arch/aarch64/init.o arch/aarch64/psci.o common/boot.o common/bakery_lock.o common/platform.o common/lib.o common/init.o common/psci.o common/gic-v3.o -o linux-system.axf --script=model.lds
> > ld: common/platform.o: in function `print_ulong_hex':
> > /src/boot-wrapper-aarch64.git/common/platform.c:58: undefined reference to `__stack_chk_guard'
> > ld: /src/boot-wrapper-aarch64.git/common/platform.c:58: undefined reference to `__stack_chk_guard'
> > ld: /src/boot-wrapper-aarch64.git/common/platform.c:66: undefined reference to `__stack_chk_fail'
> > /src/boot-wrapper-aarch64.git/common/platform.c:66:(.text.print_ulong_hex+0xa0): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `__stack_chk_fail'
> > make: *** [Makefile:684: linux-system.axf] Error 1
> > ------------------
> 
> I got curious and tried a quick test compiling this function in isolation,
> and indeed for some reason GCC (9.3.0 at -O2) seems to end up allocating 80
> bytes of stack, which is apparently large enough to trigger insertion of a
> stack check, and laboriously copying the string from static data into it.
> FWIW either making hex_chars static const, or simply '#define hex_chars
> "01234567abcdef"', not only avoids a stack check but also leads to notably
> nicer code.

For the stack check, I think Andre's patch to add -fno-stack-protector is the
correct fix, so I'd like to take that as a prerequisite.

To avoid using the stack unnecessarily and to make the code nicer, I'll also
take your suggestion with the fixup below.

Thanks,
Mark.

---->8----
-#define HEX_CHARS_PER_LONG (2 * sizeof(long))
+#define HEX_CHARS_PER_LONG     (2 * sizeof(long))
+#define HEX_CHARS              "0123456789abcdef"
 
 void print_ulong_hex(unsigned long val)
 {
-       const char hex_chars[16] = "0123456789abcdef";
        int i;
 
        for (i = HEX_CHARS_PER_LONG - 1; i >= 0; i--) {
                int v = (val >> (4 * i)) & 0xf;
-               print_char(hex_chars[v]);
+               print_char(HEX_CHARS[v]);
        }
 }

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2022-01-14 16:32 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-14 10:56 [bootwrapper PATCH v2 00/13] Cleanups and improvements Mark Rutland
2022-01-14 10:56 ` [bootwrapper PATCH v2 01/13] Document entry requirements Mark Rutland
2022-01-14 10:56 ` [bootwrapper PATCH v2 02/13] Add bit-field macros Mark Rutland
2022-01-17 12:11   ` Steven Price
2022-01-17 13:28     ` Mark Rutland
2022-01-14 10:56 ` [bootwrapper PATCH v2 03/13] aarch64: add system register accessors Mark Rutland
2022-01-14 15:32   ` Andre Przywara
2022-01-14 10:56 ` [bootwrapper PATCH v2 04/13] aarch32: add coprocessor accessors Mark Rutland
2022-01-14 10:56 ` [bootwrapper PATCH v2 05/13] aarch64: add mov_64 macro Mark Rutland
2022-01-14 15:50   ` Andre Przywara
2022-01-14 10:56 ` [bootwrapper PATCH v2 06/13] aarch64: initialize SCTLR_ELx for the boot-wrapper Mark Rutland
2022-01-14 18:12   ` Andre Przywara
2022-01-17 12:15     ` Mark Rutland
2022-01-17 13:05       ` Mark Rutland
2022-01-18 12:37         ` Andre Przywara
2022-01-25 13:32           ` Mark Rutland
2022-01-19 12:42       ` Mark Rutland
2022-01-14 10:56 ` [bootwrapper PATCH v2 07/13] Rework common init C code Mark Rutland
2022-01-17 16:23   ` Andre Przywara
2022-01-14 10:56 ` [bootwrapper PATCH v2 08/13] Announce boot-wrapper mode / exception level Mark Rutland
2022-01-17 14:39   ` Andre Przywara
2022-01-17 15:50     ` Mark Rutland
2022-01-14 10:56 ` [bootwrapper PATCH v2 09/13] aarch64: move the bulk of EL3 initialization to C Mark Rutland
2022-01-17 14:31   ` Andre Przywara
2022-01-17 18:08     ` Mark Rutland
2022-01-17 18:31       ` Andre Przywara
2022-01-18 16:50         ` Mark Brown
2022-01-19 15:22           ` Mark Rutland
2022-01-14 10:56 ` [bootwrapper PATCH v2 10/13] aarch32: move the bulk of Secure PL1 " Mark Rutland
2022-01-17 14:52   ` Andre Przywara
2022-01-14 10:56 ` [bootwrapper PATCH v2 11/13] Announce locations of memory objects Mark Rutland
2022-01-14 15:30   ` Andre Przywara
2022-01-14 16:04     ` Robin Murphy
2022-01-14 16:30       ` Mark Rutland [this message]
2022-01-14 16:21     ` Mark Rutland
2022-01-17 14:59   ` Andre Przywara
2022-01-14 10:56 ` [bootwrapper PATCH v2 12/13] Rework bootmethod initialization Mark Rutland
2022-01-17 17:43   ` Andre Przywara
2022-01-25 14:00     ` Mark Rutland
2022-01-14 10:56 ` [bootwrapper PATCH v2 13/13] Unify start_el3 & start_no_el3 Mark Rutland
2022-01-17 17:43   ` Andre Przywara
2022-01-14 15:09 ` [bootwrapper PATCH v2 00/13] Cleanups and improvements Andre Przywara
2022-01-14 15:23   ` Mark Rutland

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YeGlN6SwomrURO46@FVFF77S0Q05N \
    --to=mark.rutland@arm.com \
    --cc=Jaxson.Han@arm.com \
    --cc=Wei.Chen@arm.com \
    --cc=andre.przywara@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=robin.murphy@arm.com \
    --cc=vladimir.murzin@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox