Re: Should GCC tell GDB about its optimizations?

[Stephane Carrez <Stephane.Carrez@worldnet.fr>]

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