Runtime Loader Exported Symbols Address Size

[Joel Sherrill]

On Fri, Jun 17, 2022, 2:28 PM Alex White <alex.white at oarcorp.com> wrote:

> Hi,
>
> While testing libdl on AArch64 QEMU, we found a bug where the exported
> symbol table appears to always use 32-bit values for addresses, but where
> the exported symbols table is read in `rtems_rtl_symbol_global_add`, the
> addresses are expected to be of size `sizeof(unsigned long)`.
>
> This did not cause a problem on ARM since `sizeof(unsigned long)` is 4,
> but with AArch64 `sizeof(unsigned long)` is 8. So it is trying to read the
> address as 64 bits instead of 32.
>
> The simple fix is to use an exact-width integer type - like
> `sizeof(uint32_t)`. But this would not allow for 64-bit architectures to
> use the full address space. It would also break on 64-bit RISC-V (see
> below). Perhaps we could have an ifdef to choose a 32 or 64-bit type based
> on the architecture rather than relying on `sizeof(unsigned long)`?
>
> It looks like there is an exception in the rtems-syms tool for 64-bit
> RISC-V to emit 64-bit addresses rather than 32-bit addresses. Is this the
> right solution? Should we add another exception for AArch64?
>

After having given this some thought, I think the code that is generated
and the parsing code in rtl-sym.c should be conditionalized on the GCC CPP
predefine that indicates the size of a void *.

The code in rtl-sym.c should use a type definition for the type that the
sizeof is operating on. Using unsigned long is just not good enough. Both
cases should be fixed width types.

There also should be a very good comment above the parsing method in
rtl-sym.c explaining where the file comes from that it is reading and why
there is the need for a type which varies by architecture.

Based on our current understanding, I think this address is everything and
leaves sufficient information and organization to cover all the cases in
the future. Very likely without anyone actively having to fix anything.
Running into this issue again and again as architectures are added is not a
good long-term solution.

Chris.. is this a good path to you? Is there somewhere else in the dynamic
loader system with a similar issue?

--joel

>
> Thanks,
>
> Alex
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20220617/fc6d8aca/attachment-0001.htm>