gdb

gdb

[bemis]

Hello,

I am new to using gdb, but I didn't see a really good way to run my
executable inside of gdb.

I am trying to figure out why I am getting a core dump when I am
checking a library in libc.
I have two environment variables:

GCONV_PATH=/mnt/u2/bemis/dev/tools/build/alpha7/bootstrap-gcc_3.0.4/native/libc/

iconvdata

LC_ALL=C

then I run my library with the following command:

/mnt/u2/bemis/dev/tools/build/alpha7/bootstrap-gcc_3.0.4/na
tive/libc/elf/ld-linux.so.2 --library-path
/mnt/u2/bemis/dev/tools/build/alpha7/
bootstrap-gcc_3.0.4/native/libc:/mnt/u2/bemis/dev/tools/build/alpha7/bootstrap-g

cc_3.0.4/native/libc/math:/mnt/u2/bemis/dev/tools/build/alpha7/bootstrap-gcc_3.0

.4/native/libc/elf:/mnt/u2/bemis/dev/tools/build/alpha7/bootstrap-gcc_3.0.4/nati

ve/libc/dlfcn:/mnt/u2/bemis/dev/tools/build/alpha7/bootstrap-gcc_3.0.4/native/li

bc/nss:/mnt/u2/bemis/dev/tools/build/alpha7/bootstrap-gcc_3.0.4/native/libc/nis:

/mnt/u2/bemis/dev/tools/build/alpha7/bootstrap-gcc_3.0.4/native/libc/rt:/mnt/u2/

bemis/dev/tools/build/alpha7/bootstrap-gcc_3.0.4/native/libc/resolv:/mnt/u2/bemi

s/dev/tools/build/alpha7/bootstrap-gcc_3.0.4/native/libc/crypt:/mnt/u2/bemis/dev

/tools/build/alpha7/bootstrap-gcc_3.0.4/native/libc/linuxthreads

and then finally I run :
 /mnt/u2/bemis/d
ev/tools/build/alpha7/bootstrap-gcc_3.0.4/native/libc/dlfcn/tstcxaatexit
> /mnt
/u2/bemis/dev/tools/build/alpha7/bootstrap-gcc_3.0.4/native/libc/dlfcn/tstcxaate

xit.out

Really this is all on one command line!  What would be the proper way to
start debugging this with gdb and the core file I get from this when
I run it outside of gdb?
Thanks!
Matt Bemis
University of New Hampshire
Alpha Linux Group

Gdb

[Russell Shaw]

Hi,
After narrowing down a bug location in the last few days, it seems
all too obvious that gdb needs to be gutted and recast. It can all
be made simpler and more understandable, thus easier to maintain.

Gdb should should be a library of functions for the various things
that can be done to a target, and have no user interface and command-
line parsing at all.

All the current user terminal interaction should be in a separate
program that is linked to the gdb library.

There is far too much complexity for the simple things that gdb does.

The bug i have is that gdb does not stop at pending breakpoints i have
set in a dlopen library. I made a small testcase, and gdb does do the
pending breakpoints there ok. This bug should be easy to find and fix,
but it isn't.

If there's no plans to redo gdb, i'll do it anyway.

Re: Gdb

[Daniel Jacobowitz]

On Wed, Oct 25, 2006 at 05:05:11PM +1000, Russell Shaw wrote:
> There is far too much complexity for the simple things that gdb does.

I just don't know what to do with this message.

Yes, GDB is a bit crufty and could use some new design in places.  But
calling the target control tasks "simple" is absurd.  It is a typical
fallacy to assume that a task you are only lightly familiar with is
simple, when in fact most of the existing complexity is necessary.

> If there's no plans to redo gdb, i'll do it anyway.

You are welcome to submit individual patches which make areas of GDB
easier to understand.  There are even some suggestions on the wiki.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Gdb

[Russell Shaw]

Daniel Jacobowitz wrote:
> On Wed, Oct 25, 2006 at 05:05:11PM +1000, Russell Shaw wrote:
> 
>>There is far too much complexity for the simple things that gdb does.
> 
> I just don't know what to do with this message.
> 
> Yes, GDB is a bit crufty and could use some new design in places.  But
> calling the target control tasks "simple" is absurd.  It is a typical
> fallacy to assume that a task you are only lightly familiar with is
> simple, when in fact most of the existing complexity is necessary.

There are places with long sequences of:

   if() {
     ...
   }

   if() {
     ...
   }

   if() {
     ...
   }

Instead of something more rigorous like:

   if() {
     ...
   }
   else if {
     ...
   }
   else if {
     ...
   }
...
   else {
     ...
   }

This makes touching anything unpredictable, as there's too many combinations
of possible code paths that may or may not be valid.

That's only one small example. The code is not well modularized. It's hard to
show that here. When a "run" resets a simple breakpoint, the stack depth is no
less than 35 levels. It also invokes a tortuous 10-level trip thru various
"memory set" functions until it eventually reaches target_xfer_partial or whatever,
intermingled with re-reading symbol files, re-syncing dynamic libraries, and
resetting breakpoints.

>>If there's no plans to redo gdb, i'll do it anyway.
> 
> You are welcome to submit individual patches which make areas of GDB
> easier to understand.  There are even some suggestions on the wiki.

It's undoable by anyone not intimately familiar with the code which means
weeks of prodding with a second gdb. The payoff is better in making something
totally different and new.

Re: Gdb

[Daniel Jacobowitz]

On Wed, Oct 25, 2006 at 11:38:49PM +1000, Russell Shaw wrote:
> This makes touching anything unpredictable, as there's too many combinations
> of possible code paths that may or may not be valid.

Guess what?  The conditions aren't orthogonal _for a reason_.

I don't think there's any point in my continuing this conversation, so
this will probably be my last message.  You continue insisting that
the complexity is unnecessary, and yet you don't know why it's there.
I can assure you that it isn't there just to make our lives harder.

> It's undoable by anyone not intimately familiar with the code which
> means weeks of prodding with a second gdb. The payoff is better in
> making something totally different and new.

Having spent many days considering this, talking to others about it,
and even starting it twice, I believe that you are wrong.

There's a lot of payoff in starting from scratch, but (A) you have to
put in just about as much work, and (B) you end up with something
totally different.  If that's your goal, congratulations (I'm thinking
of Frysk here, for instance).  But if you wanted something that looked
like GDB...

-- 
Daniel Jacobowitz
CodeSourcery

Re: Gdb

[Russell Shaw]

Daniel Jacobowitz wrote:
> On Wed, Oct 25, 2006 at 11:38:49PM +1000, Russell Shaw wrote:
> 
>>This makes touching anything unpredictable, as there's too many combinations
>>of possible code paths that may or may not be valid.
> 
> Guess what?  The conditions aren't orthogonal _for a reason_.
> 
> I don't think there's any point in my continuing this conversation, so
> this will probably be my last message.  You continue insisting that
> the complexity is unnecessary, and yet you don't know why it's there.
> I can assure you that it isn't there just to make our lives harder.
> 
>>It's undoable by anyone not intimately familiar with the code which
>>means weeks of prodding with a second gdb. The payoff is better in
>>making something totally different and new.
> 
> Having spent many days considering this, talking to others about it,
> and even starting it twice, I believe that you are wrong.
> 
> There's a lot of payoff in starting from scratch, but (A) you have to
> put in just about as much work, and (B) you end up with something
> totally different.  If that's your goal, congratulations (I'm thinking
> of Frysk here, for instance).  But if you wanted something that looked
> like GDB...

The amount of code is not what i mean. It's the organization that lacks
coherency. There's too many things tacked on half-heartedly knowing whether
that was the right thing to do or the right place to put it. So any patches
i submit could easily break something on some other system, and it's hard to
know.

I'll cut or re-arrange various steps i've seen (during "run"), but i won't
submit any patches for months (needs a lot of checking).

I was going to copy stuff starting from scratch, but that seems a bit of
effort after trying it. I'll just evolve the current gdb a bit.

Re: Gdb

[Eli Zaretskii]

> Date: Thu, 26 Oct 2006 02:29:18 +1000
> From: Russell Shaw <rjshaw@netspace.net.au>
> CC:  gdb@sourceware.org
> 
> So any patches i submit could easily break something on some other
> system, and it's hard to know.

We have the patch review process and the test suite for revealing such
breakage.

Re: Gdb

[Eli Zaretskii]

> Date: Wed, 25 Oct 2006 23:38:49 +1000
> From: Russell Shaw <rjshaw@netspace.net.au>
> CC:  gdb@sourceware.org
> 
> There are places with long sequences of:
> 
>    if() {
>      ...
>    }
> 
>    if() {
>      ...
>    }
> 
>    if() {
>      ...
>    }
> 
> Instead of something more rigorous like:
> 
>    if() {
>      ...
>    }
>    else if {
>      ...

These two are not the same.  If you can show us places where the
conditions are disjoint, i.e. they cannot happen together, please do.

> When a "run" resets a simple breakpoint, the stack depth is no less
> than 35 levels.

That is not necessarily a sign of bad design.  For example, when Emacs
does garbage collection, the stack depth sometimes exceeds 10,000
levels when recursive data structures are marked.  That is normal and
by design.

> It also invokes a tortuous 10-level trip thru various
> "memory set" functions until it eventually reaches target_xfer_partial or whatever,
> intermingled with re-reading symbol files, re-syncing dynamic libraries, and
> resetting breakpoints.

This multi-level trip is mostly for valid reasons.

> It's undoable by anyone not intimately familiar with the code which means
> weeks of prodding with a second gdb.

That is a wild exaggeration, IMO.  When I first came to hack GDB to
submit a patch, it was no harder than in any other real-life program.

Perhaps you lack good tools for learning programs, or don't use them
to their full power.

Re: Gdb

[Russell Shaw]

Eli Zaretskii wrote:
>>Date: Wed, 25 Oct 2006 23:38:49 +1000
>>From: Russell Shaw <rjshaw@netspace.net.au>
>>CC:  gdb@sourceware.org
>>
>>There are places with long sequences of:
>>
>>   if() {
>>     ...
>>   }
>>
>>   if() {
>>     ...
>>   }
>>
>>   if() {
>>     ...
>>   }
>>
>>Instead of something more rigorous like:
>>
>>   if() {
>>     ...
>>   }
>>   else if {
>>     ...
> 
> These two are not the same.  If you can show us places where the
> conditions are disjoint, i.e. they cannot happen together, please do.
> 
>>When a "run" resets a simple breakpoint, the stack depth is no less
>>than 35 levels.
> 
> That is not necessarily a sign of bad design.  For example, when Emacs
> does garbage collection, the stack depth sometimes exceeds 10,000
> levels when recursive data structures are marked.  That is normal and
> by design.

The slowness and size of emacs put me off it. I use (g)vim because
editing using ex regex commands is a more direct way at doing things imho.

>>It also invokes a tortuous 10-level trip thru various
>>"memory set" functions until it eventually reaches target_xfer_partial or whatever,
>>intermingled with re-reading symbol files, re-syncing dynamic libraries, and
>>resetting breakpoints.
> 
> This multi-level trip is mostly for valid reasons.

It still seems excessive at the way it currently works, but i'll look at it
again another time.

>>It's undoable by anyone not intimately familiar with the code which means
>>weeks of prodding with a second gdb.
> 
> That is a wild exaggeration, IMO.  When I first came to hack GDB to
> submit a patch, it was no harder than in any other real-life program.
> 
> Perhaps you lack good tools for learning programs, or don't use them
> to their full power.

I just use ctags to navigate in gvim.

I've been going to make a new GUI frontend for gdb but i keep getting
blocked by bugs in other tools.

Re: Gdb

[Eli Zaretskii]

> Date: Thu, 26 Oct 2006 12:28:40 +1000
> From: Russell Shaw <rjshaw@netspace.net.au>
> CC:  gdb@sourceware.org
> 
> > That is not necessarily a sign of bad design.  For example, when Emacs
> > does garbage collection, the stack depth sometimes exceeds 10,000
> > levels when recursive data structures are marked.  That is normal and
> > by design.
> 
> The slowness and size of emacs put me off it. I use (g)vim because
> editing using ex regex commands is a more direct way at doing things imho.

What does this have to do with the issue at hand?  I used Emacs as an
example of a very deep stack being a normal situation in a working
program whose design is generally considered well-thought.

> > Perhaps you lack good tools for learning programs, or don't use them
> > to their full power.
> 
> I just use ctags to navigate in gvim.

I recommend to add at least ID-Utils to your toolchest.  I don't know
if someone wrote a gvim plug-in for it (the Emacs interface is
included in the package), but even if you invoke it from the shell,
it's an invaluable tool for finding your way around an unfamiliar
program.

Also, some parts of GDB internals are documented in gdbint.texinfo.
Sadly, many important aspects are not covered at all there, but if you
are lucky to be working on something that is described, reading that
manual can help.

Re: Gdb

[Russell Shaw]

Eli Zaretskii wrote:
>>Date: Thu, 26 Oct 2006 12:28:40 +1000
>>From: Russell Shaw <rjshaw@netspace.net.au>
>>CC:  gdb@sourceware.org
>>
>>>That is not necessarily a sign of bad design.  For example, when Emacs
>>>does garbage collection, the stack depth sometimes exceeds 10,000
>>>levels when recursive data structures are marked.  That is normal and
>>>by design.
>>
>>The slowness and size of emacs put me off it. I use (g)vim because
>>editing using ex regex commands is a more direct way at doing things imho.
> 
> What does this have to do with the issue at hand?

Mainly that i detest deep indirect stacks to reach some final target code
because it makes things slow and hard to maintain. The speed and compactness
of vi is what i'd like in gdb, without sacrificing completeness and usability.

I don't like waiting for a text editor to start (emacs), and wouldn't want to
wait for a bloated debugger to start (gdb is currently ok imo).

 > I used Emacs as an
> example of a very deep stack being a normal situation in a working
> program whose design is generally considered well-thought.
>  
>>>Perhaps you lack good tools for learning programs, or don't use them
>>>to their full power.
>>
>>I just use ctags to navigate in gvim.
> 
> I recommend to add at least ID-Utils to your toolchest.  I don't know
> if someone wrote a gvim plug-in for it (the Emacs interface is
> included in the package), but even if you invoke it from the shell,
> it's an invaluable tool for finding your way around an unfamiliar
> program.

I'll read-up on id-utils.

> Also, some parts of GDB internals are documented in gdbint.texinfo.
> Sadly, many important aspects are not covered at all there, but if you
> are lucky to be working on something that is described, reading that
> manual can help.

Re: Gdb

[Jim Blandy]

Russell Shaw <rjshaw@netspace.net.au> writes:
> After narrowing down a bug location in the last few days, it seems
> all too obvious that gdb needs to be gutted and recast. It can all
> be made simpler and more understandable, thus easier to maintain.

I think you should give it a shot.  I'd love to see a proper set of
libraries for controlling processes and interpreting debugging
information.  You may want to look at Frysk, which is a newer design
taking a very different approach, but addressing many of the same
kinds of problems that GDB tries to.

I've come to think that trying to do involved symbolic processing
(types; scoping; overload resolution; and multiply by ten where C++ is
involved) without garbage collection is like trying to build a pocket
watch out of sawdust and superglue.  Frysk is written in Java.

But I would also say that what you've written here looks to me like a
pretty common reaction of people who've had good experiences writing
their own code to unfamiliar and complex programs; and at least in my
own experience, it often mellows as one works with the code more.

Re: Gdb

[Russell Shaw]

Jim Blandy wrote:
> Russell Shaw <rjshaw@netspace.net.au> writes:
> 
>>After narrowing down a bug location in the last few days, it seems
>>all too obvious that gdb needs to be gutted and recast. It can all
>>be made simpler and more understandable, thus easier to maintain.
> 
> I think you should give it a shot.  I'd love to see a proper set of
> libraries for controlling processes and interpreting debugging
> information.  You may want to look at Frysk, which is a newer design
> taking a very different approach, but addressing many of the same
> kinds of problems that GDB tries to.
> 
> I've come to think that trying to do involved symbolic processing
> (types; scoping; overload resolution; and multiply by ten where C++ is
> involved) without garbage collection is like trying to build a pocket
> watch out of sawdust and superglue.  Frysk is written in Java.

I didn't know about Frysk. The problem is it's in Java, and java is too indirect
and resource consuming for me.

I made a scoped hierarchial automatic garbage collecting system for C where if
you created an object on the heap between these (possibly nested) macros:

   auto_scope

     AnObject *myobject = mem_new(anoldobject, AnObject);
     ...
     auto_ret(ret_result);
   end_auto
   ...
   return another_result


then any objects within the scope is automatically freed after endauto or auto_ret
if they aren't "owned" by another object outside the scope such as anoldobject.
It works for arbitraryly deep scope, and across long-jumps. A global tree of object
ownerships is maintained, so if a parent of an object is mem_freed() that has other
parents, then the object is not freed() until it has no more parents (an automatic
version of refcounts). You can also modify the scope level of objects, which is
something that is normally unmodifiable in other languages.

After getting it working, i found it slowed the code by 5-10 times and used quite a
bit of memory, because new memory-tracking objects were being used for every small
mem_malloc i did, which were very frequent (thousands per second). It's best to use
this sought of thing for tracking larger (eg, 64-byte) less frequently created objects.

I found later another hierarchial memory manager called Talloc used in Samba.
Haven't used it though. It didn't do as much as i wanted.

I'm still wondering if something like the more manual but faster cleanup chains of
gdb would be a good way of doing things.

> But I would also say that what you've written here looks to me like a
> pretty common reaction of people who've had good experiences writing
> their own code to unfamiliar and complex programs; and at least in my
> own experience, it often mellows as one works with the code more.

Hi,
I've got a closer idea of what/where the problem is now, after looking
through 2k lines of back-traces at various stages during "run" from
delete_breakpoint().

A thing i didn't like is that eg, solib_read_symbols() will eventually mess
around with resetting breakpoints 6 frames deeper in the stack. I would have
handled breakpoint readjustments *after* solib_read_symbols(). I don't know
if it is practical without knowing how all paths operate in greater detail
on all systems and targets. Because i know how it works for the current case,
it seems easier to make a minor patch than to rearrange anything.


#0  delete_breakpoint (bpt=0x84ddd58) at breakpoint.c:6750
#1  0x080e57a0 in breakpoint_re_set_one (bint=0x84ddd58) at breakpoint.c:7206
#2  0x0812ad08 in catch_errors (func=0x80e5264 <breakpoint_re_set_one>, func_args=0x84ddd58, 
errstring=0x898d310 "Error in re-setting breakpoint -413:\n", mask=6) at exceptions.c:515

#3  0x080e5825 in breakpoint_re_set () at breakpoint.c:7248
#4  0x0810e6bf in new_symfile_objfile (objfile=0x8bb8ca0, mainline=0, verbo=0) at symfile.c:868
#5  0x0810e9fb in symbol_file_add_with_addrs_or_offsets (abfd=0x8b66108, from_tty=0, 
addrs=0x8b8cf48, offsets=0x0, num_offsets=0, mainline=0, flags=8) at symfile.c:1019

#6  0x0810ea5f in symbol_file_add_from_bfd (abfd=0x8b66108, from_tty=0, addrs=0x8b8cf48, mainline=0, 
flags=8) at symfile.c:1039

#7  0x0810ea98 in symbol_file_add (name=0x8b88c58 "/usr/lib/libXfixes.so.3", from_tty=0, 
addrs=0x8b8cf48, mainline=0, flags=8) at symfile.c:1052

#8  0x08091869 in symbol_add_stub (arg=0x8b88a50) at solib.c:406
#9  0x0812ad08 in catch_errors (func=0x80917a0 <symbol_add_stub>, func_args=0x8b88a50, 
errstring=0x826c0b0 "Error while reading shared library symbols:\n", mask=6) at exceptions.c:515

#10 0x08091916 in solib_read_symbols (so=0x8b88a50, from_tty=0) at solib.c:432
#11 0x08091c95 in solib_add (pattern=0x0, from_tty=0, target=0x8317100, readsyms=1) at solib.c:684
#12 0x0811fc1b in handle_inferior_event (ecs=0xbf8931f4) at infrun.c:2198
#13 0x0811dc52 in wait_for_inferior () at infrun.c:1009
#14 0x0811da7e in proceed (addr=4294967295, siggnal=TARGET_SIGNAL_0, step=0) at infrun.c:827
#15 0x0811a704 in run_command_1 (args=0x0, from_tty=1, tbreak_at_main=0) at infcmd.c:556

gdb

[Richard A. Painter]

i was reviewing the documentation for gdb and found no references to pthreads
specifically but did see some thread support.

pthreads embodies threads, mutexes and condition variables.  i saw no references
to the mutexes and condition variables in the docs.

does gdb support pthreads, mutexes and condition variables?

thanks,
rich


-- 

+---------------------------------------------------------------+
| Richard A. Painter            Phone 719 495 7054              |
| Painter Engineering, Inc.     Mailto:r.painter@ieee.org       |
| 8470 Swan Rd.                                                 |
| Black Forest, CO 80908                                        |
|                                                               |
| Visit our Web site:         http://painter.inc                |
|         http://home.earthlink.net/~painterengineering         |
|                                                               |
| Systems & Software Engineering + LAN WAN Networking + X.25    |
| INTERNET TCP-IP + Real-time Transaction Processing            |
| System & Software Integration, Testing, Verification & Audits |
| Web Hosting & Design + Apache + PHP + modSSL + cURL           |
| Database Design & Applications + Oracle                       |
| Benchmarks + Course & Workshop Development & Delivery         |
| Financial and Medical Software Integration + Security         |
| Middleware + EDI + Cryptography + Firewalls                   |
| UNIX + Linux + Windows                                        |
|                                                               |
| What is popular is not always right and what is right is not  |
| always popular.     - Howard Cosell                           |
|                                                               |
| Chance favors the prepared mind!   Illegitima non carborundum |
+---------------------------------------------------------------+

Re: gdb

[Daniel Jacobowitz]

On Thu, Jul 25, 2002 at 08:32:43PM -0600, Richard A. Painter wrote:
> i was reviewing the documentation for gdb and found no references to pthreads
> specifically but did see some thread support.
> 
> pthreads embodies threads, mutexes and condition variables.  i saw no references
> to the mutexes and condition variables in the docs.
> 
> does gdb support pthreads, mutexes and condition variables?

How would a debugger support mutexes and condition variables?  They'll
still work in programs run under the debugger.  Pthreads does not
expose convenient interfaces for examining their states, though.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

gdb

[Kees Everaars]

Hi Eveybody
I have been trying to debug a C program that is running multiple threads. 
This has given me a lot of headache.
What I want is that I want to step through a single thread while the other 
threads do not get a chance to run while I am stepping in that single thread 
(i.e. I want "locked stepping").
In the gdb manual I read that it is possible for some Operating systems
to set the so called "scheduler-locking mode".
I have set it on. The answer of my machine (linux version 2.4.3-12 of Redhat). 
"Target 'None' cannot support this command".
Now my questions.
1) Can I configure the installation of Linux in such a way that my machine 
support the above command?
2) If not, is there in a near future a new version of Redhat Linux 
distribution  that supports "locked stepping"?
3) Is there a other debugger under Linux  that offers "locked stepping"?
4) Does the Debian linux distribution offers the "locked stepping".
5) On which Operating systems does "locked stepping" work?

Thanks in advance.

Kees Everaars

Re: gdb

[Michael Snyder]

Kees Everaars wrote:
> 
> Hi Eveybody
> I have been trying to debug a C program that is running multiple threads.
> This has given me a lot of headache.
> What I want is that I want to step through a single thread while the other
> threads do not get a chance to run while I am stepping in that single thread
> (i.e. I want "locked stepping").

Sorry -- you can't really do that.

> In the gdb manual I read that it is possible for some Operating systems
> to set the so called "scheduler-locking mode".

No, that doesn't work for linux.
Hmm, maybe somebody has some spare time to make it work?

> I have set it on. The answer of my machine (linux version 2.4.3-12 of Redhat).
> "Target 'None' cannot support this command".
> Now my questions.
> 1) Can I configure the installation of Linux in such a way that my machine
> support the above command?

No.

> 2) If not, is there in a near future a new version of Redhat Linux
> distribution  that supports "locked stepping"?

It has not been planned.

> 3) Is there a other debugger under Linux  that offers "locked stepping"?

I don't know, but I don't think so.

> 4) Does the Debian linux distribution offers the "locked stepping".
> 5) On which Operating systems does "locked stepping" work?

The only one that I know of is eCos.

Re: GDB

[Christopher Faylor]

Huh?

cgf

On Fri, Nov 16, 2001 at 08:50:51PM -0800, Maliha wrote:
>cgf@redhat.com, gdb@sources.redhat.com
>
>
>---------------------------------
>Do You Yahoo!?
>Find the one for you at Yahoo! Personals.

gdb

[Mathieu Dube]

unsubscribe gdb
-- 
Mathieu Dube	
Mondo-Live			
www.flipr.com