Re: symbol table
In message: <[EMAIL PROTECTED]> Erik Trulsson <[EMAIL PROTECTED]> writes: : On Sun, Apr 20, 2008 at 11:24:32PM -0600, M. Warner Losh wrote: : > In message: <[EMAIL PROTECTED]> : > Erik Trulsson <[EMAIL PROTECTED]> writes: : > : On Sun, Apr 20, 2008 at 12:02:09PM +0300, emily becker wrote: : > : > Hi, : > : > : > : > I have a question about symbol table. : > : > One of the section In symbol table is memory adress which symbol is located. : > : > I wonder if this memory adress is bound at run-time or compile-time? : > : : > : It depends. Symbols referring to objects in a dynamically loaded library : > : will be bound at run-time, the rest should be bound at compile-time. : > : > They are bound at link-time, not compile-time. This is splitting a : > fine hair, but compile-time is when a .o or .so is created, while link : > time combines .o-like things together into a bigger thing. : : Well, I consider linking to be part of the compilation process so for : me link-time is a subset of compile-time. : You are however completely correct that it is at link-time that the binding : happens (for those symbols that can be resolved at link-time anyway.) While you might consider them the same, these are very important differences that need to be taken into account. A compile-time constant, for example, can be used to size an automatic array. A link-time or run-time constant cannot without gcc's extensions (magic tricks can be played to make link-time constants size certain global objects, but then sizeof() those objects fail). The terminology is well worn, and matters in some contexts, so I tend to be a stickler here... Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: symbol table
On Sun, Apr 20, 2008 at 11:24:32PM -0600, M. Warner Losh wrote: > In message: <[EMAIL PROTECTED]> > Erik Trulsson <[EMAIL PROTECTED]> writes: > : On Sun, Apr 20, 2008 at 12:02:09PM +0300, emily becker wrote: > : > Hi, > : > > : > I have a question about symbol table. > : > One of the section In symbol table is memory adress which symbol is > located. > : > I wonder if this memory adress is bound at run-time or compile-time? > : > : It depends. Symbols referring to objects in a dynamically loaded library > : will be bound at run-time, the rest should be bound at compile-time. > > They are bound at link-time, not compile-time. This is splitting a > fine hair, but compile-time is when a .o or .so is created, while link > time combines .o-like things together into a bigger thing. Well, I consider linking to be part of the compilation process so for me link-time is a subset of compile-time. You are however completely correct that it is at link-time that the binding happens (for those symbols that can be resolved at link-time anyway.) > When that > bigger thing is a final link, the addresses for the static portions of > the binary are set. When the final thing is a dynamic library, the > addresses float (since all the code is PIC anyway, they don't really > matter). Dynamic parts of executables are bound at run-time. > > : > if it is compile-time, I don't understand how do we know whether the > symbol > : > is located this adress. > : > Maybe this adress is already bound by other process or like this. > : > : Each process runs in its own address space, and therefore the compiler > : (actually: the linker) can know exactly where in this address space things > : will end up. > > The run-time linker (ld.so) is the one that knows where things wind up > in a given process... libc.so and other shared libraries can and do > link at different addresses for different processes. My comment referred to those symbols that are bound at compile^W link-time. For those the linker does know what addresses they refer to. For dynamically loaded libraries it is indeed the runtime loader that knows where in the address space they will end up. -- Erik Trulsson [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: symbol table
In message: <[EMAIL PROTECTED]> Erik Trulsson <[EMAIL PROTECTED]> writes: : On Sun, Apr 20, 2008 at 12:02:09PM +0300, emily becker wrote: : > Hi, : > : > I have a question about symbol table. : > One of the section In symbol table is memory adress which symbol is located. : > I wonder if this memory adress is bound at run-time or compile-time? : : It depends. Symbols referring to objects in a dynamically loaded library : will be bound at run-time, the rest should be bound at compile-time. They are bound at link-time, not compile-time. This is splitting a fine hair, but compile-time is when a .o or .so is created, while link time combines .o-like things together into a bigger thing. When that bigger thing is a final link, the addresses for the static portions of the binary are set. When the final thing is a dynamic library, the addresses float (since all the code is PIC anyway, they don't really matter). Dynamic parts of executables are bound at run-time. : > if it is compile-time, I don't understand how do we know whether the symbol : > is located this adress. : > Maybe this adress is already bound by other process or like this. : : Each process runs in its own address space, and therefore the compiler : (actually: the linker) can know exactly where in this address space things : will end up. The run-time linker (ld.so) is the one that knows where things wind up in a given process... libc.so and other shared libraries can and do link at different addresses for different processes. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: symbol table
In message: <[EMAIL PROTECTED]> "emily becker" <[EMAIL PROTECTED]> writes: : Hi, : : I have a question about symbol table. : One of the section In symbol table is memory adress which symbol is located. : I wonder if this memory adress is bound at run-time or compile-time? Typically, run-time, but there are exceptions. : if it is compile-time, I don't understand how do we know whether the symbol : is located this adress. The exceptions are for things like 'start' which live at a fixed address by the ELF ABI specification for most processors. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: symbol table
On Sun, Apr 20, 2008 at 12:02:09PM +0300, emily becker wrote: > Hi, > > I have a question about symbol table. > One of the section In symbol table is memory adress which symbol is located. > I wonder if this memory adress is bound at run-time or compile-time? It depends. Symbols referring to objects in a dynamically loaded library will be bound at run-time, the rest should be bound at compile-time. > if it is compile-time, I don't understand how do we know whether the symbol > is located this adress. > Maybe this adress is already bound by other process or like this. Each process runs in its own address space, and therefore the compiler (actually: the linker) can know exactly where in this address space things will end up. (The above is true for FreeBSD and just about all other Unix-derived systems. Other systems can do things differently.) -- Erik Trulsson [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
symbol table
Hi, I have a question about symbol table. One of the section In symbol table is memory adress which symbol is located. I wonder if this memory adress is bound at run-time or compile-time? if it is compile-time, I don't understand how do we know whether the symbol is located this adress. Maybe this adress is already bound by other process or like this. I look forward to answers thank you ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Access to symbol table(including dynamics) at runtime
On Fri, Jun 08, 2001 at 12:17:41PM -0500, Kevin Day wrote: > I looked at this.. I see how I can dlopen my own executable, and dlsym() > will let me get addresses from symbol names, but how do I do the reverse? I > have an address and need to get the symbol name from it, not vice versa. dladdr(3) of course. Not referenced in dlopen(3) either. -- || Seth Kingsley || Platforms Lab Opps || [EMAIL PROTECTED] || To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Access to symbol table(including dynamics) at runtime
* Kevin Day <[EMAIL PROTECTED]> [010608 13:21] wrote: > > > > In the last episode (Jun 08), Kevin Day said: > > > Is there a simple way that I can lookup a symbol name(by address) > > > during runtime? > > > > > > I know I can exec nm, look up for the address I need, and get local > > > symbols, but it would be really nice if I could get addresses of > > > functions in dynamic libraries as well. I know I could use ldd to get > > > offsets of each .so and calculate from there, but I'm starting to > > > think I'm reproducing work that was done somewhere else. > > > > > > If someone could point me at a man page to something that can do what > > > I need, tell me of a library that does something similar, or tell me > > > why this can't be done, i'd be very thankful. :) > > > > Would dladdr() do what you want? > > > AHH! YES! > > I'll buy a beer to the first person who adds dladdr(3) to the SEE ALSO > section of dlopen's man page. If you want to be able to see symbols in your main executable you _may_ need to also compile it with -export-dynamic or something like that. -- -Alfred Perlstein [[EMAIL PROTECTED]] Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Access to symbol table(including dynamics) at runtime
> > In the last episode (Jun 08), Kevin Day said: > > Is there a simple way that I can lookup a symbol name(by address) > > during runtime? > > > > I know I can exec nm, look up for the address I need, and get local > > symbols, but it would be really nice if I could get addresses of > > functions in dynamic libraries as well. I know I could use ldd to get > > offsets of each .so and calculate from there, but I'm starting to > > think I'm reproducing work that was done somewhere else. > > > > If someone could point me at a man page to something that can do what > > I need, tell me of a library that does something similar, or tell me > > why this can't be done, i'd be very thankful. :) > > Would dladdr() do what you want? AHH! YES! I'll buy a beer to the first person who adds dladdr(3) to the SEE ALSO section of dlopen's man page. Thank you! -- Kevin Day [EMAIL PROTECTED] - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Access to symbol table(including dynamics) at runtime
> > Kevin Day wrote: > > > > Is there a simple way that I can lookup a symbol name(by address) during > > runtime? > > man dlopen. > I looked at this.. I see how I can dlopen my own executable, and dlsym() will let me get addresses from symbol names, but how do I do the reverse? I have an address and need to get the symbol name from it, not vice versa. -- Kevin Day [EMAIL PROTECTED] - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Access to symbol table(including dynamics) at runtime
In the last episode (Jun 08), Kevin Day said: > Is there a simple way that I can lookup a symbol name(by address) > during runtime? > > I know I can exec nm, look up for the address I need, and get local > symbols, but it would be really nice if I could get addresses of > functions in dynamic libraries as well. I know I could use ldd to get > offsets of each .so and calculate from there, but I'm starting to > think I'm reproducing work that was done somewhere else. > > If someone could point me at a man page to something that can do what > I need, tell me of a library that does something similar, or tell me > why this can't be done, i'd be very thankful. :) Would dladdr() do what you want? -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Access to symbol table(including dynamics) at runtime
Kevin Day wrote: > > Is there a simple way that I can lookup a symbol name(by address) during > runtime? man dlopen. -- farooq <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Access to symbol table(including dynamics) at runtime
On Fri, Jun 08, 2001 at 12:09:39PM -0500, Kevin Day wrote: > > > Is there a simple way that I can lookup a symbol name(by address) during > runtime? > > I know I can exec nm, look up for the address I need, and get local > symbols, but it would be really nice if I could get addresses of functions > in dynamic libraries as well. I know I could use ldd to get offsets of each > .so and calculate from there, but I'm starting to think I'm reproducing work > that was done somewhere else. > > If someone could point me at a man page to something that can do what I > need, tell me of a library that does something similar, or tell me why this > can't be done, i'd be very thankful. :) OK, you asked for it, here's a minimalistic answer: dlopen(3) :) G'luck, Peter -- If wishes were fishes, the antecedent of this conditional would be true. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Access to symbol table(including dynamics) at runtime
Is there a simple way that I can lookup a symbol name(by address) during runtime? I know I can exec nm, look up for the address I need, and get local symbols, but it would be really nice if I could get addresses of functions in dynamic libraries as well. I know I could use ldd to get offsets of each .so and calculate from there, but I'm starting to think I'm reproducing work that was done somewhere else. If someone could point me at a man page to something that can do what I need, tell me of a library that does something similar, or tell me why this can't be done, i'd be very thankful. :) -- Kevin Day [EMAIL PROTECTED] - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message