aboutsummaryrefslogtreecommitdiff
path: root/bfd/TODO
diff options
context:
space:
mode:
authorDavid MacKenzie <djm@cygnus>1993-08-07 22:38:22 +0000
committerDavid MacKenzie <djm@cygnus>1993-08-07 22:38:22 +0000
commit5f9a2245d8cbdac6cf6f3da81099e68d224e6256 (patch)
tree88a74c1fc3f8f3724027acea3597defa5780d684 /bfd/TODO
parent379dd9658225106674625254fa36004958819b47 (diff)
downloadgdb-5f9a2245d8cbdac6cf6f3da81099e68d224e6256.zip
gdb-5f9a2245d8cbdac6cf6f3da81099e68d224e6256.tar.gz
gdb-5f9a2245d8cbdac6cf6f3da81099e68d224e6256.tar.bz2
make target selection fully configurable
Diffstat (limited to 'bfd/TODO')
-rw-r--r--bfd/TODO60
1 files changed, 22 insertions, 38 deletions
diff --git a/bfd/TODO b/bfd/TODO
index 26fd83b..8d39107 100644
--- a/bfd/TODO
+++ b/bfd/TODO
@@ -1,41 +1,25 @@
-Things that still need to be handled: -*- Text -*-
+Things that still need to be done: -*- Text -*-
+
+ o - A source of space lossage is that all the target-dependent
+ code is in a single bfd_target structure. Hence all the code
+ for *writing* object files is still pulled into all the applications
+ that only care about *reading* (gdb, nm, objdump), while gas
+ has to carry along all the unneded baggage for reading objects.
+ And so one. This would be a much more substantial change,
+ and the payoff would be less (essentially none if bfd is
+ used as a shared library).
+
+ o - The storage needed by BFD data structures is also larger than strictly
+ needed. This may be difficult to do much about.
- o - change the memory usage to reflect the message which follows the
- page break.
o - implement bfd_abort, which should close the bfd but not alter the
filesystem.
- o - update the bfd doc; write a how-to-write-a-backend doc.
- o - change reloc handling as per Steve's suggestion.
- (more details please.....)
-
-Changing the way bfd uses memory. The new convention is simple:
-
- o - bfd will never write into user-supplied memory, nor attempt to
- free it.
- o - closing a bfd may reclaim all bfd-allocated memory associated
- with that bfd.
- - - bfd_target_list will be the one exception; you must reclaim the
- returned vector yourself.
-
-Interface implications are minor (get_symcount_upper_bound will go
-away; bfd_cannicalize_symtab will allocate its own memory, etc).
-
-Certain operations consume a lot of memory; for them manual
-reclaimation is available:
-
- o - bfd_canonicalize_symtab will return a pointer to a
- null-terminated vector of symbols. Subsequent calls may or may
- not return the same pointer.
- bfd_canonicalize_relocs will do the same; returning a pointer to
- an array of arelocs. Calling this function will read symbols in
- too.
-
- o - bfd_reclaim_relocs will free the memory used by these relocs.
- the symbols will be untouched.
- bfd_reclaim_symtab (ne bfd_reclaim_symbol_table) will free the
- memory allocated by canonialize_symtab.
- Since relocations point to symbols, any relocations obtained by a
- call to bfd_canonicalize_relocs will be reclaimed as well.
-
- o - if you don't call the reclaim_ functions, the memory will be
- reclaimed at bfd_close time.
+
+ o - update the bfd doc; write a how-to-write-a-backend doc, take out
+ the stupid quips and fill in all the blanks.
+
+ o - upgrade the reloc handling as per Steve's suggestion.
+
+
+
+