Re: 'char **environ' woes with cygwin

[Eli Zaretskii <eliz@delorie.com>]

> From: Chris Faylor <cgf@cygnus.com>
> 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 <ac131313@cygnus.com>
To: lars brinkhoff <lars@nocrew.org>
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 <cgf@cygnus.com>
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 <cgf@cygnus.com>
>> 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 <dj@delorie.com>
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 <chastain@cygnus.com>
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 <dj@delorie.com>
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 <cgf@cygnus.com>
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 <eliz@delorie.com>
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 <cgf@cygnus.com>
> 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 <chastain@cygnus.com>
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 <dj@delorie.com>
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 <chastain@cygnus.com>
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 <dj@delorie.com>
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 <chastain@cygnus.com>
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  <chastain@redhat.com>
+ 
+ 	* 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  <chastain@redhat.com>
  
          * 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 <sys/ptrace.h>
  #include <machine/reg.h>
  
- 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" <dave@hiauly1.hia.nrc.ca>
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 <Fabrice_Gautier@sdesigns.com>
To: "GDB (E-mail)" <gdb@sourceware.cygnus.com>
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 <shaunj@gray-interfaces.com>
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