Re: binutils status?
Hi, It was stated earlier that Ralf's unused _nm_ symbols patch would be used. What is the story on this? For a refresher: http://sources.redhat.com/ml/cygwin-apps/2002-05/msg00320.html Cheers, Nicholas Charles Wilson wrote: Christopher Faylor wrote: On Thu, May 30, 2002 at 03:24:47PM -0400, Charles Wilson wrote: Any comments here? Should I submit this patch to binutils, or can we agree and commit from here? Submit it to binutils, please. done. --Chuck -- Your favorite stores, helpful shopping tools and great gift ideas. Experience the convenience of buying online with Shop@Netscape! http://shopnow.netscape.com/
RE: binutils status ?
On Thu, May 23, 2002 at 11:50:20PM +0200, Ralf Habacker wrote: If have tested this patch with my cygin /bin dir (345 files) and rebinded kde 2.2.2 dll's and exes (335 files) and have got no problems with printing import tables. 2002-05-23 Ralf Habacker [EMAIL PROTECTED] * peXXigen.c (pe_print_idata): fixed some seg faults on printing import tables with auto-imported symbols. I have applied this patch, with Nick's permission. The patch did apply cleanly but I did have to do a substantial amount of cleanup on spacing issues. The indentation was really off, AFAICT. Thanks for this hint. I'll review the documentation to see what I have done wrong, so the next patches should be better in this way. Regards Ralf
Re: binutils status?
On Thu, May 30, 2002 at 03:24:47PM -0400, Charles Wilson wrote: Any comments here? Should I submit this patch to binutils, or can we agree and commit from here? Submit it to binutils, please. cgf
Re: binutils status?
Christopher Faylor wrote: On Thu, May 30, 2002 at 03:24:47PM -0400, Charles Wilson wrote: Any comments here? Should I submit this patch to binutils, or can we agree and commit from here? Submit it to binutils, please. done. --Chuck
RE: binutils status ?
3) Ralf's patch for objdump/cygwin crashes on auto-imported libs snip This patch does not help in this case. I will inspect this and supply a updated patch. Appended is a patch for ... see the ChangeLog entry. If have tested this patch with my cygin /bin dir (345 files) and rebinded kde 2.2.2 dll's and exes (335 files) and have got no problems with printing import tables. 2002-05-23 Ralf Habacker [EMAIL PROTECTED] * peXXigen.c (pe_print_idata): fixed some seg faults on printing import tables with auto-imported symbols. Regards Ralf objdump_ai_segfault_2.patch Description: Binary data
RE: binutils status
3) Ralf's patch for objdump/cygwin crashes on auto-imported libs Nick Clifton has applied a patch for a similar problem, I will look if this solve this already. This patch does not help in this case. I will inspect this and supply a updated patch. Ralf
RE: binutils status ?
3) Ralf's patch for objdump/cygwin crashes on auto-imported libs
Nick Clifton has applied a patch for a similar problem, I will look if this
solve this already.
I was wrong, it was Laurent Pinchart, who has applied this patch.
This patch does not help in this case. I will inspect this and supply
a updated
patch.
In peXXigen.c Line 1208 there is a case handling rebinded imports, which isn't
affected by Laurent's Patch.
/* If the time stamp is not zero, the import address
table holds actual addresses. */
if (time_stamp != 0
first_thunk != 0
first_thunk != hint_addr)
fprintf (file, \t%04lx,
(1) (long) bfd_get_32 (abfd, data + first_thunk - adj + j));
^^
this fails in case of rebinded apps or dll, that means first_thunk points into
the text segment
this printing should goes after laurent patch, when the different section is
loaded
fprintf (file, \n);
}
}
--- here starts Laurant's patch ---
if (hint_addr != first_thunk time_stamp == 0)
{
bfd_byte *ft_data;
asection *ft_section;
snip
Laurant: Can you give a hint how the line marked with (1) should be changed ?
Ralf
Re: binutils status?
--- Charles Wilson [EMAIL PROTECTED] wrote: Christopher Faylor wrote: On Mon, May 20, 2002 at 12:50:46AM -0400, Charles Wilson wrote: 1) Ralf's removing unused _nm_ symbol exports fix 2) Danny's (or Ralf's?) export-list fix (where whole static archives can be marked for non-export, or DO export...helpful for convenience libs) 3) Ralf's patch for objdump/cygwin crashes on auto-imported libs If Ralf and Danny will resubmit their patches against the current CVS, I will at least incorporate them in a new version of binutils, even if I don't check them in. Very good. Ralf? Danny? OK. I assume you mean to resubmit to binutils list. I'd say go ahead and turn on auto-import in CVS and remove the warning, Chuck. I've gotten approval from Nick Clifton to do this if we agree it's a good idea. It's obviously a good idea. I disagree that is a good idea. I like to now about unresolved data references. I would really like to see how --auto-import works with new C++ ABI before I am comfortable with that switch being on by default. I've been playing with a little trick of marking _functions_ in def files as DATA so that only the _imp__foo name is visible in the import lib. This lets me hide some of the bogons in MS libs so that I can use the standard function names in a better behaved replacement version without any worry of duplicated definitions, but still get to the MS one when I need to. Never mind, I can find another trick. I won't use gcc -shared to build those libs but use dlltool instead. At least I think the warnings should be active by default. Danny Detached Attached. http://briefcase.yahoo.com.au - Yahoo! Briefcase - Save your important files online for easy access!
Re: binutils status?
Danny Smith wrote: I'd say go ahead and turn on auto-import in CVS and remove the warning, Chuck. I've gotten approval from Nick Clifton to do this if we agree it's a good idea. It's obviously a good idea. I disagree that is a good idea. Two ideas: 1) making auto-import the default 2) turning off the warnings You appear to not like either one. I don't really care about the warnings, but the auto-import thing should be default. However, I wonder how long these warnings are going to persist. Using auto-import is not a *bug* or *oops, I forgot to declspec() something* -- it's the way DLLs are done. I look at auto-import as the new and better and more unixlike way of building shared libs. You seem to view them as nice feature, but you really ought to do it the old-fashioned way. In my view, the warnings go away eventually -- they were just there during the trial phase, which has now stretched to a REALLY long time. In your view, the warnings are TRUE warnings about BAD programming practice, and stay forever. I like to now about unresolved data references. I would really like to see how --auto-import works with new C++ ABI before I am comfortable with that switch being on by default. Well, now, that's something I hadn't considered. Good point. Warnings should probably stay, then. But that doesn't mean that auto-import shouldn't become the default. I've been playing with a little trick of marking _functions_ in def files as DATA so that only the _imp__foo name is visible in the import lib. This lets me hide some of the bogons in MS libs so that I can use the standard function names in a better behaved replacement version without any worry of duplicated definitions, but still get to the MS one when I need to. Never mind, I can find another trick. I won't use gcc -shared to build those libs but use dlltool instead. Urg. Your current solution sounds extremely hackish. Surely there's a better way that doesn't involve (a) marking functions as DATA (b) relying on --disable-auto-import being the default. double urg. At least I think the warnings should be active by default. Given the uncertainty about the new C++ ABI in gcc-3.x, I guess you're right. --Chuck
RE: binutils status?
-Original Message- From: Charles Wilson [mailto:[EMAIL PROTECTED]] Sent: Monday, May 20, 2002 6:44 PM Two ideas: 1) making auto-import the default 2) turning off the warnings You appear to not like either one. I don't really care about the warnings, but the auto-import thing should be default. However, I wonder how long these warnings are going to persist. Using auto-import is not a *bug* or *oops, I forgot to declspec() something* -- it's the way DLLs are done. But it's not complete. One cannot link against all .dll's with auto-import, and no speed tests of normal vs auto-import have been seriously conducted. I still maintain that a profile driven recompile+link is the way to go, and that when that's done auto-import can be tossed out. I look at auto-import as the new and better and more unixlike way of building shared libs. You seem to view them as nice feature, but you really ought to do it the old-fashioned way. In my view, the warnings go away eventually -- they were just there during the trial phase, which has now stretched to a REALLY long time. In your view, the warnings are TRUE warnings about BAD programming practice, and stay forever. The warnings should stay IMO. They aren't errors, but they are important. I like to now about unresolved data references. I would really like to see how --auto-import works with new C++ ABI before I am comfortable with that switch being on by default. Well, now, that's something I hadn't considered. Good point. Warnings should probably stay, then. But that doesn't mean that auto-import shouldn't become the default. For Danny - you can always build with --no-auto-import if you need the original behaviour for some project. I think that auto-import should be the default for cygwin, for now. It's too useful in the common case to be disabled. Rob
RE: binutils status?
-Original Message- From: Christopher Faylor [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 21, 2002 1:07 AM Since --auto-import has been the default for the last version of binutils, I think we should leave it that way. Yes. I think we should keep the warnings if --auto-import isn't specified on the command line but get rid of them if it is explictly specified. Including --auto-import on the command line would indicate that the user knows what they're doing, so they don't need to see warnings. Works for me. Rob
RE: binutils status
1) Ralf's removing unused _nm_ symbol exports fix
Relating to the thread
http://sources.redhat.com/ml/cygwin-apps/2002-04/msg00433.html i've updated this
patch to the latest cvs release.
--
2002-04-25 Ralf Habacker [EMAIL PROTECTED]
* pe-dll.cc (autofilter_symbolprefixlist): don't export
reimported functions.
(make_one): let create only _nm_.. for data symbols
--
$ cvs diff -ubBp pe-dll.c
Index: pe-dll.c
===
RCS file: /cvs/src/src/ld/pe-dll.c,v
retrieving revision 1.39
diff -u -3 -p -B -u -b -B -p -r1.39 pe-dll.c
--- pe-dll.c3 May 2002 13:48:55 - 1.39
+++ pe-dll.c20 May 2002 17:18:47 -
@@ -252,6 +252,8 @@ static autofilter_entry_type autofilter_
/* { __imp_, 6 }, */
/* Do __imp_ explicitly to save time. */
{ __rtti_, 7 },
+ /* Don't export reimported functions*/
+ { _nm_, 4 },
{ __builtin_, 10 },
/* Don't export symbols specifying internal DLL layout. */
{ _head_, 6 },
@@ -1793,8 +1795,11 @@ make_one (exp, parent)
quick_symbol (abfd, U (_head_), dll_symname, , UNDSEC, BSF_GLOBAL, 0);
quick_symbol (abfd, U (_imp__), exp-internal_name, , id5, BSF_GLOBAL,
0);
/* Symbol to reference ord/name of imported
- symbol, used to implement auto-import. */
- quick_symbol (abfd, U(_nm__), exp-internal_name, , id6, BSF_GLOBAL, 0);
+ symbol, used to implement auto-import.
+ (only for data symbols) */
+ if (exp-flag_data)
+quick_symbol (abfd, U(_nm__), exp-internal_name, , id6, BSF_GLOBAL,0);
+
if (pe_dll_compat_implib)
quick_symbol (abfd, U (__imp_), exp-internal_name, ,
id5, BSF_GLOBAL, 0);
--
Because revision 1.39 does not contain any functional changes and the patches
for 1.3.8 and 1.39 are the same (except some line offset), the tests I have
running in the above mentioned thread are valid.
revision 1.39
date: 2002/05/03 13:48:55; author: kazu; state: Exp; lines: +33 -33
* ld.h: Fix formatting.
* ldexp.c: Likewise.
* ldfile.c: Likewise.
* ldlang.c: Likewise.
* ldmain.c: Likewise.
* lexsup.c: Likewise.
* pe-dll.c: Likewise.
3) Ralf's patch for objdump/cygwin crashes on auto-imported libs
Nick Clifton has applied a patch for a similar problem, I will look if this
solve this already.
peXXigen.c
revision 1.7
date: 2002/05/15 15:28:12; author: nickc; state: Exp; lines: +54 -3
Do not assume that the first thunk is located in the same section as the
import table. Instead check, and if necessary load the section containing
the thunk.
Ralf
Re: binutils status?
Charles Wilson wrote: Danny Smith wrote: I'd say go ahead and turn on auto-import in CVS and remove the warning, I disagree that is a good idea. Two ideas: 1) making auto-import the default 2) turning off the warnings You appear to not like either one. I don't really care about the warnings, but the auto-import thing should be default. However, I wonder how long these warnings are going to persist. Using auto-import is not a *bug* or *oops, I forgot to declspec() something* -- it's the way DLLs are done. Please bear in mind that some folks, from whom we've heard here before, are *required* by their work to produce compiles free from warnings. As suggested, this condition I found _x_y_z_, and loaded it is not an indication of anything wrong. The message is appropriate, but it should be clearly Informational rather than a warning. -- David A. Cobb, Software Engineer, Public Access Advocate By God's Grace I am a Christian man, by my actions a great sinner. -- The Way of a Pilgrim; R. M. French, tr. Life is too short to tolerate crappy software. .
Re: binutils status?
Danny Smith wrote:
I think we should keep the warnings if --auto-import isn't specified
on the command line but get rid of them if it is explictly
specified. Including --auto-import on the command line would
indicate that the user knows what they're doing, so they don't
need to see warnings.
Works for me.
Agree This addresses my main concern of no warnings and is similar
to the way --enable-stdcall-fixup works now.
How about this?
Since the tests in /bfd/ are against pei386_auto_import != 0, effectively:
./bfd/cofflink.c: if (!h info-pei386_auto_import)
./bfd/linker.c: if (info-pei386_auto_import)
We can use the same
-1 == default, 1 == explicitly enabled, 0 == explicitly disabled
formuation that stdcall_fixup uses.
I also downgraded the message to 'info_msg' on stdout, instead of
'einfo' on stderr (this may be overkill given the 0/1/-1 changes)
Finally, I'm not sure if link_info.pei386_auto_import should be set to
'0' or to '-1' in ldmain.c. It is *reset* to '-1' at the beginning of
gld_${EMULATION_NAME}_before_parse()
in pe.em...The question is, since pei386_auto_import is part of the
global link_info structure, should a Solaris linker have that variable
set to '0' or to '-1'?
I don't think it makes any functional difference, but I'm unsure of the
stylistic issues.
--Chuck
? bfd/doc/bfdint.info
? bfd/doc/bfdint.info-1
? bfd/doc/bfdint.info-2
? bfd/doc/bfdsumm.info
? ld/ldint.info
Index: ld/ldmain.c
===
RCS file: /cvs/src/src/ld/ldmain.c,v
retrieving revision 1.46
diff -u -r1.46 ldmain.c
--- ld/ldmain.c 10 May 2002 09:49:25 - 1.46
+++ ld/ldmain.c 21 May 2002 03:52:12 -
-258,7 +258,7
link_info.eh_frame_hdr = false;
link_info.flags = (bfd_vma) 0;
link_info.flags_1 = (bfd_vma) 0;
- link_info.pei386_auto_import = false;
+ link_info.pei386_auto_import = -1; /* 0=disable 1=enable */
link_info.combreloc = true;
link_info.spare_dynamic_tags = 5;
Index: ld/emultempl/pe.em
===
RCS file: /cvs/src/src/ld/emultempl/pe.em,v
retrieving revision 1.59
diff -u -r1.59 pe.em
--- ld/emultempl/pe.em 15 Feb 2002 02:11:05 - 1.59
+++ ld/emultempl/pe.em 21 May 2002 03:52:18 -
-173,7 +173,7
#ifdef DLL_SUPPORT
config.dynamic_link = true;
config.has_shared = 1;
-/* link_info.pei386_auto_import = true; */
+ link_info.pei386_auto_import = -1; /* 1=enable 0=disable */
#if (PE_DEF_SUBSYSTEM == 9) || (PE_DEF_SUBSYSTEM == 2)
#if defined TARGET_IS_mipspe || defined TARGET_IS_armpe
-622,10 +622,10
pe_dll_do_default_excludes = 0;
break;
case OPTION_DLL_ENABLE_AUTO_IMPORT:
- link_info.pei386_auto_import = true;
+ link_info.pei386_auto_import = 1;
break;
case OPTION_DLL_DISABLE_AUTO_IMPORT:
- link_info.pei386_auto_import = false;
+ link_info.pei386_auto_import = 0;
break;
case OPTION_ENABLE_EXTRA_PE_DEBUG:
pe_dll_extra_pe_debug = 1;
-906,7 +906,10
sym = bfd_link_hash_lookup (link_info.hash, buf, 0, 0, 1);
if (sym sym-type == bfd_link_hash_defined)
{
- einfo (_(Warning: resolving %s by linking to %s (auto-import)\n),
+ if (link_info.pei386_auto_import == -1)
+ {
+info_msg (_(Info: resolving %s by linking to %s (auto-import)\n),
+ }
undef-root.string, buf);
{
bfd *b = sym-u.def.section-owner;
Re: binutils status?
Christopher Faylor wrote: I lost track. Should I make a new release or are we waiting for something new to be added? I just rebuilt binutils and made --auto-import the default. Is there a compelling reason for not doing this in the next release? I know that --auto-import isn't perfect but will it solve more problems than it creates? Waitaminute. I thought it already was the default. Hmmm...let me go check...weird, I don't see --enable-auto-import in any of my makefiles, yet I know that I'm linking to _nm_ symbols... Hmm...have I been using a local build of ld.exe all this time? Nope, datestamp on the file is 20011002... Color me confused. But if it ain't the default, it should be. And we should probably remove the warning message that gets printed (around line 908 in pe.em), or downgrade it so that it only gets printed when -v (verbose). Other than that, I know of three different things we're still waiting on (or maybe they've been committed and I missed it): 1) Ralf's removing unused _nm_ symbol exports fix 2) Danny's (or Ralf's?) export-list fix (where whole static archives can be marked for non-export, or DO export...helpful for convenience libs) 3) Ralf's patch for objdump/cygwin crashes on auto-imported libs --Chuck
Re: binutils status?
On Mon, May 20, 2002 at 12:50:46AM -0400, Charles Wilson wrote: 1) Ralf's removing unused _nm_ symbol exports fix 2) Danny's (or Ralf's?) export-list fix (where whole static archives can be marked for non-export, or DO export...helpful for convenience libs) 3) Ralf's patch for objdump/cygwin crashes on auto-imported libs If Ralf and Danny will resubmit their patches against the current CVS, I will at least incorporate them in a new version of binutils, even if I don't check them in. I'd say go ahead and turn on auto-import in CVS and remove the warning, Chuck. I've gotten approval from Nick Clifton to do this if we agree it's a good idea. It's obviously a good idea. cgf
Re: binutils status?
Christopher Faylor wrote:
On Mon, May 20, 2002 at 12:50:46AM -0400, Charles Wilson wrote:
1) Ralf's removing unused _nm_ symbol exports fix
2) Danny's (or Ralf's?) export-list fix (where whole static archives can
be marked for non-export, or DO export...helpful for convenience libs)
3) Ralf's patch for objdump/cygwin crashes on auto-imported libs
If Ralf and Danny will resubmit their patches against the current CVS,
I will at least incorporate them in a new version of binutils, even
if I don't check them in.
Very good. Ralf? Danny?
I'd say go ahead and turn on auto-import in CVS and remove the warning,
Chuck. I've gotten approval from Nick Clifton to do this if we agree
it's a good idea.
It's obviously a good idea.
Attached.
--chuck
Index: pe.em
===
RCS file: /cvs/src/src/ld/emultempl/pe.em,v
retrieving revision 1.59
diff -u -r1.59 pe.em
--- pe.em 15 Feb 2002 02:11:05 - 1.59
+++ pe.em 20 May 2002 05:26:50 -
-173,7 +173,7
#ifdef DLL_SUPPORT
config.dynamic_link = true;
config.has_shared = 1;
-/* link_info.pei386_auto_import = true; */
+ link_info.pei386_auto_import = true;
#if (PE_DEF_SUBSYSTEM == 9) || (PE_DEF_SUBSYSTEM == 2)
#if defined TARGET_IS_mipspe || defined TARGET_IS_armpe
-906,7 +906,10
sym = bfd_link_hash_lookup (link_info.hash, buf, 0, 0, 1);
if (sym sym-type == bfd_link_hash_defined)
{
- einfo (_(Warning: resolving %s by linking to %s (auto-import)\n),
+ if (pe_dll_extra_pe_debug)
+ {
+einfo (_(Warning: resolving %s by linking to %s (auto-import)\n),
+ }
undef-root.string, buf);
{
bfd *b = sym-u.def.section-owner;
