Re: [ANNOUNCEMENT] [1.7] Updated: file-5.00-1
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 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/
Re: [ANNOUNCEMENT] [1.7] Updated: file-5.00-1
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 0x6a50. 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
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 0x6a50. 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
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 0x6a50. 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 r...@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 0x6a50 ./cygmagic-1.dll r...@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: r...@host /bin $ cp cygmagic-1.dll cygmagic-1.dll.bak r...@host /bin $ ./file.exe ./file.exe ./file.exe: PE32 executable for MS Windows (console) Intel 80386 32-bit r...@host /bin $ rebase -v -b 0x6a50 ./cygmagic-1.dll ./cygmagic-1.dll: new base = 6a50, new size = 2 r...@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: r...@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 r...@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: dkad...@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
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 0x6a50. 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
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 wrote: Corinna Vinschen wrote: Apparently. I rebased the DLL alone and afterwards file simply stopped working. The DLL has a base address of 0x6a50. 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? dkad...@ubik /bin $ rebase -v -b 0x6b50 ./cygmagic-1.dll ./cygmagic-1.dll: new base = 6b50, new size = 2 dkad...@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! dkad...@ubik /bin $ rebase -v -b 0x6a50 ./cygmagic-1.dll ./cygmagic-1.dll: new base = 6a50, new size = 2 dkad...@ubik /bin $ ./file.exe ./file.exe ./file.exe: PE32 executable for MS Windows (console) Intel 80386 32-bit dkad...@ubik /bin $ rebase -v -b 0x6b50 ./cygmagic-1.dll ./cygmagic-1.dll: new base = 6b50, new size = 2 dkad...@ubik /bin $ ./file.exe ./file.exe 1 [main] file 1404 _cygtls::handle_exceptions: Error while dumping state (probably corrupted stack) Segmentation fault (core dumped) dkad...@ubik /bin $ rebase -v -b 0x6a50 ./cygmagic-1.dll ./cygmagic-1.dll: new base = 6a50, new size = 2 dkad...@ubik /bin $ ./file.exe ./file.exe ./file.exe: PE32 executable for MS Windows (console) Intel 80386 32-bit dkad...@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
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 0x6a50. 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 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
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
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
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/
