7 Sep 2002 22:58
13 Sep 2002 17:23
function calls from GDB on powerpc
Aymeric Vincent <Aymeric.Vincent <at> labri.fr>
2002-09-13 15:23:58 GMT
2002-09-13 15:23:58 GMT
when trying to call a function of the program being debugged from within GDB on powerpc, you get: read_register_bytes: Couldn't update register 65. After a little investigation, here are a few facts: - register 65 is the msr. - this error is triggered in findvar.c:read_register_bytes() when called with a REGISTER_BYTES argument (in order to load all the registers from the target, so the MSR is not specifically wanted). - replacing the error by a warning (a printf) shows that register 65 is the only register that is displayed as having problems. Consequently, as the MSR is not used in my setup (and I don't think it is widely used in gdb in "native" mode), I have removed the above-mentioned error and can happily call functions from gdb. Here are the possible correct fixes that come to my mind: 1) Change the name of register 65 to NULL or "" so that it is ignored by read_register_bytes() [requires changing stuff in rs6000 definitions] 2) Provide means to read the MSR with ptrace(2) [requires changing the kernel, powerpc/reg.h and ppcnbsd-nat.c] 3) Make up a correct (but fake) value for the MSR in ppcnbsd-nat.c Has anyone looked into this yet or plans to do so? My preference goes to 3) because it is the least intrusive, and it(Continue reading)
20 Sep 2002 19:14
Re: function calls from GDB on powerpc
Andrew Cagney <cagney <at> mac.com>
2002-09-20 17:14:14 GMT
2002-09-20 17:14:14 GMT
> when trying to call a function of the program being debugged from > within GDB on powerpc, you get: > > read_register_bytes: Couldn't update register 65. > > After a little investigation, here are a few facts: > > - register 65 is the msr. > - this error is triggered in findvar.c:read_register_bytes() when > called with a REGISTER_BYTES argument (in order to load all the > registers from the target, so the MSR is not specifically wanted). > - replacing the error by a warning (a printf) shows that register 65 > is the only register that is displayed as having problems. > > Consequently, as the MSR is not used in my setup (and I don't think it > is widely used in gdb in "native" mode), I have removed the > above-mentioned error and can happily call functions from gdb. > > Here are the possible correct fixes that come to my mind: > > 1) Change the name of register 65 to NULL or "" so that it is ignored > by read_register_bytes() [requires changing stuff in rs6000 definitions] > 2) Provide means to read the MSR with ptrace(2) [requires changing the > kernel, powerpc/reg.h and ppcnbsd-nat.c] > 3) Make up a correct (but fake) value for the MSR in ppcnbsd-nat.c Suggest doing two things: - down load a current GDB and see if the problem still occurs. - assuming it does, hack around the problem with 3.(Continue reading)
22 Sep 2002 18:15
dud ptrace values under dejagnu
Andrew Cagney <cagney <at> mac.com>
2002-09-22 16:15:59 GMT
2002-09-22 16:15:59 GMT
Hello, Current GDB (cvs -d :sources.redhat.com:/cvs/src co gdb+dejagnu OR gdb) under 1.6 and head of 1.5 has really bad test results. Part of it is attributable to a more agressive compiler (frameless functions) but part of it is not. In fact, part is downright weird. Under the dejagnu test framework I see results like: > (gdb) p t_char_values(0,0) > > Program received signal SIGSEGV, Segmentation fault. > _start () > The program being debugged was signaled while in a function called from GDB. > GDB remains in the frame where the signal was received. > To change this behavior use "set unwindonsignal on" > Evaluation of the expression containing the function (t_char_values) will be abandoned. Which would, most likely, be due to ptrace() returning SIGSEGV instead of SIGTRAP (there is a breakpoint at _start()). If you're thinking it's GDB's bundled dejangu, think again. Switching to the NetBSD [un-]bundled expect/dejagnu causes the test result to work; ONCE! After that it to fails. (the dejagnu was built before my 1.6 install. Better refresh that ...). Anyone else able to ``reproduce'' this? I don't think it is GDB and, even if its a dejagnu/expect bug, it should(Continue reading)
25 Sep 2002 18:26
mailing list and port maintainer for walnut
Klaus Heinz <k.heinz.sep.zwei <at> onlinehome.de>
2002-09-25 16:26:27 GMT
2002-09-25 16:26:27 GMT
Hi,
is there any reason why there is no 'port-walnut' list and no
'port-walnut-maintainer' address?
I must admit I have no special interest in this platform other than to
have a bit of consistency for all the ports. Maybe this would make it
easier for interested people to join the effort.
ciao
Klaus
25 Sep 2002 18:49
Re: mailing list and port maintainer for walnut
derek godfrey <derek0godfrey <at> netscape.net>
2002-09-25 16:49:31 GMT
2002-09-25 16:49:31 GMT
and again if anyone is intrested in pcore680 (force power core 680) i'll be willing to provide the code and support. k.heinz.sep.zwei <at> onlinehome.de wrote: > Hi, > > is there any reason why there is no 'port-walnut' list and no > 'port-walnut-maintainer' address? > > I must admit I have no special interest in this platform other than to > have a bit of consistency for all the ports. Maybe this would make it > easier for interested people to join the effort. > > ciao > Klaus > >
17 Sep 2002 13:26
Ethernet driver bug?
Alexander A. V'ushkov <alexvj <at> ngs.ru>
2002-09-17 11:26:19 GMT
2002-09-17 11:26:19 GMT
Hi, All!
I'm continuing to start ofppc port of NetBSD on MPC8260.
I'm deal with erratic NFS behavior, and as I suppose, there is a bug in the
implementation of the Ethernet driver (function ether_input, file
/net/if_ether_subr.c) Sometimes software interrupt, responsible for
processing IP-queue of IP-stack (ip_intr() function) is called BEFORE than
packet is really placed into IP-queue("ipintrq" variable). As a result, the
packet will be processed only when the next packet arrives.
I suppose that such behavior is ties with the specificity of the call of
read function of the "ofnet" driver. It is called with assistance of callout
mechinism. Probably, the current interrupt priority level lets software
interrupt to occur (unlike calling the read function from hardware
interrupt).
I've changed the order of actions. At first I've putted packet into
IP-queue, and then set interrupt request. The error has disappeared.
So, I want to know you opinion about the problem.
I will try 1.25 a bit later, but I think all will be ok.
RSS Feed