9:16 p.m.
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?
10:55 a.m.
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.
2:09 p.m.
On 21.12.2012, at 10:55, Mark Cave-Ayland wrote:
On 20/12/12 20:16, Programmingkid wrote:
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
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?
3:36 p.m.
On Dec 21, 2012, at 8:09 AM, Alexander Graf wrote:
On 21.12.2012, at 10:55, Mark Cave-Ayland wrote:
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.
On 20/12/12 20:16, Programmingkid wrote:
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 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?
4:05 p.m.
On Dec 21, 2012, at 9:36 AM, Programmingkid wrote:
On Dec 21, 2012, at 8:09 AM, Alexander Graf wrote:
I meant r9, not r31.
On 21.12.2012, at 10:55, Mark Cave-Ayland wrote:
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. On 20/12/12 20:16, Programmingkid wrote:
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 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?
2587
days inactive
2588
days old
4 comments
3 participants
participants (3)
-
Alexander Graf -
Mark Cave-Ayland -
Programmingkid