* [PATCH, RFC] Fix _bfd_elf_provide_symbols for weak imports
@ 2005-04-27 19:58 Julian Brown
2005-04-27 20:02 ` Julian Brown
2005-04-27 20:10 ` H. J. Lu
0 siblings, 2 replies; 5+ messages in thread
From: Julian Brown @ 2005-04-27 19:58 UTC (permalink / raw)
To: binutils; +Cc: Julian Brown
Hi,
This patch fixes running __libc_{init,fini}_array (for
.{init,fini}_array sections) with Newlib. The symbols
__init_array_{start,end} etc. are imported as weak in Newlib, which
conflicts with (I think) this change to use
gld${EMULATION_NAME}_provide_bound_symbols rather than a linker script,
to provide such symbols:
http://sources.redhat.com/ml/binutils/2005-03/msg00688.html
Without the patch, the symbols resolved to zero, which stops static
object construction/destruction from working. This affects the current
csl-arm-branch gcc (and also soon mainline for the ARM EABI target, with
a patch that is currently blocked on this problem).
Tested on arm-none-eabi with cross and with all targets on
i686-pc-linux-gnu.
OK to apply?
Julian
ChangeLog:
bfd/
* elflink.c (_bfd_elf_provide_symbol): Provide symbol for weak import.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH, RFC] Fix _bfd_elf_provide_symbols for weak imports
2005-04-27 19:58 [PATCH, RFC] Fix _bfd_elf_provide_symbols for weak imports Julian Brown
@ 2005-04-27 20:02 ` Julian Brown
2005-04-27 21:35 ` H. J. Lu
2005-04-27 20:10 ` H. J. Lu
1 sibling, 1 reply; 5+ messages in thread
From: Julian Brown @ 2005-04-27 20:02 UTC (permalink / raw)
To: Julian Brown; +Cc: binutils
[-- Attachment #1: Type: text/plain, Size: 468 bytes --]
Julian Brown wrote:
> Hi,
>
> This patch fixes running __libc_{init,fini}_array (for
> .{init,fini}_array sections) with Newlib. The symbols
> __init_array_{start,end} etc. are imported as weak in Newlib, which
> conflicts with (I think) this change to use
> gld${EMULATION_NAME}_provide_bound_symbols rather than a linker script,
> to provide such symbols:
>
> http://sources.redhat.com/ml/binutils/2005-03/msg00688.html
>
And now, with the patch.
Julian
[-- Attachment #2: binutils-weak-boundary-syms --]
[-- Type: text/plain, Size: 1140 bytes --]
? bfd/doc/bfd.info
? bfd/doc/bfd.info-1
? gas/doc/as.info
? gas/doc/as.info-1
? gprof/gprof.info
? gprof/gprof.info-1
Index: bfd/elflink.c
===================================================================
RCS file: /cvs/src/src/bfd/elflink.c,v
retrieving revision 1.148
diff -c -p -r1.148 elflink.c
*** bfd/elflink.c 27 Apr 2005 10:09:43 -0000 1.148
--- bfd/elflink.c 27 Apr 2005 19:01:52 -0000
*************** _bfd_elf_provide_symbol (struct bfd_link
*** 9808,9814 ****
struct elf_link_hash_entry *h;
h = elf_link_hash_lookup (elf_hash_table (info), name, FALSE, FALSE,
FALSE);
! if (h != NULL && h->root.type == bfd_link_hash_undefined)
{
h->root.type = bfd_link_hash_defined;
h->root.u.def.section = bfd_abs_section_ptr;
--- 9808,9815 ----
struct elf_link_hash_entry *h;
h = elf_link_hash_lookup (elf_hash_table (info), name, FALSE, FALSE,
FALSE);
! if (h != NULL && (h->root.type == bfd_link_hash_undefined
! || h->root.type == bfd_link_hash_undefweak))
{
h->root.type = bfd_link_hash_defined;
h->root.u.def.section = bfd_abs_section_ptr;
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH, RFC] Fix _bfd_elf_provide_symbols for weak imports
2005-04-27 20:02 ` Julian Brown
@ 2005-04-27 21:35 ` H. J. Lu
2005-04-28 10:43 ` Nick Clifton
0 siblings, 1 reply; 5+ messages in thread
From: H. J. Lu @ 2005-04-27 21:35 UTC (permalink / raw)
To: Julian Brown; +Cc: binutils
On Wed, Apr 27, 2005 at 08:35:39PM +0100, Julian Brown wrote:
> Julian Brown wrote:
> >Hi,
> >
> >This patch fixes running __libc_{init,fini}_array (for
> >.{init,fini}_array sections) with Newlib. The symbols
> >__init_array_{start,end} etc. are imported as weak in Newlib, which
> >conflicts with (I think) this change to use
> >gld${EMULATION_NAME}_provide_bound_symbols rather than a linker script,
> >to provide such symbols:
> >
> > http://sources.redhat.com/ml/binutils/2005-03/msg00688.html
> >
>
> And now, with the patch.
>
> Julian
> ? bfd/doc/bfd.info
> ? bfd/doc/bfd.info-1
> ? gas/doc/as.info
> ? gas/doc/as.info-1
> ? gprof/gprof.info
> ? gprof/gprof.info-1
> Index: bfd/elflink.c
> ===================================================================
> RCS file: /cvs/src/src/bfd/elflink.c,v
> retrieving revision 1.148
> diff -c -p -r1.148 elflink.c
> *** bfd/elflink.c 27 Apr 2005 10:09:43 -0000 1.148
> --- bfd/elflink.c 27 Apr 2005 19:01:52 -0000
> *************** _bfd_elf_provide_symbol (struct bfd_link
> *** 9808,9814 ****
> struct elf_link_hash_entry *h;
> h = elf_link_hash_lookup (elf_hash_table (info), name, FALSE, FALSE,
> FALSE);
> ! if (h != NULL && h->root.type == bfd_link_hash_undefined)
> {
> h->root.type = bfd_link_hash_defined;
> h->root.u.def.section = bfd_abs_section_ptr;
> --- 9808,9815 ----
> struct elf_link_hash_entry *h;
> h = elf_link_hash_lookup (elf_hash_table (info), name, FALSE, FALSE,
> FALSE);
> ! if (h != NULL && (h->root.type == bfd_link_hash_undefined
> ! || h->root.type == bfd_link_hash_undefweak))
> {
> h->root.type = bfd_link_hash_defined;
> h->root.u.def.section = bfd_abs_section_ptr;
I think it is an obvious patch.
H.J.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH, RFC] Fix _bfd_elf_provide_symbols for weak imports
2005-04-27 21:35 ` H. J. Lu
@ 2005-04-28 10:43 ` Nick Clifton
0 siblings, 0 replies; 5+ messages in thread
From: Nick Clifton @ 2005-04-28 10:43 UTC (permalink / raw)
To: H. J. Lu, Julian Brown; +Cc: binutils
Hi Julian, Hi H.J.
>> struct elf_link_hash_entry *h;
>> h = elf_link_hash_lookup (elf_hash_table (info), name, FALSE, FALSE,
>> FALSE);
>>! if (h != NULL && h->root.type == bfd_link_hash_undefined)
>> {
>> h->root.type = bfd_link_hash_defined;
>> h->root.u.def.section = bfd_abs_section_ptr;
>>--- 9808,9815 ----
>> struct elf_link_hash_entry *h;
>> h = elf_link_hash_lookup (elf_hash_table (info), name, FALSE, FALSE,
>> FALSE);
>>! if (h != NULL && (h->root.type == bfd_link_hash_undefined
>>! || h->root.type == bfd_link_hash_undefweak))
>> {
>> h->root.type = bfd_link_hash_defined;
>> h->root.u.def.section = bfd_abs_section_ptr;
> I think it is an obvious patch.
I agree - Julian - I have applied your patch.
Cheers
Nick
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH, RFC] Fix _bfd_elf_provide_symbols for weak imports
2005-04-27 19:58 [PATCH, RFC] Fix _bfd_elf_provide_symbols for weak imports Julian Brown
2005-04-27 20:02 ` Julian Brown
@ 2005-04-27 20:10 ` H. J. Lu
1 sibling, 0 replies; 5+ messages in thread
From: H. J. Lu @ 2005-04-27 20:10 UTC (permalink / raw)
To: Julian Brown; +Cc: binutils
On Wed, Apr 27, 2005 at 08:31:34PM +0100, Julian Brown wrote:
> Hi,
>
> This patch fixes running __libc_{init,fini}_array (for
> .{init,fini}_array sections) with Newlib. The symbols
> __init_array_{start,end} etc. are imported as weak in Newlib, which
> conflicts with (I think) this change to use
> gld${EMULATION_NAME}_provide_bound_symbols rather than a linker script,
> to provide such symbols:
>
> http://sources.redhat.com/ml/binutils/2005-03/msg00688.html
>
> Without the patch, the symbols resolved to zero, which stops static
> object construction/destruction from working. This affects the current
> csl-arm-branch gcc (and also soon mainline for the ARM EABI target, with
> a patch that is currently blocked on this problem).
>
> Tested on arm-none-eabi with cross and with all targets on
> i686-pc-linux-gnu.
>
> OK to apply?
>
> Julian
>
> ChangeLog:
>
> bfd/
>
> * elflink.c (_bfd_elf_provide_symbol): Provide symbol for weak import.
Where is the patch?
H.J.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2005-04-28 10:32 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-04-27 19:58 [PATCH, RFC] Fix _bfd_elf_provide_symbols for weak imports Julian Brown
2005-04-27 20:02 ` Julian Brown
2005-04-27 21:35 ` H. J. Lu
2005-04-28 10:43 ` Nick Clifton
2005-04-27 20:10 ` H. J. Lu
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).