Mirror of the gdb mailing list
 help / color / mirror / Atom feed
* 'char **environ' woes with cygwin
@ 2000-08-24 13:34 Chris Faylor
  2000-08-25  1:17 ` Eli Zaretskii
  0 siblings, 1 reply; 3+ messages in thread
From: Chris Faylor @ 2000-08-24 13:34 UTC (permalink / raw)
  To: gdb

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 <chastain@cygnus.com>
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
<chastain@redhat.com>
"love without fear"
From cgf@cygnus.com Thu Aug 24 14:52:00 2000
From: Chris Faylor <cgf@cygnus.com>
To: Michael Elizabeth Chastain <chastain@cygnus.com>
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 <chastain@cygnus.com>
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" <benoit.millot@cstelecom.com>
Cc: "gdb@sourceware.cygnus.com" <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 <benoit.millot@cstelecom.com> 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 <host>:<port>'.

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 <toddpw@windriver.com>
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 <Fabrice_Gautier@sdesigns.com>
To: "GDB (E-mail)" <gdb@sourceware.cygnus.com>
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 <dsr__17Cyg_RealTimeClockUiUiUi>:	push   %ebp
0x63c41 <dsr__17Cyg_RealTimeClockUiUiUi+1>:	mov    %esp,%ebp
0x63c43 <dsr__17Cyg_RealTimeClockUiUiUi+3>:	sub    $0x8,%esp
0x63c46 <dsr__17Cyg_RealTimeClockUiUiUi+6>:	add    $0xfffffff8,%esp
0x63c49 <dsr__17Cyg_RealTimeClockUiUiUi+9>:	pushl  0xc(%ebp)
0x63c4c <dsr__17Cyg_RealTimeClockUiUiUi+12>:	pushl  0x10(%ebp)
0x63c4f <dsr__17Cyg_RealTimeClockUiUiUi+15>:	call   0x63804
<tick__11Cyg_CounterUi>
0x63c54 <dsr__17Cyg_RealTimeClockUiUiUi+20>:	add    $0xfffffff4,%esp
0x63c57 <dsr__17Cyg_RealTimeClockUiUiUi+23>:	push   $0x89f40
0x63c5c <dsr__17Cyg_RealTimeClockUiUiUi+28>:	call   0x5f3d8
<timeslice__28Cyg_Scheduler_Implementation>
0x63c61 <dsr__17Cyg_RealTimeClockUiUiUi+33>:	leave  
0x63c62 <dsr__17Cyg_RealTimeClockUiUiUi+34>:	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 



^ permalink raw reply	[flat|nested] 3+ messages in thread
end of thread, other threads:[~2000-08-25 12:40 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <200008251825.LAA32754@train2.cygnus.com>
2000-08-25 12:40 ` 'char **environ' woes with cygwin Chris Faylor
2000-08-24 13:34 Chris Faylor
2000-08-25  1:17 ` Eli Zaretskii

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox