summaryrefslogtreecommitdiff
path: root/include/bfdlink.h
diff options
context:
space:
mode:
authorNick Clifton <nickc@redhat.com>2003-08-20 08:37:19 +0000
committerNick Clifton <nickc@redhat.com>2003-08-20 08:37:19 +0000
commit8d7cab1f462b2032b5977c11a0ef57ba61107dbc (patch)
tree29043610c2d2b8bf639c77148b60c7022c893bee /include/bfdlink.h
parentd04e7b07c8d389527908c19a24a778185fac2c18 (diff)
downloadgdb-8d7cab1f462b2032b5977c11a0ef57ba61107dbc.tar.gz
Better handking for unresolved symbols
Diffstat (limited to 'include/bfdlink.h')
-rw-r--r--include/bfdlink.h42
1 files changed, 24 insertions, 18 deletions
diff --git a/include/bfdlink.h b/include/bfdlink.h
index e8fc65f4bd0..c174dcdc698 100644
--- a/include/bfdlink.h
+++ b/include/bfdlink.h
@@ -198,6 +198,19 @@ struct bfd_sym_chain
const char *name;
};
+/* How to handle unresolved symbols.
+ There are four possibilities which are enumerated below: */
+enum report_method
+{
+ /* This is the initial value when then link_info structure is created.
+ It allows the various stages of the linker to determine whether they
+ allowed to set the value. */
+ RM_NOT_YET_SET = 0,
+ RM_IGNORE,
+ RM_GENERATE_WARNING,
+ RM_GENERATE_ERROR
+};
+
/* This structure holds all the information needed to communicate
between BFD and the linker when doing a link. */
@@ -238,24 +251,6 @@ struct bfd_link_info
need much more time and therefore must be explicitly selected. */
unsigned int optimize: 1;
- /* TRUE if BFD should generate errors for undefined symbols
- even if generating a shared object. */
- unsigned int no_undefined: 1;
-
- /* TRUE if BFD should allow undefined symbols in shared objects even
- when no_undefined is set to disallow undefined symbols. The net
- result will be that undefined symbols in regular objects will
- still trigger an error, but undefined symbols in shared objects
- will be ignored. The implementation of no_undefined makes the
- assumption that the runtime linker will choke on undefined
- symbols. However there is at least one system (BeOS) where
- undefined symbols in shared libraries is normal since the kernel
- patches them at load time to select which function is most
- appropriate for the current architecture. I.E. dynamically
- select an appropriate memset function. Apparently it is also
- normal for HPPA shared libraries to have undefined symbols. */
- unsigned int allow_shlib_undefined: 1;
-
/* TRUE if ok to have multiple definition. */
unsigned int allow_multiple_definition: 1;
@@ -305,6 +300,17 @@ struct bfd_link_info
flags. */
unsigned int noexecstack: 1;
+ /* What to do with unresolved symbols in an object file.
+ When producing static binaries the default is GENERATE_ERROR.
+ When producing dynamic binaries the default is IGNORE. The
+ assumption with dynamic binaries is that the reference will be
+ resolved at load/execution time. */
+ enum report_method unresolved_syms_in_objects;
+
+ /* What to do with unresolved symbols in a shared library.
+ The same defaults apply. */
+ enum report_method unresolved_syms_in_shared_libs;
+
/* Which symbols to strip. */
enum bfd_link_strip strip;