0

All the functions used in the main file are correctly defined. However when I try to enter the debugging mode, for some reason IDE isn't stepping into said functions when asked to. Instead it acts like a step over and ignores the lines until the very last line, where out of the blue all variables appear in the window ; prior to that, no variable is present whatsoever.

Here's the main file :

#include "pointers.h"

int main(void){
    whatisapointer();
    whatisthesizeofapointer();
    whatareNpointersplacedsuccessively(6);
    return 0;
}

the pointers.c file used to define the functions in main :

#include "pointers.h"

void whatisapointer(){
    int *pointer;                   
    pointer = allocateOneInteger(); 
    *pointer = 42;                  
}

void whatisthesizeofapointer(){
    int a = sizeof(char);
    int b = sizeof(int);
    int c = sizeof(char*);
    int d = sizeof(int*);
}

void whatareNpointersplacedsuccessively(int N){
    int i, *Npointer, *current;
    char *Npointerchar, *currentchar;
    Npointer = allocateNInteger(N);
    current = Npointer;
    current = Npointer+1;
    current = Npointer+2;
    for(i=0;i<N;i++) *(Npointer+i) = i;
    N=2*N;
    Npointerchar = allocateNChar(N);
    currentchar = Npointerchar;
    currentchar = Npointerchar+1;
    currentchar = Npointerchar+2;
    for(i=0;i<N;i++) Npointerchar[i] = 65+i;
    Npointer[N-3] = 0x68676665;
    current = Npointer+N-3;
}


int* allocateOneInteger(){
    return (int*)malloc(1*sizeof(int));
}

int* allocateNInteger(int N){
    return (int*)malloc(N*sizeof(int));
}

char* allocateNChar(int N){
    return (char*)malloc(N*sizeof(char));
}


void echange(int a,int b)
{
    int temp;
    temp=a;
    a=b;
    b=temp;
}

void echangep(int *pa,int *pb)
{
    int temp;
    temp=*pa;
    *pa=*pb;
    *pb=temp;
}

/* Fonction allocateNFloat
 */
void allocateNFloat(int N){

}

And the makefile :

CC := gcc
FLAGS := -g -Wall -Werror

all : prog

prog : pointers.o mainpointers.o
        $(CC) pointers.o mainpointers.o -o prog

fonctions.o : pointers.c pointers.h
        $(CC) -c pointers.c $(FLAGS) -o pointers.o
        
mainpointers.o : mainpointers.c pointers.h
        $(CC) -c mainpointers.c $(FLAGS) -o mainpointers.o

clean : 
            rm -f *.o
            rm -f prog

I've done some research, none of which has helped me solve this issue.

howlger
  • 31,050
  • 11
  • 59
  • 99
  • Regarding: `FLAGS := -g -Wall -Werror` This is missing some key options. Suggest: `FLAGS := -g -Wall -Wextra -Wconversion -pedantic -std=c19 -Werror` Regarding: `prog : pointers.o mainpointers.o $(CC) pointers.o mainpointers.o -o prog` This fails to tell the linker to include the debug information. Suggest: `prog : pointers.o mainpointers.o $(CC) -g pointers.o mainpointers.o -o prog` – user3629249 Nov 29 '20 at 02:32
  • regarding: `return (int*)malloc(1*sizeof(int));` (and similar statements) 1) in C, the returned type from `malloc()` is `void*` which can be assigned to any pointer. Casting just clutters the code (and is error prone). Suggest removing the cast. 2) always check (!=NULL) the returned value to assure the operation was successful. If not successful (==NULL) then call `perror( "malloc failed" );` to output to `stderr` both your error message and the text reason the system thinks the error occurred. – user3629249 Nov 29 '20 at 02:37
  • The posted code results in several memory leaks because the allocated memory is never passed to `free()` – user3629249 Nov 29 '20 at 02:39
  • regarding: `fonctions.o` This results is problems because the `make` facility is being told to generate the file: `fonctions.o` but is never told how to generate that file. Suggest: `pointers.o : pointers.c pointers.h $(CC) -c pointers.c $(FLAGS) -o pointers.o` – user3629249 Nov 29 '20 at 02:44
  • regarding: `int a = sizeof(char); int b = sizeof(int); int c = sizeof(char*); int d = sizeof(int*);` the variables `a` `b` `c` `d` are never used, so the compiler will 1) output a warning statement for each of these 4 statements about a variable being set but never used. Suggest passing each of these variables to an appropriate `printf()` statement. – user3629249 Nov 29 '20 at 02:53
  • regarding: `current = Npointer; current = Npointer+1; current = Npointer+2;` (and all the rest of the statements in the same function) 1) the compiler will output warnings about variables being set but never used. Suggest passing all the variables to `printf()` – user3629249 Nov 29 '20 at 02:55
  • the contents of the file: `pointers.h` are not posted. Unless that file contains prototypes for each of the functions in `pointers.c`, the code will not compile. Please post the contents of `pointers.h` – user3629249 Nov 29 '20 at 03:04
  • Thank you for your comments ! This has helped me a lot. You pointed out everything that was off, and thanks to that I managed to successfully recode the program. – BuctopBohr Nov 29 '20 at 16:08

1 Answers1

1

You're very likely finding that the compiler is optimizing away your code, because the functions have no side-effects. (If you're not familiar with the concept of side effects, the gist is 'changes to program state that might influence other parts of the program'---compilers aggressively prune away side-effect-free code because, by definition, doing so doesn't change the behavior of the program.)

Even allocating memory isn't a side affect, because correct code should never be able to tell whether another part of the program has allocated memory.

The easiest side-effect is to print out the result of any intermediate computation you want to inspect via the debugger; that will force the optimizer to leave the code in place.

E.g.,

int foo() //no side effects, will be optimized to an empty function or pruned.
{
    char *test = malloc(4096);
    strcpy(test, "My test string");
    return 0;
}

int foo() //dumb side effects
{
    char *test = malloc(4096);
    strcpy(test, "My test string");
    printf("%02x", ((int)test & 0xff) ^ (test[0]) );//make output depend on the operations you wish to observe
    return 0;
}

An alternate means to verify that the compiler is pruning away your code would be to disassemble the resulting object file...you should see that the functions consist of a single 'return' instruction...which is what the debugger is showing by highlighting the closing curly brace.

lockcmpxchg8b
  • 2,205
  • 10
  • 16
  • Thank you for the reply. I am still learning C, so I am unaware of this. Could you please elaborate ? I think I understood what side-effects mean, but I don't know how to disassemble object files yet. – BuctopBohr Nov 27 '20 at 22:13
  • 1
    `objdump` is a fairly common tool on Linux systems that can disassemble code. running `objdump -d ` should spit out the machine code with labels for your function names. To understand the machine code, you'll need an instruction set reference for your processor architecture...that may be a bit much...but you should still be able to see if there's a single instruction in the functions you're having trouble stepping through that sounds like 'leave' or 'return'. (Rather than the typical tens to hundreds of instructions a function usually requires) – lockcmpxchg8b Nov 27 '20 at 22:19
  • I've edited the answer...disassembly is not really an alternative to forcing side-effects so that you can see what happens in a debugger...it's really an alternative way to verify that what you're seeing is a result of the compiler pruning away your code. Edited to make that clearer. – lockcmpxchg8b Nov 27 '20 at 22:24
  • Ok, I've got the gist of it. I've tried to implement your function (the one with the side-effects on) and test it through IDE debugger, and it still doesn't go well when I try to step into foo(). Is there something I've missed ? Part of the explanation was kind of cryptic to me, I must admit. I guess I'm not comfortable enough with C yet. – BuctopBohr Nov 27 '20 at 22:57
  • Hmm. Do you have any way to capture what's on the screen before/after trying to step-into? – lockcmpxchg8b Nov 27 '20 at 23:35
  • https://zupimages.net/viewer.php?id=20/48/x20s.png this is before I try to step into foo(). The previous functions don't show as expected. https://zupimages.net/viewer.php?id=20/48/wa1t.png Same thing happens, nothing is shown and IDE simply steps over foo() instead... https://zupimages.net/viewer.php?id=20/48/j4l7.png Only in the end are shown a bunch of variables in the right tab. – BuctopBohr Nov 28 '20 at 14:01
  • Have you tried putting printf statement in foo? I noticed the 'console' window on your IDE was blank...I would have expected anything coming out of printf to appear there. maybe use `fprintf(stderr, "your output")` to make sure the output is not buffered. – lockcmpxchg8b Nov 29 '20 at 19:23
  • 1
    As stated in my other reply, someone pointed out my makefile was wrong. Tweaking this solved most of my problems actually haha. Thanks though, I've learnt quite a lot here ! :) – BuctopBohr Dec 01 '20 at 20:34