Re: syms_from_objfile() warnings and win32-nat.c IO redirection (Was: suppress annoying warnings about cygwin1.dbg)

["Pedro Alves" <pedro_alves@portugalmail.pt>]

Pedro Alves wrote:
> -       warning (_("no loadable sections found in added symbol-file %s"),
> -                objfile->name);
>
> but not touch that one:
>
> > warning: Lowest section in system-supplied DSO at 0xffffe000 is .hash at ffffe0b4
>
> as it doesn't affect the cygwin1.dbg case, because there are no
> code sections there.  Somehow I lost the '& SEC_CODE' in the
> process.
>

> >> -                    warning (_("section %s not found in %s"),
> >> -                             addrs->other[i].name,
> >> -                             objfile->name);

> >
> > I know you needed this one before because win32-nat.c specified an
> > offset for .text manually.  I don't think it does so any more, though.
> > This one's useful, since you can provoke it with a typo:
> >
> > (gdb) add-symbol-file cat 1000 -s .dataz 24
> > add symbol table from file "cat" at
> >         .text_addr = 0x3e8
> >         .dataz_addr = 0x18
> > (y or n) y
> > Reading symbols from /bin/cat...warning: section .dataz not found in /bin/cat
> >
>
> Ah, right, I clearly see that now.  I just more or less blindly
> removed the warnings that were being output.
>

> We do get that warning today, because the cygwin1.dbg file only
> contains the debug info sections, but ADDRS is filled with
> every SEC_ALLOC | SEC_LOAD section of cygwin1.dll.  Would it be
> OK to only do the warning if VERBO (it is set to from_tty in
> the case you mentioned) or info_verbose are on?
>

I failed to mention that this patch wouldn't remove the need to the
safe_symbol_file_add stderr redirection hack in win32-nat.c, as
will that warning will be hit when using  the dll_symbol_command
or add-symbol-file to load dll symbols from an object with seperate
debug info manually, but should be seen as an "incremental" fix
as a more correct solution is devised.

OK, so, on to fix this properly to remove that hack completelly.

Can anyone point me into why the non-debug sections are
preserved (as NOBITS) in the seperate debug file?
Could it be so support the case where the section headers
were stripped in the main file?
To help if there are relocs against section symbols in
the debug info?  Not sure if that makes sense in
a NOBITS section.
Or, are they added so to keep tools that currently expect
them there happy?

If they're really needed, we should then be fixing the
format instead.  If it isn't possible to emulate the NOBITS
funcionality with real sections, I think we can add a new
section to the seperate debug info file, that bfd parses
to make fake NOBITS pseudo sections (much like core file
pseudo sections).  Or maybe special casing PE/coff
support in gdb would be easier, but I don't know if other
tools expect them.

If they're not really needed, then the shortest change would be to
not pass orig_addrs to symbol_file_add
in symfile.c:symbol_file_add_with_addrs_or_offsets.

static struct objfile *
symbol_file_add_with_addrs_or_offsets (bfd *abfd, int from_tty,
                                       struct section_addr_info *addrs,
                                       struct section_offsets *offsets,
                                       int num_offsets,
                                       int mainline, int flags)
{

 struct section_addr_info *orig_addrs = NULL;

(...)

 if (addrs)
    {
      orig_addrs = copy_section_addr_info (addrs);
      make_cleanup_free_section_addr_info (orig_addrs);
    }

(...)

  if (objfile->psymtabs == NULL)
    debugfile = find_separate_debug_file (objfile);
  if (debugfile)
    {
      if (addrs != NULL)
        {
          objfile->separate_debug_objfile
            = symbol_file_add (debugfile, from_tty, orig_addrs, 0, flags);
        }
      else
        {
          objfile->separate_debug_objfile
            = symbol_file_add (debugfile, from_tty, NULL, 0, flags);
        }
      objfile->separate_debug_objfile->separate_debug_objfile_backlink
        = objfile;

(...)
}

I'm sure the sections are preserved for a reason, but what is it?

Cheers,
Pedro Alves