[arch-projects] ELF questions
Ok, I'm not really clear, on a binary level, about ELF objects, so I'm going to shoot some questions out there: Is an elf binary required to link to things such as libc? let's assume for a moment the SO does not call any libc functions. that should work fine. however, if it does call libc functions, is it able to resolve that, perhaps, strlen() is linked into it's parent?
On Wed, Mar 16, 2005 at 06:03:36PM -0600, Aaron Griffin wrote:
Ok, I'm not really clear, on a binary level, about ELF objects, so I'm going to shoot some questions out there:
Is an elf binary required to link to things such as libc? let's assume for a moment the SO does not call any libc functions. that should work fine. however, if it does call libc functions, is it able to resolve that, perhaps, strlen() is linked into it's parent?
Doesn't the linker (ld) handle resolving symbols? And if it can't find one you won't even be able to run the executable because you'll get an unresolved symbol error. Jason -- If you understand, things are just as they are. If you do not understand, things are just as they are.
On Wed, 16 Mar 2005 19:06:24 -0500, Jason Chu
On Wed, Mar 16, 2005 at 06:03:36PM -0600, Aaron Griffin wrote:
Ok, I'm not really clear, on a binary level, about ELF objects, so I'm going to shoot some questions out there:
Is an elf binary required to link to things such as libc? let's assume for a moment the SO does not call any libc functions. that should work fine. however, if it does call libc functions, is it able to resolve that, perhaps, strlen() is linked into it's parent?
Doesn't the linker (ld) handle resolving symbols? And if it can't find one you won't even be able to run the executable because you'll get an unresolved symbol error.
Jason
Well what I'm saying is this: If I have a binary, my_binary, and an SO, load_me.so. When my_binary is executed, it does nothing for, 10 seconds, then dynamically loads "load_me.so". Let's assume that load_me.so uses strlen() internally, and as such, ld would most likely link in libc...what I want is for libc and all the other crap to not be linked in, because these symbols will exist in my_binary. Now, I may be getting ahead of myself, and -fPIC/-fpic may do this for me already.... I'll look into it
Well what I'm saying is this: If I have a binary, my_binary, and an SO, load_me.so. When my_binary is executed, it does nothing for, 10 seconds, then dynamically loads "load_me.so". Let's assume that load_me.so uses strlen() internally, and as such, ld would most likely link in libc...what I want is for libc and all the other crap to not be linked in, because these symbols will exist in my_binary.
Now, I may be getting ahead of myself, and -fPIC/-fpic may do this for me already.... I'll look into it
Why worry about this? It is the job of the dynamic linker. Most likely libc won't strictly be linked to the library, instead it'll just be linked to your process (because you ran my_binary) and not linked again to the library. That was my impression of dynamic linking; loading into the symbol space when needed. All functions in all linked libraries execute the same "instance" of strlen() within a single process. Jason -- If you understand, things are just as they are. If you do not understand, things are just as they are.
That was my impression of dynamic linking; loading into the symbol space when needed. All functions in all linked libraries execute the same "instance" of strlen() within a single process.
Jason
Hmmm I think I may have been asking the question in the wrong way, but that is what I was looking for. No matter how many objects are loaded into the process space of a given binary, there is only one instance of strlen ever.
Hmmm I think I may have been asking the question in the wrong way, but that is what I was looking for. No matter how many objects are loaded into the process space of a given binary, there is only one instance of strlen ever.
Again I wonder why you care. It's not your job, as an application programmer, to care. If you were doing work on ld or writing something for a real-time system, operating system, or embedded system then you can care. Otherwise you'll find yourself buried in details. Jason -- If you understand, things are just as they are. If you do not understand, things are just as they are.
Again I wonder why you care. It's not your job, as an application programmer, to care. If you were doing work on ld or writing something for a real-time system, operating system, or embedded system then you can care. Otherwise you'll find yourself buried in details.
Jason
Agreed, but I'm not an application programmer at heart (though my professional experience says otherwise)... It was mainly a curiosity, more like "if I don't like the details of this, I'll pursue another method"
participants (2)
-
Aaron Griffin
-
Jason Chu