[PATCH] firmware: Move memcpy/memset mapping to fw_base.S

Jessica Clarke jrtc27 at jrtc27.com
Wed Dec 22 21:27:47 PST 2021


On 23 Dec 2021, at 05:26, Anup Patel <anup at brainfault.org> wrote:
> 
> On Wed, Dec 22, 2021 at 6:25 PM Jessica Clarke <jrtc27 at jrtc27.com> wrote:
>> 
>> On 22 Dec 2021, at 12:44, Anup Patel <anup.patel at wdc.com> wrote:
>>> 
>>> Some of the external firmwares using OpenSBI as library are facing
>>> issues with the weak memcpy() and memset() aliases in libsbi.a so
>>> we move these to fw_base.S. This way mapping of implicit memcpy()
>>> or memset() calls to sbi_memcpy() or sbi_memset() will only be done
>>> for OpenSBI firmwares.
>>> (Refer, https://github.com/riscv-software-src/opensbi/issues/234)
>> 
>> Consumers that want to override the definitions in libsbi should just
>> make sure -lsbi/libsbi.a appears after the object or library containing
>> the strong definition.
> 
> I agree with you. This is definitely a link-time ordering issue for external
> firmwares. Ideally, external firmware projects should fix this at their end.
> 
>> 
>> If you really want to support people that can’t get their link order
>> right (which then hurts people who *do* and want to just use libsbi’s
>> memcpy/memset) then these should be strong aliases and/or defined in C;
>> there’s zero reason for it to be in assembly and, as a downstream that
>> would need to modify this code if written in assembly, hurts
>> portability. And if for some reason you still insist on assembly then
>> you should be using tail here, not j, as j is only supported for jumps
>> within a file, not across files.
> 
> I am certainly not happy in moving this to fw_base.S but currently
> OpenSBI firmwares will only use memcpy/memset symbols implicitly
> when "-Os" compile option is used so by default this change does
> not impact users of OpenSBI firmwares.
> 
> At this point, the number of OpenSBI firmware users is much more
> than the number of libsbi.a users so eventually we have to be more
> strict with external firmwares otherwise such things will continue to
> add restrictions on things we can do in libsbi.a.
> 
> I want to release OpenSBI v1.0 this week so for the time being I will
> will replace the use of "j" with "tail" and post a v2. Post OpenSBI v1.0,
> release, I will try to find a better solution (may be add C sources for
> firmware and move it there).

Is there not an argument to be made that we should break their broken
build systems *now* rather than post-1.0 when there might be some kind
of greater expectation about stability?

Jess

> Regards,
> Anup
> 
>> 
>> Jess
>> 
>>> Signed-off-by: Anup Patel <anup.patel at wdc.com>
>>> ---
>>> firmware/fw_base.S   | 14 ++++++++++++++
>>> lib/sbi/sbi_string.c |  6 ------
>>> 2 files changed, 14 insertions(+), 6 deletions(-)
>>> 
>>> diff --git a/firmware/fw_base.S b/firmware/fw_base.S
>>> index 1569e60..6197a7f 100644
>>> --- a/firmware/fw_base.S
>>> +++ b/firmware/fw_base.S
>>> @@ -561,6 +561,20 @@ fw_platform_init:
>>>      add     a0, a1, zero
>>>      ret
>>> 
>>> +     /* Map implicit memcpy() added by compiler to sbi_memcpy() */
>>> +     .section .text
>>> +     .align 3
>>> +     .globl memcpy
>>> +memcpy:
>>> +     j       sbi_memcpy
>>> +
>>> +     /* Map implicit memset() added by compiler to sbi_memset() */
>>> +     .section .text
>>> +     .align 3
>>> +     .globl memset
>>> +memset:
>>> +     j       sbi_memset
>>> +
>>> .macro        TRAP_SAVE_AND_SETUP_SP_T0
>>>      /* Swap TP and MSCRATCH */
>>>      csrrw   tp, CSR_MSCRATCH, tp
>>> diff --git a/lib/sbi/sbi_string.c b/lib/sbi/sbi_string.c
>>> index c67c02e..c87bce9 100644
>>> --- a/lib/sbi/sbi_string.c
>>> +++ b/lib/sbi/sbi_string.c
>>> @@ -122,9 +122,6 @@ void *sbi_memset(void *s, int c, size_t count)
>>>      return s;
>>> }
>>> 
>>> -void *memset(void *s, int c, size_t count) \
>>> -__attribute__((weak, alias("sbi_memset")));
>>> -
>>> void *sbi_memcpy(void *dest, const void *src, size_t count)
>>> {
>>>      char *temp1       = dest;
>>> @@ -138,9 +135,6 @@ void *sbi_memcpy(void *dest, const void *src, size_t count)
>>>      return dest;
>>> }
>>> 
>>> -void *memcpy(void *dest, const void *src, size_t count) \
>>> -__attribute__((weak, alias("sbi_memcpy")));
>>> -
>>> void *sbi_memmove(void *dest, const void *src, size_t count)
>>> {
>>>      char *temp1       = (char *)dest;
>>> --
>>> 2.25.1
>>> 
>>> 
>>> --
>>> opensbi mailing list
>>> opensbi at lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/opensbi
>> 




More information about the opensbi mailing list