This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC/RFA] Set current language when dumping symtab


On Sun, May 29, 2005 at 12:10:56PM +1000, Joel Brobecker wrote:
> > > 2005-05-02  Joel Brobecker  <brobecker@adacore.com>
> > > 
> > >         * symmisc.c (dump_symtab_1): Renamed from dump_symtab.
> > >         (dump_symtab): New function.
> > >         * Makefile.in (symmisc.o): Add dependency on ui-out.h.
> > 
> > What's the new dependency on ui-out.h for?  I didn't see anything
> > obvious in the patch.
> 
> I agree it's not obvious. That's because of TRY_CATCH:
> 
> #define TRY_CATCH(EXCEPTION,MASK) \
>      { \
>        EXCEPTIONS_SIGJMP_BUF *buf = \
>          exceptions_state_mc_init (uiout, &(EXCEPTION), (MASK)); \
>        EXCEPTIONS_SIGSETJMP (*buf); \
>      } \
>      while (exceptions_state_mc_action_iter ()) \
>        while (exceptions_state_mc_action_iter_1 ())
> 
> There is a dependency on "uiout". Perhaps it would be better to include
> that file from exceptions.h, rather than requiring all clients to include
> it themselves? I could send a separate RFA for that.

Yes please.  I figured it was something like that, went looking at the
definition, and my eyes skipped right over it.

> > Also, what crashes?  i.e. why specifically is it harmful to have the
> > wrong language set?
> 
> In Ada, we rely on some special encoding to convey some information
> that certain debugging formats such as stabs can not express. In our
> case, one of the C symtabs had an entity whose name mislead the Ada
> language, and caused it to try to access something that didn't exist.
> This caused an internal-error, IIRC.

Hmm... I guess this bit is OK.

> > Also, I am not convinced that the new TRY_CATCH is necessary.  The
> > only bit likely to throw is print_symbol, which is already wrapped in
> > catch_errors.
> 
> That's true, and I'd be happy to remove it. But I thought that it might
> be safer to use it anyway, so that any change underneath that might cause
> an exception to be thrown does not affect this code. This is a hard
> guaranty that the language will never be changed as a side-effect of
> this command.

That's the sort of thinking that leads to hordes of exception regions
that no one can ever remove.  Please let's not.

-- 
Daniel Jacobowitz
CodeSourcery, LLC


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]