From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Faylor To: gdb@sources.redhat.com Subject: 'char **environ' woes with cygwin Date: Thu, 24 Aug 2000 13:34:00 -0000 Message-id: <20000824163339.A9295@cygnus.com> X-SW-Source: 2000-08/msg00123.html I've recently painfully learned that gdb explicitly declares 'char **environ' all over the place. This presents a problem for cygwin since environ is now being imported from the cygwin DLL. I've modified configure.in to egrep unistd.h for an environ declaration and define HAVE_ENVIRON if unistd.h contains a declaration. The question is, where do I put a: #ifndef HAVE_ENVIRON char **environ; #endif ? My initial choice was gdb's "environ.h" but that means that a number of files need to include this just to get this declaration. So, I'm wondering if putting this in defs.h is a better choice. Can anyone tell me the best place to include this? I assume that everyone agrees that putting the above in one header file is better than sprinkling it throughout the sources. cgf >From chastain@cygnus.com Thu Aug 24 14:11:00 2000 From: Michael Elizabeth Chastain To: cgf@cygnus.com, gdb@sources.redhat.com Subject: Re: 'char **environ' woes with cygwin Date: Thu, 24 Aug 2000 14:11:00 -0000 Message-id: <200008242113.OAA07076@train2.cygnus.com> X-SW-Source: 2000-08/msg00124.html Content-length: 1264 > I've recently painfully learned that gdb explicitly declares 'char **environ' > all over the place. Quickie look: I see a bunch of strange uses in event-top.c, main.c, top.c. There is a bunch of (replicated) code that wants to compute the memory in use, so from time to time it takes sbrk(0) - &some_data_variable. The "&some_data_variable" is simply an arbitrary invariant address in the data segment. I bet that the author chose "&environ" for the marker variable to use simply because it's a variable that's usually there. Better code: extern char * sbrk_initial; ... sbrk_initial = sbrk(0); ... space = sbrk(0) - sbrk_initial; > My initial choice was gdb's "environ.h" but that means that a number of files > need to include this just to get this declaration. I think if you fix the "compute space in use" code that a lot of those references to &environ will evaporate. I also don't see the point of the declarations in gdbserver/low-{hppabsd,linux,nbsd,sparc,sun3}.c. and inftarg.c. That leaves environ.c, fork-child.c, go32-nat.c, infcmd.c, inferior.h, kdb-start.c. Those look like files that need to include "environ.h" because they are using or changing the environment. Michael Chastain "love without fear" >From cgf@cygnus.com Thu Aug 24 14:52:00 2000 From: Chris Faylor To: Michael Elizabeth Chastain Cc: gdb@sources.redhat.com Subject: Re: 'char **environ' woes with cygwin Date: Thu, 24 Aug 2000 14:52:00 -0000 Message-id: <20000824175146.A15009@cygnus.com> References: <200008242113.OAA07076@train2.cygnus.com> X-SW-Source: 2000-08/msg00125.html Content-length: 1105 On Thu, Aug 24, 2000 at 02:13:22PM -0700, Michael Elizabeth Chastain wrote: >> I've recently painfully learned that gdb explicitly declares 'char **environ' >> all over the place. > >Quickie look: > >I see a bunch of strange uses in event-top.c, main.c, top.c. There is >a bunch of (replicated) code that wants to compute the memory in >use, so from time to time it takes sbrk(0) - &some_data_variable. >The "&some_data_variable" is simply an arbitrary invariant address in >the data segment. I bet that the author chose "&environ" for the marker >variable to use simply because it's a variable that's usually there. > >Better code: > > extern char * sbrk_initial; > > ... > sbrk_initial = sbrk(0); > ... > > space = sbrk(0) - sbrk_initial; That doesn't seem equivalent to the code that uses environ. I don't understand what the code is actually trying to do, but it seems incredibly ill-advised if it is relying on `environ' being in the heap somewhere. However, if it is safe to make this assumption, I guess we could set "sbrk_initial" in gdb's main() from the third argument to main(). cgf >From chastain@cygnus.com Thu Aug 24 15:16:00 2000 From: Michael Elizabeth Chastain To: cgf@cygnus.com, gdb@sources.redhat.com Subject: Re: 'char **environ' woes with cygwin Date: Thu, 24 Aug 2000 15:16:00 -0000 Message-id: <200008242218.PAA07323@train2.cygnus.com> X-SW-Source: 2000-08/msg00126.html Content-length: 1548 > That doesn't seem equivalent to the code that uses environ. I don't > understand what the code is actually trying to do, but it seems > incredibly ill-advised if it is relying on `environ' being in the heap > somewhere. Cheesy ascii art coming up ... sbrk(0) -> +-------+ | | | heap | | | sbrk(0) -> +-------+ +-------+ | | | | | ... | | ... | | | | | &environ -> |environ| &environ -> |environ| | | | | | ... | | ... | +-------+ +-------+ extern char **environ; extern char **environ; char *lim = (char *) sbrk(0); char *lim = (char *) sbrk(0); space_at_cmd_start = (long) \ long space_now = lim - (char *) &environ; (lim - (char *) &environ); long space_diff = \ space_now - space_at_cmd_start; Note that this code uses &environ. It never uses the *value* of environ, just its address. As far as this code is concerned, "environ" is just a variable that is guaranteed to be in the data segment. If you run gdb as "gdb --statistics", then you will see "space_now" and "space_diff" printed after each command. The initial "startup size" is bogus because &environ can be anywhere in the data segment. "space_now" - "space_at_cmd_start" is equal to the amount of memory that's been allocated from sbrk. It would be simpler to compute this directly and leave &environ out of the picture. It would also eliminate the crufty pointer arithmetic between the brk section and the data section. Michael >From jtc@redback.com Thu Aug 24 15:28:00 2000 From: jtc@redback.com (J.T. Conklin) To: "Benoit MILLOT" Cc: "gdb@sourceware.cygnus.com" Subject: Re: Questions about SDS Target Date: Thu, 24 Aug 2000 15:28:00 -0000 Message-id: <5mog2i8fay.fsf@jtc.redback.com> References: <39A543E9.4C5EBE4F@cstelecom.com> X-SW-Source: 2000-08/msg00127.html Content-length: 1486 >>>>> "Benoit" == Benoit MILLOT writes: Benoit> I have a ppc target with probe and using SDS on UDP or TCP. I Benoit> want to know if it s possible to work with gdb and ddd (on tcp Benoit> or udp) I don't know what if any differences there are in SDS/pROBE+ protocol when it is running over a network connection. If it is the same, and it can be made to operate over a TCP connection, you might be able to connect with `target sds :'. I searched the SDS, ISI, and WindRiver web sites for a pROBE+ protocol specification without luck. In fact, I could not find any technical info on pROBE+ at all. Todd, is there anything I'm missing? Benoit> So i can try with my own stub? Benoit> where can i found a stub on ppc using net connection, (i have already a Benoit> ppc stub for serial line)! Has someone got an example of net stub for Benoit> any target? While there aren't any ppc sample stubs distributed with GDB, it's not difficult to come up with one from those provided. The "hard work" is all in your exception handler, and that's likely to be customized to your target environment. The stub's I/O requirements are very minimal --- just functions to get and put characters. Interfacing this with your network stack is going to be target specific. As I want things to be as simple as possible, I usually do simple serial i/o and use a terminal server to provide network access. --jtc -- J.T. Conklin RedBack Networks >From toddpw@windriver.com Thu Aug 24 16:55:00 2000 From: Todd Whitesel To: jtc@redback.com Cc: benoit.millot@cstelecom.com (Benoit MILLOT), gdb@sourceware.cygnus.com (gdb@sourceware.cygnus.com) Subject: Re: Questions about SDS Target Date: Thu, 24 Aug 2000 16:55:00 -0000 Message-id: <200008242355.QAA23947@alabama.wrs.com> References: <5mog2i8fay.fsf@jtc.redback.com> X-SW-Source: 2000-08/msg00128.html Content-length: 344 > I searched the SDS, ISI, and WindRiver web sites for a pROBE+ protocol > specification without luck. In fact, I could not find any technical > info on pROBE+ at all. Todd, is there anything I'm missing? Dunno, I haven't been merged into their group so I would have to track down somebody and ask. -- Todd Whitesel toddpw @ windriver.com >From Fabrice_Gautier@sdesigns.com Thu Aug 24 17:01:00 2000 From: Fabrice Gautier To: "GDB (E-mail)" Subject: Wrong PC after external interrupt. Date: Thu, 24 Aug 2000 17:01:00 -0000 Message-id: <8AE4B526B977D411841F00A0CC334020052C28@cuz-exchange.sdesigns.net> X-SW-Source: 2000-08/msg00129.html Content-length: 2175 Hi, Sometime (means: too often) when I interrupt my running program with GDB, the instruction pointer is not aligned on an assembler instruction but one byte too far. So when I try to step after that I often get a SIGILL or a SIGSEGV. Example: Running an eCos program, the target is i386-elf, and I'm using insight under Cygwin. Console output: ================ Init device '/dev/ttydiag' Init tty channel: 77D78 Init device '/dev/haldiag' HAL/diag SERIAL init Breakpoint 3, main () at main.c:22 0x63c55 in Cyg_RealTimeClock::dsr (vector=32, count=0, data=590112) at //E/cvswork/ecos/packages/kernel/current/src/common/clock.cxx:913 Program received signal SIGILL, Illegal instruction. 0x63c55 in Cyg_RealTimeClock::dsr (vector=32, count=0, data=590112) at //E/cvswork/ecos/packages/kernel/current/src/common/clock.cxx:913 ================ When I disassemble the Cyg_RealTimeClock::dsr function i have: ============================== Dump of assembler code for function dsr__17Cyg_RealTimeClockUiUiUi: 0x63c40 : push %ebp 0x63c41 : mov %esp,%ebp 0x63c43 : sub $0x8,%esp 0x63c46 : add $0xfffffff8,%esp 0x63c49 : pushl 0xc(%ebp) 0x63c4c : pushl 0x10(%ebp) 0x63c4f : call 0x63804 0x63c54 : add $0xfffffff4,%esp 0x63c57 : push $0x89f40 0x63c5c : call 0x5f3d8 0x63c61 : leave 0x63c62 : ret End of assembler dump. ======================== So you see that the program should have been stopped on 0x63c54 and not 0x63c55 I've experienced many times this problem with eCos. I know at least another person that have the same symptom (SIGILL or SIGSEGV when Continuing an interrupted program) with linux. Thanks -- Fabrice Gautier fabrice_gautier@sdesigns.com