This is the mail archive of the gdb-patches@sourceware.org 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: MIPS: Handle manual calls of MIPS16 functions with a call stub


On Feb 13, 2008 10:27 AM, Maciej W. Rozycki <macro@mips.com> wrote:
> On Fri, 8 Feb 2008, Jim Blandy wrote:
> > Putting ISA information in low bits of DWARF attribute values isn't
> > the way we've decided to do things.
>
>  Unfortunately this is what the current versions of the relevant tools do
> and I think it has been like this for a while.  The linker does not
> differentiate between relocations used for taking an address of a function
> for the purpose of making a call and for other uses and the same
> relocation types are used in both cases.
>
>  Ultimately it is the linker that should be fixed (though from the current
> behaviour I think GAS has a problem here as well), but I am afraid broken
> tools and broken binaries are going to be out there for a while yet, so it
> may be a reasonable idea to try to handle them as well as possible.  I
> recognise pointer_to_address() may not be the best choice here though.
>
>  However I think it will have to be involved anyway elsewhere as I find
> the current model assumed by GDB inconsistent.

It seems that we all agree on the following:

- It's contrary to the DWARF spec for producers to put arch-specific
  information in the low bits of the addresses in the line number
  table, function and block address ranges, and so on.  Existing
  toolchains that do this are buggy, but that's life.

- The addresses in GDB's line tables and block ranges should not have
  such extra bits set in them.

- The proper place to store arch-specific data on minimal symbols is
  in the 'info' field of 'struct minimal_symbol'.  In cases like
  MIPS16, the gdbarch_push_dummy_call method can consult that
  information at call time to see which calling convention is
  appropriate.

If we agree that we want to work around the linker bugs in GDB's
reader, that means we have to clear those bits and stash the
information elsewhere when we read the DWARF.  So something like
Maciej's original patch doesn't seem wrong to me.

The name 'make_symbol_special' seems awfully vague, though.  Is the
term 'special' inherited from outside GDB, or did it originate within
GDB?  In either case, I don't want it propagating into the DWARF
reader; that's horrible.  :)


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