This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils 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: RFA: Skip ARM ELF Mapping symbols when showing disassembly


So GDB and objdump both need this information? How does objdump handle
all this?

- should there be a BFD method that lets GDB better identify a user visibile [minimal] symbol (gdb's elf reader currently contains what can only be described as heuristics).

- should there be a BFD method that, given an address and symbol table, indicates the relevant ISA/ABI?

- or even just have BFD export name->addr and addr->name methods?

Andrew



The real question should be "what does gdb/objdump need to know?". I think the answer to this is that it needs to know what is at a particular address in an image. In other words, it needs to be asking "what type of object is at address X?" How that information is stored in the image is not of particular interest outside of the BFD. In particular, it shouldn't matter whether the information is stored in mapping symbols or some other section in the object file.

So I think the bfd needs to export a bfd_map_address_to_type() interface that hides all the details of the representation behind it. What's less clear is what types need to be returned, for ARM we really need to return something like BFD_OBJECT_DATA, BFD_OBJECT_ARM or BFD_OBJECT_THUMB, but it would vary from processor to processor.

It's at this point, things get weird.


BFD hands GDB a raw symbol table (ignoring coff m'kay) and then GDB implements the search algorithm. To implement a addr->attrib method, BFD's going to need a mechanism for searching GDB's symbol table and/or get at the underlying bfd symbol table.

That's why I mention the third one. Throw the whole problem back at BFD :-) Why does GDB even need a minimal symbol table anyway ....

Andrew



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