* '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
* Re: 'char **environ' woes with cygwin
2000-08-24 13:34 'char **environ' woes with cygwin Chris Faylor
@ 2000-08-25 1:17 ` Eli Zaretskii
0 siblings, 0 replies; 3+ messages in thread
From: Eli Zaretskii @ 2000-08-25 1:17 UTC (permalink / raw)
To: gdb
> 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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: 'char **environ' woes with cygwin
[not found] <200008251825.LAA32754@train2.cygnus.com>
@ 2000-08-25 12:40 ` Chris Faylor
0 siblings, 0 replies; 3+ messages in thread
From: Chris Faylor @ 2000-08-25 12:40 UTC (permalink / raw)
To: gdb
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 21756 bytes --]
On Fri, Aug 25, 2000 at 11:25:32AM -0700, 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?
It doesn't really affect me. I proposed eliminating the use of 'extern
char **environ' throughout gdb. Your patch removes the extern... just
like mine does, so it's fine with me.
I do agree that we shouldn't be using environ like this, though, so
eliminating it is a good idea.
However, I tried your patch and it failed here on cygwin:
i686-pc-cygwin-gcc -c -g -O2 -I. -I/cygnus/src/sourceware/gdb -I/cygnus/src/sourceware/gdb/config -DHAVE_CONFIG_H -I/cygnus/src/sourceware/gdb/../include/opcode -I/cygnus/src/sourceware/gdb/../readline/.. -I../bfd -I/cygnus/src/sourceware/gdb/../bfd -I/cygnus/src/sourceware/gdb/../include -I../intl -I/cygnus/src/sourceware/gdb/../intl -DGDBTK -Wimplicit -Wreturn-type -Wcomment -Wtrigraphs -Wformat -Wparentheses -Wpointer-arith -Wuninitialized /cygnus/src/sourceware/gdb/event-top.c
/cygnus/src/sourceware/gdb/event-top.c: In function `command_handler':
/cygnus/src/sourceware/gdb/event-top.c:550: invalid operands to binary -
/cygnus/src/sourceware/gdb/event-top.c: In function `command_line_handler_continuation':
/cygnus/src/sourceware/gdb/event-top.c:582: invalid operands to binary -
Coercing 'sbrk(0)' to '(char *) sbrk(0)' fixed this.
cgf
From Fabrice_Gautier@sdesigns.com Fri Aug 25 12:49:00 2000
From: Fabrice Gautier <Fabrice_Gautier@sdesigns.com>
To: 'Daniel Berlin' <dan@cgsoftware.com>
Cc: "GDB (E-mail)" <gdb@sourceware.cygnus.com>
Subject: RE: Multi-thread debugging with eCos on i386 pc platform
Date: Fri, 25 Aug 2000 12:49:00 -0000
Message-id: <8AE4B526B977D411841F00A0CC334020052C2D@cuz-exchange.sdesigns.net>
X-SW-Source: 2000-08/msg00148.html
Content-length: 421
> -----Original Message-----
> From: Daniel Berlin [ mailto:dan@cgsoftware.com ]
> Subject: RE: Multi-thread debugging with eCos on i386 pc platform
>
> Yup, i noticed this porting to BeOS.
> I have fixes for it.
>
> > [...] Even more deeper, this is the read_fp() function that at
>
> I fixed this too.
Cooool...
And where are the fixes available?
Thank you.
--
Fabrice Gautier
fabrice_gautier@sdesigns.com
From ezannoni@cygnus.com Fri Aug 25 12:57:00 2000
From: Elena Zannoni <ezannoni@cygnus.com>
To: "John David Anglin" <dave@hiauly1.hia.nrc.ca>
Cc: gdb@sourceware.cygnus.com
Subject: Re: somread.c:480: invalid lvalue in assignment
Date: Fri, 25 Aug 2000 12:57:00 -0000
Message-id: <14758.53158.949196.765727@kwikemart.cygnus.com>
References: <200008251914.PAA11706@hiauly1.hia.nrc.ca>
X-SW-Source: 2000-08/msg00149.html
Content-length: 1346
John David Anglin writes:
> 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)
Oops, my fault. Thanks for pointing it out.
I'll commit a patch asap.
In the meantime you should change the line like this:
- ANOFFSET (objfile->section_offsets, i) = text_addr;
+ (objfile->section_offsets)->offsets[i] = text_addr;
I'll get a proper patch in before the end of the day.
Elena
From dave@hiauly1.hia.nrc.ca Fri Aug 25 17:32:00 2000
From: "John David Anglin" <dave@hiauly1.hia.nrc.ca>
To: ezannoni@cygnus.com (Elena Zannoni)
Cc: gdb@sourceware.cygnus.com
Subject: Re: somread.c:480: invalid lvalue in assignment
Date: Fri, 25 Aug 2000 17:32:00 -0000
Message-id: <200008260032.UAA12611@hiauly1.hia.nrc.ca>
References: <14758.53158.949196.765727@kwikemart.cygnus.com>
X-SW-Source: 2000-08/msg00150.html
Content-length: 1685
Elena,
In case you didn't notice, the same problem occurs in somsolib.c and maybe
in other places.
Regards,
Dave
>
> John David Anglin writes:
> > 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)
>
> Oops, my fault. Thanks for pointing it out.
> I'll commit a patch asap.
> In the meantime you should change the line like this:
>
> - ANOFFSET (objfile->section_offsets, i) = text_addr;
> + (objfile->section_offsets)->offsets[i] = text_addr;
>
> I'll get a proper patch in before the end of the day.
>
> Elena
>
--
J. David Anglin dave.anglin@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
From ezannoni@cygnus.com Fri Aug 25 17:42:00 2000
From: Elena Zannoni <ezannoni@cygnus.com>
To: "John David Anglin" <dave@hiauly1.hia.nrc.ca>
Cc: ezannoni@cygnus.com (Elena Zannoni), gdb@sourceware.cygnus.com
Subject: Re: somread.c:480: invalid lvalue in assignment
Date: Fri, 25 Aug 2000 17:42:00 -0000
Message-id: <14759.4732.282394.564068@kwikemart.cygnus.com>
References: <14758.53158.949196.765727@kwikemart.cygnus.com> <200008260032.UAA12611@hiauly1.hia.nrc.ca>
X-SW-Source: 2000-08/msg00151.html
Content-length: 1972
John David Anglin writes:
> Elena,
>
> In case you didn't notice, the same problem occurs in somsolib.c and maybe
> in other places.
>
> Regards,
> Dave
> >
Sorry, the culprit is this patch:
http://sources.redhat.com/ml/gdb-patches/2000-08/msg00139.html
Will fix asap.
Elena
> > John David Anglin writes:
> > > 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)
> >
> > Oops, my fault. Thanks for pointing it out.
> > I'll commit a patch asap.
> > In the meantime you should change the line like this:
> >
> > - ANOFFSET (objfile->section_offsets, i) = text_addr;
> > + (objfile->section_offsets)->offsets[i] = text_addr;
> >
> > I'll get a proper patch in before the end of the day.
> >
> > Elena
> >
>
>
> --
> J. David Anglin dave.anglin@nrc.ca
> National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
From kettenis@wins.uva.nl Sun Aug 27 08:35:00 2000
From: Mark Kettenis <kettenis@wins.uva.nl>
To: gdb@sourceware.cygnus.com
Subject: Linux threads support
Date: Sun, 27 Aug 2000 08:35:00 -0000
Message-id: <200008271535.e7RFZZc04890@delius.kettenis.local>
X-SW-Source: 2000-08/msg00152.html
Content-length: 2066
After concluding that the current Linux threads support is pretty much
broken beyond repair, I have been working on a reimplementation, which
consists of two layers:
1. A Linux LWP layer. This presents a group of Linux processes (which
are assumed to share a single address space) to GDB as a
multi-threaded process. It should be useful on its right, i.e. for
programs that don't use the LinuxThreads library, but the clone()
system call directly.
2. A generic libthread_db layer (contains only a few Linux-specific
hooks). This contains much code from Michael Snyder's lin-thread.c
module, but since most of the Linux-specific stuff is factored out
into the Linux LWP layer, it should be possible to make it usable
for Solaris without much problems.
The old LinuxThreads support contained linux-thread.c isn't there
anymore. It shouldn't be too difficult to reimplement it, but I'm not
eager to do so. Supporting one threads debugging module is bad enough.
Anyway, I'm now at a point where I think it functions better than the
current threads support, and I really need to get it more widely
tested. I see two possibilities:
1. Post a patch and hope that people take the trouble of applying it.
2. Put the new code directly in the CVS (possible in a seperate
branch).
I think option 1 is doomed to fail. For option 2 I'd like some
opinions (especially from the maintainers of the various Linux ports):
* Should the stuff be checked in on a seperate branch?
* How important is support for older Linux systems (pre-libthread_db,
i.e. pre glibc-2.1.3) give the fact that GDB has never had any
satisfactory threads support for these systems, and older versions
of the LinuxThreads library contain many critical bugs?
* Who needs to review this stuff? Michael Snyder is listed as the
threads maintainer and did the origional integration/implementation
of the Linux threads support. However, he seems to be pretty busy,
and he once told me he isn't too familiar with the peculiarities of
the Linux stuff.
Mark
From kevinb@cygnus.com Sun Aug 27 09:06:00 2000
From: Kevin Buettner <kevinb@cygnus.com>
To: Mark Kettenis <kettenis@wins.uva.nl>, gdb@sourceware.cygnus.com
Subject: Re: Linux threads support
Date: Sun, 27 Aug 2000 09:06:00 -0000
Message-id: <1000827160616.ZM14856@ocotillo.lan>
References: <200008271535.e7RFZZc04890@delius.kettenis.local> <kettenis@wins.uva.nl>
X-SW-Source: 2000-08/msg00153.html
Content-length: 1384
On Aug 27, 5:35pm, Mark Kettenis wrote:
> Anyway, I'm now at a point where I think it functions better than the
> current threads support, and I really need to get it more widely
> tested. I see two possibilities:
>
> 1. Post a patch and hope that people take the trouble of applying it.
>
> 2. Put the new code directly in the CVS (possible in a seperate
> branch).
>
> I think option 1 is doomed to fail. For option 2 I'd like some
> opinions (especially from the maintainers of the various Linux ports):
I agree with you regarding option 1. For option 2, I think you should
just check in your changes on the trunk. It's scary, but I don't
think it'll get tested otherwise.
> * Should the stuff be checked in on a seperate branch?
As noted above, I don't think a separate branch would be advisable.
In fact, I think it's be more likely that people would test your
changes if you posted a patch than if you created a branch with your
changes.
> * How important is support for older Linux systems (pre-libthread_db,
> i.e. pre glibc-2.1.3) give the fact that GDB has never had any
> satisfactory threads support for these systems, and older versions
> of the LinuxThreads library contain many critical bugs?
I don't see any need to offer thread support for older Linux systems.
gdb should still be able to debug non-threaded programs on these
systems though.
From listasagosto@waycom.com.ar Sun Aug 27 10:40:00 2000
From: listasagosto@waycom.com.ar
To: gdb@sourceware.cygnus.com
Subject: Despues no diga que no le avisamos !!
Date: Sun, 27 Aug 2000 10:40:00 -0000
Message-id: <219a8cc98cbff416ec0fdb7f4af65879@NO-ID-FOUND.mhonarc.org>
X-SW-Source: 2000-08/msg00154.html
Content-length: 5154
* * * * * I N C R E I B L E ! ! ! * * * * *
¿SabÃa ud. que cuando envÃa e-mails masivos
promocionando un producto o servicio,
estadÃsticamente recibe una respuesta positiva del 3
a 6 por mil ?
¿Le vendrÃa bien a usted incorporar de 270 a 540
nuevos clientes ?
¿Sabe que su única inversión para lograrlo es de
$45, y que no necesita conocimientos previos sobre
el tema?
Si usted siempre quiso incursionar en el comercio
electrónico y no sabe cómo hacerlo, nosotros le
brindamos TODAS las herramientas necesarias para que
pueda lograrlo.
¿Por qué usted no puede ganar dinero como tantas
otras personas utilizando esta poderosa herramienta
?
Antes de continuar, queremos hacer hincapié en un
punto muy importante:
LAS BASES DE DATOS QUE COMERCIALIZAMOS SON NUEVAS ,o
sea, actualizadas (“FRESCAS” COMO SE LAS CONOCE EN
LA JERGA).
NO SE DEJE ENGAÑAR, Y NO COMPRE BASES DE DATOS VIEJAS QUE NO SIRVEN PARA
NADA!
ESTAS MISMAS BASES QUE NOSOTROS COMERCIALIZAMOS, OTROS LAS VENDEN POR $100
O $130 !!!
Si usted trabaja con bases de datos que no están
actualizadas, como las que se acostumbran a
comercializar por este medio, tendrá una efectividad
muchÃsimo menor.
¿Qué le ofrecemos para que usted pueda lograr su
objetivo?
Un CD-ROM con:
1. Un programa muy sencillo y útil para que pueda
realizar el envÃo masivo de e-mails, y llevar
un control de los mails enviados, los pedidos
de información y todo lo necesario para que
usted no tenga que preocuparse por nada, mas
que para presionar un par de teclas. Si utiliza
un modem de 56K, este programa enviará unos
16000 e-mails “PERSONALIZADOS” por hora!!!
2. Las instrucciones en castellano para utilizar
el programa.
3. Otro programa (secundario) que le permitirá
ordenar las direcciones de e-mail.
4. Y lo mas importante, nuestra base de datos
“ACTUALIZADA”, “NUEVA” y “VIRGEN” de mas de 500
mil direcciones de e-mail. Muchas de ellas
están acompañadas del nombre del titular par
poder personalizar cada e-mail (esto se hace en
forma automática).
Están todas ordenadas y separadas por región
(Capital Federal, Gran Buenos Aires Norte, Sur y
Oeste, Provincia de Buenos Aires, Interior del
paÃs, etc.)
OBSEQUIO: agregamos 850 mil
direcciones de e-mail de Latinoamérica y
España, también ordenadas y clasificadas
por paÃs (Brasil, Bolivia, Chile,
Colombia, Costa Rica, Cuba, Dominicana,
Ecuador, España, Guatemala, Honduras,
México, Nicaragua, Panamá, Paraguay, Perú,
Puerto Rico, Salvador, Uruguay y
Venezuela).
*******************************************
Este mismo paquete es vendido por la competencia a $100
Y para cerrar la promoción, proponemos una oferta
especial por todo el paquete de $39 válida
únicamente para pedidos recibidos antes del
MARTES 28 de Agosto!!! (inclusive, último dÃa)
* * * * * $ 3 9 * * * * *
* * * * * I N C R E I B L E ! ! ! * * * * *
********************************************
Los CDs serán enviados por Correo Argentino, y
abonados por la modalidad contrarreembolso
(agregando $3).
Para hacer un pedido NO responda a este e-mail!
Los pedidos serán recibidos PREFERENTEMENTE por
teléfono al
15-4036-2573 (de 13 a 20 hs.)
TODOS LOS DIAS
INCLUYENDO FINES DE SEMANA Y FERIADOS
o a argentinaagosto@uol.com.ar
indicando su nombre, teléfono de contacto y
dirección exacta y completa (incluyendo código
postal).
--------------------------------------------------------------------------
Este mensaje se envÃa con la complacencia de la nueva legislación sobre
correo electrónico: Por sección 301, parrafo (a)(2)(C) de S.1618. Bajo el
decreto S.1618 titulo 3ro. Aprobado por el 105 congreso base de las
normativas Internacionales sobre SPAM, este E-mail no podrá ser
considerado SPAM mientras incluya una forma de ser removido.
Este mensaje será enviado por única vez, y si desea ser removido de
nuestra base de datos en forma definitiva, responda a este e-mail
indicando
"Remover" en el subject.
From lars@nocrew.org Tue Aug 29 04:48:00 2000
From: lars brinkhoff <lars@nocrew.org>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: PDP-10
Date: Tue, 29 Aug 2000 04:48:00 -0000
Message-id: <8566oke1a7.fsf@junk.nocrew.org>
References: <853djurgax.fsf@junk.nocrew.org> <39A641B6.25EDF1E1@cygnus.com>
X-SW-Source: 2000-08/msg00155.html
Content-length: 1023
Andrew Cagney <ac131313@cygnus.com> writes:
> 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
I'm willing to give it a try. Would it be acceptable for inclusion in
GDB?
From Fabrice_Gautier@sdesigns.com Tue Aug 29 15:37:00 2000
From: Fabrice Gautier <Fabrice_Gautier@sdesigns.com>
To: "GDB (E-mail)" <gdb@sourceware.cygnus.com>
Subject: GDB internals: thread infos
Date: Tue, 29 Aug 2000 15:37:00 -0000
Message-id: <8AE4B526B977D411841F00A0CC334020052C33@cuz-exchange.sdesigns.net>
X-SW-Source: 2000-08/msg00156.html
Content-length: 1199
Hi,
I'm trying to understand how gdb retrieve thread information, thread frame
and thread pc.
I started in the info_threads_command function.
So there in order to retrieve thread $pc it call the
functionswitch_to_thread which I presume do only a frame switch.
So here is this function:
static void
switch_to_thread (pid)
int pid;
{
if (pid == inferior_pid)
return;
inferior_pid = pid;
flush_cached_frames ();
registers_changed ();
stop_pc = read_pc ();
select_frame (get_current_frame (), 0);
}
I assume that inferior_pid should contain the thread id of the current
selected thread.
Then I have a few questions:
What does the registers_changed() should do and where is it defined?
Which pc does the read_pc command should return? The one of the inferior_pid
thread ?
Then in the get_current_frame function, it ends up calling:
current_frame = create_new_frame (read_fp (), read_pc ());
What frame pointer should read_fp() return? I presume this is the one of the
thread we are switching too. right?
idem for read_pc(). But at what point is there an interaction with the
target to get effectively those values.
--
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 --
2000-08-24 13:34 'char **environ' woes with cygwin Chris Faylor
2000-08-25 1:17 ` Eli Zaretskii
[not found] <200008251825.LAA32754@train2.cygnus.com>
2000-08-25 12:40 ` Chris Faylor
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox