static and global variable problem

[Programmingkid]

I was doing some debugging of an issue with the hash_page_32() function in the file
ofmem.c, when I noticed a very odd problem. The static variable next_grab_slot never
changes value. I tried declaring it as a global variable and its value still never
changes. I used gdb to monitor its value. Local variables work just fine. Any body know a
way to fix this problem? My guess is this is a gcc problem. What is your theory?

[Mark Cave-Ayland]

On 20/12/12 20:16, Programmingkid wrote:

  I was doing some debugging of an issue with the
hash_page_32() function in the file ofmem.c, when I noticed a very odd problem. The static
variable next_grab_slot never changes value. I tried declaring it as a global variable and
its value still never changes. I used gdb to monitor its value. Local variables work just
fine. Any body know a way to fix this problem? My guess is this is a gcc problem. What is
your theory?
The first thing I would check is have you changed the CFLAGS from -Os to 
-O0 to disable optimisation? Otherwise gdb is missing information it 
needs to work correctly, and will start to do some strange things.

Also I note that when Alex did some work on this back in 2009, he made a 
minor change to PPC's OFMEM here: 
http://lists.openbios.org/pipermail/openbios/2009-July/003796.html. Alex 
- should the change to hash_page_32() be committed or is that another 
hack to work around something else?


ATB,

Mark.

[Alexander Graf]

On 21.12.2012, at 10:55, Mark Cave-Ayland wrote:

  On 20/12/12 20:16, Programmingkid wrote:
 
  I was doing some debugging of an issue with the
hash_page_32() function in the file ofmem.c, when I noticed a very odd problem. The static
variable next_grab_slot never changes value. I tried declaring it as a global variable and
its value still never changes. I used gdb to monitor its value. Local variables work just
fine. Any body know a way to fix this problem? My guess is this is a gcc problem. What is
your theory?
 
 The first thing I would check is have you changed the CFLAGS from -Os to -O0 to disable
optimisation? Otherwise gdb is missing information it needs to work correctly, and will
start to do some strange things.
 
 Also I note that when Alex did some work on this back in 2009, he made a minor change to
PPC's OFMEM here: http://lists.openbios.org/pipermail/openbios/2009-July/003796.html.
Alex - should the change to hash_page_32() be committed or is that another hack to work
around something else?
I quite frankly don't remember what exactly I was trying to fix. I think the basic
idea was that incrementing it by 3 we evict entries more fairly. But thinking about it
again, I don't seem to understand why either myself :)


Alex

[Programmingkid]

On Dec 21, 2012, at 8:09 AM, Alexander Graf wrote:

  
 On 21.12.2012, at 10:55, Mark Cave-Ayland wrote:
 
  On 20/12/12 20:16, Programmingkid wrote:
 
  I was doing some debugging of an issue with the
hash_page_32() function in the file ofmem.c, when I noticed a very odd problem. The static
variable next_grab_slot never changes value. I tried declaring it as a global variable and
its value still never changes. I used gdb to monitor its value. Local variables work just
fine. Any body know a way to fix this problem? My guess is this is a gcc problem. What is
your theory?
 
 The first thing I would check is have you changed the CFLAGS from -Os to -O0 to disable
optimisation? Otherwise gdb is missing information it needs to work correctly, and will
start to do some strange things.
 
 Also I note that when Alex did some work on this back in 2009, he made a minor change to
PPC's OFMEM here: http://lists.openbios.org/pipermail/openbios/2009-July/003796.html.
Alex - should the change to hash_page_32() be committed or is that another hack to work
around something else?
 
 I quite frankly don't remember what exactly I was trying to fix. I think the basic
idea was that incrementing it by 3 we evict entries more fairly. But thinking about it
again, I don't seem to understand why either myself :)
I was investigating this problem and was wondering if register r31 has any special purpose
in OpenBIOS. My guess is it is suppose to point to the global variable address space.

[Programmingkid]

On Dec 21, 2012, at 9:36 AM, Programmingkid wrote:

  
 On Dec 21, 2012, at 8:09 AM, Alexander Graf wrote:
 
  
 On 21.12.2012, at 10:55, Mark Cave-Ayland wrote:
 
  On 20/12/12 20:16, Programmingkid wrote:
 
  I was doing some debugging of an issue with the
hash_page_32() function in the file ofmem.c, when I noticed a very odd problem. The static
variable next_grab_slot never changes value. I tried declaring it as a global variable and
its value still never changes. I used gdb to monitor its value. Local variables work just
fine. Any body know a way to fix this problem? My guess is this is a gcc problem. What is
your theory?
 
 The first thing I would check is have you changed the CFLAGS from -Os to -O0 to disable
optimisation? Otherwise gdb is missing information it needs to work correctly, and will
start to do some strange things.
 
 Also I note that when Alex did some work on this back in 2009, he made a minor change to
PPC's OFMEM here: http://lists.openbios.org/pipermail/openbios/2009-July/003796.html.
Alex - should the change to hash_page_32() be committed or is that another hack to work
around something else?
 
 I quite frankly don't remember what exactly I was trying to fix. I think the basic
idea was that incrementing it by 3 we evict entries more fairly. But thinking about it
again, I don't seem to understand why either myself :)
 
 I was investigating this problem and was wondering if register r31 has any special
purpose in OpenBIOS. My guess is it is suppose to point to the global variable address
space.
I meant r9, not r31.