From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eli Zaretskii To: gdb@sources.redhat.com Subject: Re: 'char **environ' woes with cygwin Date: Fri, 25 Aug 2000 01:17:00 -0000 Message-id: <200008250817.EAA23502@indy.delorie.com> References: <20000824163339.A9295@cygnus.com> X-SW-Source: 2000-08/msg00130.html > From: Chris Faylor > Date: Thu, 24 Aug 2000 16:33:39 -0400 > > I've recently painfully learned that gdb explicitly declares 'char **environ' > all over the place. I see "extern char **environ", not "char **environ", the only exception being kdb-start.c. > This presents a problem for cygwin since environ is now being imported from > the cygwin DLL. Could you please explain more why is this a problem. I'm afraid I don't know enough about the Cygwin DLL to get the idea. > I've modified configure.in to egrep unistd.h for an environ declaration and > define HAVE_ENVIRON if unistd.h contains a declaration. What about systems where environ is declared in some other header? > The question is, where do I put a: > > #ifndef HAVE_ENVIRON > char **environ; > #endif This would probably break some ports, at least the DJGPP one (unless I'm missing something): the DJGPP startup code includes this definition, but no DJGPP header declares environ. So we will wind up having multiple definitions at link time. I think HAVE_ENVIRON cannot be based on examining the headers alone; you must link a test program which says "extern char **environ" and tries to access environ: if linking succeeds, you can define HAVE_ENVIRON. The program needs to include unistd.h and any other header which might declare environ. >From ac131313@cygnus.com Fri Aug 25 02:53:00 2000 From: Andrew Cagney To: lars brinkhoff Cc: gdb@sourceware.cygnus.com Subject: Re: PDP-10 Date: Fri, 25 Aug 2000 02:53:00 -0000 Message-id: <39A641B6.25EDF1E1@cygnus.com> References: <853djurgax.fsf@junk.nocrew.org> X-SW-Source: 2000-08/msg00131.html Content-length: 873 lars brinkhoff wrote: > > I'm delighted to read, in the first chapter of GDB Internals, that GDB > should be able to run everywhere. Next year, I may be working on a > port to PDP-10, which is a 36-bit word-adressed machine. It's running > the TOPS-20 operating system. > > Does this seem to be possible? It may take a little (lot of) work :-( findvar.c contains: /* Basic byte-swapping routines. GDB has needed these for a long time... All extract a target-format integer at ADDR which is LEN bytes long. */ #if TARGET_CHAR_BIT != 8 || HOST_CHAR_BIT != 8 /* 8 bit characters are a pretty safe assumption these days, so we assume it throughout all these swapping routines. If we had to deal with 9 bit characters, we would need to make len be in bits and would have to re-write these routines... */ you lose #endif Andrew >From cgf@cygnus.com Fri Aug 25 09:35:00 2000 From: Chris Faylor To: gdb@sources.redhat.com Subject: Re: 'char **environ' woes with cygwin Date: Fri, 25 Aug 2000 09:35:00 -0000 Message-id: <20000825123514.A7947@cygnus.com> References: <20000824163339.A9295@cygnus.com> <200008250817.EAA23502@indy.delorie.com> X-SW-Source: 2000-08/msg00132.html Content-length: 2819 On Fri, Aug 25, 2000 at 04:17:21AM -0400, Eli Zaretskii wrote: >> From: Chris Faylor >> Date: Thu, 24 Aug 2000 16:33:39 -0400 >> >> I've recently painfully learned that gdb explicitly declares 'char **environ' >> all over the place. > >I see "extern char **environ", not "char **environ", the only >exception being kdb-start.c. Um. Right. The point is that these are being explicitly declared. >> This presents a problem for cygwin since environ is now being imported from >> the cygwin DLL. > >Could you please explain more why is this a problem. I'm afraid I >don't know enough about the Cygwin DLL to get the idea. Variables and functions imported from a DLL need to include: __declspec(dllimport) So, for Windows, environ needs to be: extern char __declspec(dllimport) **environ; >> I've modified configure.in to egrep unistd.h for an environ declaration and >> define HAVE_ENVIRON if unistd.h contains a declaration. > >What about systems where environ is declared in some other header? Then, I presume that they will continue to work as they always have. The 'extern char **environ' seems to have been in gdb for some time. >> The question is, where do I put a: >> >> #ifndef HAVE_ENVIRON >> char **environ; >> #endif > >This would probably break some ports, at least the DJGPP one (unless >I'm missing something): the DJGPP startup code includes this >definition, but no DJGPP header declares environ. So we will wind up >having multiple definitions at link time. Sorry. I should have added an extern. >I think HAVE_ENVIRON cannot be based on examining the headers alone; >you must link a test program which says "extern char **environ" and >tries to access environ: if linking succeeds, you can define >HAVE_ENVIRON. The program needs to include unistd.h and any other >header which might declare environ. I don't see why. Are you asserting that a unistd.h file will declare 'environ' but will not actually define it in the C library? If that is the case, then how did gdb ever work? AFAICT, gdb relies on the existence of environ. If 'environ' is defined in unistd.h (as it is in cygwin and most of the UNIX systems I surveyed) then the 'extern char **environ;' won't be activated. Otherwise, if there is no declaration in unistd.h then there will be an 'extern char **environ;'. The only thing I can't make determinations of what header files to search on systems for which I don't have access, and it apparently doesn't matter anyway. If this is a problem for some future port, then configure.in will have to be changed. Otherwise, this change should only affect targets which define environ in unistd.h. I was trying to avoid adding an "#ifdef __CYGWIN__" because I hate using system-specific solutions for what is actually a generic (if minor) problem. cgf >From dj@delorie.com Fri Aug 25 09:45:00 2000 From: DJ Delorie To: gdb@sourceware.cygnus.com Subject: Re: 'char **environ' woes with cygwin Date: Fri, 25 Aug 2000 09:45:00 -0000 Message-id: <39A69F60.EDDA1916@delorie.com> References: <20000824163339.A9295@cygnus.com> <200008250817.EAA23502@indy.delorie.com> X-SW-Source: 2000-08/msg00133.html Content-length: 355 Eli Zaretskii wrote: > Could you please explain more why is this a problem. I'm afraid I > don't know enough about the Cygwin DLL to get the idea. Cygwin has something like one of these: #define environ (*(__get_environ())) -or- extern __declspec(dllimport) char **environ; DLLs are better at exporting functions than variables (think DXE). >From chastain@cygnus.com Fri Aug 25 09:56:00 2000 From: Michael Elizabeth Chastain To: dj@delorie.com, gdb@sourceware.cygnus.com Subject: Re: 'char **environ' woes with cygwin Date: Fri, 25 Aug 2000 09:56:00 -0000 Message-id: <200008251658.JAA07299@train2.cygnus.com> X-SW-Source: 2000-08/msg00134.html Content-length: 273 > #define environ (*(__get_environ())) > -or- > extern __declspec(dllimport) char **environ; The "#define environ" macro is going to yield interesting results when various places call "&environ". Then again, maybe none of those places are part of gdb on Cygwin. Michael >From dj@delorie.com Fri Aug 25 10:05:00 2000 From: DJ Delorie To: chastain@cygnus.com Cc: gdb@sourceware.cygnus.com Subject: Re: 'char **environ' woes with cygwin Date: Fri, 25 Aug 2000 10:05:00 -0000 Message-id: <200008251705.NAA21327@envy.delorie.com> References: <200008251658.JAA07299@train2.cygnus.com> X-SW-Source: 2000-08/msg00135.html Content-length: 258 > > #define environ (*(__get_environ())) > > The "#define environ" macro is going to yield interesting results > when various places call "&environ". Then again, maybe none of those > places are part of gdb on Cygwin. I just tested it, and it works fine. >From cgf@cygnus.com Fri Aug 25 10:06:00 2000 From: Chris Faylor To: gdb@sourceware.cygnus.com Subject: Re: 'char **environ' woes with cygwin Date: Fri, 25 Aug 2000 10:06:00 -0000 Message-id: <20000825130553.E8102@cygnus.com> References: <200008251658.JAA07299@train2.cygnus.com> X-SW-Source: 2000-08/msg00136.html Content-length: 468 On Fri, Aug 25, 2000 at 09:58:09AM -0700, Michael Elizabeth Chastain wrote: >> #define environ (*(__get_environ())) >> -or- >> extern __declspec(dllimport) char **environ; > >The "#define environ" macro is going to yield interesting results >when various places call "&environ". Then again, maybe none of those >places are part of gdb on Cygwin. Dunno where that __get_environ comes from but I've already built a cygwin gdb with my proposed changes, of course. cgf >From eliz@delorie.com Fri Aug 25 10:09:00 2000 From: Eli Zaretskii To: gdb@sources.redhat.com Subject: Re: 'char **environ' woes with cygwin Date: Fri, 25 Aug 2000 10:09:00 -0000 Message-id: <200008251709.NAA23981@indy.delorie.com> References: <20000824163339.A9295@cygnus.com> <200008250817.EAA23502@indy.delorie.com> <20000825123514.A7947@cygnus.com> X-SW-Source: 2000-08/msg00137.html Content-length: 1201 > From: Chris Faylor > Date: Fri, 25 Aug 2000 12:35:14 -0400 > > So, for Windows, environ needs to be: > > extern char __declspec(dllimport) **environ; I think some other packages I've seen define a preprocessor symbol DLLIMPORT or some such, whose definition is empty for all platforms except Windows. Of course, your suggestion is okay as well. > >> #ifndef HAVE_ENVIRON > >> char **environ; > >> #endif > > > >This would probably break some ports, at least the DJGPP one (unless > >I'm missing something): the DJGPP startup code includes this > >definition, but no DJGPP header declares environ. So we will wind up > >having multiple definitions at link time. > > Sorry. I should have added an extern. > > >I think HAVE_ENVIRON cannot be based on examining the headers alone; > >you must link a test program which says "extern char **environ" and > >tries to access environ: if linking succeeds, you can define > >HAVE_ENVIRON. The program needs to include unistd.h and any other > >header which might declare environ. > > I don't see why. That's because I thought you *really* wanted to declare "char **environ" instead of "extern char **environ". A misunderstanding. >From chastain@cygnus.com Fri Aug 25 10:14:00 2000 From: Michael Elizabeth Chastain To: chastain@cygnus.com, dj@delorie.com Cc: gdb@sourceware.cygnus.com Subject: Re: 'char **environ' woes with cygwin Date: Fri, 25 Aug 2000 10:14:00 -0000 Message-id: <200008251716.KAA15715@train2.cygnus.com> X-SW-Source: 2000-08/msg00138.html Content-length: 332 > I just tested it, and it works fine. Ok, I am curious. What does "gdb --statistics" look like? In particular, the "Space used" line? (gdb) file /bin/bash Reading symbols from /bin/bash...(no debugging symbols found)...done. Command execution time: 0.010000 Space used: 279516 (+69632 for this command) Michael >From dj@delorie.com Fri Aug 25 10:43:00 2000 From: DJ Delorie To: chastain@cygnus.com Cc: gdb@sourceware.cygnus.com Subject: Re: 'char **environ' woes with cygwin Date: Fri, 25 Aug 2000 10:43:00 -0000 Message-id: <200008251743.NAA21590@envy.delorie.com> References: <200008251716.KAA15715@train2.cygnus.com> X-SW-Source: 2000-08/msg00139.html Content-length: 199 162Mb, but that's not what I meant when I said "it works fine". I meant gcc could handle the syntax fine. If gdb wants a variable in its own data area, it should declare one just for that purpose. >From chastain@cygnus.com Fri Aug 25 11:06:00 2000 From: Michael Elizabeth Chastain To: chastain@cygnus.com, dj@delorie.com Cc: gdb@sourceware.cygnus.com Subject: Re: 'char **environ' woes with cygwin Date: Fri, 25 Aug 2000 11:06:00 -0000 Message-id: <200008251808.LAA22026@train2.cygnus.com> X-SW-Source: 2000-08/msg00140.html Content-length: 588 > 162Mb, but that's not what I meant when I said "it works fine". I > meant gcc could handle the syntax fine. Right. That's what I thought you meant, too. > If gdb wants a variable in its own data area, it should declare one > just for that purpose. Violently agree. gdb would still have the problem of subtracting sbrk(0) - &global. That worked fine in 1980 but addresses in different segments can be relocated anywhere now. It really should be doing: marker_1 = sbrk(0); ... compute ... compute ... marker_2 = sbrk(0); space_used = marker_2 - marker_1; Michael >From dj@delorie.com Fri Aug 25 11:12:00 2000 From: DJ Delorie To: chastain@cygnus.com Cc: gdb@sourceware.cygnus.com Subject: Re: 'char **environ' woes with cygwin Date: Fri, 25 Aug 2000 11:12:00 -0000 Message-id: <200008251812.OAA21955@envy.delorie.com> References: <200008251808.LAA22026@train2.cygnus.com> X-SW-Source: 2000-08/msg00141.html Content-length: 248 > space_used = marker_2 - marker_1; This won't work in DJGPP either. sbrk() allocates memory from wherever the system can find it - it doesn't always show up in contiguous blocks. Not that many DJGPP users care how much memory gdb is using. >From chastain@cygnus.com Fri Aug 25 11:23:00 2000 From: Michael Elizabeth Chastain To: cgf@cygnus.com, chastain@cygnus.com, dj@delorie.com Cc: gdb@sourceware.cygnus.com Subject: Re: 'char **environ' woes with cygwin Date: Fri, 25 Aug 2000 11:23:00 -0000 Message-id: <200008251825.LAA32754@train2.cygnus.com> X-SW-Source: 2000-08/msg00142.html Content-length: 10726 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 === Index: ChangeLog =================================================================== RCS file: /cvs/src/src/gdb/ChangeLog,v retrieving revision 1.626 diff -c -3 -p -r1.626 ChangeLog *** ChangeLog 2000/08/24 10:48:22 1.626 --- ChangeLog 2000/08/25 18:18:45 *************** *** 1,3 **** --- 1,16 ---- + 2000-08-25 Michael Chastain + + * event-top.c (command_handler): Change space reporting to + compare sbrk(0) values directly without using &environ. + * top.c (command_loop): Ditto. + * main.c (captured_main): Remove initial space reporting message. + * gdbserver/low-hppabsd.c : Remove extraneous declaration of environ. + * gdbserver/low-linux.c: Ditto. + * gdbserver/low-nbsd.c: Ditto. + * gdbserver/low-sparc.c: Ditto. + * gdbserver/low-sun3.c: Ditto. + * inftarg.c: Ditto. + 2000-08-20 Michael Chastain * remote.c (read_frame): Handle SERIAL_TIMEOUT while reading Index: event-top.c =================================================================== RCS file: /cvs/src/src/gdb/event-top.c,v retrieving revision 1.8 diff -c -3 -p -r1.8 event-top.c *** event-top.c 2000/07/30 01:48:25 1.8 --- event-top.c 2000/08/25 18:18:45 *************** command_handler (char *command) *** 475,481 **** struct continuation_arg *arg2; long time_at_cmd_start; #ifdef HAVE_SBRK ! long space_at_cmd_start = 0; #endif extern int display_time; extern int display_space; --- 475,481 ---- struct continuation_arg *arg2; long time_at_cmd_start; #ifdef HAVE_SBRK ! char * sbrk_at_cmd_start = (char *) 0; #endif extern int display_time; extern int display_space; *************** command_handler (char *command) *** 505,514 **** if (display_space) { #ifdef HAVE_SBRK ! extern char **environ; ! char *lim = (char *) sbrk (0); ! ! space_at_cmd_start = (long) (lim - (char *) &environ); #endif } --- 505,511 ---- if (display_space) { #ifdef HAVE_SBRK ! sbrk_at_cmd_start = (char *) sbrk (0); #endif } *************** command_handler (char *command) *** 526,532 **** arg1->next = arg2; arg2->next = NULL; arg1->data.integer = time_at_cmd_start; ! arg2->data.integer = space_at_cmd_start; add_continuation (command_line_handler_continuation, arg1); } --- 523,529 ---- arg1->next = arg2; arg2->next = NULL; arg1->data.integer = time_at_cmd_start; ! arg2->data.pointer = sbrk_at_cmd_start; add_continuation (command_line_handler_continuation, arg1); } *************** command_handler (char *command) *** 549,563 **** if (display_space) { #ifdef HAVE_SBRK ! extern char **environ; ! char *lim = (char *) sbrk (0); ! long space_now = lim - (char *) &environ; ! long space_diff = space_now - space_at_cmd_start; ! ! printf_unfiltered ("Space used: %ld (%c%ld for this command)\n", ! space_now, ! (space_diff >= 0 ? '+' : '-'), ! space_diff); #endif } } --- 546,553 ---- if (display_space) { #ifdef HAVE_SBRK ! printf_unfiltered ("Space used for this command: %ld\n", ! sbrk(0) - sbrk_at_cmd_start); #endif } } *************** command_line_handler_continuation (struc *** 573,579 **** extern int display_space; long time_at_cmd_start = arg->data.longint; ! long space_at_cmd_start = arg->next->data.longint; bpstat_do_actions (&stop_bpstat); /*do_cleanups (old_chain); *//*?????FIXME????? */ --- 563,569 ---- extern int display_space; long time_at_cmd_start = arg->data.longint; ! char * sbrk_at_cmd_start = arg->next->data.pointer; bpstat_do_actions (&stop_bpstat); /*do_cleanups (old_chain); *//*?????FIXME????? */ *************** command_line_handler_continuation (struc *** 588,602 **** if (display_space) { #ifdef HAVE_SBRK ! extern char **environ; ! char *lim = (char *) sbrk (0); ! long space_now = lim - (char *) &environ; ! long space_diff = space_now - space_at_cmd_start; ! ! printf_unfiltered ("Space used: %ld (%c%ld for this command)\n", ! space_now, ! (space_diff >= 0 ? '+' : '-'), ! space_diff); #endif } } --- 578,585 ---- if (display_space) { #ifdef HAVE_SBRK ! printf_unfiltered ("Space used for this command: %ld\n", ! sbrk(0) - sbrk_at_cmd_start); #endif } } Index: inftarg.c =================================================================== RCS file: /cvs/src/src/gdb/inftarg.c,v retrieving revision 1.4 diff -c -3 -p -r1.4 inftarg.c *** inftarg.c 2000/07/30 01:48:25 1.4 --- inftarg.c 2000/08/25 18:18:45 *************** int child_thread_alive (int); *** 91,98 **** static void init_child_ops (void); - extern char **environ; - struct target_ops child_ops; int child_suppress_run = 0; /* Non-zero if inftarg should pretend not to --- 91,96 ---- Index: main.c =================================================================== RCS file: /cvs/src/src/gdb/main.c,v retrieving revision 1.3 diff -c -3 -p -r1.3 main.c *** main.c 2000/05/28 01:12:28 1.3 --- main.c 2000/08/25 18:18:45 *************** extern int gdbtk_test (char *); *** 685,691 **** END_PROGRESS (argv[0]); ! /* Show time and/or space usage. */ if (display_time) { --- 685,691 ---- END_PROGRESS (argv[0]); ! /* Show time usage. */ if (display_time) { *************** extern int gdbtk_test (char *); *** 693,709 **** printf_unfiltered ("Startup time: %ld.%06ld\n", init_time / 1000000, init_time % 1000000); - } - - if (display_space) - { - #ifdef HAVE_SBRK - extern char **environ; - char *lim = (char *) sbrk (0); - - printf_unfiltered ("Startup size: data size %ld\n", - (long) (lim - (char *) &environ)); - #endif } /* The default command loop. --- 693,698 ---- Index: top.c =================================================================== RCS file: /cvs/src/src/gdb/top.c,v retrieving revision 1.17 diff -c -3 -p -r1.17 top.c *** top.c 2000/08/01 05:06:03 1.17 --- top.c 2000/08/25 18:18:45 *************** command_loop (void) *** 1559,1565 **** int stdin_is_tty = ISATTY (stdin); long time_at_cmd_start; #ifdef HAVE_SBRK ! long space_at_cmd_start = 0; #endif extern int display_time; extern int display_space; --- 1559,1565 ---- int stdin_is_tty = ISATTY (stdin); long time_at_cmd_start; #ifdef HAVE_SBRK ! char * sbrk_at_cmd_start = (char *) 0; #endif extern int display_time; extern int display_space; *************** command_loop (void) *** 1601,1610 **** if (display_space) { #ifdef HAVE_SBRK ! extern char **environ; ! char *lim = (char *) sbrk (0); ! ! space_at_cmd_start = (long) (lim - (char *) &environ); #endif } --- 1601,1607 ---- if (display_space) { #ifdef HAVE_SBRK ! sbrk_at_cmd_start = (char *) sbrk (0); #endif } *************** command_loop (void) *** 1624,1638 **** if (display_space) { #ifdef HAVE_SBRK ! extern char **environ; ! char *lim = (char *) sbrk (0); ! long space_now = lim - (char *) &environ; ! long space_diff = space_now - space_at_cmd_start; ! ! printf_unfiltered ("Space used: %ld (%c%ld for this command)\n", ! space_now, ! (space_diff >= 0 ? '+' : '-'), ! space_diff); #endif } } --- 1621,1628 ---- if (display_space) { #ifdef HAVE_SBRK ! printf_unfiltered ("Space used for this command: %ld\n", ! sbrk(0) - sbrk_at_cmd_start); #endif } } Index: gdbserver/low-hppabsd.c =================================================================== RCS file: /cvs/src/src/gdb/gdbserver/low-hppabsd.c,v retrieving revision 1.2 diff -c -3 -p -r1.2 low-hppabsd.c *** low-hppabsd.c 2000/07/30 01:48:28 1.2 --- low-hppabsd.c 2000/08/25 18:18:45 *************** char buf2[MAX_REGISTER_RAW_SIZE]; *** 47,53 **** #include #include - extern char **environ; extern int errno; extern int inferior_pid; void quit (), perror_with_name (); --- 47,52 ---- Index: gdbserver/low-linux.c =================================================================== RCS file: /cvs/src/src/gdb/gdbserver/low-linux.c,v retrieving revision 1.4 diff -c -3 -p -r1.4 low-linux.c *** low-linux.c 2000/07/30 01:48:28 1.4 --- low-linux.c 2000/08/25 18:18:45 *************** char buf2[MAX_REGISTER_RAW_SIZE]; *** 53,59 **** #define PTRACE_XFER_TYPE int #endif - extern char **environ; extern int errno; extern int inferior_pid; void quit (), perror_with_name (); --- 53,58 ---- Index: gdbserver/low-nbsd.c =================================================================== RCS file: /cvs/src/src/gdb/gdbserver/low-nbsd.c,v retrieving revision 1.3 diff -c -3 -p -r1.3 low-nbsd.c *** low-nbsd.c 2000/07/30 01:48:28 1.3 --- low-nbsd.c 2000/08/25 18:18:45 *************** char buf2[MAX_REGISTER_RAW_SIZE]; *** 42,48 **** extern int sys_nerr; // extern char **sys_errlist; - extern char **environ; extern int inferior_pid; void quit (), perror_with_name (); --- 42,47 ---- Index: gdbserver/low-sparc.c =================================================================== RCS file: /cvs/src/src/gdb/gdbserver/low-sparc.c,v retrieving revision 1.2 diff -c -3 -p -r1.2 low-sparc.c *** low-sparc.c 2000/07/30 01:48:28 1.2 --- low-sparc.c 2000/08/25 18:18:45 *************** char buf2[MAX_REGISTER_RAW_SIZE]; *** 52,58 **** extern int sys_nerr; extern char **sys_errlist; - extern char **environ; extern int errno; extern int inferior_pid; void quit (), perror_with_name (); --- 52,57 ---- Index: gdbserver/low-sun3.c =================================================================== RCS file: /cvs/src/src/gdb/gdbserver/low-sun3.c,v retrieving revision 1.2 diff -c -3 -p -r1.2 low-sun3.c *** low-sun3.c 2000/07/30 01:48:28 1.2 --- low-sun3.c 2000/08/25 18:18:45 *************** char buf2[MAX_REGISTER_RAW_SIZE]; *** 49,55 **** extern int sys_nerr; extern char **sys_errlist; - extern char **environ; extern int errno; extern int inferior_pid; void quit (), perror_with_name (); --- 49,54 ---- >From dave@hiauly1.hia.nrc.ca Fri Aug 25 12:14:00 2000 From: "John David Anglin" To: gdb@sourceware.cygnus.com Subject: somread.c:480: invalid lvalue in assignment Date: Fri, 25 Aug 2000 12:14:00 -0000 Message-id: <200008251914.PAA11706@hiauly1.hia.nrc.ca> X-SW-Source: 2000-08/msg00143.html Content-length: 951 Building the current CVS version of gdb under hpux 10.20 fails here: gcc -c -O3 -D__HP_CURSES -I. -I. -I./config -DHAVE_CONFIG_H -I./../include/opcode -I./../readline/.. -I../bfd -I./../bfd -I./../include -I../intl -I./../intl -Wimplicit -Wreturn-type -Wcomment -Wtrigraphs -Wformat -Wparentheses -Wpointer-arith -Wuninitialized somread.c somread.c: In function `som_symfile_read': somread.c:362: warning: implicit declaration of function `init_import_symbols' somread.c: In function `som_symfile_offsets': somread.c:480: invalid lvalue in assignment make[1]: *** [somread.o] Error 1 make[1]: Leaving directory `/xxx/gnu/gdb-5.0/gdb' make: *** [all-gdb] Error 2 The offending line is: for (i = 0; i < SECT_OFF_MAX; i++) ANOFFSET (objfile->section_offsets, i) = text_addr; Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) >From Fabrice_Gautier@sdesigns.com Fri Aug 25 12:18:00 2000 From: Fabrice Gautier To: "GDB (E-mail)" Subject: RE: Multi-thread debugging with eCos on i386 pc platform Date: Fri, 25 Aug 2000 12:18:00 -0000 Message-id: <8AE4B526B977D411841F00A0CC334020052C2C@cuz-exchange.sdesigns.net> X-SW-Source: 2000-08/msg00144.html Content-length: 1451 Hi, The problem seems that GDB doesn't succeed in switching frame stack to access threads information. More precisely, in the switch_to_thread function we have: select_frame (get_current_frame (), 0); that doesn't select the correct frame. Even more deeper, this is the read_fp() function that at some point always return the same frame pointer (that is the one from the running thread) Can someone tell me how does read_fp() should work in order to get the correct frame pointer? There may be an bug in eCos (see a discussion about that on the eCos mailing list archives) and I would like to know at wich point in this process there is an interaction between gdb and the target. Thank you -- Fabrice Gautier fabrice_gautier@sdesigns.com > -----Original Message----- > From: Fabrice Gautier [ mailto:Fabrice_Gautier@sdesigns.com ] > Sent: Wednesday, August 23, 2000 12:54 PM > To: GDB (E-mail) > Subject: Multi-thread debugging with eCos on i386 pc platform > > > Hi, > > I'm trying to debug a multithreaded eCos program. I'm using gdb 5 for > cygwin. > > I can see the threads created but I can't see where is the instruction > pointer for each thread nor can i change thread. > > The problem may be in the eCos stub code but I can't find > where and I would > like to know from what struture or from where does gdb know > the position of > each thread? > > Thanks you > > -- > Fabrice Gautier > fabrice_gautier@sdesigns.com > >From shaunj@gray-interfaces.com Fri Aug 25 12:21:00 2000 From: Shaun Jackman To: gdb@sources.redhat.com Subject: ARM simulator - memory alignment Date: Fri, 25 Aug 2000 12:21:00 -0000 Message-id: <00082513202400.00275@ed> X-SW-Source: 2000-08/msg00145.html Content-length: 359 Is it possible to get the ARM simulator to stop a "continue" and generate a warning if the simulated ARM ever attemps an unaligned memory access? This would be very useful for porting apps from a target where alignment isn't an issue. something like... (gdb) c Continuing. unaligned access, main () at main.c:8 8 int i = *p; (gdb) Thanks, Shaun