From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21357 invoked by alias); 22 Nov 2002 00:47:07 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 21344 invoked from network); 22 Nov 2002 00:47:06 -0000 Received: from unknown (HELO jackfruit.Stanford.EDU) (171.64.38.136) by sources.redhat.com with SMTP; 22 Nov 2002 00:47:06 -0000 Received: (from carlton@localhost) by jackfruit.Stanford.EDU (8.11.6/8.11.6) id gAM0l5128212; Thu, 21 Nov 2002 16:47:05 -0800 X-Authentication-Warning: jackfruit.Stanford.EDU: carlton set sender to carlton@math.stanford.edu using -f To: gdb Cc: per@bothner.com, green@redhat.com Subject: allocate_objfile (NULL, 0) From: David Carlton Date: Thu, 21 Nov 2002 16:47:00 -0000 Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-11/txt/msg00321.txt.bz2 I'm in a situation where I want to create an artificial block to store some artificial symbols. I've followed the lead of jv-lang.c (which needs a block to store symbols associated to dynamic classes); that code creates an object file via this call: dynamics_objfile = allocate_objfile (NULL, 0); and then creates a symtab within it, creates global and static blocks for that symtab, and stuffs stuff into the global block. The problem with this is that the resulting objfile doesn't have a name, and there is code within GDB that assumes that objfile->name is non-NULL. I ran into this problem in solib.c's symbol_add_stub, but there may well be other places that make that assumption. So something should be fixed. It seems that the three possible options are: 1) Not allow code to assume that objfile->name is always non-NULL. 2) Modify allocate_objfile to set the allocated objfile's name to the empty string in the case where its first argument is NULL. 3) Fix jv-lang.c to set objfile->name explicitly. I'll be happy to submit a patch that does one of these, but I wanted to poll people to see which option they prefer. My vote is for option number 2: the code in solib.c seems reasonable enough, so I don't like option number 1, and allocate_objfile seems to go to some length to work well when its first argument is NULL, so it wouldn't hurt for it to handle this issue as well. It would, of course, be possible to do both options 2 and 3: assuming that we agree that option 2 is good, then it would be up to the Java maintainers as to whether they wanted to follow option 3 as well. David Carlton carlton@math.stanford.edu