Hello,
Got that on imac g3.
CC kernel/kgdb.o
kernel/kgdb.c: In function 'kgdb_handle_exception':
kernel/kgdb.c:940: error: invalid lvalue in unary '&'
kernel/kgdb.c:940: warning: type defaults to 'int' in declaration of '_o_'
kernel/kgdb.c:940: error: invalid lvalue in unary '&'
kernel/kgdb.c:940: warning: type defaults to 'int' in declaration of '_n_'
kernel/kgdb.c:940: error: invalid lvalue in unary '&'
kernel/kgdb.c:940: error: invalid lvalue in unary '&'
kernel/kgdb.c:940: error: invalid lvalue in unary '&'
kernel/kgdb.c:940: warning: type defaults to 'int' in declaration of 'type name'
make[1]: *** [kernel/kgdb.o] Blad 1
make: *** [kernel] Blad 2
Regards,
Mariusz
From: Andrew Morton <akpm@linux-foundation.org> Date: 2007-08-22 19:48:19
On Wed, 22 Aug 2007 21:04:28 +0200
Mariusz Kozlowski [off-list ref] wrote:
Hello,
Got that on imac g3.
CC kernel/kgdb.o
kernel/kgdb.c: In function 'kgdb_handle_exception':
kernel/kgdb.c:940: error: invalid lvalue in unary '&'
kernel/kgdb.c:940: warning: type defaults to 'int' in declaration of '_o_'
kernel/kgdb.c:940: error: invalid lvalue in unary '&'
kernel/kgdb.c:940: warning: type defaults to 'int' in declaration of '_n_'
kernel/kgdb.c:940: error: invalid lvalue in unary '&'
kernel/kgdb.c:940: error: invalid lvalue in unary '&'
kernel/kgdb.c:940: error: invalid lvalue in unary '&'
kernel/kgdb.c:940: warning: type defaults to 'int' in declaration of 'type name'
make[1]: *** [kernel/kgdb.o] Blad 1
make: *** [kernel] Blad 2
I'm not surprised.
while (cmpxchg(&atomic_read(&debugger_active), 0, (procid + 1)) != 0) {
a) cmpxchg isn't available on all architectures
b) we can't just go and take the address of atomic_read()'s return value!
c) that's pretty ugly-looking stuff anyway.
From: Jason Wessel <jason.wessel@windriver.com> Date: 2007-08-22 22:45:25
Andrew Morton wrote:
On Wed, 22 Aug 2007 21:04:28 +0200
Mariusz Kozlowski [off-list ref] wrote:
quoted
Hello,
Got that on imac g3.
CC kernel/kgdb.o
kernel/kgdb.c: In function 'kgdb_handle_exception':
kernel/kgdb.c:940: error: invalid lvalue in unary '&'
kernel/kgdb.c:940: warning: type defaults to 'int' in declaration of '_o_'
kernel/kgdb.c:940: error: invalid lvalue in unary '&'
kernel/kgdb.c:940: warning: type defaults to 'int' in declaration of '_n_'
kernel/kgdb.c:940: error: invalid lvalue in unary '&'
kernel/kgdb.c:940: error: invalid lvalue in unary '&'
kernel/kgdb.c:940: error: invalid lvalue in unary '&'
kernel/kgdb.c:940: warning: type defaults to 'int' in declaration of 'type name'
make[1]: *** [kernel/kgdb.o] Blad 1
make: *** [kernel] Blad 2
Against the tip of the kernel + kgdb patches this config builds. I
wonder if is the compiler or the macros for atomic_read or cmpxchg have
changed for in the -mm tree. Perhaps it is not relevant though if you
read on.
I'm not surprised.
while (cmpxchg(&atomic_read(&debugger_active), 0, (procid + 1)) != 0) {
a) cmpxchg isn't available on all architectures
It was available for all the archs that the kgdb had been implemented on
at the time.
b) we can't just go and take the address of atomic_read()'s return value!
Perhaps yes, perhaps no I guess it depends on what actually gets
generated... In the past the intent of this was to guard for the race
to be the master processor and looked like some attempt to do it
atomically. This code had been in use for a number of years at this point.
c) that's pretty ugly-looking stuff anyway.
Perhaps there is a cleaner way to do the same thing and avoid the
cmpxchg all together. I used the attached patch to eliminate the
cmpxchg operation.
Jason.
From: Andrew Morton <akpm@linux-foundation.org> Date: 2007-08-22 23:54:23
On Wed, 22 Aug 2007 17:44:12 -0500
Jason Wessel [off-list ref] wrote:
quoted hunk
Perhaps there is a cleaner way to do the same thing and avoid the
cmpxchg all together. I used the attached patch to eliminate the
cmpxchg operation.
Jason.
[kgdb_enter_atomic.patch text/plain (2.0KB)]
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
---
kernel/kgdb.c | 18 ++++++++++++++++--
1 file changed, 16 insertions(+), 2 deletions(-)
@@ -638,8 +639,14 @@ static void kgdb_wait(struct pt_regs *rekgdb_info[processor].task=current;atomic_set(&procindebug[processor],1);+/* The master processor must be active to enter here, but this is+*gaurdincasethemasterprocessorhadnotbeenselectedif+*thiswasanentryvianmi.+*/+while(!atomic_read(&debugger_active));
eek. We're in the process of hunting down and eliminating exactly this
construct. There have been cases where the compiler cached the
atomic_read() result in a register, turning the above into an infinite
loop.
Plus we should never add power-burners like that into the kernel anyway.
That loop should have a cpu_relax() in it. Which will also fix the
compiler problem described above.
Thirdly, please always add a newline when coding statements like that:
while (expr())
;
From: Jason Wessel <jason.wessel@windriver.com> Date: 2007-08-23 03:25:46
Andrew Morton wrote:
On Wed, 22 Aug 2007 17:44:12 -0500
Jason Wessel [off-list ref] wrote:
quoted
+ while (!atomic_read(&debugger_active));
eek. We're in the process of hunting down and eliminating exactly this
construct. There have been cases where the compiler cached the
atomic_read() result in a register, turning the above into an infinite
loop.
Plus we should never add power-burners like that into the kernel anyway.
That loop should have a cpu_relax() in it. Which will also fix the
compiler problem described above.
Agreed, and fixed with a cpu_relax.
Thirdly, please always add a newline when coding statements like that:
while (expr())
;
The other instances I found of the same problem in the kgdb core are
fixed too.
I merged all the changes into the for_mm branch in the kgdb git tree.
Thanks,
Jason.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jason Wessel wrote:
Andrew Morton wrote:
quoted
On Wed, 22 Aug 2007 17:44:12 -0500
Jason Wessel [off-list ref] wrote:
quoted
+ while (!atomic_read(&debugger_active));
eek. We're in the process of hunting down and eliminating exactly this
construct. There have been cases where the compiler cached the
atomic_read() result in a register, turning the above into an infinite
loop.
Plus we should never add power-burners like that into the kernel
anyway. That loop should have a cpu_relax() in it. Which will also
fix the
compiler problem described above.
Agreed, and fixed with a cpu_relax.
quoted
Thirdly, please always add a newline when coding statements like that:
while (expr())
;
The other instances I found of the same problem in the kgdb core are
fixed too.
I merged all the changes into the for_mm branch in the kgdb git tree.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Pete/Piet Delaney wrote:
Jason Wessel wrote:
quoted
Andrew Morton wrote:
quoted
On Wed, 22 Aug 2007 17:44:12 -0500
Jason Wessel [off-list ref] wrote:
quoted
+ while (!atomic_read(&debugger_active));
eek. We're in the process of hunting down and eliminating exactly this
construct. There have been cases where the compiler cached the
atomic_read() result in a register, turning the above into an infinite
loop.
Plus we should never add power-burners like that into the kernel
anyway. That loop should have a cpu_relax() in it. Which will also
fix the
compiler problem described above.
Agreed, and fixed with a cpu_relax.
quoted
quoted
Thirdly, please always add a newline when coding statements like that:
while (expr())
;
The other instances I found of the same problem in the kgdb core are
fixed too.
quoted
I merged all the changes into the for_mm branch in the kgdb git tree.
- -
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFG1gnFJICwm/rv3hoRApOoAJ9BHXLsIuxDiOCaAFRfAZGwrDXATQCeLL3O
bxtr3qz0soPRghPmtSZgOqc=
=kQd1
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Pete/Piet Delaney wrote:
Jason Wessel wrote:
quoted
Andrew Morton wrote:
quoted
On Wed, 22 Aug 2007 17:44:12 -0500
Jason Wessel [off-list ref] wrote:
quoted
+ while (!atomic_read(&debugger_active));
eek. We're in the process of hunting down and eliminating exactly this
construct. There have been cases where the compiler cached the
atomic_read() result in a register, turning the above into an infinite
loop.
Plus we should never add power-burners like that into the kernel
anyway. That loop should have a cpu_relax() in it. Which will also
fix the
compiler problem described above.
Agreed, and fixed with a cpu_relax.
quoted
quoted
Thirdly, please always add a newline when coding statements like that:
while (expr())
;
The other instances I found of the same problem in the kgdb core are
fixed too.
quoted
I merged all the changes into the for_mm branch in the kgdb git tree.
Where is the kgdb git tree?
Why am I getting this when I do:
git clone
http://master.kernel.org/pub/scm/linux/kernel/git/jwessel/linux-2.6-kgdb.git
-
----------------------------------------------------------------------------
error: Couldn't get
http://master.kernel.org/pub/scm/linux/kernel/git/jwessel/linux-2.6-kgdb.git/refs/tags/v2.6.11
for tags/v2.6.11
The requested URL returned error: 404
error: Could not interpret tags/v2.6.11 as something to pull
rm: cannot remove directory
`/nethome/piet/Src/linux/git/jwessel/linux-2.6-kgdb/.git/clone-tmp':
Directory not empty
/nethome/piet/Src/linux/git/jwessel$
-
----------------------------------------------------------------------------
We are getting a problem with VMware where kernel text is the schedler
is getting wacked with four null bytes into the code. Thought I'd use
the current linux-2.6-kgdb.git tree and possible the CONFIG_DEBUG_RODATA
patch to make kernel text readonly:
https://www.x86-64.org/pipermail/patches/2007-March/003666.html
I thought the kernel text was RO and gdb had to disable it to
insert a breakpoint.
- -piet
- -
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFG1hshJICwm/rv3hoRAhTGAJ46pq69zYHqRmT+yTmRx+RVh8aBtgCfdyFM
gl91xCFTy0NJxHalVXpd9Os=
=c8FZ
-----END PGP SIGNATURE-----
From: Randy Dunlap <hidden> Date: 2007-08-30 01:42:31
On Wed, 29 Aug 2007 18:19:29 -0700 Pete/Piet Delaney wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Pete/Piet Delaney wrote:
quoted
Jason Wessel wrote:
quoted
Andrew Morton wrote:
quoted
On Wed, 22 Aug 2007 17:44:12 -0500
Jason Wessel [off-list ref] wrote:
quoted
+ while (!atomic_read(&debugger_active));
eek. We're in the process of hunting down and eliminating exactly this
construct. There have been cases where the compiler cached the
atomic_read() result in a register, turning the above into an infinite
loop.
Plus we should never add power-burners like that into the kernel
anyway. That loop should have a cpu_relax() in it. Which will also
fix the
compiler problem described above.
Agreed, and fixed with a cpu_relax.
quoted
quoted
Thirdly, please always add a newline when coding statements like that:
while (expr())
;
The other instances I found of the same problem in the kgdb core are
fixed too.
quoted
I merged all the changes into the for_mm branch in the kgdb git tree.
We are getting a problem with VMware where kernel text is the schedler
is getting wacked with four null bytes into the code. Thought I'd use
the current linux-2.6-kgdb.git tree and possible the CONFIG_DEBUG_RODATA
patch to make kernel text readonly:
https://www.x86-64.org/pipermail/patches/2007-March/003666.html
I thought the kernel text was RO and gdb had to disable it to
insert a breakpoint.
- -piet
- -
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFG1hshJICwm/rv3hoRAhTGAJ46pq69zYHqRmT+yTmRx+RVh8aBtgCfdyFM
gl91xCFTy0NJxHalVXpd9Os=
=c8FZ
-----END PGP SIGNATURE-----
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
From: Jason Wessel <jason.wessel@windriver.com> Date: 2007-08-30 02:13:18
Pete/Piet Delaney wrote:
We are getting a problem with VMware where kernel text is the schedler
is getting wacked with four null bytes into the code. Thought I'd use
the current linux-2.6-kgdb.git tree and possible the CONFIG_DEBUG_RODATA
patch to make kernel text readonly:
https://www.x86-64.org/pipermail/patches/2007-March/003666.html
I thought the kernel text was RO and gdb had to disable it to
insert a breakpoint.
If you are going to make all the kernel text RO, then you are going to
have to add some code to the kgdb write memory so as to unprotect a
given page or all the breakpoint writes are going to fail.
Alternatively you can use HW breakpoints. But, I have no idea if your
VM Ware simulated HW emulate HW breakpoint registers or not.
Jason.