bfd.flags&DYNAMIC vs. bfd_link_info.static

bfd.flags&DYNAMIC vs. bfd_link_info.static

[John Reiser]

In binutils-2.11/bfd/elf32-i386.c, function elf_i386_relocate_section()
tests elf_hash_table(info)->dynamic_sections_created
when it seems that output_bfd->flags & DYNAMIC, or info->static,
could be more correct.  For instance, the dynamic sections are
created for a static link (ET_EXEC) that uses shared libraries,
yet a GOT32 relocation in an input file (a compiled PIC reference
to a defined global) should get the same relocation, independent
of whether the output is linked against shared or not.
[A complete bug report was sent to bug-binutils last night;
link crtbeginS.o without -shared but with -lc, and check the
reference to __dso_handle in __do_global_dtors_aux.]

Also, it seems that bfd_link_info.static is rarely set.
bfd_elf32_bfd_final_link() should set the value near
settting abfd->flags |= DYNAMIC.  Or, there could be a
comment about the meaning, coverage, and overlap of
DYNAMIC, dynamic_sections_created, and .static.

--

Re: bfd.flags&DYNAMIC vs. bfd_link_info.static

[H . J . Lu]

On Fri, Jun 01, 2001 at 11:27:18AM -0700, John Reiser wrote:
> [A complete bug report was sent to bug-binutils last night;
> link crtbeginS.o without -shared but with -lc, and check the
> reference to __dso_handle in __do_global_dtors_aux.]

Please also CC your binutils bug reports to binutils@sources.redhat.com.
There are no archives for bug-binutils.


H.J.

Re: bfd.flags&DYNAMIC vs. bfd_link_info.static

[Philip Blundell]

>Please also CC your binutils bug reports to binutils@sources.redhat.com.
>There are no archives for bug-binutils.

Not specifically, but see e.g.

http://sources.redhat.com/ml/bug-gnu-utils/2001-05/msg00357.html

p.


-- 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.5 (GNU/Linux)
Comment: Exmh version 2.1.1 10/15/1999 (debian)

iD8DBQE7F/TLVTLPJe9CT30RAtXRAJ9g9Ps60ZhUo3lJtS0MOjsk8o7lHwCeIufc
9Sluh2JD3LDcocjm1JCdG1U=
=9Ndu
-----END PGP SIGNATURE-----

Re: bfd.flags&DYNAMIC vs. bfd_link_info.static

[H . J . Lu]

On Fri, Jun 01, 2001 at 09:02:19PM +0100, Philip Blundell wrote:
> >Please also CC your binutils bug reports to binutils@sources.redhat.com.
> >There are no archives for bug-binutils.
> 
> Not specifically, but see e.g.
> 
> http://sources.redhat.com/ml/bug-gnu-utils/2001-05/msg00357.html
> 

It is not accessible from

http://sources.redhat.com/binutils/


H.J.

Re: bfd.flags&DYNAMIC vs. bfd_link_info.static

[John Reiser]

> Please also CC your binutils bug reports to binutils@sources.redhat.com.
> There are no archives for bug-binutils.

OK.  I note that Philip Blundell has provided a reference in this case.

Should bfd/README be updated to add the second address for bug reporting?

-- 
John Reiser, jreiser@BitWagon.com

Re: bfd.flags&DYNAMIC vs. bfd_link_info.static

[H . J . Lu]

On Fri, Jun 01, 2001 at 01:07:46PM -0700, John Reiser wrote:
> > Please also CC your binutils bug reports to binutils@sources.redhat.com.
> > There are no archives for bug-binutils.
> 
> OK.  I note that Philip Blundell has provided a reference in this case.

I don't see anything wrong. You have to used -shared to create DSO.


H.J.

Re: bfd.flags&DYNAMIC vs. bfd_link_info.static

[John Reiser]

> I don't see anything wrong. You have to used -shared to create DSO.

The GOT32 relocation for __dso_handle is not perfomed correctly.
The pointer in the GOT is left as 0, instead of &__dso_handle
(or something that ld-linux.so.2 tuns into &__dso_handle; but
in this case there is a NONE relocation that is the "smoking gun".)

I don't want a DSO (ET_DYN), I want an ET_EXEC with the GOT32
relocation performed correctly.  

-- 
John Reiser, jreiser@BitWagon.com

Re: bfd.flags&DYNAMIC vs. bfd_link_info.static

[John Reiser]

This change helps, so far.
The NONE relocation is still present in .rel.got, but the slot itself
already has been relocated (output is ET_EXEC (no -shared), not ET_DYN).

--- ../../old/binutils-2.11/bfd/elf32-i386.c    Wed Feb 14 01:43:10 2001
+++ elf32-i386.c        Fri Jun  1 15:12:59 2001
@@ -1412,4 +1412,5 @@
                      && h->plt.offset != (bfd_vma) -1)
                  || (r_type == R_386_GOT32
+                      && !(h->elf_link_hash_flags & ELF_LINK_FORCED_LOCAL)
                      && elf_hash_table (info)->dynamic_sections_created
                      && (! info->shared
@@ -1483,4 +1484,5 @@
 
              if (! elf_hash_table (info)->dynamic_sections_created
+                  || h->elf_link_hash_flags & ELF_LINK_FORCED_LOCAL
                  || (info->shared
                      && (info->symbolic || h->dynindx == -1)

-- 
John Reiser, jreiser@BitWagon.com

Re: bfd.flags&DYNAMIC vs. bfd_link_info.static

[Alan Modra]

On Fri, Jun 01, 2001 at 03:30:57PM -0700, John Reiser wrote:
> This change helps, so far.
> The NONE relocation is still present in .rel.got, but the slot itself
> already has been relocated (output is ET_EXEC (no -shared), not ET_DYN).

I'm in the middle of fixing this, as I did for elf32-hppa.c just recently.

-- 
Alan Modra

elf32-i386.c .got

[Alan Modra]

This probably should be split up into three patches, in the same way
I organized the ChangeLog entries, but it was all done at one time and
I'm too lazy to break up the commits.

bfd/ChangeLog
	* elf32-i386.c (struct elf_i386_link_hash_table): Add sgot,
	sgotplt, srelgot, splt, srelplt, sdynbss, srelbss fields.
	(elf_i386_link_hash_table_create): Init them.
	(create_got_section): New function.
	(elf_i386_create_dynamic_sections): New function.
	(elf_backend_create_dynamic_sections): Set to above.
	(elf_i386_check_relocs): Use shortcuts from hash table rather than
	calling bfd_get_section_by_name.
	(elf_i386_gc_sweep_hook): Likewise.
	(elf_i386_adjust_dynamic_symbol): Likewise.
	(elf_i386_size_dynamic_sections): Likewise.
	(elf_i386_relocate_section): Likewise.
	(elf_i386_finish_dynamic_sections): Likewise.

The above is really only an optimization.  Calling bfd_get_section_by_name
inside functions like elf_i386_adjust_dynamic_section, which are called
via bfd_hash_traverse for all symbols can be a little expensive, especially
if we have a lot of sections (eg. gcc -ffunction-sections).  The following
a) delays allocation of .got and .rel.got space until
   size_dynamic_sections.  Garbage collection, symbol versioning and
   visibility, and shared library semantics combine to make it impossible
   to do so earlier without R_386_NONE relocs appearing in .rel.got.
b) Fixes initialisation of .got for symbols that have been forced local.
c) Implements .plt reference counting for all reloc types.  Previously,
   R_386_32 and R_386_PC32 relocs were not reference counted, so garbage
   collection wasn't ideal.

	* elf32-i386.c (elf_i386_check_relocs): Don't allocate .got and
	.relgot space here.
	(elf_i386_gc_sweep_hook): ..and no need to deallocate here..
	(elf32_hppa_adjust_dynamic_symbol): ..and don't allocate .plt and
	.rel.plt here..
	(allocate_plt_and_got): ..instead do it all here.  New function.
	(elf_i386_size_dynamic_sections): Allocate local .got space and
	call allocate_plt_and_got.  No need to zap .relgot if not dynamic.
	(bfd_elf32_bfd_final_link): Delete.  (ie. use regular final link
	rather than gc variety).
	(WILL_CALL_FINISH_DYNAMIC_SYMBOL): Define.
	(elf_i386_relocate_section): Use it here and correct handling of
	R_386_GOT32.  Provide section and offset for "unresolvable
	relocation" error message.
	(elf_i386_finish_dynamic_symbol): Correct handling of R_386_GOT32.

	* elf32-i386.c (elf_i386_discard_copies): Rename to
	discard_copies, and use elf_link_hash_entry arg rather than
	elf_i386_link_hash_entry.
	(elf_i386_link_hash_traverse): Delete.
	(elf_i386_size_dynamic_sections): Adjust call to discard_copies.
	Tidy sizing of dynamic sections.
	(elf_i386_check_relocs <R_386_32, R_386_PC32>): Reference count
	possible .plt entries.
	(elf_i386_gc_sweep_hook): Likewise.
	(elf_i386_adjust_dynamic_symbol): Discard .plt entries for
	everything with plt.refcount <= 0.

-- 
Alan Modra

Re: elf32-i386.c .got

[John Reiser]

>    x86.diff

With regard to relocating the reference to __dso_handle, the patched code
performs correctly, and leaves no R_386_NONE.

-- 
John Reiser, jreiser@BitWagon.com

Re: bfd.flags&DYNAMIC vs. bfd_link_info.static

[Philip Blundell]

>> Please also CC your binutils bug reports to binutils@sources.redhat.com.
>> There are no archives for bug-binutils.
>
>OK.  I note that Philip Blundell has provided a reference in this case.
>
>Should bfd/README be updated to add the second address for bug reporting?

No: bug-binutils is the right place to send reports about released versions.
I'll see if something can be done to create an archive of that list, or at
least link to the bug-gnu-utils archive from the binutils web page.

p.

-- 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.5 (GNU/Linux)
Comment: Exmh version 2.1.1 10/15/1999 (debian)

iD8DBQE7F/xTVTLPJe9CT30RAsPQAJ9XJbA/yGXOSoufsRH7C4zfWhmOogCg0c4P
Sj+B7RywaElAzpA3RSv4qfo=
=zn/W
-----END PGP SIGNATURE-----