This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [patch] cleanup: Remove INVALID_ENTRY_POINT (+FR-V modification)
- From: Pedro Alves <pedro at codesourcery dot com>
- To: gdb-patches at sourceware dot org
- Cc: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- Date: Sat, 31 Oct 2009 15:42:13 +0000
- Subject: Re: [patch] cleanup: Remove INVALID_ENTRY_POINT (+FR-V modification)
- References: <20091031150829.GA27608@host0.dyn.jankratochvil.net>
On Saturday 31 October 2009 15:08:29, Jan Kratochvil wrote:
> @@ -316,7 +320,7 @@ entry_point_address (void)
> ? ?struct gdbarch *gdbarch;
> ? ?CORE_ADDR entry_point;
> ?
> - ?if (symfile_objfile == NULL)
> + ?if (symfile_objfile == NULL || !symfile_objfile->ei.entry_point_p)
> ? ? ?return 0;
Previously, when we had a main symbol file, but the entry point was
invalid (how common is that?), we'd return ~0 here, but now we'll
return 0. Is there potential for breakage? inside_entry_func for
instance could trigger false positives more often. Makes me wonder about
exposing the invalid-entry-point-ity to callers. Say, by adding a new
entry_point_address_p(), or better, adjusting the interface to:
/* If there's a valid and known entry point, fills ENTRY_P with it
and return true; otherwise return false. */
int entry_point_address (CORE_ADDR *entry_p);
Otherwise looks ok to me.
--
Pedro Alves