Statically link or in-line memcpy using GCC

Question

I have the following C code:

char* ptr1;
char* ptr2;
memcpy(ptr1,ptr2,32);

This is code I didn't write, but inherited and I'm trying to make it run on ARM bare-metal rather than Linux (works fine on Linux).

I'm wondering what the implementation of memcpy is? Is there a way to get GCC to include its code (I assume it's all userspace code) with the resulting binary (static link)? Right now, if I compile (even using -static) I see the following disassembly:

memcpy (ptr1, ptr2, 32);
     800e37fc: d0000a14  adrp  x20, 80225000 <mode_wider_mode+0x20>
     800e3800: 9113c294  add x20, x20, #0x4f0
     800e3804: aa1403e0  mov x0, x20
     800e3808: d2800802  mov x2, #0x40                   // #64
     800e380c: 90000ae1  adrp  x1, 8023f000 <reg_class_subclasses+0xa0>
     800e3810: 91138021  add x1, x1, #0x4e0
     800e3814: 9402ee4f  bl  8019f150 <__dl_iterate_phdr+0x158>

Which jumps to the dl_iterate_phdr table (looks up pointer in shared library I believe?).

Which seems to indicate memcpy is still dynamically linked. Obviously the above ASM code wouldn't work in a bare-metal system.

I could implement my own memcpy but I was wondering if (on Linux host) I could just get the code for it to be included in my binary. After all it's probably just iterating a loop right?

yes, statically link. Statically linked code should use dynamic linking and if it does then something is horribly wrong. You use -static for the linking, right? — user253751, Apr 25 '23 at 22:59
Are you sure the names in the disassembly are accurate? <__dl_iterate_phdr+0x158> isn't necessarily part of __dl_iterate_phdr. It could be the next thing after __dl_iterate_phdr — user253751, Apr 25 '23 at 23:10
You're totally right. It actually ends up jumping to the .iplt section of the code. Which I believe is still a system call right? — jkang, Apr 25 '23 at 23:16
You should review my comments in your previous question: [How do I tell which libraries were statically linked by GCC](https://stackoverflow.com/q/76096364/5382650) As I mentioned, `.iplt` is an ELF section. The _kernel_ does _not_ interpret this. It is handled by the _ELF interpreter_. See `man ld.so`. The kernel does `mmap` on the ELF executable, reads a portion of it to find the full path to the interpreter, maps _that_ into memory and transfers control to it. See my answer: [Is Dynamic Linker part of Kernel or GCC Library on Linux Systems?](https://stackoverflow.com/a/38857878/5382650) ... — Craig Estey, Apr 26 '23 at 01:11
... Then, the ELF interpreter does the symbol linking. There _is_ a bare metal `libc`. It is `Newlib`. See: [C standard libraries on bare metal](https://electronics.stackexchange.com/questions/223929/c-standard-libraries-on-bare-metal) and https://en.wikipedia.org/wiki/Newlib And, as I previously mentioned, have a look at RTEMS https://www.rtems.org/ It is extremely lightweight. You can reduce your [programmer] porting time [from the months you'll have with your current "bare metal" approach]. — Craig Estey, Apr 26 '23 at 01:16
So a lot of this is new to me. I'll read into the basics more to groq this answer. However, naive question at first: why am I looking up anything in the ELF interpreter at all for memcpy if it's statically linked? — jkang, Apr 26 '23 at 01:27
Your lucky I'm still here. You should message me directly using the `@` syntax if you want a quicker response. [Again] referring to the previous question, I suggested various tools (e.g. `file`, `ldd`, `readelf`, `objdump`) that would help you with that. If you're _not_ going to respond to peoples' suggestions, it will be harder for you. You just posted your `gcc` command, but none of the analysis of the resulting executable. The `file` and `ldd` commands will verify what you actually have. IIRC, `-static` isn't always a guarantee if a lib only has `.so` and no `.a` — Craig Estey, Apr 26 '23 at 01:35

Statically link or in-line memcpy using GCC

0 Answers0