RE: Cygwin GDB crashes from cvs - solib

["Dave Korn" <dave dot korn at artimi dot com>]

On 10 April 2006 18:21, Daniel Jacobowitz wrote:

> Currently win32-nat.c sets in_dynsym_resolve_code and open_symbol_file
> to NULL.  The latter doesn't normally get called, but when it does,
> it is called unconditionally; the former is called by "step".  Should
> win32-nat provide dummy functions or should the call sites check?  Anyone
> have an opinion?

  Well, IIUIC, we have various target vectors of different kinds throughout
gcc binutils and gdb, and in every case that I can bring to mind off the top
of my head, there's no requirement that every single entry has to be
initialised, and a NULL entry indicates 'target does not have capability'.

  So from that point of view, ISTM that no call site should blindly jump
through a target vector pointer without first checking that it is non-NULL,
unless it already 'knows' by some other means that the current target /has/ to
have the capability in question (in which case if the pointer is NULL it's a
programming bug because the information in the target vector must not be
semantically self-consistent).

  IASTM that if we start requiring all function-pointers in target vectors to
be filled out with a pointer to a dummy function if there is no real function
for the target, we lose the ability to test if the target has the given
capability, and it would, in time, lead to people being tempted to write
really ugly code such as:-

  if (current_target_so_ops->open_symbol_file == &dummy_open_symbol_file_stub)
    ... assume we don't have the capability ...
  else 
    ... assume we do ...

which wouldn't be a good thing IMO.

  However that's a generic POV on the general issue.  Cgf will probably have a
relevant opinion about this particular problem since he's been paying some
attention to the win32 native solib stuff lately and I would defer to his
judgement on this one.

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....