Re: PATCH: PR gas/5035: x86_64-pc-mingw32-as.exe failed to work

Re: PATCH: PR gas/5035: x86_64-pc-mingw32-as.exe failed to work

[Kai Tietz]

Hi J.H.,

> obj-coff.c doesn't check size of def_symbol_in_progress any other
> places. The only difference is set_function is used here.
> set_function is defined as
> 
> static symbolS *line_fsym;
> #define set_function(F)         (line_fsym = (F), coff_add_linesym (F))
> 
> I believe the check is wrong.

Yes, indeed. We should use here the bfd_hostptr_t, or remove it all.
BTW there are 'long' type array allocations, which may should use instead 
the bfd_hostptr_t, too. Because the imagebase is getting substracted by 
them, which is on 64-bit systems 64-bits wide. Additionally I found a 
fwrite of these longs as 4-byte value, without checking the endianess. I 
think this is not correct, too ?

Cheers,
 i.A. Kai Tietz

|  (\_/)  This is Bunny. Copy and paste Bunny
| (='.'=) into your signature to help him gain
| (")_(") world domination.

------------------------------------------------------------------------------------------
  OneVision Software Entwicklungs GmbH & Co. KG
  Dr.-Leo-Ritter-Straße 9 - 93049 Regensburg
  Tel: +49.(0)941.78004.0 - Fax: +49.(0)941.78004.489 - www.OneVision.com
  Commerzbank Regensburg - BLZ 750 400 62 - Konto 6011050
  Handelsregister: HRA 6744, Amtsgericht Regensburg
  Komplementärin: OneVision Software Entwicklungs Verwaltungs GmbH
  Dr.-Leo-Ritter-Straße 9 – 93049 Regensburg
  Handelsregister: HRB 8932, Amtsgericht Regensburg - Geschäftsführer: 
Ulrike Döhler, Manuela Kluger

Questions about use of type long in bfd.

[Kai Tietz]

Hi all,

inspirated by the patch of H.J. I investigated in bfd about the use of the 
type 'long' as data member and I found some points not sure if they are 
correct:

In the structure 'coff_final_link_info' the members sym_indices, indices, 
and outsyms are of type 'long *'('long') ?
In cofflink.c: _bfd_coff_generic_relocate_section line 2996: Use of fwrite 
?
In elf64-ppc.c: structure _ppc64_elf_section_data member opd_adjust has 
type long ?

Are these point OK for targets, when a 'long' is less than a pointer 
equaivalent scalar - eg. x86_64-pc-mingw32 ?

Cheers,
 i.A. Kai Tietz

|  (\_/)  This is Bunny. Copy and paste Bunny
| (='.'=) into your signature to help him gain
| (")_(") world domination.

------------------------------------------------------------------------------------------
  OneVision Software Entwicklungs GmbH & Co. KG
  Dr.-Leo-Ritter-Straße 9 - 93049 Regensburg
  Tel: +49.(0)941.78004.0 - Fax: +49.(0)941.78004.489 - www.OneVision.com
  Commerzbank Regensburg - BLZ 750 400 62 - Konto 6011050
  Handelsregister: HRA 6744, Amtsgericht Regensburg
  Komplementärin: OneVision Software Entwicklungs Verwaltungs GmbH
  Dr.-Leo-Ritter-Straße 9 – 93049 Regensburg
  Handelsregister: HRB 8932, Amtsgericht Regensburg - Geschäftsführer: 
Ulrike Döhler, Manuela Kluger

Re: Questions about use of type long in bfd.

[Alan Modra]

On Mon, Sep 17, 2007 at 11:40:05AM +0200, Kai Tietz wrote:
> In elf64-ppc.c: structure _ppc64_elf_section_data member opd_adjust has 
> type long ?
> 
> Are these point OK for targets, when a 'long' is less than a pointer 
> equaivalent scalar - eg. x86_64-pc-mingw32 ?

The elf64-ppc.c long *opd_adjust is fine until ld manages to remove
over 89 million functions from an executable.  :-)

-- 
Alan Modra
Australia Development Lab, IBM

Re: Questions about use of type long in bfd.

[Kai Tietz]

Alan Modra wrote on 17.09.2007 12:11:18:
> On Mon, Sep 17, 2007 at 11:40:05AM +0200, Kai Tietz wrote:
> > In elf64-ppc.c: structure _ppc64_elf_section_data member opd_adjust 
has 
> > type long ?
> > 
> > Are these point OK for targets, when a 'long' is less than a pointer 
> > equaivalent scalar - eg. x86_64-pc-mingw32 ?
> 
> The elf64-ppc.c long *opd_adjust is fine until ld manages to remove
> over 89 million functions from an executable.  :-)

Sounds fine enough 8-)
But the other points seems to be a bit more serious, AFAICS. Especially 
the fwrite issue in cofflink.c.

Cheers,
 i.A. Kai Tietz

|  (\_/)  This is Bunny. Copy and paste Bunny
| (='.'=) into your signature to help him gain
| (")_(") world domination.

------------------------------------------------------------------------------------------
  OneVision Software Entwicklungs GmbH & Co. KG
  Dr.-Leo-Ritter-Straße 9 - 93049 Regensburg
  Tel: +49.(0)941.78004.0 - Fax: +49.(0)941.78004.489 - www.OneVision.com
  Commerzbank Regensburg - BLZ 750 400 62 - Konto 6011050
  Handelsregister: HRA 6744, Amtsgericht Regensburg
  Komplementärin: OneVision Software Entwicklungs Verwaltungs GmbH
  Dr.-Leo-Ritter-Straße 9 – 93049 Regensburg
  Handelsregister: HRB 8932, Amtsgericht Regensburg - Geschäftsführer: 
Ulrike Döhler, Manuela Kluger

Re: Questions about use of type long in bfd.

[Nick Clifton]

Hi Kai,

> In cofflink.c: _bfd_coff_generic_relocate_section line 2996: Use of fwrite 
> ?

Look a little further back in the code where there is a comment describing why 
a long is being written:

   /* Relocation to a symbol in a section which isn't
      absolute.  We output the address here to a file.
      This file is then read by dlltool when generating the
      reloc section.  Note that the base file is not
      portable between systems.  We write out a long here,
      and dlltool reads in a long.  */


> In the structure 'coff_final_link_info' the members sym_indices, indices, 
> and outsyms are of type 'long *'('long') ?

You may have outdated sources.  In the version of libcoff-in.h that I am 
looking at the coff_final_link_info structure does not have an indices field 
and the outsyms field is a bfd_byte*.  The sym_indices field is a long* though 
and this does look like a possible bug.  Would you care to submit a patch for it ?

Cheers
   Nick

Re: Questions about use of type long in bfd.

[Kai Tietz]

Hi Nick,

> > In cofflink.c: _bfd_coff_generic_relocate_section line 2996: Use of 
fwrite 
> > ?
> 
> Look a little further back in the code where there is a comment 
> describing why 
> a long is being written:
> 
>    /* Relocation to a symbol in a section which isn't
>       absolute.  We output the address here to a file.
>       This file is then read by dlltool when generating the
>       reloc section.  Note that the base file is not
>       portable between systems.  We write out a long here,
>       and dlltool reads in a long.  */
> 
> 
> > In the structure 'coff_final_link_info' the members sym_indices, 
indices, 
> > and outsyms are of type 'long *'('long') ?
> 
> You may have outdated sources.  In the version of libcoff-in.h that I am 

> looking at the coff_final_link_info structure does not have an indices 
field 
> and the outsyms field is a bfd_byte*.  The sym_indices field is a 
> long* though 
> and this does look like a possible bug.  Would you care to submit a 
> patch for it ?

Thank you for anwsering. AFAI checked the sources, the 'long' type for 
sym_indices seems to be fine. May it could be altered to a new type as 
bfd_signed_size_type (according to bfd_size_type).

Sorry, for making the noice.

Cheers,
 i.A. Kai Tietz

|  (\_/)  This is Bunny. Copy and paste Bunny
| (='.'=) into your signature to help him gain
| (")_(") world domination.

------------------------------------------------------------------------------------------
  OneVision Software Entwicklungs GmbH & Co. KG
  Dr.-Leo-Ritter-Straße 9 - 93049 Regensburg
  Tel: +49.(0)941.78004.0 - Fax: +49.(0)941.78004.489 - www.OneVision.com
  Commerzbank Regensburg - BLZ 750 400 62 - Konto 6011050
  Handelsregister: HRA 6744, Amtsgericht Regensburg
  Komplementärin: OneVision Software Entwicklungs Verwaltungs GmbH
  Dr.-Leo-Ritter-Straße 9 – 93049 Regensburg
  Handelsregister: HRB 8932, Amtsgericht Regensburg - Geschäftsführer: 
Ulrike Döhler, Manuela Kluger

Re: PATCH: PR gas/5035: x86_64-pc-mingw32-as.exe failed to work

[Nick Clifton]

Hi H.J.

> 2007-09-16  H.J. Lu  <hongjiu.lu@intel.com>
> 
> 	PR gas/5035
> 	* config/obj-coff.c (obj_coff_endef): Remove checking size of
> 	def_symbol_in_progress.

Approved - please apply.

Cheers
   Nick

PATCH: PR gas/5035: x86_64-pc-mingw32-as.exe failed to work

[H.J. Lu]

obj-coff.c doesn't check size of def_symbol_in_progress any other
places. The only difference is set_function is used here.
set_function is defined as

static symbolS *line_fsym;
#define set_function(F)         (line_fsym = (F), coff_add_linesym (F))

I believe the check is wrong.


H.J.
----
2007-09-16  H.J. Lu  <hongjiu.lu@intel.com>

	PR gas/5035
	* config/obj-coff.c (obj_coff_endef): Remove checking size of
	def_symbol_in_progress.

--- gas/config/obj-coff.c.foo	2007-07-03 06:45:19.000000000 -0700
+++ gas/config/obj-coff.c	2007-09-16 15:07:25.000000000 -0700
@@ -777,7 +777,6 @@ obj_coff_endef (int ignore ATTRIBUTE_UNU
 
   if (SF_GET_FUNCTION (def_symbol_in_progress))
     {
-      know (sizeof (def_symbol_in_progress) <= sizeof (long));
       set_function (def_symbol_in_progress);
       SF_SET_PROCESS (def_symbol_in_progress);