Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Stephane Carrez <Stephane.Carrez@worldnet.fr>
To: Michael Snyder <msnyder@cygnus.com>
Cc: Keith Seitz <keiths@cygnus.com>, gdb-patches@sources.redhat.com
Subject: Re: [RFA]: Fix gdb.base/callfwmall.exp for platforms without malloc
Date: Mon, 21 May 2001 14:20:00 -0000	[thread overview]
Message-ID: <3B098795.1CD78B21@worldnet.fr> (raw)
In-Reply-To: <3B095A01.D85C9E5D@cygnus.com>

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1942 bytes --]

Hi!

Michael Snyder a écrit :
> 
> Keith Seitz wrote:
> >
> > On Mon, 21 May 2001, Michael Snyder wrote:
> >
> > > No -- but perhaps we could approve a patch that would cause this
> > > test to be skipped (or xfailed) for targets in which we know it
> > > cannot pass.
> >
> > Somewhere I am sitting on patches to change the behavior of this to XFAIL
> > if malloc does not exist. It does not rely on a particular config
> > variable. Instead, it queries gdb if malloc exists in the symbol table.
> >
> > Would this be better? (Didn't we have this discussion a little while ago?
> > Deja vu?)
> 
> Yes it did, and no that would not be better.  ;-)
> The idea of the test is to confirm that GDB can pass the test
> even if there is no malloc.  I know this is counter-intuitive,
> because we are all used to the idea that gdb can NOT pass this
> test if there is no malloc -- but apparently there are some
> targets (at least one) on which it can.

Hum... if I understand, the only good fix is to fix GDB so that it no longer
calls 'malloc'.  I would be very happy to see that fix in GDB.  You cannot rely
on a possible 'malloc'.  I have two examples in mind here: 68HC11 programs
and... ChorusOS kernel.

Do you have any patch or are you working on any fix so that GDB does not call
'malloc' any more?

For example, by allocating the string on the stack, as it does for the arguments.
Ok, it's more complex; you'll need a two-pass argument processing, one for
string allocation, and one to really push the arguments.

	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


  reply	other threads:[~2001-05-21 14:20 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <3B07B042.6BAD93A0@worldnet.fr>
2001-05-21 10:43 ` Michael Snyder
2001-05-21 10:56   ` Keith Seitz
2001-05-21 11:10     ` Michael Snyder
2001-05-21 14:20       ` Stephane Carrez [this message]
2001-05-21 14:58         ` Michael Snyder
2001-05-21 22:45         ` Jim Blandy
2001-06-06  9:07         ` Andrew Cagney
2001-05-22  9:16 Michael Elizabeth Chastain

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3B098795.1CD78B21@worldnet.fr \
    --to=stephane.carrez@worldnet.fr \
    --cc=gdb-patches@sources.redhat.com \
    --cc=keiths@cygnus.com \
    --cc=msnyder@cygnus.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox