PATCH: w64 native support

[Kai Tietz]

Hello,

trying to build libbfd and the other binutils tools native for x86_64
mingw, I noticed some bugs in libbfd and other places, where the type
"long" was used instead of the bfd_vma type for may pointer values. Also I
introduced for libiberty "splay-tree.h" a necessary patch about
pointer/long sizes.

ChangeLogs:

For bfd:

2007-04-10 Kai Tietz <***@onevision.com>

* bfd/coffcode.h: Replace use of long by bfd_vma.
* bfd/coffgen.c: Likewise.
* bfd/elf-eh-frame.c: Likewise.
* bfd/peicode.h: Likewise.

For binutils:

2007-04-10 Kai Tietz <***@onevision.com>

* binutils/resres.c: Cast sizeof explicit to type "long".

For gas:

2007-04-10 Kai Tietz <***@onevision.com>

* gas/symbols.c: Replace use of long by bfd_vma and
print via fprintf_vma.
* gas/write.c: Likewise.

For gprof:

2007-04-10 Kai Tietz <***@onevision.com>

* gprof/cg_print.c: Explict cast sizeof to long.
* gprof/hist.c: Likewise.

For include:

2007-04-10 Kai Tietz <***@onevision.com>

* include/splay-tree.h: (libi_uhostptr_t): New type.
(libi_shostptr_t): New type.
(splay_tree_key, splay_tree_value): Use libi_uhostptr_t type.
* include/coff/internal.h: (_n_zeroes, _n_offset): Type vma_bfd.


For libiberty:

2007-04-10 Kai Tietz <***@onevision.com>

* libiberty/strerror.c: Undefine sys_nerr and sys_errlist for w64
sake.

Regards,
i.A. Kai Tietz



------------------------------------------------------------------------------------------
OneVision Software Entwicklungs GmbH & Co. KG
Dr.-Leo-Ritter-Straße 9 - 93049 Regensburg
Tel: [phone] - Fax: [phone] - 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

[Kai Tietz]

Have you looked at
http://sources.redhat.com/bugzilla/show_bug.cgi?id=2737
Does windres work for x64?

I replaced in all structures of windres.h the type "unsigned long" by
"unsigned int" for test and patched the dependent files to use not

long

type-specifier in printf methods. It works that way, but I am not

certain,

if this would break an other target, where "int" isn't 4 bytes long ?

^^^^^
It should be host, not target.
It is better than what we have today. You can add
assert (sizeof (int) == 4);
somewhere.

Ok, I on that.

But I noticed, while bootstrap my patch on it on cygwin, that the
replacement of long to bfd_vma does not work as explected for 32-bit hosts
and using --enable-64-bit-bfd. Gcc claims, that pointer size and integer
size are not fitting.
I think, we have to introduce a type bfd_hostptr_t or something like that
to solve this problem ?

Regards,
i.A. Kai Tietz

------------------------------------------------------------------------------------------
OneVision Software Entwicklungs GmbH & Co. KG
Dr.-Leo-Ritter-Straße 9 - 93049 Regensburg
Tel: [phone] - Fax: [phone] - 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üh

[H. J. Lu]

Post by Kai Tietz

Have you looked at
http://sources.redhat.com/bugzilla/show_bug.cgi?id=2737
Does windres work for x64?

I replaced in all structures of windres.h the type "unsigned long" by
"unsigned int" for test and patched the dependent files to use not

long

type-specifier in printf methods. It works that way, but I am not

certain,

if this would break an other target, where "int" isn't 4 bytes long ?

^^^^^
It should be host, not target.
It is better than what we have today. You can add
assert (sizeof (int) == 4);
somewhere.

Ok, I on that.
But I noticed, while bootstrap my patch on it on cygwin, that the
replacement of long to bfd_vma does not work as explected for 32-bit hosts
and using --enable-64-bit-bfd. Gcc claims, that pointer size and integer
size are not fitting.
I think, we have to introduce a type bfd_hostptr_t or something like that
to solve this problem ?

I don't think it is needed. --enable-64-bit-bfd works fine for
Linux/x86. If --enable-64-bit-bfd doesn't work for cygwin, it
should be fixed.


H.J.

[H. J. Lu]

Post by H. J. Lu

Post by Kai Tietz

Have you looked at
http://sources.redhat.com/bugzilla/show_bug.cgi?id=2737
Does windres work for x64?

I replaced in all structures of windres.h the type "unsigned long" by
"unsigned int" for test and patched the dependent files to use not

long

type-specifier in printf methods. It works that way, but I am not

certain,

if this would break an other target, where "int" isn't 4 bytes long ?

^^^^^
It should be host, not target.
It is better than what we have today. You can add
assert (sizeof (int) == 4);
somewhere.

Ok, I on that.
But I noticed, while bootstrap my patch on it on cygwin, that the
replacement of long to bfd_vma does not work as explected for 32-bit hosts
and using --enable-64-bit-bfd. Gcc claims, that pointer size and integer
size are not fitting.
I think, we have to introduce a type bfd_hostptr_t or something like that
to solve this problem ?

I don't think it is needed. --enable-64-bit-bfd works fine for
Linux/x86. If --enable-64-bit-bfd doesn't work for cygwin, it
should be fixed.

I think the main problem of the PE port may be there is no clear
line bewteen internal and external data structure so that it is very
hard to cross compile a PE target on a differnt endian or 64bit host.


H.J.

[H. J. Lu]

Post by Kai Tietz
Hello,
trying to build libbfd and the other binutils tools native for x86_64
mingw, I noticed some bugs in libbfd and other places, where the type
"long" was used instead of the bfd_vma type for may pointer values. Also I
introduced for libiberty "splay-tree.h" a necessary patch about
pointer/long sizes.

Have you looked at

http://sources.redhat.com/bugzilla/show_bug.cgi?id=2737

Does windres work for x64?


H.J.

[Kai Tietz]

Post by Kai Tietz
Hello,
trying to build libbfd and the other binutils tools native for x86_64
mingw, I noticed some bugs in libbfd and other places, where the type
"long" was used instead of the bfd_vma type for may pointer values. Also I
introduced for libiberty "splay-tree.h" a necessary patch about
pointer/long sizes.

Have you looked at
http://sources.redhat.com/bugzilla/show_bug.cgi?id=2737
Does windres work for x64?

For x64 mingw yes, because the type long remains 32-bit in MS ABI. This
bug seems to be more a bug of mingw headers for x64 linux. Because on x64
linux the long becomes 64-bit wide, but for MS abi this isn't true. May
the types of this defines as DWORD should be retyped as "unsigned int" ?
On MS Abi there is a new type DWORD64 for 64-bit width.

Regards,
i.A. Kai Tietz

------------------------------------------------------------------------------------------
OneVision Software Entwicklungs GmbH & Co. KG
Dr.-Leo-Ritter-Straße 9 - 93049 Regensburg
Tel: [phone] - Fax: [phone] - 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,

[Kai Tietz]

Have you looked at
http://sources.redhat.com/bugzilla/show_bug.cgi?id=2737
Does windres work for x64?

I replaced in all structures of windres.h the type "unsigned long" by
"unsigned int" for test and patched the dependent files to use not long
type-specifier in printf methods. It works that way, but I am not certain,
if this would break an other target, where "int" isn't 4 bytes long ?

Regards,
i.A. Kai Tietz

------------------------------------------------------------------------------------------
OneVision Software Entwicklungs GmbH & Co. KG
Dr.-Leo-Ritter-Straße 9 - 93049 Regensburg
Tel: [phone] - Fax: [phone] - 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:
Ulr

[H. J. Lu]

Have you looked at
http://sources.redhat.com/bugzilla/show_bug.cgi?id=2737
Does windres work for x64?

I replaced in all structures of windres.h the type "unsigned long" by
"unsigned int" for test and patched the dependent files to use not long
type-specifier in printf methods. It works that way, but I am not certain,
if this would break an other target, where "int" isn't 4 bytes long ?

^^^^^
It should be host, not target.

It is better than what we have today. You can add

assert (sizeof (int) == 4);

somewhere.


H.J.

[Paul Koning]

Have you looked at
http://sources.redhat.com/bugzilla/show_bug.cgi?id=2737
Does windres work for x64?

I replaced in all structures of windres.h the type "unsigned long"
by "unsigned int" for test and patched the dependent files to use
not long type-specifier in printf methods. It works that way, but
I am not certain, if this would break an other target, where "int"
isn't 4 bytes long ?

H> ^^^^^ It should be host, not target.

H> It is better than what we have today. You can add

H> assert (sizeof (int) == 4);

Ok, I'll ask a dump question.

Isn't this the sort of platform specific type stuff that "configure"
was invented for?

paul

[Kai Tietz]

Hello,

I did the windres.h patch changing the long to int types, so that problem
#2737 seems to be solved.
Additionally I introduced in bfd-in.h the type "bfd_hostptr_t" and its
hexadeicmal printf representation in macro "BFD_HOSTPTR_T_PRT_X". For now,
AFAIS, only WIN64 has a long type lesser than a pointer, therefore I made
the define dependent on the definiton of _WIN64. The modification in
splay-tree.h header has the same reason.

ChangeLogs:

For bfd:

2007-04-11 Kai Tietz <***@onevision.com>

* bfd/bfd-in.h: (bfd_hostptr_t): New type for max(long,void *)
width.
(BFD_HOSTPTR_T_PRT_X): Printf a bfd_hostptr_t type.
* bfd/bfd-in2.h: Regenerate.
* bfd/coffcode.h: Replace use of long by bfd_hostptr_t.
* bfd/coffgen.c: Likewise.
* bfd/elf-eh-frame.c: Likewise.
* bfd/peicode.h: Likewise.

For binutils:

2007-04-10 Kai Tietz <***@onevision.com>

* binutils/resres.c: Cast sizeof explicit to type "long".
* binutils/resrc.c: Adjust printf formatter for ints.
* binutils/windres.c: (main): Assert if sizeof(int) not 4 bytes.
* binutils/windres.h: Changed windows structure to use
int type instead of long type.

For gas:

2007-04-10 Kai Tietz <***@onevision.com>

* gas/symbols.c: Replace use of long by bfd_hostptr_t and
print via BFD_HOSTPTR_T_PRT_X.
* gas/write.c: Likewise.

For gprof:

2007-04-10 Kai Tietz <***@onevision.com>

* gprof/cg_print.c: Explict cast sizeof to long.
* gprof/hist.c: Likewise.

For include:

2007-04-10 Kai Tietz <***@onevision.com>

* include/splay-tree.h: (libi_uhostptr_t): New type.
(libi_shostptr_t): New type.
(splay_tree_key, splay_tree_value): Use libi_uhostptr_t type.
* include/coff/internal.h: (_n_zeroes, _n_offset): Type as
bfd_hostptr_t
instead of long.


For libiberty:

2007-04-10 Kai Tietz <***@onevision.com>

* libiberty/strerror.c: Undefine sys_nerr and sys_errlist for w64
sake.

Regards,
i.A. Kai Tietz



------------------------------------------------------------------------------------------
OneVision Software Entwicklungs GmbH & Co. KG
Dr.-Leo-Ritter-Straße 9 - 93049 Regensburg
Tel: [phone] - Fax: [phone] - 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

[H. J. Lu]

Post by Kai Tietz
Hello,
I did the windres.h patch changing the long to int types, so that problem
#2737 seems to be solved.

No, it doesn't work on big endian host. You should array of char
in external data structures.

Post by Kai Tietz
Additionally I introduced in bfd-in.h the type "bfd_hostptr_t" and its
hexadeicmal printf representation in macro "BFD_HOSTPTR_T_PRT_X". For now,
AFAIS, only WIN64 has a long type lesser than a pointer, therefore I made
the define dependent on the definiton of _WIN64. The modification in

I don't believe we need BFD_HOSTPTR_T_PRT_X. As I said before, the
PE problem is there is no clear line between external and internal
data structues. You should be able to use long long, even in big
endian, internally to hold any PE data type. You just need to convert
it to the proper size in proper endian when you write it out. You
shouldn't have any problem when it is done peoperly.


H.J.

[H. J. Lu]

Post by H. J. Lu

Post by Kai Tietz
Hello,
I did the windres.h patch changing the long to int types, so that problem
#2737 seems to be solved.

No, it doesn't work on big endian host. You should array of char
in external data structures.

Post by Kai Tietz
Additionally I introduced in bfd-in.h the type "bfd_hostptr_t" and its
hexadeicmal printf representation in macro "BFD_HOSTPTR_T_PRT_X". For now,
AFAIS, only WIN64 has a long type lesser than a pointer, therefore I made
the define dependent on the definiton of _WIN64. The modification in

I don't believe we need BFD_HOSTPTR_T_PRT_X. As I said before, the
PE problem is there is no clear line between external and internal
data structues. You should be able to use long long, even in big
endian, internally to hold any PE data type. You just need to convert
it to the proper size in proper endian when you write it out. You
shouldn't have any problem when it is done peoperly.

We do need a new type when casting from pointer to integer. But
it should be determined in autoconf. You can use AC_CHECK_SIZEOF.


H.J.

[Kai Tietz]

Hello,

I have isolated the windres patch from the w64 one.

ChangeLog:

2007-04-11 Kai Tietz <***@onevision.com>

* binutils/resres.c: Cast sizeof explicit to type "long".
(res_hdr): Changed to use int instead of long.
(resres_host_bigendian, HOST_ISBIGENDIAN): Check for
big endian hosts.
(write_res_data_16, write_res_data_32, write_res_data_res_hdr,
read_res_data_16, read_res_data_32, read_res_data_res_hdr): New.
* binutils/resrc.c: Adjust printf formatter for ints.
* binutils/windres.c: (main): Assert if sizeof(int) not 4 bytes.
* binutils/windres.h: Changed windows structure to use
int type instead of long type.

Regards,
i.A. Kai Tietz


------------------------------------------------------------------------------------------
OneVision Software Entwicklungs GmbH & Co. KG
Dr.-Leo-Ritter-Straße 9 - 93049 Regensburg
Tel: [phone] - Fax: [phone] - 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

[H. J. Lu]

Post by Kai Tietz
Hello,
I have isolated the windres patch from the w64 one.
* binutils/resres.c: Cast sizeof explicit to type "long".
(res_hdr): Changed to use int instead of long.
(resres_host_bigendian, HOST_ISBIGENDIAN): Check for
big endian hosts.
(write_res_data_16, write_res_data_32, write_res_data_res_hdr,
read_res_data_16, read_res_data_32, read_res_data_res_hdr): New.
* binutils/resrc.c: Adjust printf formatter for ints.
* binutils/windres.c: (main): Assert if sizeof(int) not 4 bytes.
* binutils/windres.h: Changed windows structure to use
int type instead of long type.

Can you try to use existing data type I/O routines in bfd?


H.J.

[Kai Tietz]

Post by H. J. Lu
Can you try to use existing data type I/O routines in bfd?

You mean the endian swapping ?

Regards,
i.A. Kai Tietz

------------------------------------------------------------------------------------------
OneVision Software Entwicklungs GmbH & Co. KG
Dr.-Leo-Ritter-Straße 9 - 93049 Regensburg
Tel: [phone] - Fax: [phone] - 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ö

[H. J. Lu]

Post by Kai Tietz

Post by H. J. Lu
Can you try to use existing data type I/O routines in bfd?

You mean the endian swapping ?

Yes. Also you should use

unsigned char characteristics [4];

instead of

unsigned long characteristics;

or

unsigned int characteristics;


H.J.

[Kai Tietz]

Post by H. J. Lu

Post by Kai Tietz

Post by H. J. Lu
Can you try to use existing data type I/O routines in bfd?

You mean the endian swapping ?

Yes. Also you should use
unsigned char characteristics [4];
instead of
unsigned long characteristics;
or
unsigned int characteristics;

Nightmares, ... 8| I begun to modify structure using character arrays ...
I come to the point, that this means for big parts of windres better a
complete rewrite. Structures with internal/external scope and data
modifications are really wired.
May we should first use my last patch, so that the problem is solved, and
then I will begin to reorganize the windres tool to be host idependent. By
this I can add some missing resource types to it.

What do you think about my suggestion to continue ?

Regards,
i.A. Kai Tietz

------------------------------------------------------------------------------------------
OneVision Software Entwicklungs GmbH & Co. KG
Dr.-Leo-Ritter-Straße 9 - 93049 Regensburg
Tel: [phone] - Fax: [phone] - 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 Klug

[H. J. Lu]

Post by Kai Tietz

Post by H. J. Lu

Post by Kai Tietz

Post by H. J. Lu
Can you try to use existing data type I/O routines in bfd?

You mean the endian swapping ?

Yes. Also you should use
unsigned char characteristics [4];
instead of
unsigned long characteristics;
or
unsigned int characteristics;

Nightmares, ... 8| I begun to modify structure using character arrays ...
I come to the point, that this means for big parts of windres better a
complete rewrite. Structures with internal/external scope and data
modifications are really wired.
May we should first use my last patch, so that the problem is solved, and
then I will begin to reorganize the windres tool to be host idependent. By
this I can add some missing resource types to it.
What do you think about my suggestion to continue ?

That is fine with me. If you do this, you don't need to handle
endian and just replace long with int since you will rewrite it
later anyway.


H.J.

[Kai Tietz]

Post by H. J. Lu

Post by Kai Tietz
Nightmares, ... 8| I begun to modify structure using character arrays ...
I come to the point, that this means for big parts of windres better a
complete rewrite. Structures with internal/external scope and data
modifications are really wired.
May we should first use my last patch, so that the problem is solved, and
then I will begin to reorganize the windres tool to be host

idependent. By

Post by H. J. Lu

Post by Kai Tietz
this I can add some missing resource types to it.
What do you think about my suggestion to continue ?

That is fine with me. If you do this, you don't need to handle
endian and just replace long with int since you will rewrite it
later anyway.

This is the patch changing the windres source using int instead of long. I
bootstrap it on cygwin 32 and for x86_64-mingw.
This patch does not solve the endian problem, reasoned by the use of
fwrite/fread.
ChangeLog for binutils/:

2007-04-16 Kai Tietz <***@onevision.com>

* rclex.l: Replace long by int usage.
* rcparse.y: Likewise.
* resbin.c: Likewise.
* rescoff.c: Likewise.
* resrc.c: Likewise.
* resres.c: Likewise.
* windres.h: Likewise.
* windres.c: Likewise.
(main): Add assert if sizeof int has not 4 byte
size.


Regards,
i.A. Kai Tietz



------------------------------------------------------------------------------------------
OneVision Software Entwicklungs GmbH & Co. KG
Dr.-Leo-Ritter-Straße 9 - 93049 Regensburg
Tel: [phone] - Fax: [phone] - 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

[Christopher Faylor]

Post by Kai Tietz

Post by H. J. Lu

Post by Kai Tietz
Nightmares, ... 8| I begun to modify structure using character arrays

...

Post by H. J. Lu

Post by Kai Tietz
I come to the point, that this means for big parts of windres better a
complete rewrite. Structures with internal/external scope and data
modifications are really wired.
May we should first use my last patch, so that the problem is solved,

and

Post by H. J. Lu

Post by Kai Tietz
then I will begin to reorganize the windres tool to be host

idependent. By

Post by H. J. Lu

Post by Kai Tietz
this I can add some missing resource types to it.
What do you think about my suggestion to continue ?

That is fine with me. If you do this, you don't need to handle
endian and just replace long with int since you will rewrite it
later anyway.

This is the patch changing the windres source using int instead of long. I
bootstrap it on cygwin 32 and for x86_64-mingw.
This patch does not solve the endian problem, reasoned by the use of
fwrite/fread.

If you are assuming that int means 32 bits, wouldn't it make sense to
use a type like u_int32_t which explicitly spells that out?

cgf

[H. J. Lu]

Post by Christopher Faylor

Post by Kai Tietz

Post by H. J. Lu

Post by Kai Tietz
Nightmares, ... 8| I begun to modify structure using character arrays

...

Post by H. J. Lu

Post by Kai Tietz
I come to the point, that this means for big parts of windres better a
complete rewrite. Structures with internal/external scope and data
modifications are really wired.
May we should first use my last patch, so that the problem is solved,

and

Post by H. J. Lu

Post by Kai Tietz
then I will begin to reorganize the windres tool to be host

idependent. By

Post by H. J. Lu

Post by Kai Tietz
this I can add some missing resource types to it.
What do you think about my suggestion to continue ?

That is fine with me. If you do this, you don't need to handle
endian and just replace long with int since you will rewrite it
later anyway.

This is the patch changing the windres source using int instead of long. I
bootstrap it on cygwin 32 and for x86_64-mingw.
This patch does not solve the endian problem, reasoned by the use of
fwrite/fread.

If you are assuming that int means 32 bits, wouldn't it make sense to
use a type like u_int32_t which explicitly spells that out?

u_int32_t is a good idea if it doesn't require extra change since
this is a temporary patch until windres can be rewritten properly.


H.J.

[Kai Tietz]

Post by H. J. Lu

Post by Christopher Faylor

Post by Kai Tietz

Post by H. J. Lu

Post by Kai Tietz
Nightmares, ... 8| I begun to modify structure using character arrays

...

Post by H. J. Lu

Post by Kai Tietz
I come to the point, that this means for big parts of

windresbetter a

Post by H. J. Lu

Post by Christopher Faylor

Post by Kai Tietz

Post by H. J. Lu

Post by Kai Tietz
complete rewrite. Structures with internal/external scope and data
modifications are really wired.
May we should first use my last patch, so that the problem is solved,

and

Post by H. J. Lu

Post by Kai Tietz
then I will begin to reorganize the windres tool to be host

idependent. By

Post by H. J. Lu

Post by Kai Tietz
this I can add some missing resource types to it.
What do you think about my suggestion to continue ?

That is fine with me. If you do this, you don't need to handle
endian and just replace long with int since you will rewrite it
later anyway.

This is the patch changing the windres source using int instead of long. I
bootstrap it on cygwin 32 and for x86_64-mingw.
This patch does not solve the endian problem, reasoned by the use of
fwrite/fread.

If you are assuming that int means 32 bits, wouldn't it make sense to
use a type like u_int32_t which explicitly spells that out?

u_int32_t is a good idea if it doesn't require extra change since
this is a temporary patch until windres can be rewritten properly.

Such a types as u_int32_t, u_int16_t, ... are really a good idea, but that
these types are not available on all platforms in sys/types.h. :( So this
would
need some further work on a temporary thing.
But I think, it would be a good idea to introduce those kind of types to
bfd.
E.g. bfd_uint32_t, bfd_int32, bfd_int16, ...

Regards,
i.A. Kai Tietz

------------------------------------------------------------------------------------------
OneVision Software Entwicklungs GmbH & Co. KG
Dr.-Leo-Ritter-Straße 9 - 93049 Regensburg
Tel: [phone] - Fax: [phone] - 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ühre

[Christopher Faylor]

Post by Christopher Faylor
If you are assuming that int means 32 bits, wouldn't it make sense to
use a type like u_int32_t which explicitly spells that out?

u_int32_t is a good idea if it doesn't require extra change since this
is a temporary patch until windres can be rewritten properly.

Such a types as u_int32_t, u_int16_t, ... are really a good idea, but
that these types are not available on all platforms in sys/types.h. :(
So this would need some further work on a temporary thing. But I
think, it would be a good idea to introduce those kind of types to bfd.
E.g. bfd_uint32_t, bfd_int32, bfd_int16, ...

We've all had experience with "temporary" changes, though, so I think it
makes sense to do this the right way. Doesn't configure provide a way to
determine the size of ints/longs?

cgf

[H. J. Lu]

Post by Christopher Faylor

Post by Christopher Faylor
If you are assuming that int means 32 bits, wouldn't it make sense to
use a type like u_int32_t which explicitly spells that out?

u_int32_t is a good idea if it doesn't require extra change since this
is a temporary patch until windres can be rewritten properly.

Such a types as u_int32_t, u_int16_t, ... are really a good idea, but
that these types are not available on all platforms in sys/types.h. :(
So this would need some further work on a temporary thing. But I
think, it would be a good idea to introduce those kind of types to bfd.
E.g. bfd_uint32_t, bfd_int32, bfd_int16, ...

We've all had experience with "temporary" changes, though, so I think it
makes sense to do this the right way. Doesn't configure provide a way to
determine the size of ints/longs?

I don't think binutils will work at all if sizeof int < 32. I am not
sure if we should worry about int > 32 here. In anycase, as I said
before, the proper thing to do is to use unsigned char [4]:

http://sourceware.org/ml/binutils/2007-04/msg00154.html

Anything less is temporary.


H.J.

[Kai Tietz]

Post by H. J. Lu

Post by Christopher Faylor

Post by Christopher Faylor
If you are assuming that int means 32 bits, wouldn't it make sense to
use a type like u_int32_t which explicitly spells that out?

u_int32_t is a good idea if it doesn't require extra change since this
is a temporary patch until windres can be rewritten properly.

Such a types as u_int32_t, u_int16_t, ... are really a good idea, but
that these types are not available on all platforms in sys/types.h.

:(

Post by H. J. Lu

Post by Christopher Faylor

So this would need some further work on a temporary thing. But I
think, it would be a good idea to introduce those kind of types to bfd.
E.g. bfd_uint32_t, bfd_int32, bfd_int16, ...

We've all had experience with "temporary" changes, though, so I think it
makes sense to do this the right way. Doesn't configure provide a way to
determine the size of ints/longs?

I don't think binutils will work at all if sizeof int < 32. I am not
sure if we should worry about int > 32 here. In anycase, as I said
http://sourceware.org/ml/binutils/2007-04/msg00154.html
Anything less is temporary.

I agree to that. I am now nearly through to extend windres by some missing
(or new) resource types as MANIFEST, DLGINIT, TOOLBAR, ANICURSOR, ANIICON,
etc. Also I near through to produce a re-compilable RC dump (e.g.
bitmaps).
I rewrote the rclex as just c lexer not using flex anymore. It seems to be
much faster and a more flexible way to implement this kind of tokenizer.
Also the lexer and the yacc file now will support unicode strings by L""
too.
I isolated the resource definition structures and I will begin now to
rewrite the internal structure representation.
The endian test I generalized to be setup in windres.c on startup globally
by using two global as "host_is_big_endian" and "target_is_big_endian" to
cover more easily the endian stuff.

I think I will have completed with that next midweek AFAICS.

Do you have may some helpful suggestions or some additons ?

Regards,
i.A. Kai Tietz

------------------------------------------------------------------------------------------
OneVision Software Entwicklungs GmbH & Co. KG
Dr.-Leo-Ritter-Straße 9 - 93049 Regensburg
Tel: [phone] - Fax: [phone] - 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�

[H. J. Lu]

Post by Kai Tietz
The endian test I generalized to be setup in windres.c on startup globally
by using two global as "host_is_big_endian" and "target_is_big_endian" to
cover more easily the endian stuff.

Can you use BFD for I/O? It has endian independent I/O routines.


H.J.

[Kai Tietz]

Post by H. J. Lu

Post by Kai Tietz
The endian test I generalized to be setup in windres.c on startup globally
by using two global as "host_is_big_endian" and "target_is_big_endian" to
cover more easily the endian stuff.

Can you use BFD for I/O? It has endian independent I/O routines.

I do, if you mean bfd_getb16, bfd_getl16, etc.

Regards,
i.A. Kai Tietz

------------------------------------------------------------------------------------------
OneVision Software Entwicklungs GmbH & Co. KG
Dr.-Leo-Ritter-Straße 9 - 93049 Regensburg
Tel: [phone] - Fax: [phone] - 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 K

[H. J. Lu]

Post by Kai Tietz

Post by H. J. Lu

Post by Kai Tietz
The endian test I generalized to be setup in windres.c on startup

globally

Post by H. J. Lu

Post by Kai Tietz
by using two global as "host_is_big_endian" and "target_is_big_endian"

to

Post by H. J. Lu

Post by Kai Tietz
cover more easily the endian stuff.

Can you use BFD for I/O? It has endian independent I/O routines.

I do, if you mean bfd_getb16, bfd_getl16, etc.

I meant bfd_get_16, bfd_put_16, .....



H.J.

[Dave Korn]

Post by Kai Tietz
Do you have may some helpful suggestions or some additons ?

Accept underscores in identifiers! (See previous post!)


cheers,
DaveK

[Kai Tietz]

Post by Dave Korn

Post by Kai Tietz
Do you have may some helpful suggestions or some additons ?

Accept underscores in identifiers! (See previous post!)

The new lexer is capable for underscores. I missed to mention that.
May it would be worth to sent the new lexer infront of the update ?
I think I could separate it easily from the rest of the update.

Regards,
i.A. Kai Tietz

------------------------------------------------------------------------------------------
OneVision Software Entwicklungs GmbH & Co. KG
Dr.-Leo-Ritter-Straße 9 - 93049 Regensburg
Tel: [phone] - Fax: [phone] - 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, Manuel

[Dave Korn]

Post by Kai Tietz

Post by Dave Korn

Post by Kai Tietz
Do you have may some helpful suggestions or some additons ?

Accept underscores in identifiers! (See previous post!)

The new lexer is capable for underscores. I missed to mention that.
May it would be worth to sent the new lexer infront of the update ?
I think I could separate it easily from the rest of the update.

That's probably a good idea, multiple smaller patches relating to isolated areas of functionality make for better testability and less risk of breakage.


cheers,
DaveK

[Kai Tietz]

Hello,

This is my suggested patch for replacing the windres resource file lexer.
The lexer has the same feature set as the prior one, but also supports
underscores, dollars, and digits in resource identifiers.

ChangeLog:

2007-04-23 Kai Tietz <***@onevision.com>

* binutils/rclex.c: New file.
* binutils/rclex.l: Remove file.
* binutils/Makefile.am: Replaced rclex.l by rclex.c.
* binutils/Makefile.in: Regenerated.



Regards,
i.A. Kai Tietz




------------------------------------------------------------------------------------------
OneVision Software Entwicklungs GmbH & Co. KG
Dr.-Leo-Ritter-Straße 9 - 93049 Regensburg
Tel: [phone] - Fax: [phone] - 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

Post by Dave Korn

Post by Kai Tietz

Post by Dave Korn

Post by Kai Tietz
Do you have may some helpful suggestions or some additons ?

Accept underscores in identifiers! (See previous post!)

The new lexer is capable for underscores. I missed to mention that.
May it would be worth to sent the new lexer infront of the update ?
I think I could separate it easily from the rest of the update.

That's probably a good idea, multiple smaller patches relating to
isolated areas of functionality make for better testability and less
risk of breakage.
cheers,
DaveK
--
Can't think of a witty .sigline today....

[Christopher Faylor]

Post by Kai Tietz
Hello,
This is my suggested patch for replacing the windres resource file lexer.
The lexer has the same feature set as the prior one, but also supports
underscores, dollars, and digits in resource identifiers.
* binutils/rclex.c: New file.
* binutils/rclex.l: Remove file.
* binutils/Makefile.am: Replaced rclex.l by rclex.c.
* binutils/Makefile.in: Regenerated.

I'm sorry that I missed this before but what was the rationale for
replacing the (f)lex file with a .c file? That seems like a step backwards
to me.

You also have \r\n endings in the file that you provided. It's a minor
issue but, as long as I'm here...

cgf

[Kai Tietz]

Post by Christopher Faylor
I'm sorry that I missed this before but what was the rationale for
replacing the (f)lex file with a .c file? That seems like a step backwards
to me.

The use of flex looks more professional, but at a closer look a pure c
lexer is getting
easier to maintain and more efficant. E.g. gcc use now for a long term no
flex anymore to
implement the c token scanner. To use flex is sometimes as to break a fly
on the wheel.

Post by Christopher Faylor
You also have \r\n endings in the file that you provided. It's a minor
issue but, as long as I'm here...

Upps. Corrected it, see attachment ;)

Regards,
i.A. Kai Tietz



------------------------------------------------------------------------------------------
OneVision Software Entwicklungs GmbH & Co. KG
Dr.-Leo-Ritter-Straße 9 - 93049 Regensburg
Tel: [phone] - Fax: [phone] - 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

[Christopher Faylor]

Post by Kai Tietz

Post by Christopher Faylor
I'm sorry that I missed this before but what was the rationale for
replacing the (f)lex file with a .c file? That seems like a step
backwards to me.

The use of flex looks more professional, but at a closer look a pure c
lexer is getting easier to maintain and more efficant. E.g. gcc use
now for a long term no flex anymore to implement the c token scanner.
To use flex is sometimes as to break a fly on the wheel.

Speed is not really an issue in this case but, regardless, *claims* of
efficiency are not really useful unless they are accompanied by actual
data.

Your implementation is ~4K larger than the .l version and, since it is
is a complete reimplementation, there is no way to tell what regressions
there may be. Have you tried running the test suite on your version,
anemic as the windres test may be?

Changing the current version of the lexer to accept more characters seems
like it would be trivial, FWIW.

cgf

[Dave Korn]

Post by Christopher Faylor
Your implementation is ~4K larger than the .l version

Source or compiled-down object?

Post by Christopher Faylor
Changing the current version of the lexer to accept more characters seems
like it would be trivial, FWIW.

Certainly was.


cheers,
DaveK

[Kai Tietz]

Post by Dave Korn

Post by Christopher Faylor
Your implementation is ~4K larger than the .l version

Source or compiled-down object?

Origin rclex.l as source 12k, after flex 66k, obj code 106k.
New rclex.c as source 16k, obj code 89k.

Regards,
i.A. Kai Tietz

------------------------------------------------------------------------------------------
OneVision Software Entwicklungs GmbH & Co. KG
Dr.-Leo-Ritter-Straße 9 - 93049 Regensburg
Tel: [phone] - Fax: [phone] - 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, Man

[Christopher Faylor]

Post by Dave Korn

Post by Christopher Faylor
Your implementation is ~4K larger than the .l version

Source or compiled-down object?

Origin rclex.l as source 12k, after flex 66k, obj code 106k. New
rclex.c as source 16k, obj code 89k.

IMO, object size doesn't mean much. It's the maintainability of the
source code that is at issue. There is 4k more source code to maintain
in the .c version.

If this version provided some other benefits like improved error
checking, demonstrated improved robustness, or more features, I could
buy those as a reason to move to it. AFAICT, the only rationale you've
given is that gcc doesn't use a lex parser.

cgf

[Kai Tietz]

Post by H. J. Lu
We do need a new type when casting from pointer to integer. But
it should be determined in autoconf. You can use AC_CHECK_SIZEOF.

I adjust my patch not using the printf macro and using configure.in in bfd
to find the proper type for bfd_hostptr_t. Also I adjust the autodetection
of 64 bit in configure by using the size of a "void *" == 8 for detection.

ChangeLog:

2007-04-18 Kai Tietz <***@onevision.com>

* bfd/bfd-in.h: (BFD_HOST_64BIT_LONG_LONG): New
as equivalent for BFD_HOST_64BIT_LONG.
(BFD_HOSTPTR_T): Host pointer type for casting a
pointer to an integer type.
(bfd_hostptr_t): The typedef of BFD_HOSTPTR_T.
(sprintf_vma, fprintf_vma): Add support for long long prints.
* bfd/bfd-in2.h: Regenerate.
* bfd/configure.in: (BFD_HOST_64BIT_LONG_LONG): New
as equivalent for BFD_HOST_64BIT_LONG.
(BFD_HOSTPTR_T): Host pointer type for casting a
pointer to an integer type. Defauls is "unsigned long".
(AC_CHECK_SIZEOF(void *)): New.
(host64): Set it if the pointer size is 8.
* bfd/configure: Regenerate.
* bfd/config.in: Add macro SIZEOF_VOID_P.
* bfd/coffcode.h: Replace host ptr type assuming "long" to
bfd_hostptr_t type.
* bfd/coffgen.c: Likewise.
* bfd/elf-eh-frame.c: Likewise.
* bfd/peicode.h: Likewise.
* gas/symbols.c: Print bfd_hostptr_t to file via fprintf_vma.
* gas/write.c: Likewise.
* gprof/cg_print.c: Force cast of sizeof to be a long.
* gprof/hist.c: Likewise.
* include/splay-tree.h: New type libi_uhostptr_t needed for
w64 when a long is not wide enought for a pointer for
splay_tree_key and splay_tree_value..
(splay_tree_key, splay_tree_value): As above, see comment.
* include/coff/internal.h: Replace host ptr type assuming "long"
to bfd_hostptr_t type.
* libiberty/strerror.c: Undefine sys_nerr and sys_errlist if
allready defined in front by runtime headers.

Regards,
i.A. Kai Tietz


------------------------------------------------------------------------------------------
OneVision Software Entwicklungs GmbH & Co. KG
Dr.-Leo-Ritter-Straße 9 - 93049 Regensburg
Tel: [phone] - Fax: [phone] - 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

[NightStrike]

Post by Kai Tietz

Post by H. J. Lu
We do need a new type when casting from pointer to integer. But
it should be determined in autoconf. You can use AC_CHECK_SIZEOF.

I adjust my patch not using the printf macro and using configure.in in bfd
to find the proper type for bfd_hostptr_t. Also I adjust the autodetection
of 64 bit in configure by using the size of a "void *" == 8 for detection.
* bfd/bfd-in.h: (BFD_HOST_64BIT_LONG_LONG): New
as equivalent for BFD_HOST_64BIT_LONG.
(BFD_HOSTPTR_T): Host pointer type for casting a
pointer to an integer type.
(bfd_hostptr_t): The typedef of BFD_HOSTPTR_T.
(sprintf_vma, fprintf_vma): Add support for long long prints.
* bfd/bfd-in2.h: Regenerate.
* bfd/configure.in: (BFD_HOST_64BIT_LONG_LONG): New
as equivalent for BFD_HOST_64BIT_LONG.
(BFD_HOSTPTR_T): Host pointer type for casting a
pointer to an integer type. Defauls is "unsigned long".
(AC_CHECK_SIZEOF(void *)): New.
(host64): Set it if the pointer size is 8.
* bfd/configure: Regenerate.
* bfd/config.in: Add macro SIZEOF_VOID_P.
* bfd/coffcode.h: Replace host ptr type assuming "long" to
bfd_hostptr_t type.
* bfd/coffgen.c: Likewise.
* bfd/elf-eh-frame.c: Likewise.
* bfd/peicode.h: Likewise.
* gas/symbols.c: Print bfd_hostptr_t to file via fprintf_vma.
* gas/write.c: Likewise.
* gprof/cg_print.c: Force cast of sizeof to be a long.
* gprof/hist.c: Likewise.
* include/splay-tree.h: New type libi_uhostptr_t needed for
w64 when a long is not wide enought for a pointer for
splay_tree_key and splay_tree_value..
(splay_tree_key, splay_tree_value): As above, see comment.
* include/coff/internal.h: Replace host ptr type assuming "long"
to bfd_hostptr_t type.
* libiberty/strerror.c: Undefine sys_nerr and sys_errlist if
allready defined in front by runtime headers.
Regards,
i.A. Kai Tietz

Please correct me if I am wrong, but it appears that this was never
committed. Is it going to be?

[Nick Clifton]

Hi Kai,

In the better late than never category we have...

Post by Kai Tietz
* bfd/bfd-in.h: (BFD_HOST_64BIT_LONG_LONG): New
as equivalent for BFD_HOST_64BIT_LONG.
(BFD_HOSTPTR_T): Host pointer type for casting a
pointer to an integer type.
(bfd_hostptr_t): The typedef of BFD_HOSTPTR_T.
(sprintf_vma, fprintf_vma): Add support for long long prints.
* bfd/bfd-in2.h: Regenerate.
* bfd/configure.in: (BFD_HOST_64BIT_LONG_LONG): New
as equivalent for BFD_HOST_64BIT_LONG.
(BFD_HOSTPTR_T): Host pointer type for casting a
pointer to an integer type. Defauls is "unsigned long".
(AC_CHECK_SIZEOF(void *)): New.
(host64): Set it if the pointer size is 8.
* bfd/configure: Regenerate.
* bfd/config.in: Add macro SIZEOF_VOID_P.
* bfd/coffcode.h: Replace host ptr type assuming "long" to
bfd_hostptr_t type.
* bfd/coffgen.c: Likewise.
* bfd/elf-eh-frame.c: Likewise.
* bfd/peicode.h: Likewise.
* gas/symbols.c: Print bfd_hostptr_t to file via fprintf_vma.
* gas/write.c: Likewise.
* gprof/cg_print.c: Force cast of sizeof to be a long.
* gprof/hist.c: Likewise.
* include/splay-tree.h: New type libi_uhostptr_t needed for
w64 when a long is not wide enought for a pointer for
splay_tree_key and splay_tree_value..
(splay_tree_key, splay_tree_value): As above, see comment.
* include/coff/internal.h: Replace host ptr type assuming "long"
to bfd_hostptr_t type.
* libiberty/strerror.c: Undefine sys_nerr and sys_errlist if
allready defined in front by runtime headers.

I have now checked all of this patch in, apart from the change to
libiberty. You will need to submit that one separately to the libiberty
maintainers.

Cheers
Nick

[NightStrike]

Post by Nick Clifton
Hi Kai,
In the better late than never category we have...

Post by Kai Tietz
* bfd/bfd-in.h: (BFD_HOST_64BIT_LONG_LONG): New
as equivalent for BFD_HOST_64BIT_LONG.
(BFD_HOSTPTR_T): Host pointer type for casting a
pointer to an integer type.
(bfd_hostptr_t): The typedef of BFD_HOSTPTR_T.
(sprintf_vma, fprintf_vma): Add support for long long prints.
* bfd/bfd-in2.h: Regenerate.
* bfd/configure.in: (BFD_HOST_64BIT_LONG_LONG): New
as equivalent for BFD_HOST_64BIT_LONG.
(BFD_HOSTPTR_T): Host pointer type for casting a
pointer to an integer type. Defauls is "unsigned long".
(AC_CHECK_SIZEOF(void *)): New.
(host64): Set it if the pointer size is 8.
* bfd/configure: Regenerate.
* bfd/config.in: Add macro SIZEOF_VOID_P.
* bfd/coffcode.h: Replace host ptr type assuming "long" to
bfd_hostptr_t type.
* bfd/coffgen.c: Likewise.
* bfd/elf-eh-frame.c: Likewise.
* bfd/peicode.h: Likewise.
* gas/symbols.c: Print bfd_hostptr_t to file via fprintf_vma.
* gas/write.c: Likewise.
* gprof/cg_print.c: Force cast of sizeof to be a long.
* gprof/hist.c: Likewise.
* include/splay-tree.h: New type libi_uhostptr_t needed for
w64 when a long is not wide enought for a pointer for
splay_tree_key and splay_tree_value..
(splay_tree_key, splay_tree_value): As above, see comment.
* include/coff/internal.h: Replace host ptr type assuming "long"
to bfd_hostptr_t type.
* libiberty/strerror.c: Undefine sys_nerr and sys_errlist if
allready defined in front by runtime headers.

I have now checked all of this patch in, apart from the change to
libiberty. You will need to submit that one separately to the libiberty
maintainers.
Cheers
Nick

Does anyone know if this made it into libiberty?

[Kai Tietz]

Post by H. J. Lu

Post by Kai Tietz
Hello,
I did the windres.h patch changing the long to int types, so that problem
#2737 seems to be solved.

No, it doesn't work on big endian host. You should array of char
in external data structures.

Ok, I take a look for big-endian hosts and the external data structures.

Post by H. J. Lu

Post by Kai Tietz
Additionally I introduced in bfd-in.h the type "bfd_hostptr_t" and its
hexadeicmal printf representation in macro "BFD_HOSTPTR_T_PRT_X". For now,
AFAIS, only WIN64 has a long type lesser than a pointer, therefore I made
the define dependent on the definiton of _WIN64. The modification in

I don't believe we need BFD_HOSTPTR_T_PRT_X. As I said before, the
PE problem is there is no clear line between external and internal
data structues. You should be able to use long long, even in big
endian, internally to hold any PE data type. You just need to convert
it to the proper size in proper endian when you write it out. You
shouldn't have any problem when it is done peoperly.

The "long long" would work, if there would not be the -Werror parameter
for gcc. The gcc bubbles a warning also for the case, that the integer
casted to/from a pointer is bigger :(. This would break an cross from
32-bit to 64-bit.
The helper macro BFD_HOSTPTR_T_PTR_X is for sure not coercively, but
simplivies the readability AFAICS.

Regards,
i.A. Kai Tietz

------------------------------------------------------------------------------------------
OneVision Software Entwicklungs GmbH & Co. KG
Dr.-Leo-Ritter-Straße 9 - 93049 Regensburg
Tel: [phone] - Fax: [phone] - 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:
Ulr

[Daniel Jacobowitz]

Post by Kai Tietz
The "long long" would work, if there would not be the -Werror parameter
for gcc. The gcc bubbles a warning also for the case, that the integer
casted to/from a pointer is bigger :(. This would break an cross from
32-bit to 64-bit.

We already have an autoconf macro in the tree to generate a stdint.h.
Gnulib also has one that we can import.

It's long past time to start assuming intptr_t.

[Kai Tietz]

Post by Daniel Jacobowitz

Post by Kai Tietz
The "long long" would work, if there would not be the -Werror parameter
for gcc. The gcc bubbles a warning also for the case, that the integer
casted to/from a pointer is bigger :(. This would break an cross from
32-bit to 64-bit.

We already have an autoconf macro in the tree to generate a stdint.h.
Gnulib also has one that we can import.
It's long past time to start assuming intptr_t.

Yes, ice ages ... It seems that on every project and library the same old
story reappears ;)
But as I learned, not on every c-runtime necessarily an stdint header is
present and/or want to be included ;()

Re-inventing the wheel, may this patch could work (beside the
BFD_HOSTPTR_T_PRT_X).

Regards,
i.A. Kai Tietz




------------------------------------------------------------------------------------------
OneVision Software Entwicklungs GmbH & Co. KG
Dr.-Leo-Ritter-Straße 9 - 93049 Regensburg
Tel: [phone] - Fax: [phone] - 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

[Daniel Jacobowitz]

Post by Kai Tietz
Yes, ice ages ... It seems that on every project and library the same old
story reappears ;)
But as I learned, not on every c-runtime necessarily an stdint header is
present and/or want to be included ;()
Re-inventing the wheel, may this patch could work (beside the
BFD_HOSTPTR_T_PRT_X).

Please read my message a second time, since you missed my point :-)
If the OS is missing a usable intptr_t we already have autoconf macros
to create it.

[Kai Tietz]

Post by Daniel Jacobowitz

Post by Kai Tietz
Yes, ice ages ... It seems that on every project and library the same old
story reappears ;)
But as I learned, not on every c-runtime necessarily an stdint header is
present and/or want to be included ;()
Re-inventing the wheel, may this patch could work (beside the
BFD_HOSTPTR_T_PRT_X).

Please read my message a second time, since you missed my point :-)
If the OS is missing a usable intptr_t we already have autoconf macros
to create it.

I didn't missed your point, but what is needed would be something like a
longptr_t (which is not part of C99 AFAIK). The same discussion I had in
the past about the subject "splay-tree.h" header. Not on all platforms is
a long less or equal to a pointer.

Regards,
i.A. Kai Tietz

------------------------------------------------------------------------------------------
OneVision Software Entwicklungs GmbH & Co. KG
Dr.-Leo-Ritter-Straße 9 - 93049 Regensburg
Tel: [phone] - Fax: [phone] - 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ühr

[Daniel Jacobowitz]

Post by Kai Tietz
I didn't missed your point, but what is needed would be something like a
longptr_t

Why? Do you need something that can hold either a long or a pointer?
You were complaining, in the message I replied to, about warnings on
casts. You can solve that by casting through intptr_t.