Like Tree1Likes
  • 1 Post By Jesdisciple

Makefiles, GCC's -ggdb option, and Valgrind

This is a discussion on Makefiles, GCC's -ggdb option, and Valgrind within the C Programming forums, part of the General Programming Boards category; To get right to the point, Valgrind is reporting filenames and line numbers for errors in some files but not ...

  1. #1
    Registered User
    Join Date
    Aug 2008
    Posts
    129

    Makefiles, GCC's -ggdb option, and Valgrind

    To get right to the point, Valgrind is reporting filenames and line numbers for errors in some files but not others. The makefiles say to include full debugging info in all compilations, so I would expect identical behavior. The only difference is which makefile the instructions come from.

    This is the makefile for my library sources; Valgrind doesn't show line numbers for any of these.
    Code:
    # Makefile
    
    filesystem.o: filesystem.c filesystem.h
    	gcc -ggdb -ansi -c filesystem.c
    
    filesystem.h: list.h
    
    list.o: list.c list.h
    	gcc -ggdb -ansi -c list.c
    
    list.h: toolkit.h
    
    toolkit.o: toolkit.c toolkit.h
    	gcc -ggdb -ansi -c toolkit.c
    And these are my project sources; line numbers are shown for all of them. EDIT: Oh, and ../Jesdisciple is my library directory.
    Code:
    # Makefile
    
    outliner: main.o outline.o ../Jesdisciple/filesystem.o ../Jesdisciple/list.o ../Jesdisciple/toolkit.o
    	gcc -ggdb -ansi -o outliner main.o outline.o ../Jesdisciple/filesystem.o ../Jesdisciple/list.o ../Jesdisciple/toolkit.o
    
    main.o: main.c outline.c outline.h ../Jesdisciple/filesystem.h 
    	gcc -ggdb -ansi -c main.c outline.c
    
    outline.h: ../Jesdisciple/filesystem.h
    
    include ../Jesdisciple/Makefile
    Can anyone please hint at what I did wrong? Thanks!

    P.S. Sorry for bumping Enter a little too soon.
    Last edited by Jesdisciple; 03-12-2009 at 06:16 PM.

  2. #2
    Registered User
    Join Date
    Aug 2008
    Posts
    129
    (bump)

  3. #3
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    You may need to show us what parts it is showing errors in. It is possible that you'll get reports from valgrind inside the C library, in which case you do not get symbols by adding -g to YOUR compile.

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  4. #4
    Frequently Quite Prolix dwks's Avatar
    Join Date
    Apr 2005
    Location
    Canada
    Posts
    8,045
    Code:
    main.o: main.c outline.c outline.h ../Jesdisciple/filesystem.h 
    	gcc -ggdb -ansi -c main.c outline.c
    You're defeating the purpose of make here. The idea of make is that you only have to compile what needs compiling, as opposed to always compiling both source files.

    May I suggest some alternative makefiles that use built-in rules and should perform the same as yours?
    Code:
    # Makefile
    CC = gcc
    CFLAGS = -ggdb -ansi
    OBJECTS = filesystem.o list.o toolkit.o
    
    filesystem.o: filesystem.c filesystem.h
    filesystem.h: list.h
    list.o: list.c list.h
    list.h: toolkit.h
    toolkit.o: toolkit.c toolkit.h
    If you want to be really fancy, you can make those dependencies automatically generated.

    Code:
    # Makefile
    
    CC = gcc
    CFLAGS = -ggdb -ansi
    OBJECTS = filesystem.o list.o toolkit.o
    
    include depend
    .PHONY: depend
    depend:
    	$(CC) -MM $(OBJECTS) > depend
    Likewise for the second Makefile, except you'd probably replace the outliner: target with something like this . . . .
    Code:
    outliner: $(OBJECTS) $(Jesdisciple_OBJECTS)
    	$(CC) $(CFLAGS) -o $@ $^
    Anyway, just thought you might want to know more about what make can do . . . .
    dwk

    Seek and ye shall find. quaere et invenies.

    "Simplicity does not precede complexity, but follows it." -- Alan Perlis
    "Testing can only prove the presence of bugs, not their absence." -- Edsger Dijkstra
    "The only real mistake is the one from which we learn nothing." -- John Powell


    Other boards: DaniWeb, TPS
    Unofficial Wiki FAQ: cpwiki.sf.net

    My website: http://dwks.theprogrammingsite.com/
    Projects: codeform, xuni, atlantis, nort, etc.

  5. #5
    Registered User
    Join Date
    Aug 2008
    Posts
    129
    Mats: I'm pretty sure that's not what I was seeing, but I tried to make a fake error anyway to make sure. That didn't go so well; see below.

    dwk: I changed the makefiles and thought everything was fine, but when I tried to make an error in a library source I got a bunch of errors in the project sources about undefined stuff coming from library sources. (And that was after I changed the main source so recompilation would be attempted.) So the library's timestamps are no longer being checked.

    When I removed the fake errors and triggered another update for the main source, the troublesome errors remained. I also tried compiling the library sources directly; this showed me some line comments which I removed, but the "bad" errors still didn't leave.

    I don't think make's (kinda long) output would be very useful, but it's available upon request.

    EDIT: I figured the problem out: Jesdisciple_OBJECTS wasn't defined before use. I reversed the order of dependencies in the makefiles and now have a different problem:
    Code:
    make: *** No rule to make target `toolkit.c', needed by `toolkit.o'.  Stop.
    And I believe the confusion stems from make finding those filenames in the makefile of the project directory (where the variable is expanded). Can I automatically prefix them with ../Jesdisciple/?

    EDIT2: I resolved the makefile problem by adding ../Jesdisciple/ to the beginning of every library object and moving them to the project makefile, and then reversing the order of dependencies again so the include was at the bottom. After this, the original problem seems to have disappeared. Thanks!

    Here are the makefiles:
    Code:
    # Makefile
    CC = gcc
    CFLAGS = -ggdb -ansi
    OBJECTS = main.o outline.o
    
    include ../Jesdisciple/Makefile
    
    outline.h: ../Jesdisciple/filesystem.h
    outline.o: outline.c outline.h
    
    main.o: main.c outline.h
    
    outliner: $(OBJECTS) $(Jesdisciple_OBJECTS)
    	$(CC) $(CFLAGS) -o $@ $^
    Code:
    # Makefile
    Jesdisciple_OBJECTS = filesystem.o list.o toolkit.o
    
    toolkit.o: toolkit.c toolkit.h
    
    list.h: toolkit.h
    list.o: list.c list.h
    
    filesystem.h: list.h
    filesystem.o: filesystem.c filesystem.h list.h
    Thanks!
    Last edited by Jesdisciple; 03-14-2009 at 08:39 AM.

  6. #6
    Registered User
    Join Date
    Aug 2008
    Posts
    129
    ...Or so I thought. I was rushed this morning, and I actually didn't make an error for Valgrind - just for GCC. I really didn't need to make one for Valgrind as I'm already dealing with several. Here's a good example:
    Code:
    16 bytes in 2 blocks are definitely lost in loss record 1 of 13
    ==7693==    at 0x402603E: malloc (vg_replace_malloc.c:207)
    ==7693==    by 0x804AEFB: split (list.c:206)
    ==7693==    by 0x804A60E: dir_exists (in /home/chris/NetBeansProjects/Outliner/outliner)
    ==7693==    by 0x804A77F: dir_create (in /home/chris/NetBeansProjects/Outliner/outliner)
    ==7693==    by 0x804940F: outline_init (outline.c:31)
    ==7693==    by 0x804902E: main (main.c:170)
    And come to think of it, this only affects filesystem.c.

    EDIT: I have no idea what caused it this time, but after I fixed my fake compile error (which I had forgotten about), the line numbers showed up. Sorry for taking your time!
    Last edited by Jesdisciple; 03-14-2009 at 07:26 PM.
    leijing likes this.

Popular pages Recent additions subscribe to a feed

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21