add-symbol-file change in gdb 5.1

[Kevin Nomura <nomura at netapp dot com>]

We use gdb to debug homegrown loadable modules that are
based on Alpha a.out format.  To tell gdb about symbols for
a dynamically loaded module, up to gdb 5.0 one did:

	add-symbol-file modulefile loadaddress

This established the .text, .data and .bss addresses from
the single provided loadaddress, which is the only parameter
readily available to the user.  The code that did this is
symfile.c:syms_from_objfile().

In gdb 5.1 it seems only .text is established by this form of
the command.  The user, following what they are used to, now sees
their data symbols flagged as invalid memory or maybe with junk
values. This is because all other sections are left at address 0.

The user *could* dump the a.out header and relocate these sections 
by hand, then specify:

	add-symbol-file modulefile .text ___ .data ___ .bss ___

Some questions:

- Am I missing something about the use of the command?  Do standard
  loadable modules still behave nicely in gdb 5.1 and this is
  specific to my homegrown loader (even though it uses a.out
  straightforwardly)?

- From my understanding of a.out and ELF I don't see why the
  relocation arithmetic to get the .data and .bss sections is
  less robust than for .text.  Why not compute them all, so as
  not to expose a user to this?

- Web search gave this reference from a Cygnus developer:
  http://sources.redhat.com/ml/gdb/2000-04/msg00020.html
  Is this related to the change we now see?  I would disagree
  with the statement that the previous mechanism doesn't work
  for non-text sections, but maybe this is again unique to our
  simple loader.

Thanks for any suggestions.

Kevin Nomura
Network Appliance