public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
* Removing leftover traces of mmalloc?
@ 2004-08-05 21:07 Nathanael Nerode
  2004-08-06 14:57 ` Andrew Cagney
  0 siblings, 1 reply; 3+ messages in thread
From: Nathanael Nerode @ 2004-08-05 21:07 UTC (permalink / raw)
  To: gdb

With the removal of mmalloc support from gdb, nothing in src or gcc is
actually using mmalloc.  Furthermore, support appears to have been removed
prior to the branching of GDB 6.1.

Would it be appropriate to delete the mmalloc directory and all the trailing
references thereto?  If not, would it at any rate be appropriate to stop
shipping it with GDB and delete the various trailing references?

Reply to list please.  :-)

-- 
There are none so blind as those who will not see.

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Removing leftover traces of mmalloc?
  2004-08-05 21:07 Removing leftover traces of mmalloc? Nathanael Nerode
@ 2004-08-06 14:57 ` Andrew Cagney
  2004-08-10 15:51   ` Andrew Cagney
  0 siblings, 1 reply; 3+ messages in thread
From: Andrew Cagney @ 2004-08-06 14:57 UTC (permalink / raw)
  To: Nathanael Nerode; +Cc: gdb

> With the removal of mmalloc support from gdb, nothing in src or gcc is
> actually using mmalloc.  Furthermore, support appears to have been removed
> prior to the branching of GDB 6.1.
> 
> Would it be appropriate to delete the mmalloc directory and all the trailing
> references thereto?  If not, would it at any rate be appropriate to stop
> shipping it with GDB and delete the various trailing references?

I think it is fine to break the the GDB <-> mmalloc connection (by 
zapping it from config et.al.).

As for removing it (cvs rm -f), perhaphs we can avoid it (although I 
don't care).

GDB has a growing list of top-level src directories that it doesn't need 
to be included in a distro (src/mmalloc/ is one).  I think its time to 
prune the `gdb' module (which, I know, is not a very backward compatible 
thing to do).

Andrew

PS: But `what-if' GDB needs to replace obstacks with something more like 
mmalloc (ah, the irony)? We can then revive it - here we need to deal 
with `what-is' :-)


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Removing leftover traces of mmalloc?
  2004-08-06 14:57 ` Andrew Cagney
@ 2004-08-10 15:51   ` Andrew Cagney
  0 siblings, 0 replies; 3+ messages in thread
From: Andrew Cagney @ 2004-08-10 15:51 UTC (permalink / raw)
  To: Andrew Cagney, Nathanael Nerode; +Cc: gdb

>> With the removal of mmalloc support from gdb, nothing in src or gcc is
>> actually using mmalloc.  Furthermore, support appears to have been removed
>> prior to the branching of GDB 6.1.
>>
>> Would it be appropriate to delete the mmalloc directory and all the trailing
>> references thereto?  If not, would it at any rate be appropriate to stop
>> shipping it with GDB and delete the various trailing references?
> 
> 
> I think it is fine to break the the GDB <-> mmalloc connection (by zapping it from config et.al.).

Hmm, I just noted some lingering calls to [x]mmalloc in the objfile 
reader.  I'll replace them (their reason for being there is gone).

Since GDB works around the lack of mmalloc this wouldn't have been noticed.

Andrew

> As for removing it (cvs rm -f), perhaphs we can avoid it (although I don't care).
> 
> GDB has a growing list of top-level src directories that it doesn't need to be included in a distro (src/mmalloc/ is one).  I think its time to prune the `gdb' module (which, I know, is not a very backward compatible thing to do).
> 
> Andrew
> 
> PS: But `what-if' GDB needs to replace obstacks with something more like mmalloc (ah, the irony)? We can then revive it - here we need to deal with `what-is' :-)


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2004-08-10 15:51 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-08-05 21:07 Removing leftover traces of mmalloc? Nathanael Nerode
2004-08-06 14:57 ` Andrew Cagney
2004-08-10 15:51   ` Andrew Cagney

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).