<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jun 17, 2022, 2:28 PM Alex White <<a href="mailto:alex.white@oarcorp.com">alex.white@oarcorp.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
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)`.<br>
<br>
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.<br>
<br>
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)`?<br>
<br>
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?<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">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 *.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">Chris.. is this a good path to you? Is there somewhere else in the dynamic loader system with a similar issue?</div><div dir="auto"><br></div><div dir="auto">--joel</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Thanks,<br>
<br>
Alex<br>
_______________________________________________<br>
devel mailing list<br>
<a href="mailto:devel@rtems.org" target="_blank" rel="noreferrer">devel@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
</blockquote></div></div></div>