Question

I did it using disassemble main in gdb i.e I used dissassemble main in gdb to determine the address of the next line and that's how I skipped to the desired line. Is there a way in which we can determine the address of next line w/o using disassemble main . i.e in c directly. Also if there are any other methods please mention.

 #include<stdio.h>

fun()
{
  int i,*j;

  j=&i;

  j++;
  j++;
  j++;

  *j=*j+13; //to skip first printf +13


  *j=*j+21; //to skip first and second printf +21 ie. 21 + 13

  //*j=*j+13; //to skip first,second,third printf +13 ie. 21 + 13 + 13
}

main()
{
  int a;
  a=5;

  fun();
  printf("hello1");
  printf("%d\n",a);
  printf("hello2");

}
Was it helpful?

Solution 2

The short answer is no. There is no way to determine the address of the next line.

You could use the goto statement, of which an example can be seen here.

However this is still discouraged as it leads to messy and unreadable code.

What you are doing is not skipping to the next line but you are in fact only skipping the next function call (which was pushed onto the stack) by forceably clearing the stack. Your code will only skip the next "function" and not the next "line". I would equate this behaviour to the debugger's "step over" functionality. You are modifying the stack which stores the parameters for the function but does not necessarily store the function "code".

The fact that you are directly modifying the stack frame makes your code machine/compiler dependent.

As @dodgethesteamroller said, there's only one way to completely control your execution the way you want and that is with assembly. You can look up the asm() command that is available in C if you want to play with inline assembly code. You can read more about that here and this too will make your code machine dependent.

What you want to do is not possible because code memory can be (and usually is) separate to data memory.

OTHER TIPS

Not only is this not portable from machine to machine or OS to OS, it's not even guaranteed that it would work right from one execution of your program to the next. Generally you can't rely that a linker will put your code in the same place in RAM. Ever. Unless you are using some extremely constrained and deterministic environment like a very small embedded system. I wouldn't recommend the practice even then--use assembly language and program on the bare metal if you want that type of total control.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top