Re: Understanding multiple definitions in C program

[Orlando Arias <orlandoarias at gmail dot com>]

Greetings,

When linking your application, the linker sees that malloc() is an
external symbol and generates a PLT entry for it in your application. It
also generates the necessary GOT entry to match the PLT entry. The
function malloc() does not get added to your program.

At runtime, if using lazy binding (default in most systems/binaries),
upon the first call to malloc(), the GOT for malloc() entry points to
the first PLT entry (this is done at load time). When the call is
executed, the PLT entry for malloc() takes the address on the
corresponding GOT entry and jumps to the first PLT entry. This entry is
tasked with jumping into the dynamic resolver, which resolves the symbol
malloc(), updates the GOT entry for it and proceeds to jump into the
actual function.

To answer your questions then:

- Resolution of malloc() is done by the resolver. How it does it is
documented in its manual. If you have it available you can access it
with the command 'man ld.so'. Of importance here is the following:

       If  a  shared  object  dependency  does not contain a slash,
       then it is searched for in the following order:

       o  (ELF only) Using the directories specified in the  DT_RPATH
       dynamic section  attribute of the binary if present and
       DT_RUNPATH attribute does not exist.  Use of DT_RPATH is
       deprecated.

       o  Using the environment  variable  LD_LIBRARY_PATH  (unless
       the  executable is being run in secure-execution mode; see
       below).  in which case it is ignored.


You explicitly set LD_LIBRARY_PATH to the current directory where the
libmalloc.so shared object happens to reside. The resolver picks this
one up over the one in libc.so.

- This is a runtime behaviour which is documented. GCC does not need to
report any multiple definitions on the grounds that (1) GCC is a
compiler collection and not a linker, and (2) The symbols are being
dynamically resolved on the application (shared objects), as opposed to
statically linking (at which point, ld will complain that you DO have
duplicate symbols, unless one of them is flagged as weak).

- This is standard UNIX behaviour. You can use this behaviour to
dynamically replace functions, have multiple versions of the same
function and the such. For more information, refer to the corresponding
manual page and the book "UNIX System V Release 4 Programmer's Guide:
ANSI C and Programming Support Tools".

Cheers,
Orlando.

On 07/17/2016 11:30 PM, linu cherian wrote:
> Hi,
> 
> Recently observed that, gcc doesnt warns/give error when i had a
> private malloc definition in my C program, though it had dependency on
> the libc. 
> 
> main.c
> ----------
> #include <stdio.h>
> #include <stdlib.h>
> 
> 
> int main()
> {
> 
>   printf("Calling malloc\n");
> 
>   malloc(100);
> }
> 
> malloc.c
> -------------
>  #include <stdio.h>
> #include <stdlib.h>
> 
> 
> void *malloc(size_t x)
> {
>   printf("hello my malloc %lu \n", x);
>   /* do nothing */
> }
> 
> Makefile
> -------------
> all: malloc
> 
> 
> libmalloc.so:libmalloc.o
>         gcc -shared  malloc.o -o libmalloc.so
> 
> libmalloc.o: malloc.c
>         gcc -fpic -c malloc.c
> 
> 
> 
> malloc: main.c libmalloc.so
>         gcc  malloc.c main.c -L. -lfoo -o malloc
> 
> 
> clean:
>         rm -f *.a *.o
> 
> 
> When i compiled and ran the above code, the output was,
> # export LD_LIBRARY_PATH=.
> #./malloc
> Calling malloc
> hello my malloc 100
> 
> #gcc --version
> gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3
> Copyright (C) 2011 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> 
> 
> 1. On what criteria, does the  malloc symbol get resolved, since we
>    have multiple  definitions, one in libmalloc and other libc. 
> 
> 2. Wont it be better if gcc reports multiple definitions as error, since
>     - allowing multiple definitions is error prone
>     - there is inconsistency on  how gcc handles multiple definitions
>       with regard to -static and without -static.
>       (ie. with -static gcc reports error for this)
> 
> 3. Could someone please help me understand why multiple definitions
>    are desired in dynamic linked case ? 
> 
> Appreciate your help.
> 
> Thanks.
>

Attachment: signature.asc
Description: OpenPGP digital signature