0

I am trying to follow this basic program involving pointer into the memory. At first We define counter to be 0 (outside main) then we make p_int to point at the same address as a counter. But when i go into the loop for some reason it compares the register with 21 instead of 2. after that when i have tried to change the adress and value of the pointer to a tottaly different vaue and address, it exits in an error,although it compiled well. Whele did i go wrong? Thanks.

int counter=0;

int main()
{
 int *p_int;
 p_int=&counter; 
  while (*p_int <2)
  {
    (*p_int)++;
  }

  p_int=(int*)0x20000002U;
  *p_int=0xDEADBEEF;
  return 0;
}

enter image description here

enter image description here

enter image description here

enter image description here

rocko445
  • 129
  • 7
  • 5
    You should not dereference any memory location which you don't own. It will lead to undefined behavior. – kiran Biradar May 13 '20 at 11:31
  • 3
    You can't dereference pointers to memory that doesn't belong to your program, that leads to *undefined behavior*. – Some programmer dude May 13 '20 at 11:31
  • You're probably running on an ARM with an MMU that faults on invalid addresses. Where invalid means outside physical address space, or if you're running under an OS like Linux, to a virtual page your process doesn't own. You haven't said anything about any details of what kind of fault or error, so I closed this as a duplicate of some other questions about setting a pointer value to an arbitrary integer and then dereferencing. – Peter Cordes May 13 '20 at 12:40
  • Hello, why when my counter is outside of the main then it compares it with 21 instead if 2? Thanks. – rocko445 May 13 '20 at 12:40
  • what compiler is this and what settings, etc to produce that output? (I am not seeing this with gcc) – old_timer May 13 '20 at 12:43
  • What? Are you sure if faults inside the loop? Copy/paste disassembly as text and show where it faults. (Don't post pictures of text.) Are you sure your asm was compiled from this version of the source? Comparing with `21` doesn't make sense. – Peter Cordes May 13 '20 at 12:44
  • 1
    an mmu wouldnt replace a 2 with a 21. and from some clues here this looks like an mcu not a full sized arm and note that the code not talked about the code below the while is an unaligned access and yet another problem with this code. – old_timer May 13 '20 at 12:45
  • with -O1 I can get gcc to make a loop that compares with 2... – old_timer May 13 '20 at 12:51
  • 1
    but your disassembly does not match the C code, so I dont see how the disassembly is related to the code posted in the question. and that is probably why it doesnt make sense. – old_timer May 13 '20 at 12:53
  • hmm, cant see how those other questions are remotely related to this one...whatever... – old_timer May 13 '20 at 12:53
  • @old_timer: They're duplicates of the *when i have tried to change the adress and value of the pointer to a tottaly different vaue and address, it exits in an error.* The OP asked where they went wrong, and setting a pointer to point somewhere arbitrary is definitely a place where they went wrong. (Also I didn't notice the 2 vs 21 part of the intro until after looking at the code and the comments. That doesn't make any sense anyway so the question needs closing until more details are added, if that's what it was supposed to be about.) – Peter Cordes May 13 '20 at 14:49
  • the op was asking how come I put a 2 in and get a 21 although the screen shot of the 21 is a disassembly of code that does not match the code asked in the question, cant be the compiler output for that code anyway. – old_timer May 13 '20 at 18:29
  • this is arm you dont get segmentation faults in arm – old_timer May 13 '20 at 18:30
  • if the totally different address thing is the code at the bottom then that is an alignment issue which can be valid on arms if you disable checking or it is disabled on reset, but if enabled then you get a fault. which if this code is on an os then that might simply exit poorly (but will compile just fine). – old_timer May 13 '20 at 18:33
  • and there are questions that have been answered about alignment, which the quoted ones are not. – old_timer May 13 '20 at 18:34
  • the wild pointer one implies this code is fine which it appears to be (other than the alignment issue), although I would never use pointers like this as you have probably seen me comment... – old_timer May 13 '20 at 18:36
  • thumb + thumb2 extensions implies this is either an armv7 or an armv7-m so either full sized or a microcontroller the 0x2000xxxx address implies microcontroller (cortex-m) and that implies not on an operating system at least not one with some command line that might exit so exit doesnt make sense yet... – old_timer May 13 '20 at 18:37
  • the indentation of the p_int assignment to the address of the global implies that was added later, without that the code more closely matches the disassembly – old_timer May 13 '20 at 18:39

0 Answers0