Re: path for gdb/dwarf2read.c, support 16-bit targets in dwarf-2

[Andrew Cagney <ac131313 at cygnus dot com>]

Stephane Carrez wrote:
> 
> Hi Andrew,
> 
> Andrew Cagney wrote:
> >
> > Stephane Carrez wrote:
> > >
> > > Hi!
> > >
> > > One part of the patch for dwarf2 correction with 16-bit target has
> > > been lost. If you are still not convinced by the fix, have a look
> > > at gas/dwarf2dbg.c in out_set_addr() where we obtain the address
> > > size in a good way.
> > >
> > > Can you integrate it?
> >
> > FYI,
> >
> > My reading of the thread from when this patch was last posted is that it
> > wasn't clear that this was a bug and the change was the correct thing to
> > do.
> >
> For me, it's a bug. The address size specified in dwarf2 is 16 and
> because we use arch_size which corresponds to the ELF32/ELF64 size,
> gdb stops reading with an error (dwarf2read.c:983):
> 
>       if (address_size < address_significant_size)
>         {
>           error ("Dwarf Error: bad address size (%ld) in compilation unit header (offset 0x%lx +
> 11).",
>                  (long) cu_header.addr_size,
>                  (long) (beg_of_comp_unit - dwarf_info_buffer));
> 

As far as I know, the dwarf2 and elf information are both ment to be
self contained.  There shouldn't be any need to refer to some arbitrary
bfd table to determine what is going on.  If the info says that an
address is 16 bits for a given section then it sounds like GDB should
just believe it.

As JimK suggested:
> Or to put it another way, specifically what went wrong on the 68HC11
> if you didn't change dwarf2read.c?  If it was just the "Dwarf Error:
> bad address size" error, what happens if you just comment out that
> check?

Rather than diging values out of archures I think the possibility of:
	cu_header.address_size < elf-header.address_size
should be documented as being just as legetimate (sarcasm :-) as:
	cu_header.address_size > elf-header.address_size
and the check either replaced or removed.

	Andrew