From mboxrd@z Thu Jan 1 00:00:00 1970 From: Fernando Nasser To: shaunj@gray-interfaces.com Cc: gdb@sources.redhat.com Subject: Re: debugging an Atmel EB40 with a Jeeni Date: Mon, 25 Sep 2000 11:53:00 -0000 Message-id: <39CF9F0E.1A9D5231@cygnus.com> References: <00092512292800.00690@ed> X-SW-Source: 2000-09/msg00135.html Shaun Jackman wrote: > > I have an Atmel EB40. I'm using GDB and a Jeeni to debug it. > When I set the ARM CPSR register, I get a data abort. > This shouldn't touch data at all. What's happening? > This GDB was configured as "--host=i586-pc-linux-gnu --target=arm-elf"... > (gdb) target rdi e=jeeni > JEENI (ADP, ARM7TDI) Rev 2.0 > Rebuilt on Oct 18 1999 at 18:31:13 > SN=0009J002 ENET=00:80:CF:00:09:E4 > IP=192.168.2.2 > Connected to ARM RDI target. > (gdb) set $cpsr=0x1f > RDI_read: data abort, no memory at specified address? > RDI_read: data abort, no memory at specified address? > Cannot access memory at address 0x852b5a7c > (gdb) > The address (0x852b5a7c) is way out in lala land and if > anything tried to access it it would definately cause a data abort. > > Also, a really strange issue with a block memory clear hanging. > This GDB was configured as "--host=i586-pc-linux-gnu --target=arm-elf"... > (gdb) target rdi e=jeeni > JEENI (ADP, ARM7TDI) Rev 2.0 > Rebuilt on Oct 18 1999 at 18:31:13 > SN=0009J002 ENET=00:80:CF:00:09:E4 > IP=192.168.2.2 > Connected to ARM RDI target. > (gdb) set *(int*)0xffe00020=1 > (gdb) set *(int*)0xffe00004=0x2002121 > (gdb) set *(char*)0x20005a3 = 0 > (gdb) set *(char*)0x20005a4 = 0 > (gdb) set *(char*)0x20005a5 = 0 > (gdb) set (char[0x5a5])*0x2000000={} > [hangs here, never hear a word from it again] > > The two writes to 0xffe0xxxx map the sram to 0x2000000. > All the above writes work just fine, but any block clear larger than 0x5a4 hangs it. > Any idea what's happening here? > I have no idea, but we can know a little bit more if you turn log on. Better double check the help, but if I remember well it goes like that: (gdb) set rdilogfile (gdb) set rdilogenable true Maybe you should turn log on after the connection so you don't get too much log. This should give us a clue. -- Fernando Nasser Red Hat - Toronto E-Mail: fnasser@cygnus.com 2323 Yonge Street, Suite #300 Tel: 416-482-2661 ext. 311 Toronto, Ontario M4P 2C9 Fax: 416-482-6299 >From ac131313@cygnus.com Mon Sep 25 12:28:00 2000 From: Andrew Cagney To: Michael Elizabeth Chastain Cc: cgf@cygnus.com, dj@delorie.com, gdb@sourceware.cygnus.com Subject: Re: 'char **environ' woes with cygwin Date: Mon, 25 Sep 2000 12:28:00 -0000 Message-id: <39CFA681.AF0946F@cygnus.com> References: <200008251825.LAA32754@train2.cygnus.com> X-SW-Source: 2000-09/msg00136.html Content-length: 913 Michael Elizabeth Chastain wrote: > > Ok, here's a patch against sourceware that rips out the "environ" crap. > I haven't even built with it. > > After doing the math, the fixed address "&environ" cancels out. So this > won't make things any worse (or better) for djgpp or other systems where > malloc() does more than increment an sbrk pointer. > > Chris, do you think this makes your life easier enough to warrant some > testing and integration into sourceware? > > Michael Can this change be simplified further? Vis: o save an sbrk() call at the start to get the current top of heap o call sbrk () at the display time time and use that to compute the size. Also can the nasty bit of math used to make the computation be pushed into a function somewhere? I think your proposed change just needs to be pushed a little bit further so that all the nasties are eliminated :-) enjoy, Andrew >From ac131313@cygnus.com Mon Sep 25 12:34:00 2000 From: Andrew Cagney To: lars brinkhoff Cc: gdb@sourceware.cygnus.com Subject: Re: PDP-10 Date: Mon, 25 Sep 2000 12:34:00 -0000 Message-id: <39CFA7E0.A7F93C52@cygnus.com> References: <853djurgax.fsf@junk.nocrew.org> <39A641B6.25EDF1E1@cygnus.com> <8566oke1a7.fsf@junk.nocrew.org> X-SW-Source: 2000-09/msg00137.html Content-length: 708 lars brinkhoff wrote: > > It may take a little (lot of) work :-( findvar.c contains: > > I'm willing to give it a try. Would it be acceptable for inclusion in > GDB? As a remote target? Yes. As native target, maybe :-) GDB needs to get its act together with respect to sizeof host/target char. With respect to a native GDB, well, that could be more interesting again. However, provided there is an active maintainer it is still a possibility - depends mostly on the level of damage. The main thing is to get the issues out in the public domain early so that people can understand what changes (and in particular new programming conventions) are going to be needed for this to work Enjoy, Andrew >From chastain@cygnus.com Mon Sep 25 12:42:00 2000 From: Michael Elizabeth Chastain To: ac131313@cygnus.com, chastain@cygnus.com Cc: cgf@cygnus.com, dj@delorie.com, gdb@sourceware.cygnus.com Subject: Re: 'char **environ' woes with cygwin Date: Mon, 25 Sep 2000 12:42:00 -0000 Message-id: <200009251945.MAA13853@train2.cygnus.com> X-SW-Source: 2000-09/msg00138.html Content-length: 283 Andrew Cagney wrote: > I think your proposed change just needs to be pushed a little bit > further so that all the nasties are eliminated :-) OK, I will push it a little bit further and submit it as a sourceware patch. But it's a weekend task rather than a weekday task. Michael >From ac131313@cygnus.com Mon Sep 25 12:44:00 2000 From: Andrew Cagney To: gdb-announce@sources.redhat.com Cc: gdb@sources.redhat.com Subject: [maint] Add Mark Kettenis to blanket write privs maintainers Date: Mon, 25 Sep 2000 12:44:00 -0000 Message-id: <39CFAA4A.78C34214@cygnus.com> X-SW-Source: 2000-09/msg00139.html Content-length: 228 Hello, In response to many many recommendations (and happily accepted by Mark), I've added Mark K to the list of ``Blanket Write Privs'' GDB maintainers. Mark, you've been doing an amazing job! Thanks from everyone. Andrew >From ac131313@cygnus.com Mon Sep 25 13:12:00 2000 From: Andrew Cagney To: RDBrown@mira.net, RodneyBrown@mynd.com Cc: Geoff Keating , gdb@sources.redhat.com Subject: Re: Preferred format of Copyright statement Date: Mon, 25 Sep 2000 13:12:00 -0000 Message-id: <39CFB0B7.7A445052@cygnus.com> References: <200008162301.JAA00501@iji.local> X-SW-Source: 2000-09/msg00140.html Content-length: 1097 > > I know this has a tendency to line-wrap, but so what? No human will > > ever care. So we might as well make it completely correct. > > Ok, will produce that form. > Given that the first attempt over gdb > gives a patch file of ~900k touching 1725 files, would it be more useful > to provide patches for the few percent of cases needing manual fixes and > provide the script to be run when the maintainer finds it convenient? > Or should it only fix those with ranges or 2-digit years and leave (C) > removal where the year list is Ok? > > (Trying to conserve maintainer think time, not be a WOFTAM). (Yes I know your e-mail was posted a month ago :-(). Could I suggest a multi-step process like Kevin is doing to clean up PARAMS. I'd suggest doing the automated changes and then as a later pass, do the hand changes. You won't need maintainer approval for this change. Just give a weeks notice on the big jumbo change. enjoy, Andrew PS: I my take on how to format copyright is that IanC's guideline is simply too complicated for us programming types - we're a simple bunch :-) >From cgf@cygnus.com Mon Sep 25 13:30:00 2000 From: Chris Faylor To: Michael Elizabeth Chastain Cc: ac131313@cygnus.com, dj@delorie.com, gdb@sourceware.cygnus.com Subject: Re: 'char **environ' woes with cygwin Date: Mon, 25 Sep 2000 13:30:00 -0000 Message-id: <20000925162926.D12392@cygnus.com> References: <200009251945.MAA13853@train2.cygnus.com> X-SW-Source: 2000-09/msg00141.html Content-length: 532 On Mon, Sep 25, 2000 at 12:45:09PM -0700, Michael Elizabeth Chastain wrote: >Andrew Cagney wrote: > >> I think your proposed change just needs to be pushed a little bit >> further so that all the nasties are eliminated :-) > >OK, I will push it a little bit further and submit it as a sourceware >patch. But it's a weekend task rather than a weekday task. I agree. Also, for what it's worth, this change is no longer required for Cygwin. I was trying to work around a header file change that turned out to be an actual bug. cgf >From sjackman@ed.gray.internal Mon Sep 25 13:56:00 2000 From: Shaun Jackman To: gdb@sources.redhat.com Subject: Re: debugging an Atmel EB40 with a Jeeni Date: Mon, 25 Sep 2000 13:56:00 -0000 Message-id: References: <39CF9F0E.1A9D5231@cygnus.com> X-SW-Source: 2000-09/msg00142.html Content-length: 2351 On Mon, 25 Sep 2000, Fernando Nasser wrote: > Shaun Jackman wrote: > > > > I have an Atmel EB40. I'm using GDB and a Jeeni to debug it. > > When I set the ARM CPSR register, I get a data abort. > > This shouldn't touch data at all. What's happening? > > This GDB was configured as "--host=i586-pc-linux-gnu --target=arm-elf"... > > (gdb) target rdi e=jeeni > > JEENI (ADP, ARM7TDI) Rev 2.0 > > Rebuilt on Oct 18 1999 at 18:31:13 > > SN=0009J002 ENET=00:80:CF:00:09:E4 > > IP=192.168.2.2 > > Connected to ARM RDI target. > > (gdb) set $cpsr=0x1f > > RDI_read: data abort, no memory at specified address? > > RDI_read: data abort, no memory at specified address? > > Cannot access memory at address 0x852b5a7c > > (gdb) > > The address (0x852b5a7c) is way out in lala land and if > > anything tried to access it it would definately cause a data abort. > > > > Also, a really strange issue with a block memory clear hanging. > > This GDB was configured as "--host=i586-pc-linux-gnu --target=arm-elf"... > > (gdb) target rdi e=jeeni > > JEENI (ADP, ARM7TDI) Rev 2.0 > > Rebuilt on Oct 18 1999 at 18:31:13 > > SN=0009J002 ENET=00:80:CF:00:09:E4 > > IP=192.168.2.2 > > Connected to ARM RDI target. > > (gdb) set *(int*)0xffe00020=1 > > (gdb) set *(int*)0xffe00004=0x2002121 > > (gdb) set *(char*)0x20005a3 = 0 > > (gdb) set *(char*)0x20005a4 = 0 > > (gdb) set *(char*)0x20005a5 = 0 > > (gdb) set (char[0x5a5])*0x2000000={} > > [hangs here, never hear a word from it again] > > > > The two writes to 0xffe0xxxx map the sram to 0x2000000. > > All the above writes work just fine, but any block clear larger than 0x5a4 hangs it. > > Any idea what's happening here? > > > > I have no idea, but we can know a little bit more if you turn log on. > Better double check the help, but if I remember well it goes like that: > (gdb) set rdilogfile > (gdb) set rdilogenable true > > Maybe you should turn log on after the connection so you don't get too much log. > This should give us a clue. I wasn't able to find any rdi log or debug commands. (gdb) help set rdi Ambiguous set command "rdi": rdiheartbeat, rdiromatzero. There were some remote* commands (remotedebug, remotelogfile), but as I understand it these have no effect with rdi. They only work with remote gdb stubs. Is there a rdi debug mode I can't find? Thanks, Shaun