Re: [PATCH 06/11 v5] Add target/symbol.h

[Gary Benson <gbenson@redhat.com>]

Doug Evans wrote:
> Gary Benson writes:
> > +/* Find a symbol that matches NAME.  Limit the search to OBJFILE if
> > +   OBJFILE is non-NULL and the implementation supports limiting the
> > +   search to specific object files.  If a match is found, store the
> > +   matching symbol's address in ADDR and return nonzero.  Return zero
> > +   if no symbol matching NAME is found.  Raise an exception if OBJFILE
> > +   is non-NULL and the implementation does not support limiting
> > +   searches to specific object files.  */
> > +
> > +extern int target_look_up_symbol (const char *name, CORE_ADDR *addr,
> > +				  struct objfile *objfile);
> 
> Can this comment spell out that either a mangled or demangled
> form of the symbol is allowed for NAME?
> [assuming that that is indeed the case]

It is the case.  I'll update the comment.

> Also, the target/target.h memory routines return zero for success
> and a non-zero error code for failure.  E.g.,
> 
> +/* Read LEN bytes of target memory at address MEMADDR, placing the
> +   results in GDB's memory at MYADDR.  Return zero for success,
> +   nonzero if any error occurs.  Implementations of this function may
> +   define and use their own error codes, but functions in the common,
> +   nat and target directories must treat the return code as opaque.
> +   No guarantee is made about the contents of the data at MYADDR if
> +   any error occurs.  */
> +
> +extern int target_read_memory (CORE_ADDR memaddr, gdb_byte *myaddr,
> +			       ssize_t len);
> 
> Do we want to be consistent here, and have the same results for
> target_look_up_symbol? [and throughout the target API]

That seems reasonable to me, I'll make the change.

Thanks,
Gary

-- 
http://gbenson.net/