* Re: Should GCC tell GDB about its optimizations?
[not found] <38C051C3.260D666B@apple.com>
@ 2000-03-03 17:03 ` Timothy J. Wood
2000-03-04 3:03 ` Stephane Carrez
1 sibling, 0 replies; 3+ messages in thread
From: Timothy J. Wood @ 2000-03-03 17:03 UTC (permalink / raw)
To: shebs; +Cc: gdb, gcc
From: Stan Shebs <shebs@apple.com>
>But today, the result is just lame; hackers
t>rying to debug get lots of squirrelly behavior from GDB.
What sort of squirrelly behavior are you talking about exactly? If it is
just the typical problem where GCC reuses register's and stack locations
when variables lifetime's are over, this would seem like a gdb problem, not
a GCC problem. gdb should be able to look at the debugging info and notice
that the variable you are trying to print is not currently live. It could
then print out a message that says so, rather than printing out whatever
random crud happens to be at the place of the variable's death.
Of course, I only know about the stabs format (and only as used on MacOS X
Server/MacOS X) -- this format seems to provide enough information to
implement this behavior in gdb. I would assume that other debug info
formats would have the same information.
Is there some other behavior that isn't covered by the above?
-tim
From brg@sartre.dgate.ORG Fri Mar 03 17:38:00 2000
From: "Brian R. Gaeke" <brg@sartre.dgate.ORG>
To: Stan Shebs <shebs@apple.com>
Cc: gcc@gcc.gnu.org, gdb@sourceware.cygnus.com
Subject: Re: Should GCC tell GDB about its optimizations?
Date: Fri, 03 Mar 2000 17:38:00 -0000
Message-id: <20000303173847.A1487@celes.dgate.ORG>
References: <38C051C3.260D666B@apple.com>
X-SW-Source: 2000-03/msg00067.html
Content-length: 1596
And then spake Stan Shebs, as follows:
> Ideally of course, GCC would issue lots of amazingly detailed debug info,
> and GDB would use it to reconstruct and report program state just as the
> programmer expects to see it. But today, the result is just lame; hackers
> trying to debug get lots of squirrelly behavior from GDB. The problem is
> that they don't know whether the randomness is due to bugs in the program,
> or to the effect of the optimizer. So the suggestion came up to have GCC
> issue debug info stating what optimizations have been applied to a file,
> and to have GDB report that information per-function, so that users could
> lower their expectations appropriately.
You may (or perhaps may not) find some of the material Caroline Tice has
worked on here at UCB useful -- ISTR she was investigating debugging
optimized code and did work on a compiler that outputted a lot of
information on the transformations that were applied to the code (and
debugging tools that used it.)
Disclaimer: I don't have any direct knowledge of how her code did what
it did, so I can't really be of much help -- but I just thought that
her dissertation talk sounded a lot like what you are trying to do...
http://sunsite.berkeley.edu/Dienst/UI/2.0/Describe/ncstrl.ucb/CSD-99-1077
http://www.cs.berkeley.edu/~cmtice/
-Brian
--
Brian R. Gaeke, brg@sartre.dgate.ORG -- PGP/GPG gleefully accepted
"the iguana / in the petshop window on St Catherine Street / crested,
royal-eyed, ruling / its kingdom of water-dish and sawdust / dreams of
sawdust" - Margaret Atwood, "Dreams of the Animals"
From leisner@rochester.rr.com Fri Mar 03 22:08:00 2000
From: "Marty Leisner" <leisner@rochester.rr.com>
To: shebs@apple.com
Cc: gcc@gcc.gnu.org, gdb@sourceware.cygnus.com, leisner@rochester.rr.com
Subject: Re: Should GCC tell GDB about its optimizations?
Date: Fri, 03 Mar 2000 22:08:00 -0000
Message-id: <200003040446.XAA04330@rochester.rr.com>
References: <38C051C3.260D666B@apple.com>
X-SW-Source: 2000-03/msg00068.html
Content-length: 3255
Yes...!!!
I proposed something like this years ago...I almost hacked up
gcc to put this in (I think I started...)
It is incredibly useful in the real world to encapsulate what
compiler flags were used in the binary (essentially the gcc command
line with preprocessor flags).
I just compiled a trivial C program with -O3 to see..
The .s file has
.ident "GCC: (GNU) 2.95.2 19991024 (release)"
Is there a way for nm to decode this? (strings can show it,
but its pretty meaningless in the binary).
For example:
...
GCC: (GNU) egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)
GCC: (GNU) egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)
GCC: (GNU) 2.95.2 19991024 (release)
GCC: (GNU) 2.95.2 19991024 (release)
GCC: (GNU) 2.95.2 19991024 (release)
GCC: (GNU) egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)
....
I don't know how to take apart elf binaries off the top
of my head, but I assume there is information someplace encoded
to match this up with specific files.
gdb doesn't have to warn, but you should be able to use a tool
to figure this out.
Marty Leisner
Stan Shebs <shebs@apple.com> writes on Fri, 03 Mar 2000 15:58:59 PST
> I'm sure this subject has come up before, but I don't remember any
> consensus...
>
> In the process of finishing Mac OS X, Apple has hundreds of engineers
> beating on GCC and GDB every day. The system has literally hundreds
> of subcomponents; everything from the kernel to speech output to Hebrew
> font support (sort of like a Linux system preloaded with everything
> you can find on freshmeat :-) ). By default, everything is built with
> optimization turned on. While an engineer can turn off optimization
> for a specific bit of code, it's not practical to build an entire system
> with optimization turned off. So in practice any single program
consists
> of a combination of optimized and unoptimized code.
>
> Ideally of course, GCC would issue lots of amazingly detailed debug
info,
> and GDB would use it to reconstruct and report program state just as the
> programmer expects to see it. But today, the result is just lame;
hackers
> trying to debug get lots of squirrelly behavior from GDB. The problem
is
> that they don't know whether the randomness is due to bugs in the
program,
> or to the effect of the optimizer. So the suggestion came up to have
GCC
> issue debug info stating what optimizations have been applied to a file,
> and to have GDB report that information per-function, so that users
could
> lower their expectations appropriately.
>
> Although my first reaction was to say "bleah", upon reflection I
wondered
> if I was too easily dismissing the concerns of real users of the tools.
> This sort of thing routinely confuses users; even with years of GNU
> experience, I still find myself being caught by surprise because I've
> forgotten that part of the code was optimized. A simple warning from
the
> debugger would have saved me some time and trouble.
> If there's consensus that this would be a worthwhile addition, I'll
> work up a specific design and publish it.
>
> Stan
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Should GCC tell GDB about its optimizations?
[not found] <38C051C3.260D666B@apple.com>
2000-03-03 17:03 ` Should GCC tell GDB about its optimizations? Timothy J. Wood
@ 2000-03-04 3:03 ` Stephane Carrez
2000-04-01 0:00 ` Stephane Carrez
1 sibling, 1 reply; 3+ messages in thread
From: Stephane Carrez @ 2000-03-04 3:03 UTC (permalink / raw)
To: shebs; +Cc: gcc, gdb
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 18044 bytes --]
Hi!
Stan Shebs wrote:
> I'm sure this subject has come up before, but I don't remember any
> consensus...
>
> In the process of finishing Mac OS X, Apple has hundreds of engineers
> beating on GCC and GDB every day. The system has literally hundreds
> of subcomponents; everything from the kernel to speech output to Hebrew
> font support (sort of like a Linux system preloaded with everything
> you can find on freshmeat :-) ). By default, everything is built with
> optimization turned on. While an engineer can turn off optimization
> for a specific bit of code, it's not practical to build an entire system
> with optimization turned off. So in practice any single program consists
> of a combination of optimized and unoptimized code.
>
We have some similar problem at Sun with ChorusOS. However, I've never
seen that mixing optimized/non optimized code was really the problem.
It was rather related to mixing debugging/non debugging code. May
be that's also the problem you are facing with (ie, compile some parts
with -g, some others without).
My understanding is that this makes debugging wrong because GDB
is not able to find out what registers are saved in functions not compiled
with -g. I don't think this is related to optimization (also see
"Timothy J. Wood" <tjw@omnigroup.com> e-mail).
There is a notion of level of debugging info in GCC. I think it was
intended to emit only the minimal debugging info (such as frame layout
or things like that). In this case, the complete system should be built
with such minimal debugging info (frame layout). Some specific files
could be compiled with -g (full debug).
This makes sense also for any library in general that you link with
(libc, ...). If such library is not compiled with -g, you cannot get
valid access to your local variables when you stop in some system call.
Now, if your function is compiled without optimization, gcc will not
allocate your local variables in registers, and GDB should be able
to give you good values for local variables.
This is my understanding of debugging with DWARF-2.
Anyway, it makes sense to know whether some files are compiled with
optimization or not.
Stephane
-----------------------------------------------------------------------
Home Office
E-mail: stcarrez@worldnet.fr Stephane.Carrez@sun.com
WWW: http://home.worldnet.fr/stcarrez http://www.sun.com
Mail: 17, rue Foucher Lepelletier 6, avenue Gustave Eiffel
92130 Issy Les Moulineaux 78182 Saint Quentin en Yvelines
France
From eliz@delorie.com Sat Mar 04 23:38:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: ac131313@cygnus.com
Cc: kingdon@redhat.com, gdb@sourceware.cygnus.com
Subject: Re: Dependence on config.status
Date: Sat, 04 Mar 2000 23:38:00 -0000
Message-id: <200003050737.CAA10121@indy.delorie.com>
References: <200002280657.BAA27090@indy.delorie.com> <38BCCA84.74A4143E@cygnus.com> <bem9u49sh.fsf@rtl.cygnus.com> <200003021007.FAA04124@indy.delorie.com> <38C0ACF2.C00719B0@cygnus.com>
X-SW-Source: 2000-03/msg00076.html
Content-length: 509
> Eli Zaretskii wrote:
> >
> > > Well, if memory serves, if you re-ran configure in such a way that
> > > tm.h started linking to a different file, then the config.status
> > > dependency was the only way to force a rebuild.
> >
> > How about adding some #define to config.h that would also change when
> > this happens?
>
> Such as the names of the tm, xm and nm files?
Yes, that's what I had in mind. Since the configure scripts already
knows the names of those files, it could put them into config.h.
From eliz@delorie.com Sun Mar 05 00:05:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: kettenis@wins.uva.nl
Cc: gdb@sourceware.cygnus.com, gdb-patches@sourceware.cygnus.com
Subject: Re: `long double' support for ix86 targets
Date: Sun, 05 Mar 2000 00:05:00 -0000
Message-id: <200003050805.DAA10149@indy.delorie.com>
References: <200003031531.e23FV8T00285@delius.kettenis.local>
X-SW-Source: 2000-03/msg00077.html
Content-length: 885
> I intend to check in the following patch in a week or two, but since
> this change affects most of the ix86 targets, I'd like to give people
> the opportunity to object.
>
> Mark
>
>
> 2000-03-02 Mark Kettenis <kettenis@gnu.org>
>
> * config/i386/tm-i386.h (TARGET_LONG_DOUBLE_FORMAT): Define as
> &floatformat_i387_ext.
> (TARGET_LONG_DOUBLE_BITS): Define as 96.
> (REGISTER_VIRTUAL_TYPE): Change type for FPU registers to
> `builtin_type_long_double'.
> (REGISTER_CONVERT_TO_VIRTUAL): Simply copy over the data, and pad
> with zeroes.
> (REGISTER_CONVERT_TO_RAW): Simply copy over the significant data.
> (i387_to_double, double_to_i387): Remove prototypes.
These changes are okay for DJGPP.
Btw, shouldn't we also have identical definition for
HOST_LONG_DOUBLE_FORMAT for native debugging? Several functions ask
about the host and target format being identical.
From eliz@delorie.com Sun Mar 05 00:36:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: gdb@sourceware.cygnus.com
Subject: COERCE_FLOAT_TO_DOUBLE
Date: Sun, 05 Mar 2000 00:36:00 -0000
Message-id: <200003050836.DAA10166@indy.delorie.com>
X-SW-Source: 2000-03/msg00078.html
Content-length: 428
The comments about COERCE_FLOAT_TO_DOUBLE in valops.c seem to suggest
that every modern architecture should define it to
standard_coerce_float_to_double. I was about to add that definition
to tm-go32.h when I noticed that none of the other i386 targets,
including linux native, does that--they all use the default
definition.
Shouldn't most/all i386 targets, at least those which use GCC, use
standard_coerce_float_to_double?
From eliz@delorie.com Sun Mar 05 00:50:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: gdb@sourceware.cygnus.com
Cc: ezannoni@cygnus.com
Subject: Buffering problems with "gdb < foo"
Date: Sun, 05 Mar 2000 00:50:00 -0000
Message-id: <200003050850.DAA10185@indy.delorie.com>
X-SW-Source: 2000-03/msg00079.html
Content-length: 1150
A comment in event-top.c (inside the change_line_handler function)
says this:
/* NOTE: this operates on input_fd, not instream. If we are reading
commands from a file, instream will point to the file. However in
async mode, we always read commands from a file with editing
off. This means that the 'set editing on/off' will have effect
only on the interactive session. */
However, running "gdb < foo" seems to contradict this: I put a
breakpoint in gdb_readline2, and it is never hit. Am I missing
something?
The problem with this is that if the file `foo' includes a command
which needs a confirmation, the call to fgetc in query will eatup lots
of characters which will never again be seen by the event loop. In my
case, fgetc read all the file (it was small), so GDB hit EOF and
exited. I can prevent this from happening by putting "set editing off"
in the input file. Invoking GDB with --noasync also solves the
problem.
Does this work on Unix? If so, it would make this a DJGPP-specific
problem.
If this is not DJGPP-specific, then I think _initialize_event_loop
should turn editing off if input_fd is not a tty.
From ac131313@cygnus.com Sun Mar 05 00:56:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Eli Zaretskii <eliz@delorie.com>
Cc: kingdon@redhat.com, gdb@sourceware.cygnus.com
Subject: Re: Dependence on config.status
Date: Sun, 05 Mar 2000 00:56:00 -0000
Message-id: <38C220BE.44922A6@cygnus.com>
References: <200002280657.BAA27090@indy.delorie.com> <38BCCA84.74A4143E@cygnus.com> <bem9u49sh.fsf@rtl.cygnus.com> <200003021007.FAA04124@indy.delorie.com> <38C0ACF2.C00719B0@cygnus.com> <200003050737.CAA10121@indy.delorie.com>
X-SW-Source: 2000-03/msg00080.html
Content-length: 1020
Eli Zaretskii wrote:
>
> > Eli Zaretskii wrote:
> > >
> > > > Well, if memory serves, if you re-ran configure in such a way that
> > > > tm.h started linking to a different file, then the config.status
> > > > dependency was the only way to force a rebuild.
> > >
> > > How about adding some #define to config.h that would also change when
> > > this happens?
> >
> > Such as the names of the tm, xm and nm files?
>
> Yes, that's what I had in mind. Since the configure scripts already
> knows the names of those files, it could put them into config.h.
Well I've long had in mind a ``maint build-info'' command that printed
out things like:
tm/xm/hm.h
the --host/target/build tupples
the compiler
the path to the source tree
the build date
the user/machine
Assuming your suggestion works (JimK doesn't find more technical flaws
(1) :-) A change putting tm/xm/hm into config.h is ok with me :-)
Andrew
(1) I think changing tm/xm/nm happens sufficiently often for it to be
dangerous to not force a rebuild.
From ac131313@cygnus.com Sun Mar 05 01:03:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Jim Kingdon <kingdon@redhat.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: [MAINT/RFC] Start devolving maintenance responsibility
Date: Sun, 05 Mar 2000 01:03:00 -0000
Message-id: <38C22262.FFA0191@cygnus.com>
References: <38BC81A0.17D25C8@cygnus.com> <bbt4y3s8k.fsf@rtl.cygnus.com> <38BE146B.46ED6E4D@cygnus.com> <200003021446.JAA31093@devserv.devel.redhat.com>
X-SW-Source: 2000-03/msg00081.html
Content-length: 1917
Jim Kingdon wrote:
>
> > Sorry, devolve, as a word, is probably more meaningful to people from
> > Commonwealth countries.
>
> I'm familiar with the word (e.g. Scotland) but at least for me it has
> all these connotations of national sovereignty and power and such.
> For example, it is a dead end to assume that an OS vendor should
> automatically maintain GDB on that OS because they "own" the platform
> or something.
>
> > The underlying concern I have isn't with people like you that have been
> > hacking on open code for years, its with people familar with GDB but not
> > so familar with open source. For that reason, I think it is useful to
> > spell out, in basic terms, how the system should work.
>
> Maybe link to The Cathedral and the Bazaar (which is well known) and
> Alan Cox's Town Council paper (which deserves to be better known and
> is at http://slashdot.org/features/98/10/13/1423253.shtml )? I was
> just showing the Town Council paper to someone in a GDB context and it
> seemed to resonate.
>
> I'm sure the looseness of this approach will make some people nervous.
> But you can't build trust through rules and policies either. What is
> going to turn GDB development into the (more) vibrant community we
> want it to be is delivering on the promises to add maintainers and
> otherwise open up. We've made great progress in the last month and
> let's keep it up.
Try this:
``
Note individuals who maintain parts of the debugger need approval to
check in changes outside of the immediate domain that they maintain.
If there is no maintainer for a given domain then the responsibility
falls to the head maintainer.
If there are several maintainers for a given domain then
responsibility falls to the first maintainer. The first maintainer is
free to devolve maintainership responsibility anyway they like.
Refs: http://slashdot.org/features/98/10/13/1423253.shtml
''
Andrew
From johan.rydberg@netinsight.se Sun Mar 05 07:57:00 2000
From: Johan Rydberg <johan.rydberg@netinsight.se>
To: gdb@sourceware.cygnus.com
Subject: probelms with registers
Date: Sun, 05 Mar 2000 07:57:00 -0000
Message-id: <38C292EF.50B53C09@netinsight.se>
X-SW-Source: 2000-03/msg00082.html
Content-length: 682
Hi!
I'm developing a "gdb-simulator" for a CPU, and it seems to
work pretty good. But I have some questions. When I try to
display the registers it says everyone except the link register
is unavailable. Why this? It also fetches the PC register, but
it also says it's unavailable.
And, how do I from gdb call the `sim_info´ function? Right
now I have implemented a "sim info" command, but since it's
defined in the simulator interface I guess that there's a
better way to do this.
regards,
Johan.
--
Johan Rydberg johan.rydberg@netinsight.net
Net Insight AB, Sweden direct: +46-8-685 04 17
http://www.netinsight.net phone: +46-8-685 04 00
fax: +46-8-685 04 20
From kingdon@redhat.com Sun Mar 05 10:10:00 2000
From: Jim Kingdon <kingdon@redhat.com>
To: ac131313@cygnus.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: [MAINT/RFC] Start devolving maintenance responsibility
Date: Sun, 05 Mar 2000 10:10:00 -0000
Message-id: <200003051810.NAA09213@devserv.devel.redhat.com>
References: <38BC81A0.17D25C8@cygnus.com> <bbt4y3s8k.fsf@rtl.cygnus.com> <38BE146B.46ED6E4D@cygnus.com> <200003021446.JAA31093@devserv.devel.redhat.com> <38C22262.FFA0191@cygnus.com>
X-SW-Source: 2000-03/msg00083.html
Content-length: 36
> Try this:
That looks fine to me.
From schwab@suse.de Mon Mar 06 02:55:00 2000
From: Andreas Schwab <schwab@suse.de>
To: leisner@rochester.rr.com
Cc: shebs@apple.com, gcc@gcc.gnu.org, gdb@sourceware.cygnus.com
Subject: Re: Should GCC tell GDB about its optimizations?
Date: Mon, 06 Mar 2000 02:55:00 -0000
Message-id: <200003061054.LAA20310@hawking.suse.de>
References: <200003040446.XAA04330@rochester.rr.com>
X-SW-Source: 2000-03/msg00084.html
Content-length: 1609
"Marty Leisner" <leisner@rochester.rr.com> writes:
|> Yes...!!!
|>
|> I proposed something like this years ago...I almost hacked up
|> gcc to put this in (I think I started...)
|>
|> It is incredibly useful in the real world to encapsulate what
|> compiler flags were used in the binary (essentially the gcc command
|> line with preprocessor flags).
|>
|> I just compiled a trivial C program with -O3 to see..
|>
|> The .s file has
|> .ident "GCC: (GNU) 2.95.2 19991024 (release)"
|>
|> Is there a way for nm to decode this? (strings can show it,
|> but its pretty meaningless in the binary).
|>
|> For example:
|> ...
|> GCC: (GNU) egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)
|> GCC: (GNU) egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)
|> GCC: (GNU) 2.95.2 19991024 (release)
|> GCC: (GNU) 2.95.2 19991024 (release)
|> GCC: (GNU) 2.95.2 19991024 (release)
|> GCC: (GNU) egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)
|> ....
|>
|> I don't know how to take apart elf binaries off the top
|> of my head, but I assume there is information someplace encoded
|> to match this up with specific files.
This information is concatenated in the .comment section. It can be
listed with "objdump -sj.comment ....". But there is no easy way to map
it back to the object modules apart from the fact that the order is the
same as the order of the modules linked in.
Andreas.
--
Andreas Schwab "And now for something
SuSE Labs completely different."
Andreas.Schwab@suse.de
SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg
From ezannoni@cygnus.com Mon Mar 06 09:56:00 2000
From: Elena Zannoni <ezannoni@cygnus.com>
To: Eli Zaretskii <eliz@delorie.com>
Cc: gdb@sourceware.cygnus.com, ezannoni@cygnus.com
Subject: Re: Buffering problems with "gdb < foo"
Date: Mon, 06 Mar 2000 09:56:00 -0000
Message-id: <14531.61750.823726.628635@kwikemart.cygnus.com>
References: <200003050850.DAA10185@indy.delorie.com>
X-SW-Source: 2000-03/msg00085.html
Content-length: 1497
Eli Zaretskii writes:
>
> A comment in event-top.c (inside the change_line_handler function)
> says this:
>
> /* NOTE: this operates on input_fd, not instream. If we are reading
> commands from a file, instream will point to the file. However in
> async mode, we always read commands from a file with editing
> off. This means that the 'set editing on/off' will have effect
> only on the interactive session. */
>
> However, running "gdb < foo" seems to contradict this: I put a
> breakpoint in gdb_readline2, and it is never hit. Am I missing
> something?
>
Yeah, I tried to think hard about all the possible cases, but
obvioulsy I missed this one.
> The problem with this is that if the file `foo' includes a command
> which needs a confirmation, the call to fgetc in query will eatup lots
> of characters which will never again be seen by the event loop. In my
> case, fgetc read all the file (it was small), so GDB hit EOF and
> exited. I can prevent this from happening by putting "set editing off"
> in the input file. Invoking GDB with --noasync also solves the
> problem.
>
Yep.
> Does this work on Unix? If so, it would make this a DJGPP-specific
> problem.
I haven't tried, but probably it won't. Can you send me your command file?
>
> If this is not DJGPP-specific, then I think _initialize_event_loop
> should turn editing off if input_fd is not a tty.
I think so, can you submit a patch to do this?
Thanks.
Elena
From tennis@cisco.com Mon Mar 06 10:37:00 2000
From: Tennis Smith <tennis@cisco.com>
To: gdb-trolls@cisco.com, gdb@sourceware.cygnus.com
Subject: Finding a Source File
Date: Mon, 06 Mar 2000 10:37:00 -0000
Message-id: <4.1.20000306101424.00a5a510@lethe>
X-SW-Source: 2000-03/msg00086.html
Content-length: 972
Hi,
I'm trying to set a breakpoint in a file that is indirectly
included in my project. When I try to set a breakpoint
on it, the following message occurs:
No source file named MismatchedTokenException.cpp.
The file lives in a separate tree which contains various support
routines. I've added to my path the location of the file, but
that didn't work.
Any ideas??
TIA,
-Tennis
-------------------------------------------------------------------------
| | Cisco Systems, Inc. Tennis Smith
||| ||| 170 West Tasman Drive Software Engineer
||||| ||||| San Jose, CA 95134-1706 Test Technology
.:|||||||:..:|||||||:. Phone: (408) 527-4424
Fax: (408) 527-6245 tennis@cisco.com
Cisco Systems Inc. Pager: 1-800-796-7363
"Yes, it's my real name..." PIN# 101-0528
-------------------------------------------------------------------------
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Should GCC tell GDB about its optimizations?
2000-03-04 3:03 ` Stephane Carrez
@ 2000-04-01 0:00 ` Stephane Carrez
0 siblings, 0 replies; 3+ messages in thread
From: Stephane Carrez @ 2000-04-01 0:00 UTC (permalink / raw)
To: shebs; +Cc: gcc, gdb
Hi!
Stan Shebs wrote:
> I'm sure this subject has come up before, but I don't remember any
> consensus...
>
> In the process of finishing Mac OS X, Apple has hundreds of engineers
> beating on GCC and GDB every day. The system has literally hundreds
> of subcomponents; everything from the kernel to speech output to Hebrew
> font support (sort of like a Linux system preloaded with everything
> you can find on freshmeat :-) ). By default, everything is built with
> optimization turned on. While an engineer can turn off optimization
> for a specific bit of code, it's not practical to build an entire system
> with optimization turned off. So in practice any single program consists
> of a combination of optimized and unoptimized code.
>
We have some similar problem at Sun with ChorusOS. However, I've never
seen that mixing optimized/non optimized code was really the problem.
It was rather related to mixing debugging/non debugging code. May
be that's also the problem you are facing with (ie, compile some parts
with -g, some others without).
My understanding is that this makes debugging wrong because GDB
is not able to find out what registers are saved in functions not compiled
with -g. I don't think this is related to optimization (also see
"Timothy J. Wood" <tjw@omnigroup.com> e-mail).
There is a notion of level of debugging info in GCC. I think it was
intended to emit only the minimal debugging info (such as frame layout
or things like that). In this case, the complete system should be built
with such minimal debugging info (frame layout). Some specific files
could be compiled with -g (full debug).
This makes sense also for any library in general that you link with
(libc, ...). If such library is not compiled with -g, you cannot get
valid access to your local variables when you stop in some system call.
Now, if your function is compiled without optimization, gcc will not
allocate your local variables in registers, and GDB should be able
to give you good values for local variables.
This is my understanding of debugging with DWARF-2.
Anyway, it makes sense to know whether some files are compiled with
optimization or not.
Stephane
-----------------------------------------------------------------------
Home Office
E-mail: stcarrez@worldnet.fr Stephane.Carrez@sun.com
WWW: http://home.worldnet.fr/stcarrez http://www.sun.com
Mail: 17, rue Foucher Lepelletier 6, avenue Gustave Eiffel
92130 Issy Les Moulineaux 78182 Saint Quentin en Yvelines
France
From jtc@redback.com Sat Apr 01 00:00:00 2000
From: jtc@redback.com (J.T. Conklin)
To: gdb@sourceware.cygnus.com
Subject: memory region attribute CLI
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <5mr9dd5dlt.fsf@jtc.redbacknetworks.com>
X-SW-Source: 2000-q1/msg00703.html
Content-length: 1326
I've been told to work on memory region attributes full time, so I
expect to make significant progress in the next few days.
* create memory region:
mem <start> <end> attribute [attribute ...]
example:
(gdb) mem 0x00008000 0x0000FFFF ro 8
(gdb) mem 0x00007FF0 0x00007FFF rw
(gdb) mem 0x00007FE0 0x00007FEF wo 16
(gdb) mem 0x00007FD0 0x00007FDF ro
I've followed the behavior of "display" and do not output a message
indicating the number of the memory region that has been created.
But as I write this message, it seems that it probably should. I
think an argument could be made that the same should be done for
displays...
* enable/disable memory region:
enable mem <region-id> [<region-id> ...]
disable mem <region-id> [<region-id> ...]
example:
(gdb) disable mem 2
* delete memory regions:
delete mem <region-id> [<region-id> ...]
example:
(gdb) delete mem 3
* show memory regions:
info mem
example:
(gdb) info mem
Num Enb Address Attr
1: y 0x00008000-0x0000FFFF ro, 8
2: n 0x00007FF0-0x00007FFF rw
4: y 0x00007FD0-0x00007FDF ro
Thoughts?
--jtc
--
J.T. Conklin
RedBack Networks
From dje@transmeta.com Sat Apr 01 00:00:00 2000
From: Doug Evans <dje@transmeta.com>
To: gdb@sourceware.cygnus.com
Cc: dje@transmeta.com
Subject: Guile scripting
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200002132323.PAA12301@casey.transmeta.com>
X-SW-Source: 2000-q1/msg00256.html
Content-length: 997
I found this in the gdb archives.
What's the state of "first version of libgdb, w/Guile scripting" ?
---
To: gdb at sourceware dot cygnus dot com
Subject: Re: Next release of GDB
From: James Ingham <jingham at leda dot cygnus dot com>
Date: 07 Sep 1999 09:32:06 -0700
Newsgroups: cygnus.gdb
Organization: Cygnus Solutions
References: <199909051618.SAA01412@caracol.first.gmd.de>
Clemens Klein-Robbenhaar <robbe@prosun.first.gmd.de> writes:
Presumably, the Objective C support would be in the MacOS X Support
bits. MacOS X being based on NextStep, which is in turn heavily
Objective C based...
Jim
> Stan Shebs wrote:
>
> [...]
> > Here are some additional things that I would like to see, but that
> > ought not to hold up the release if they can't be gotten in:
> >
> > * first version of libgdb, w/Guile scripting
> > * GNU/Linux thread_db library support
> > * asynchronous execution for GNU/Linux
> > * fork following for GNU/Linux
> > * HP WDB 1.1 bits
From ogoh@cise.ufl.edu Sat Apr 01 00:00:00 2000
From: "Okehee Goh" <ogoh@cise.ufl.edu>
To: <gdb@sourceware.cygnus.com>
Subject: Error during installing GDB using Cygwin32.
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <001501bf5b23$b053fb20$8daae380@hsilab.cise.ufl.edu>
X-SW-Source: 2000-q1/msg00015.html
Content-length: 720
Hi,
I'm now trying to install gdb-4.18 on the win98 using cygwin32.
But it gave out the following error message and faild to make gdb.exe.
"gdb-4.18/readline/kill.c:611: undefined reference to 'OpenClipboard'
gdb-4.18/readline/kill.c:611: undefined reference to 'GetClipboardData'
gdb-4.18/readline/kill.c:611: undefined reference to 'CloseClipboard'"
When I examined the related part of above error at kill.c,
these function was to support Cygwin32.
How can I deal with this problem? Is there any patch for solving this
problem?
Thanks in advance.
********************************************************************
Okehee Goh
RealTime System Lab. (T) 1-352-392-6836
CISE Dept. University Of Florida
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2000-04-01 0:00 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <38C051C3.260D666B@apple.com>
2000-03-03 17:03 ` Should GCC tell GDB about its optimizations? Timothy J. Wood
2000-03-04 3:03 ` Stephane Carrez
2000-04-01 0:00 ` Stephane Carrez
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox