JehanneOS/newlib
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

Better handking for unresolved symbols

Browse Source
This commit is contained in:
Nick Clifton 2003-08-20 08:37:14 +00:00
parent 6f6d673cc5
commit d704b32411
2 changed files with 33 additions and 18 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
include/ChangeLog
View File

@ -1,3 +1,12 @@
2003-08-20 Nick Clifton <nickc@redhat.com>
* bfdlink.h (enum report_method): New enum. Describes how to
report something.
(struct bfd_link_info): Delete fields 'no_undefined' and
'allow_shlib_undefined'. Replace with
'unresolved_symbols_in_objects' and
'unresolved_symbols_in_shared_libs'.
2003-08-07 Alan Modra <amodra@bigpond.net.au> 2003-08-07 Alan Modra <amodra@bigpond.net.au>
* bfdlink.h: Remove PARAMS macro. Replace PTR with void *. * bfdlink.h: Remove PARAMS macro. Replace PTR with void *.

42
include/bfdlink.h
View File

@ -198,6 +198,19 @@ struct bfd_sym_chain
const char *name; 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 /* This structure holds all the information needed to communicate
between BFD and the linker when doing a link. */ 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. */ need much more time and therefore must be explicitly selected. */
unsigned int optimize: 1; 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. */ /* TRUE if ok to have multiple definition. */
unsigned int allow_multiple_definition: 1; unsigned int allow_multiple_definition: 1;
@ -305,6 +300,17 @@ struct bfd_link_info
flags. */ flags. */
unsigned int noexecstack: 1; 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. */ /* Which symbols to strip. */
enum bfd_link_strip strip; enum bfd_link_strip strip;