Mirror of the gdb mailing list
 help / color / mirror / Atom feed
* -Wmissing-prototypes ...
@ 1999-11-27 18:50 Andrew Cagney
  1999-09-20  0:46 ` -Wmissing-prototypes Andrew Cagney
       [not found] ` <37CB6DBE.2083662F@cygnus.com>
  0 siblings, 2 replies; 4+ messages in thread
From: Andrew Cagney @ 1999-11-27 18:50 UTC (permalink / raw)
  To: gdb

FYI,

There is now a reasonable chance that GDB can be compiled with the
-Wmissing-prototypes option.  Thanks to JimI, JimB and Fernando and
Elena for various specific cleanups.

	Andrew

My current list is:

--enable-build-warnings=-Werror\
,-Wimplicit\
,-Wreturn-type\
,-Wcomment\
,-Wtrigraphs\
,-Wformat\
,-Wparentheses\
,-Wpointer-arith\
,-Wmissing-prototypes\
,-Woverloaded-virtual\
From cgf@cygnus.com Sat Nov 27 18:50:00 1999
From: cgf@cygnus.com (Chris Faylor)
To: gdb@sourceware.cygnus.com
Subject: Re: Debugging Windows Namespace extension dll
Date: Sat, 27 Nov 1999 18:50:00 -0000
Message-id: <7rpjdk$a2b$1@cronkite.cygnus.com>
References: <l03130300b404ff236a3b@[138.251.135.28]>
X-SW-Source: 1999-q4/msg00333.html
Content-length: 1219

In article <l03130300b404ff236a3b@[138.251.135.28]>,
Mark Hindley  <mh15@st-andrews.ac.uk> wrote:
>I am in the middle of writing a windows namespace extension implemented as
>an in process server dll. I have got the basic structure complete and it
>builds fine with gcc, but I can not get it to debug with gdb.
>
>I am trying:
>
>exec-file /windows/explorer.exe
>
>source-file MyDll.dll
>
>set args /root, {My CLSID},
>
>
>There appears to be 2 problems. I get an access violation when the dll is
>read, eith as the initial symbol file, or when it is loaded by explorer
>when the programme is run. The other is that I am unable to set any
>breakpoints. If I type
>
>break DllMain
>
>the reply is
>
>Cannot access memory at 0x....

The way that I normally do something like this is:

    gdb /windows/explorer.exe
    symbol-file MyDll.dll
    set args /root
    l DllMain
    bp <first line number in DllMain>
    run

As you probably, know using 'symbol-file' wipes out any existing symbol file
so this may not be exactly what you want.  You could use add-sym if you know
the load address of your DLL.

Hope this helps,
Chris Faylor
-- 
cgf@cygnus.com
http://www.cygnus.com/
From ac131313@cygnus.com Sat Nov 27 18:50:00 1999
From: Andrew Cagney <ac131313@cygnus.com>
To: gdb@sourceware.cygnus.com
Subject: -Werror -Wformat -Wimplicit
Date: Sat, 27 Nov 1999 18:50:00 -0000
Message-id: <37CB6DBE.2083662F@cygnus.com>
X-SW-Source: 1999-q4/msg00334.html
Content-length: 1339

Just FYI,

The next snap (Jason only just made one) is very likely to be buildable
with the configuration option:

--enable-build-warnings=-Werror\
,-Wimplicit\
,-Wreturn-type\
,-Wcomment\
,-Wtrigraphs\
,-Wformat\
,-Wparentheses\
,-Wpointer-arith\
,-Woverloaded-virtual

I've cleaned up numerous targets and, for them, the source code contains
*ZERO* warnings of the types listed above.

Assuming that your host's header files are in good condition, it
shouldn't take much for a few maintainers to wack their native build
into similar shape.

For the curious.  The full list looks like:

  enable_build_warnings=`echo -Werror\
\
,$W\
,-Wimplicit\
,-Wreturn-type\
,$Wunused\
,$Wswitch\
,-Wcomment\
,-Wtrigraphs\
,-Wformat\
,$Wchar$subscripts\
,$Wuninitialized\
,-Wparentheses\
,$Wtemplate$debugging\
\
,$Wtraditional\
,$Wshadow\
,$Wid$clash$len\
,-Wpointer-arith\
,$Wcast$qual\
,$Wcast$align\
,$Wwrite$strings\
,$Wconversion\
,$Waggregate$return\
,$Wstrict$prototypes\
,$Wmissing$prototypes\
,$Wmissing$declarations\
,$Wredundant$decls\
,$Wnested$externs\
,$Wenum$clash\
,-Woverloaded-virtual\
,$Winline\

so while there is a long way to go, the list of those working is very
useful (namely -Wformat, -Wimplicit, -Wparen and -Wcomment - especially
-Wformat!).

	enjoy,
		Andrew
From msnyder@cygnus.com Sat Nov 27 18:50:00 1999
From: Michael Snyder <msnyder@cygnus.com>
To: gdb@sourceware.cygnus.com
Cc: ptr@paragraph.ru
Subject: Re: gdb 4.18 on Solaris 7 x86?
Date: Sat, 27 Nov 1999 18:50:00 -0000
Message-id: <37CC6A59.5106@cygnus.com>
References: <14273.5137.480144.257285@icecle>
X-SW-Source: 1999-q4/msg00339.html
Content-length: 1844

Petr Ovchenkov wrote:
> 
> Is anybody made 4.18 working under Solaris 7 x86?

I don't have a Solaris 7 x86 system, but it works
fine for me on Solaris 6 x86.  I'm not sure what
might have changed in Solaris 7.

> I made changes in gdb/procfs.c so no more
> "Inappropriate ioctl for device" happens, and correct permittions for
> /proc/XXXX/crt. But still can't set any breakpoint (indeed can,
> but gdb don't stop on it).

Can't comment without seeing your changes.
I've never seen that message, and breakpoints are
working fine for me on Solaris 6 x86.

> > more test.c
> #include <stdio.h>
> 
> int main( int argc, char **argv )
> {
>   printf( "%s", "Hello, GNU!\n" );
>   return 0;
> }
> > gcc -ggdb test.c -lthread

Just curious -- why are you linking libthread to this program?

> GNU gdb 4.18
> Copyright 1998 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "i386-pc-solaris2.7"...
> (gdb) break main
> Breakpoint 1 at 0x80489b2: file test.c, line 5.
> (gdb) run
> Starting program: /export/home/ptr/tmp/Test/a.out
> Hello, GNU!
> /proc/11504/ctl: No such file or directory.
> procfs_write_pcwstop failed
> (gdb) quit
> The program is running.  Exit anyway? (y or n) y
> >
> 
> When gdb say "/proc/11504/ctl: No such file or directory.", process
> already exited. When I try "target solaris-thread", result the same.
> 
> Can any help?
> 
> If somebody interesting by /proc/... workaround for Solaris 7,
> patch for available.

I'd be willing to look at your patch.

				Michael Snyder
From jingham@leda.cygnus.com Sat Nov 27 18:50:00 1999
From: James Ingham <jingham@leda.cygnus.com>
To: gdb@sourceware.cygnus.com
Subject: Re: Next release of GDB
Date: Sat, 27 Nov 1999 18:50:00 -0000
Message-id: <mf4sh6el89.fsf@leda.cygnus.com>
References: <199909051618.SAA01412@caracol.first.gmd.de>
X-SW-Source: 1999-q4/msg00341.html
Content-length: 1942

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

>>>>>>>>>>>> > * Apple MacOS X support bits

> > * Current VxWorks (Tornado) support bits
> > * Current LynxOS support bits
> > * m68k BDM patches
> > * Ada language support
> > 
> > There are probably many other important things that I'm forgetting,
> > please speak up and remind me about them!
> [...]
> 
> .. what about Objective C support? That should not be to hard.
> (For gdb-4.16 and gdb-4.17, there was a patch,
> afaik by Michael Snyder <msnyder@NeXT.com>;
> still present at ftp://alpha.gnu.org/gnu/gnustep/contrib
> This patch does not work for gdb-4.18, but only because the code
> changed too much for the "patch" program to apply, I think.) 
> 
> Have I missed some point here -- has the Objective C patch
> been rejected because of pricipal reasons not supporting Objective C
> in gdb? As I scanned the archives, I found only 
> Christopher Seawood <cls@seawood.org> 
> http://sourceware.cygnus.com/ml/gdb-patches/1998/msg00115.html
> raising the same issue, but without getting any feedback.
>  
>  Or has just nobody been around so far interested in doing the
> (little) work?
> 
> 
> regards, 
>  clemens

-- 
++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++
Jim Ingham                                              jingham@cygnus.com
Cygnus Solutions Inc.
From msnyder@cygnus.com Sat Nov 27 18:50:00 1999
From: Michael Snyder <msnyder@cygnus.com>
To: gdb@sourceware.cygnus.com
Subject: Re: overlays and hardware breakpoints
Date: Sat, 27 Nov 1999 18:50:00 -0000
Message-id: <37D5CAFE.7F3B@cygnus.com>
References: <5mwvu8ft9t.fsf@jtc.redbacknetworks.com>
X-SW-Source: 1999-q4/msg00343.html
Content-length: 386

J.T. Conklin wrote:

> But while studying breakpoint.c, I noticed that there does not seem
> to be support for using hardware breakpoints and overlays.  Although
> CPUs with hardware breakpoint registers typically have large address
> spaces, it is not inconceivable that overlays may be used. 

Almost surely an oversight.  If you care to add it, 
I'll review it.
				Michael
From ac131313@cygnus.com Sat Nov 27 18:50:00 1999
From: Andrew Cagney <ac131313@cygnus.com>
To: gdb@sourceware.cygnus.com
Subject: ERF TARGET_WAITKIND_EOF
Date: Sat, 27 Nov 1999 18:50:00 -0000
Message-id: <37F0529C.B0694A78@cygnus.com>
X-SW-Source: 1999-q4/msg00337.html
Content-length: 1119

Hello,

(I've also seen LOST, DEAD, DOA, KABOOM, KAPUT ..suggested :-).

At present when communication with a target is lost, the target
internally indicates the falure by directly killing the target
(mourn_inferior()) and longjmping out of there (error ()).

When it comes to async and providing clean library like behavour, having
things randomly call error() isn't nice (besides longjmp's are bad N'kay
;-).

I'd like to propose the new ``enum target_waitkind'' TARGET_WAITKIND_EOF
that target_wait() can return to indicate that the target just went
kaput. The semantics would require the target_*() vector to post the the
failure reason on gdb_stderr and then return TARGET_WAINTKIND_EOF.

Initially the remote async and remote extended-async targets would be
the only ones capable of returning this result.  This would ensure that
other non-async targets would not be affected.

Clearly this is going to stur up WFI (or what ever it is today).

I'd like comments on this and (perhaphs) someone willing to handle the
WFI side.  I'd be willing to take care of the remote.c side.


	Andrew
From msnyder@cygnus.com Sat Nov 27 18:50:00 1999
From: "Michael Snyder" <msnyder@cygnus.com>
To: gdb@sourceware.cygnus.com
Subject: Re: Lets talk to each other...
Date: Sat, 27 Nov 1999 18:50:00 -0000
Message-id: <7svnb4$5cb$1@cronkite.cygnus.com>
References: <19990927151348.A22339@sco.com> <990928043014.ZM29997@ocotillo.lan> <199909280657.IAA00175@delius.kettenis.nl> <990929033103.ZM17365@ocotillo.lan> <199909291554.RAA18158@landau.wins.uva.nl>
X-SW-Source: 1999-q4/msg00345.html
Content-length: 307


Mark Kettenis wrote in message <199909291554.RAA18158@landau.wins.uva.nl>...
>HJ's patch has
>the drawback that it also tries to solve a totally unrelated problem
>(curses on Solaris 7), which needs some more investigation and
>probably should be

And is being.

>fixed in autoconf instead.




^ permalink raw reply	[flat|nested] 4+ messages in thread
[parent not found: <Pine.SUN.3.91.991202192443.17848B-100000@is>]
end of thread, other threads:[~1999-12-02 22:19 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1999-11-27 18:50 -Wmissing-prototypes Andrew Cagney
1999-09-20  0:46 ` -Wmissing-prototypes Andrew Cagney
     [not found] ` <37CB6DBE.2083662F@cygnus.com>
     [not found]   ` <199912021414.JAA16068@mescaline.gnu.org>
1999-12-02  7:42     ` -Wmissing-prototypes Andreas Jaeger
     [not found] <Pine.SUN.3.91.991202192443.17848B-100000@is>
1999-12-02 22:19 ` -Wmissing-prototypes Andreas Jaeger

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