[ANNOUNCEMENT] [1.7] Updated: file-5.00-1

[ANNOUNCEMENT] [1.7] Updated: file-5.00-1

[Corinna Vinschen]

I've updated the Cygwin 1.7 version of file to 5.00-1.

This is an update to the latest official upstream version 5.00.
The Cygwin version is build from the vanilla sources with the
latest libtool applied and a minor change in an error message.
Both changes have been send upstream.


To update your installation, click on the "Install Cygwin now" link on
the http://cygwin.com/ web page.  This downloads setup.exe to your
system.  Then, run setup and answer all of the questions.

              *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in the email header of this message.
Send email to the address specified there.  It will be in the format:

cygwin-announce-unsubscribe-you=yourdomain.com@cygwin.com

If you need more information on unsubscribing, start reading here:

http://sources.redhat.com/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available   
starting at this URL.

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat, Inc.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: [ANNOUNCEMENT] [1.7] Updated: file-5.00-1

[Charles Wilson]

Corinna Vinschen wrote:
> I've updated the Cygwin 1.7 version of file to 5.00-1.

Odd behavior: after I did a rebaseall, I was consistently seeing
coredumps using this version of file.  Reverting to the older version of
file fixed it, as did re-installing the new version.

I haven't rebased again, but is there any reason to suspect that
cygmagic-1.dll is not rebaseable?

(Vista Home Premium 32bit; cygwin-1.7.0-40)

--
Chuck


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: [ANNOUNCEMENT] [1.7] Updated: file-5.00-1

[Corinna Vinschen]

On Feb 19 23:03, Charles Wilson wrote:
> Corinna Vinschen wrote:
> > I've updated the Cygwin 1.7 version of file to 5.00-1.
> 
> Odd behavior: after I did a rebaseall, I was consistently seeing
> coredumps using this version of file.  Reverting to the older version of
> file fixed it, as did re-installing the new version.
> 
> I haven't rebased again, but is there any reason to suspect that
> cygmagic-1.dll is not rebaseable?

Apparently.  I rebased the DLL alone and afterwards file simply stopped
working.  The DLL has a base address of 0x6a500000.  Even rebasing to
the very same address results in a coredump!

The DLL has been built with -static-libgcc.  Assuming that this might
have been the reason I rebuilt the file package without -static-libgcc,
so the DLL now depends on cyggcc_s.dll.  And, guess what, afterwards
the DLL is rebaseable just fine.

Dave?  Any idea why this occurs?  The crash happens when the Cygwin DLL
is running the ctors list.  Given that the file package is using plain
C, it seems that a static libgcc is non-relocatable for whatever reason.

For the time being, I create and uploaded a new file package which 
depends on gcc4-runtime.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: [ANNOUNCEMENT] [1.7] Updated: file-5.00-1

[Dave Korn]

Corinna Vinschen wrote:
> On Feb 19 23:03, Charles Wilson wrote:
>> Corinna Vinschen wrote:
>>> I've updated the Cygwin 1.7 version of file to 5.00-1.
>> Odd behavior: after I did a rebaseall, I was consistently seeing
>> coredumps using this version of file.  Reverting to the older version of
>> file fixed it, as did re-installing the new version.
>>
>> I haven't rebased again, but is there any reason to suspect that
>> cygmagic-1.dll is not rebaseable?
> 
> Apparently.  I rebased the DLL alone and afterwards file simply stopped
> working.  The DLL has a base address of 0x6a500000.  Even rebasing to
> the very same address results in a coredump!
> 
> The DLL has been built with -static-libgcc.  Assuming that this might
> have been the reason I rebuilt the file package without -static-libgcc,
> so the DLL now depends on cyggcc_s.dll.  And, guess what, afterwards
> the DLL is rebaseable just fine.
> 
> Dave?  Any idea why this occurs?  The crash happens when the Cygwin DLL
> is running the ctors list.  Given that the file package is using plain
> C, it seems that a static libgcc is non-relocatable for whatever reason.

  Investigating.  While I do that, I noticed a bug:

libtool: compile:  gcc-4 -DHAVE_CONFIG_H -I. -I..
-DMAGIC=\"/usr/local/share/file/magic\" -Wall -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Wmissing-declarations -Wredundant-decls
-Wnested-externs -Wsign-compare -Wreturn-type -Wswitch -Wshadow -Wcast-qual
-Wwrite-strings -Wextra -Wunused-parameter -g -O2 -MT magic.lo -MD -MP -MF
.deps/magic.Tpo -c magic.c -o magic.o
magic.c: In function 'file_or_fd':
magic.c:304: warning: passing argument 1 of 'strlcat' makes pointer from
integer without a cast

   304				(void)strlcat(strlcpy(tmp, inname, len), ".exe", len);


  That sort of construct works for "strcat (strcpy ())" but not for the 'l'
versions, they aren't drop-in replacements.

  <suddenly does HUGE double-take on seeing surrounding code>

   251	public const char *
   252	magic_file(struct magic_set *ms, const char *inname)

               ...

   257	private const char *
   258	file_or_fd(struct magic_set *ms, const char *inname, int fd)

/sighs  *facepalm*  <hurried grep>

    68	#define private static
    69	#ifndef protected
    70	#define protected
    71	#endif
    72	#define public

*headdesk* *facepalm* *headdesk* *facepalm* *headdesk*

    cheers,
      DaveK



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: [ANNOUNCEMENT] [1.7] Updated: file-5.00-1

[Dave Korn]

Corinna Vinschen wrote:
>> I haven't rebased again, but is there any reason to suspect that
>> cygmagic-1.dll is not rebaseable?
>
> Apparently.  I rebased the DLL alone and afterwards file simply stopped
> working.  The DLL has a base address of 0x6a500000.  Even rebasing to
> the very same address results in a coredump!
>
> The DLL has been built with -static-libgcc.  Assuming that this might
> have been the reason I rebuilt the file package without -static-libgcc,
> so the DLL now depends on cyggcc_s.dll.  And, guess what, afterwards
> the DLL is rebaseable just fine.
>
> Dave?  Any idea why this occurs?

  Nope, I can't reproduce it yet.  I installed the file-5.00-1 sources and
then ran

root@host /usr/src/file-5.00-1
$ ./configure  --prefix=/usr/local CC='gcc-4 -static-libgcc'
$ make
$ cd src/.libs/
$ cp cygmagic-1.dll cygmagic-1.dll.bak
$ rebase -v -b 0x6a500000 ./cygmagic-1.dll

root@host /usr/src/file-5.00-1/src/.libs
$ ./file.exe ./file.exe
file: could not find any magic files!

  No crash.  Then I tried it on the live version in /bin:

root@host /bin
$ cp cygmagic-1.dll cygmagic-1.dll.bak

root@host /bin
$ ./file.exe ./file.exe
./file.exe: PE32 executable for MS Windows (console) Intel 80386 32-bit

root@host /bin
$ rebase -v -b 0x6a500000 ./cygmagic-1.dll
./cygmagic-1.dll: new base = 6a500000, new size = 20000

root@host /bin
$ ./file.exe ./file.exe
./file.exe: PE32 executable for MS Windows (console) Intel 80386 32-bit

  I verified that I have the statically linked version installed, rather than
the update you just uploaded:

root@host /bin
$ cygcheck ./cygmagic-1.dll
F:\cygwin-1.7\bin\cygmagic-1.dll
  F:\cygwin-1.7\bin\cygwin1.dll
    C:\WINNT\system32\ADVAPI32.DLL
      C:\WINNT\system32\NTDLL.DLL
      C:\WINNT\system32\KERNEL32.DLL
      C:\WINNT\system32\RPCRT4.DLL
  F:\cygwin-1.7\bin\cygz.dll

root@host /bin

  Did I do something wrong?  Did you do something differently?  I note that
after my attempt to rebase at the same address, the DLL afterward is identical
to the one before:

DKAdmin@ubik /bin
$ md5sum cygmagic-1.dll cygmagic-1.dll.bak
1628930e970b95891bd5ce79bab9f814 *cygmagic-1.dll
1628930e970b95891bd5ce79bab9f814 *cygmagic-1.dll.bak

  Do you see the same result?  Because if so, that would be *really* strange!

> The crash happens when the Cygwin DLL
> is running the ctors list.  Given that the file package is using plain
> C, it seems that a static libgcc is non-relocatable for whatever reason.

  I'm fairly certain it shouldn't be.  You can't expect exceptions to work
right in these circumstances, but I wouldn't see why they would be involved.

  Can one of you and Chuck run addr2line on the stackdump from the crash?  I
have no idea what's even going on yet.


    cheers,
      DaveK


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: [ANNOUNCEMENT] [1.7] Updated: file-5.00-1

[Corinna Vinschen]

On Feb 20 13:35, Dave Korn wrote:
> Corinna Vinschen wrote:
> > Apparently.  I rebased the DLL alone and afterwards file simply stopped
> > working.  The DLL has a base address of 0x6a500000.  Even rebasing to
> > the very same address results in a coredump!
> > 
> > The DLL has been built with -static-libgcc.  Assuming that this might
> > have been the reason I rebuilt the file package without -static-libgcc,
> > so the DLL now depends on cyggcc_s.dll.  And, guess what, afterwards
> > the DLL is rebaseable just fine.
> > 
> > Dave?  Any idea why this occurs?  The crash happens when the Cygwin DLL
> > is running the ctors list.  Given that the file package is using plain
> > C, it seems that a static libgcc is non-relocatable for whatever reason.
> 
>   Investigating.  While I do that, I noticed a bug:
> 
> libtool: compile:  gcc-4 -DHAVE_CONFIG_H -I. -I..
> -DMAGIC=\"/usr/local/share/file/magic\" -Wall -Wstrict-prototypes
> -Wmissing-prototypes -Wpointer-arith -Wmissing-declarations -Wredundant-decls
> -Wnested-externs -Wsign-compare -Wreturn-type -Wswitch -Wshadow -Wcast-qual
> -Wwrite-strings -Wextra -Wunused-parameter -g -O2 -MT magic.lo -MD -MP -MF
> .deps/magic.Tpo -c magic.c -o magic.o
> magic.c: In function 'file_or_fd':
> magic.c:304: warning: passing argument 1 of 'strlcat' makes pointer from
> integer without a cast
> 
>    304				(void)strlcat(strlcpy(tmp, inname, len), ".exe", len);
> 
> 
>   That sort of construct works for "strcat (strcpy ())" but not for the 'l'
> versions, they aren't drop-in replacements.

Urgh!


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: [ANNOUNCEMENT] [1.7] Updated: file-5.00-1

[Corinna Vinschen]

On Feb 20 14:45, Corinna Vinschen wrote:
> On Feb 20 13:35, Dave Korn wrote:
> > magic.c:304: warning: passing argument 1 of 'strlcat' makes pointer from
> > integer without a cast
> > 
> >    304				(void)strlcat(strlcpy(tmp, inname, len), ".exe", len);
> > 
> > 
> >   That sort of construct works for "strcat (strcpy ())" but not for the 'l'
> > versions, they aren't drop-in replacements.
> 
> Urgh!

Upstream has changed my code!  Sacrilege!

Fortunately this code won't be used anymore in Cygwin 1.7 because 1.7
appends the .exe suffix in calls to open transparently.

I'll send a fix upstream.  The fix is to remove the CYGWIN specific code.
I won't create a 1.5.x version of file >= 5.00 anyway.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: [ANNOUNCEMENT] [1.7] Updated: file-5.00-1

[Dave Korn]

Dave Korn wrote:
> Corinna Vinschen wrote:

>> Apparently.  I rebased the DLL alone and afterwards file simply stopped
>> working.  The DLL has a base address of 0x6a500000.  Even rebasing to
>> the very same address results in a coredump!

>   Nope, I can't reproduce it yet.  

  I can now, but not by rebasing to the exact same address; did something just
go amiss in your testing of that particular case maybe?


DKAdmin@ubik /bin
$ rebase -v -b 0x6b500000 ./cygmagic-1.dll
./cygmagic-1.dll: new base = 6b500000, new size = 20000

DKAdmin@ubik /bin
$ ./file.exe ./file.exe
      1 [main] file 1556 _cygtls::handle_exceptions: Error while dumping state
(probably corrupted stack)
Segmentation fault (core dumped)


  It's reversible, too!


DKAdmin@ubik /bin
$ rebase -v -b 0x6a500000 ./cygmagic-1.dll
./cygmagic-1.dll: new base = 6a500000, new size = 20000

DKAdmin@ubik /bin
$ ./file.exe ./file.exe
./file.exe: PE32 executable for MS Windows (console) Intel 80386 32-bit

DKAdmin@ubik /bin
$ rebase -v -b 0x6b500000 ./cygmagic-1.dll
./cygmagic-1.dll: new base = 6b500000, new size = 20000

DKAdmin@ubik /bin
$ ./file.exe ./file.exe
      1 [main] file 1404 _cygtls::handle_exceptions: Error while dumping state
(probably corrupted stack)
Segmentation fault (core dumped)

DKAdmin@ubik /bin
$ rebase -v -b 0x6a500000 ./cygmagic-1.dll
./cygmagic-1.dll: new base = 6a500000, new size = 20000

DKAdmin@ubik /bin
$ ./file.exe ./file.exe
./file.exe: PE32 executable for MS Windows (console) Intel 80386 32-bit

DKAdmin@ubik /bin

  Ok, now I'll try debugging it.

    cheers,
      DaveK


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: [ANNOUNCEMENT] [1.7] Updated: file-5.00-1

[Corinna Vinschen]

On Feb 20 14:14, Dave Korn wrote:
> Dave Korn wrote:
> > Corinna Vinschen wrote:
> 
> >> Apparently.  I rebased the DLL alone and afterwards file simply stopped
> >> working.  The DLL has a base address of 0x6a500000.  Even rebasing to
> >> the very same address results in a coredump!
> 
> >   Nope, I can't reproduce it yet.  
> 
>   I can now, but not by rebasing to the exact same address; did something just
> go amiss in your testing of that particular case maybe?

I have no idea, sorry.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: [ANNOUNCEMENT] [1.7] Updated: file-5.00-1

[Dave Korn]

Dave Korn wrote:

>   Ok, now I'll try debugging it.

  Ah.  Right.  Ouch.  I see what's going on.  Rebasing does not interact well
with the presence of unresolved weaks.  Gah.

  The problem arises here, in cygming-crtbegin.c:

-----------------------<snip>-----------------------
extern void __register_frame_info (const void *, struct object *)
				   TARGET_ATTRIBUTE_WEAK;
-----------------------<snip>-----------------------
/* We need to indirect through a variable, as gcc assumes
 that a function label used as a constant is never zero.  */
void (*register_frame_info_ptr) (const void *, struct object *) =
__register_frame_info;
-----------------------<snip>-----------------------
                 < comments, #ifdefs folded >
void
__gcc_register_frame (void)
{
  void (*register_frame_fn) (const void *, struct object *) = 0;
  HANDLE h = GetModuleHandle (LIBGCC_SONAME);
  if (h)
    register_frame_fn = (void (*) (const void *, struct object *))
			GetProcAddress (h, "__register_frame_info");
  if (!register_frame_fn)
    register_frame_fn = register_frame_info_ptr;

  if (register_frame_fn)
     register_frame_fn (__EH_FRAME_BEGIN__, &obj);
-----------------------<snip>-----------------------

  The purpose of playing these games is in order not to drag in the whole
exception handling machinery into a statically-linked application unless we
actually need it.  We're relying on detecting an unlinked weak symbol by it
having a value of zero at runtime.  That usually works, but the pointer
variable register_frame_info_ptr must have some kind of reloc pointing at it,
because rebase adjusts it, so instead of zero it becomes equal to the
difference between the new and old base addresses.

  I'll need to do some thinking about this, as it might be possible to make it
work, but in any case, the rule should be that DLLs are *always* linked
against shared-libgcc, regardless; even plain old C with no exceptions.  It's
OK if you're linking an entire app statically to link against static libgcc,
but it's definitely bad practice when building a DLL.  I should probably warn
against this usage in the compiler, if not fail it altogether; not sure yet,
because it does basically work, even if the DLL it produces isn't rebaseable,
and because it might not be difficult to make rebase skip relocating
unresolved weaks, and because I have this long-term scheme to make weaks work
properly on win32 like they do on ELF which would avoid the problem altogether.



  Take-home point: never use -static-libgcc when building a DLL.

    cheers,
      DaveK


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: [ANNOUNCEMENT] [1.7] Updated: file-5.00-1

[Corinna Vinschen]

On Feb 20 15:06, Dave Korn wrote:
> Dave Korn wrote:
>   Ah.  Right.  Ouch.  I see what's going on.  Rebasing does not interact well
> with the presence of unresolved weaks.  Gah.
> [...]
>   I'll need to do some thinking about this, as it might be possible to make it
> work, but in any case, the rule should be that DLLs are *always* linked
> against shared-libgcc, regardless; even plain old C with no exceptions.  It's
> OK if you're linking an entire app statically to link against static libgcc,
> but it's definitely bad practice when building a DLL.  I should probably warn
> against this usage in the compiler, if not fail it altogether; not sure yet,
> because it does basically work, even if the DLL it produces isn't rebaseable,
> and because it might not be difficult to make rebase skip relocating
> unresolved weaks, and because I have this long-term scheme to make weaks work
> properly on win32 like they do on ELF which would avoid the problem altogether.
> 
> 
> 
>   Take-home point: never use -static-libgcc when building a DLL.

Baeh.  The two of us discussed this in PM a couple of days back and I
still don't like the idea to depend on cyggcc_s.dll for more or less
every other package providing a DLL.  If that's becoming the default, we
need at least to put the gcc-runtime package into Base, IMHO.  Yes,
I know you can simply add the dependency to setup.hint, but still.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: [ANNOUNCEMENT] [1.7] Updated: file-5.00-1

[Dave Korn]

Corinna Vinschen wrote:
>>
>>   Take-home point: never use -static-libgcc when building a DLL.
> 
> Baeh.  The two of us discussed this in PM a couple of days back and I
> still don't like the idea to depend on cyggcc_s.dll for more or less
> every other package providing a DLL.  

  Nah, I think I was expressing that too strongly.  I guess if something's
only pulling in a few math functions from the DLL, it shouldn't need to do so
dynamically if it doesn't want to.  I'll find a way to make this usage work
under rebasing.

    cheers,
      DaveK



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: [ANNOUNCEMENT] [1.7] Updated: file-5.00-1

[Dave Korn]

Dave Korn wrote:

>   The purpose of playing these games is in order not to drag in the whole
> exception handling machinery into a statically-linked application unless we
> actually need it.  We're relying on detecting an unlinked weak symbol by it
> having a value of zero at runtime.  That usually works, but the pointer
> variable register_frame_info_ptr must have some kind of reloc pointing at it,
> because rebase adjusts it, so instead of zero it becomes equal to the
> difference between the new and old base addresses.


  That rang a bell, and reminded me of something Danny posted a little while back:

http://sourceware.org/ml/binutils/2008-07/msg00372.html

  So I believe now this is a symptom of a buggy ld already fixed upstream.
I'll try the testcase again against one of my CVS builds of binutils and
report back, but I expect it will fix the problem and rebase will no longer
alter the unlinked weak null-initialised pointer.

    cheers,
      DaveK


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: [ANNOUNCEMENT] [1.7] Updated: file-5.00-1

[Dave Korn]

Dave Korn wrote:
> http://sourceware.org/ml/binutils/2008-07/msg00372.html
> 
>   So I believe now this is a symptom of a buggy ld already fixed upstream.
> I'll try the testcase again against one of my CVS builds of binutils and
> report back, but I expect it will fix the problem and rebase will no longer
> alter the unlinked weak null-initialised pointer.

  Confirmed.  (This has implications which I will pursue in the GCC4 thread on
-apps.)

    cheers,
      DaveK


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/