Re: relocation truncated to fit: R_X86_64_PC32 against undefined symbol `len'
Hi Richard, On Sat, Apr 5, 2014 at 6:51 PM, Richard wrote: > > Hello Everyone, > > I recently (two weeks ago or so) upgraded the cygwin installation on an XP > 64 bit (corp edition) box and in getting things running on it again I've > been having various troubles, even though I was VERY careful to watch for > any installation errors - none were noticed. Normally I don't do development > on this box but copy over from other systems. I had at least one program > that was not behaving correctly - it would apparently hide output sent to > stdout among other mysteries. After fiddling with things I decided to just > rebuild on that box from sources - it's almost all gnu c. (Note that this > code needs to run unchanged on many different platforms.) > > At some point I get to the gcc call to bind together three object files into > an executable - all the object files having just been built with zero errors > - and I get this particular "undefined reference to `len'" error. Of course > I went hunting for the use of 'len' - which is a pretty absurd effort as a > simple grep matches on coutless noise such as 'filename' or 'strlen', etc. Have you tried the -w option of grep? > However, a thorough search revealed no uses of just 'len', yet I don't deny > I could possibly have overlooked it. Try the following in the directory where the object files are: nm *.o | grep -P '\.o:|\blen\b' > Even so, this directory was taken > wholesale from a 64 bit system (Win 7) with an older cygwin installation > where the code compiles and runs fine. So somehow I don't think it's > actually in my code but rather a library reference problem somehow. > > The specific set of error output from make is: > > $ gcc -o ctjc.exe ctjc.o hashc.o sha1.o; > ctjc.o:ctjc.c:(.text+0x2287): undefined reference to `len' > ctjc.o:ctjc.c:(.text+0x2287): relocation truncated to fit: R_X86_64_PC32 > against undefined symbol `len' You may have a mix of 32-bit and 64-bit object files. What does the following command print? file *.o Csaba -- GCS a+ e++ d- C++ ULS$ L+$ !E- W++ P+++$ w++$ tv+ b++ DI D++ 5++ The Tao of math: The numbers you can count are not the real numbers. Life is complex, with real and imaginary parts. "Ok, it boots. Which means it must be bug-free and perfect. " -- Linus Torvalds "People disagree with me. I just ignore them." -- Linus Torvalds -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: long_int vs int byte sizes
On Sun, Apr 6, 2014 at 8:35 AM, Rob wrote: > I think so. I've not yet struck a case on Windows where either int or long > are not 4 bytes. (Haven't tried Cygwin64.) Obviously you never used a 16-bit compiler :) (where int is 16 bits and long is 32 bits usually) Csaba -- GCS a+ e++ d- C++ ULS$ L+$ !E- W++ P+++$ w++$ tv+ b++ DI D++ 5++ The Tao of math: The numbers you can count are not the real numbers. Life is complex, with real and imaginary parts. "Ok, it boots. Which means it must be bug-free and perfect. " -- Linus Torvalds "People disagree with me. I just ignore them." -- Linus Torvalds -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Possibly wrong address passed to callq asm instruction within MPIR test binaries
Jean-Pierre Flori writes: > The problem we recently encountered was the following: > in gmp-impl.h, mpn_store (which can be either a macro or a function if > efficient assembly is available, and so is always a function on x86_64) > was not marked __declspec(dllexport/dllimport). I can confirm that GMP has the same problem when I patch out these attributes (which I wanted to do because these cause lots of spurious warnings during compilation). This works fine on 32bit, but produces segmentation faults in some (not all) 64bit test binaries. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf rackAttack: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Possibly wrong address passed to callq asm instruction within MPIR test binaries
On Apr 6 20:20, Jean-Pierre Flori wrote:
> [...]
> The problem we recently encountered was the following:
> in gmp-impl.h, mpn_store (which can be either a macro or a function if
> efficient assembly is available, and so is always a function on x86_64)
> was not marked __declspec(dllexport/dllimport).
> (See https://github.com/wbhart/mpir/blob/master/gmp-impl.h#L2419 for the
> current version with the __GMP_DECLSPEC, defined in mpir.h (from gmp-
> h.in) where this gets defined as __declspec(dllimport) for the user
> visible header and use outside of MPIR itself)
> It seems that because of this lack, the call to mpn_store from a bunch of
> test executables produced the wrong callq instruction.
> Once we added the __GMP_DECLSPEC the function got correctly called.
>
> What I don't really get is that from what I've read e.g. here : https://
> access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/4/
> html/Using_ld_the_GNU_Linker/win32.html
> is that the dllimport/export should not be needed anymore.
And in fact it isn't.
> So I took a slightly deeper look and played with the definition of
> __GMP_DECLSPEC in gmp-h.in/mpir.h to be empty or __declspec(dllexport/
> import).
> The library was built with:
> ./configure --disable-static --enable-shared
> make
> make check (-> potential segfaults when testing the mpn dir)
>
> As far as dllexport is concerned, we pass --export-all-symbols to ld, and
> as expected, we don't need the dllexport part when building the library
> (we get __imp_ and __nm_ symbols for functions).
>
> But it seems that the --enable-auto-import counterpart (which should be
> ld default) is defeated.
> I've had a look at the assembly and objects produced by gcc before linking
> and they indeed look different.
> With the dllimport magic, I get in t-neg.s:
> movq%rax, %rcx
> movq__imp___gmpn_store(%rip), %rax
> call*%rax
> Without it I get:
> movq%rax, %rcx
> call__gmpn_store
> Similar differences in the object file (t-neg.o).
> Looking at the exes produced (.libs/t-neg.exe) gives with the dllimport
> magic:
>100401115: 48 89 c1mov%rax,%rcx
>100401118: 48 8b 05 f1 71 00 00mov0x71f1(%rip),%rax#
> 100408310 <__imp___gmpn_store>
>10040111f: ff d0 callq *%rax
> Without it:
>10040: 48 89 c1mov%rax,%rcx
>100401114: e8 f7 71 00 00 callq 100408310
> <__imp___gmpn_store>
This is ok. Look closely at the address after the callq. It's the
start address of the executable (0x1:0040) plus an offset. If you
disassemble the executable you will find a jmp statement at this
address. This is the trampoline code which is automatically generated
for external references if they are not marked with dllimport.
The problem at this point is that I can't reproduce your issue with a
simple example. Here's the example:
SNIP
$ cat > lib.c <
int
foo (int a)
{
printf ("a = %d\n", a);
return a;
}
EOF
$ cat > app.c <
extern int foo (int);
int
main ()
{
int x = foo (42);
printf ("x = %d\n", x);
return 0;
}
EOF
$ gcc -g -shared -o lib.dll lib.c
$ gcc -g -o app app.c lib.dll
$ ./app
a = 42
x = 42
SNAP
Let's have a look into the executable:
$ objdump -d app.exe
[...]
0001004010d0 :
1004010d0: 55 push %rbp
1004010d1: 48 89 e5mov%rsp,%rbp
1004010d4: 48 83 ec 30 sub$0x30,%rsp
1004010d8: e8 93 00 00 00 callq 100401170 <__main>
1004010dd: b9 2a 00 00 00 mov$0x2a,%ecx
1004010e2: e8 59 06 00 00 callq 100401740
1004010e7: 89 45 fcmov%eax,-0x4(%rbp)
[...]
So the call to foo is a call to address 1:00401740. Let's have
a look what is at that address:
000100401740 :
100401740: ff 25 1a 5a 00 00 jmpq *0x5a1a(%rip)# 100407160
<__imp_foo>
Address 100407160 is somewhere within the IAT which gets relocated
at runtime.
This is exactly as it's supposed to be.
Now, here's the question: Where is your problem different? What
exactly makes your code fail? Can you construct your problem from
my simple testcase, or can you construct an equally simple testcase
which fails?
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
pgpg5F7iECioF.pgp
Description: PGP signature
Re: relocation truncated to fit: R_X86_64_PC32 against undefined symbol `len'
On Apr 5 09:51, Richard wrote: > > Hello Everyone, > > I recently (two weeks ago or so) upgraded the cygwin installation on > an XP 64 bit (corp edition) box and in getting things running on it > again I've been having various troubles, even though I was VERY > careful to watch for any installation errors - none were noticed. > Normally I don't do development on this box but copy over from other > systems. I had at least one program that was not behaving correctly > - it would apparently hide output sent to stdout among other > mysteries. After fiddling with things I decided to just rebuild on > that box from sources - it's almost all gnu c. (Note that this code > needs to run unchanged on many different platforms.) > > At some point I get to the gcc call to bind together three object > files into an executable - all the object files having just been > built with zero errors - and I get this particular "undefined > reference to `len'" error. Of course I went hunting for the use of > 'len' - which is a pretty absurd effort as a simple grep matches on > coutless noise such as 'filename' or 'strlen', etc. However, a > thorough search revealed no uses of just 'len', yet I don't deny I > could possibly have overlooked it. Even so, this directory was taken > wholesale from a 64 bit system (Win 7) with an older cygwin > installation where the code compiles and runs fine. So somehow I > don't think it's actually in my code but rather a library reference > problem somehow. > > The specific set of error output from make is: > > $ gcc -o ctjc.exe ctjc.o hashc.o sha1.o; > ctjc.o:ctjc.c:(.text+0x2287): undefined reference to `len' > ctjc.o:ctjc.c:(.text+0x2287): relocation truncated to fit: > R_X86_64_PC32 against undefined symbol `len' > /usr/bin/ld: ctjc.o: bad reloc address 0x0 in section `.pdata' > /usr/bin/ld: final link failed: Invalid operation > collect2: error: ld returned 1 exit status > > Any assistance greatly appreciated. As I outlined in other mail to this list just a couple of days ago, the "relocation truncated to fit" stuff is a red herring. It's just a side-effect of the way addressing and relocation on x86_64 works. The important part of the message is the first one: undefined reference to `len'. That's what you have to look for. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpAH5CjDG6ld.pgp Description: PGP signature
Re: long_int vs int byte sizes
On Apr 6 16:35, sisyph...@optusnet.com.au wrote: > -Original Message- From: Joseph Maxwell > > >[quote] > >int x = 0xAB78 in decimal format is : 43896 > >and > >unsigned int y = 0xAB78 in decimal format is : 43896 > >The size of int is 4 bytes > >[/quote] > > > >Not quite what I expected, sine the leftmost bit in 'int' is 1 and > >would be the negative flag. > > No - the full 32-bit representation of 0xAB78 is: > > 1010 1011 0111 1000 > > The leftmost bit is zero. > > > >Note size of int and long int are the same both are 4 bytes long > > > >Is this to be expected? > > I think so. I've not yet struck a case on Windows where either int > or long are not 4 bytes. (Haven't tried Cygwin64.) On x86_64 Cygwin, sizeof (long) == 8. See http://cygwin.com/faq/faq.html#faq.programming.64bitporting > Certainly, on some other systems, int is 4 bytes and long is 8 bytes. > The standards permit both configurations. There's no standard which restricts the sizes of the datatypes in that way. There's only this rule to follow: sizeof (char) <= sizeof (short) <= sizeof (int) <= sizeof (long) Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp00rvSBCWr1.pgp Description: PGP signature
Re: could mkgroup be updated to define the group root?
On Apr 6 13:29, Patrick Rouleau wrote: > Hi! > > After a fresh Cygwin installation, /etc/group contains this line: > root:S-1-5-32-544:0: > > When we update the file /etc/group with mkgroup, that line is lost. > > Is it possible to update mkgroup to include that line in its output? Just add it yourself using a script. mkgroup never produced this line, it's part of the profile scripts, and even this will go away at one point, as soon as the AD integration in Cygwin goes life. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp_4HtWIQ3WM.pgp Description: PGP signature
Re: exe.stackdump is always empty
On Apr 4 22:07, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote:
> Any ideas, please?
>
> > http://cygwin.com/problems.html
> > http://cygwin.com/acronyms/#STC
>
> $ cat assert.c
> #include
>
> int main(void)
> { assert(0);
> return 0;
> }
>
> $ ulimit -a
> core file size (blocks, -c) unlimited
> data seg size (kbytes, -d) unlimited
> file size (blocks, -f) unlimited
> open files (-n) 256
> pipe size(512 bytes, -p) 8
> stack size (kbytes, -s) 2025
> cpu time (seconds, -t) unlimited
> max user processes (-u) 256
> virtual memory (kbytes, -v) unlimited
>
> $ gcc -g assert.c
>
> $ ./a.exe
> assertion "0" failed: file "assert.c", line 4, function: main
> Aborted (core dumped)
>
> $ cat a.exe.stackdump
> Stack trace:
> Frame Function Args
Hmm, not me. In my case a stackdump is generated, albeit not very
complete:
$ cat assert.exe.stackdump
Stack trace:
Frame Function Args
0028A898 610303D2 (00B4, EA60, 00A4, 0028A8E8)
0028A9A8 610DA4DD (75D2E158, , 6E00016F, )
The 64 bit stackdump looks better:
$ cat assert.exe.stackdump
Stack trace:
FrameFunctionArgs
023A480 0018006F733 (7FF9E9680EBF, 000, 003, 016)
006 00180070C6A (023A940, 000, 09C, 000)
023A660 0018011AEE8 (0341B10, 000, 000, 000)
0C1 00180117FEE (003, 000, 000, 000)
023AAB0 001801184BB (7FF9E967ED89, 000, 00100403032, 006)
023AAB0 0018011868C (7FF9E6A9151B, 0004048, 001801EE0D8, 0018011CB7C)
023AAB0 0018011894F (00100403030, 00100403032, 004, 001801EE02F)
023AAB0 00180041B45 (000, 000, 000, 023AB90)
023AAE0 001004010FC (020, 3000100FF00, 0018004819A,
000)
023AB90 0018004820B (000, 000, 000, 000)
000 0018004611B (000, 000, 000, 000)
000 00180046274 (000, 000, 000, 000)
000 0010040 (000, 000, 000, 000)
000 00100401010 (000, 000, 000, 000)
000 7FF9E93115DD (000, 000, 000, 000)
000 7FF9E96B43D1 (000, 000, 000, 000)
End of stack trace (more stack frames may be present)
but I'm not exactly an expert in how to generate a stackdump on i686.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
pgpbtVUAGVMHJ.pgp
Description: PGP signature
Re: Possibly wrong address passed to callq asm instruction within MPIR test binaries
Le Mon, 07 Apr 2014 10:43:12 +0200, Corinna Vinschen a écrit :
> On Apr 6 20:20, Jean-Pierre Flori wrote:
>> [...]
>> The problem we recently encountered was the following:
>> in gmp-impl.h, mpn_store (which can be either a macro or a function if
>> efficient assembly is available, and so is always a function on x86_64)
>> was not marked __declspec(dllexport/dllimport).
>> (See https://github.com/wbhart/mpir/blob/master/gmp-impl.h#L2419 for
>> the current version with the __GMP_DECLSPEC, defined in mpir.h (from
>> gmp- h.in) where this gets defined as __declspec(dllimport) for the
>> user visible header and use outside of MPIR itself)
>> It seems that because of this lack, the call to mpn_store from a bunch
>> of test executables produced the wrong callq instruction.
>> Once we added the __GMP_DECLSPEC the function got correctly called.
>>
>> What I don't really get is that from what I've read e.g. here :
>> https://
>> access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/4/
>> html/Using_ld_the_GNU_Linker/win32.html is that the dllimport/export
>> should not be needed anymore.
>
> And in fact it isn't.
>
>> So I took a slightly deeper look and played with the definition of
>> __GMP_DECLSPEC in gmp-h.in/mpir.h to be empty or __declspec(dllexport/
>> import).
>> The library was built with:
>> ./configure --disable-static --enable-shared make make check (->
>> potential segfaults when testing the mpn dir)
>>
>> As far as dllexport is concerned, we pass --export-all-symbols to ld,
>> and as expected, we don't need the dllexport part when building the
>> library (we get __imp_ and __nm_ symbols for functions).
>>
>> But it seems that the --enable-auto-import counterpart (which should be
>> ld default) is defeated.
>> I've had a look at the assembly and objects produced by gcc before
>> linking and they indeed look different.
>> With the dllimport magic, I get in t-neg.s:
>> movq%rax, %rcx movq__imp___gmpn_store(%rip), %rax call
>> *%rax
>> Without it I get:
>> movq%rax, %rcx call__gmpn_store
>> Similar differences in the object file (t-neg.o).
>> Looking at the exes produced (.libs/t-neg.exe) gives with the dllimport
>> magic:
>>100401115: 48 89 c1mov%rax,%rcx 100401118:
>>48 8b 05 f1 71 00 00mov0x71f1(%rip),%rax#
>> 100408310 <__imp___gmpn_store>
>>10040111f: ff d0 callq *%rax
>> Without it:
>>10040: 48 89 c1mov%rax,%rcx 100401114:
>>e8 f7 71 00 00 callq 100408310
>> <__imp___gmpn_store>
>
> This is ok. Look closely at the address after the callq. It's the
> start address of the executable (0x1:0040) plus an offset. If you
> disassemble the executable you will find a jmp statement at this
> address. This is the trampoline code which is automatically generated
> for external references if they are not marked with dllimport.
>
> The problem at this point is that I can't reproduce your issue with a
> simple example. Here's the example:
>
> SNIP
> $ cat > lib.c <
>
> int foo (int a)
> {
> printf ("a = %d\n", a);
> return a;
> }
> EOF $ cat > app.c <
>
> extern int foo (int);
>
> int main ()
> {
> int x = foo (42); printf ("x = %d\n", x);
> return 0;
> }
> EOF $ gcc -g -shared -o lib.dll lib.c $ gcc -g -o app app.c lib.dll $
> ./app a = 42 x = 42 SNAP
>
> Let's have a look into the executable:
>
> $ objdump -d app.exe [...]
> 0001004010d0 :
>1004010d0: 55 push %rbp 1004010d1: 48 89
>e5mov%rsp,%rbp 1004010d4: 48 83 ec 30
> sub$0x30,%rsp 1004010d8: e8 93 00 00 00 callq
>100401170 <__main>
>1004010dd: b9 2a 00 00 00 mov$0x2a,%ecx 1004010e2:
>e8 59 06 00 00 callq 100401740
>1004010e7: 89 45 fcmov%eax,-0x4(%rbp)
>[...]
>
> So the call to foo is a call to address 1:00401740. Let's have a look
> what is at that address:
>
> 000100401740 :
>100401740: ff 25 1a 5a 00 00 jmpq *0x5a1a(%rip)#
>100407160 <__imp_foo>
>
> Address 100407160 is somewhere within the IAT which gets relocated at
> runtime.
For most functions I indeed see this trampoline trick within the binary.
>
> This is exactly as it's supposed to be.
>
> Now, here's the question: Where is your problem different? What
> exactly makes your code fail? Can you construct your problem from my
> simple testcase, or can you construct an equally simple testcase which
> fails?
Looking a little further, it seems the problematic functions are those
directly assembled from assembly code.
That was the case of mpn_store on x86_64.
And when I remove all dllimport, the call to the function mpn_addadd_n
also gives a segfault when executing t-addadd_n.exe.
Note that the test t-aors.exe does not segfault, and indeed it only uses
the mpn_add_1 and mpn_sub_1
Re: Request for Junctions be treated consistently
On Apr 5 04:13, Linda Walsh wrote: > Corinna Vinschen wrote: > >On Apr 1 09:39, Linda Walsh wrote: > >>If I mount a device using mount vol in 2 different places, will they > >>have different device numbers the same? > > > >The same, just as on Linux. > --- > Why special case junctions created with 'linkd' to return > as symlinks but not 'mountvol' if they both suffer from the same > possibilities of circular mounting? I.e. creating circular loops > is no reason for linux to force the 'bind' command to look like > a 'symlink', but the same conditions exist. I > [...] > - > >Sorry, but I really don't understand your question here. > > You said: > >If you create a directory junction to an existing dir and treat it as > >directory, the directory shows up twice under the same device number. > >Find or tar will enumerate (and archive) the dir twice. > --- > Under similar circumstances, it's not a problem on linux -- they > are the same device numbers but the above utilities don't loop > infinitely. I didn't talked about loops. > I don't think your original concern is as big a problem as you > think, as is indicated by the above setup on linux. > > I.e. is there some other reason to not treat "linkd" mounts > the same as "mountvol" mounts -- in a manner equivalent to linux's > 'bind' mounts? > > I.e. I don't see that that linkd which creates a junction-mount > point, should be treated as a symlink. It would provide valuable > benefit in cygwin terms in being able to setup directories at > multiple place like 'bind' does on linux, and be resistant to being > overwritten like symlinks. Look, directory reparse points are, by and large, symlinks to another, real directory entry. The directory has a primary path, which is its own path under which it has been created, and the reparse point is just a pointer to this directory. If that's not a symlink, what is? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpZ6maXWU9yj.pgp Description: PGP signature
Re: Possibly wrong address passed to callq asm instruction within MPIR test binaries
On Apr 7 09:14, Jean-Pierre Flori wrote:
> Le Mon, 07 Apr 2014 10:43:12 +0200, Corinna Vinschen a écrit :
> > On Apr 6 20:20, Jean-Pierre Flori wrote:
> >> Looking at the exes produced (.libs/t-neg.exe) gives with the dllimport
> >> magic:
> >>100401115: 48 89 c1mov%rax,%rcx 100401118:
> >>48 8b 05 f1 71 00 00mov0x71f1(%rip),%rax#
> >> 100408310 <__imp___gmpn_store>
> >>10040111f: ff d0 callq *%rax
> >> Without it:
> >>10040: 48 89 c1mov%rax,%rcx 100401114:
> >>e8 f7 71 00 00 callq 100408310
> >> <__imp___gmpn_store>
> >
> > This is ok. Look closely at the address after the callq. It's the
> > start address of the executable (0x1:0040) plus an offset. If you
> > disassemble the executable you will find a jmp statement at this
> > address. This is the trampoline code which is automatically generated
> > for external references if they are not marked with dllimport.
> >
> > The problem at this point is that I can't reproduce your issue with a
> > simple example. Here's the example:
> >
> > SNIP
> > $ cat > lib.c <
> >
> > int foo (int a)
> > {
> > printf ("a = %d\n", a);
> > return a;
> > }
> > EOF $ cat > app.c <
> >
> > extern int foo (int);
> >
> > int main ()
> > {
> > int x = foo (42); printf ("x = %d\n", x);
> > return 0;
> > }
> > EOF $ gcc -g -shared -o lib.dll lib.c $ gcc -g -o app app.c lib.dll $
> > ./app a = 42 x = 42 SNAP
> >
> > Let's have a look into the executable:
> >
> > $ objdump -d app.exe [...]
> > 0001004010d0 :
> >1004010d0: 55 push %rbp 1004010d1: 48 89
> >e5mov%rsp,%rbp 1004010d4: 48 83 ec 30
> > sub$0x30,%rsp 1004010d8: e8 93 00 00 00 callq
> >100401170 <__main>
> >1004010dd: b9 2a 00 00 00 mov$0x2a,%ecx 1004010e2:
> >e8 59 06 00 00 callq 100401740
> >1004010e7: 89 45 fcmov%eax,-0x4(%rbp)
> >[...]
> >
> > So the call to foo is a call to address 1:00401740. Let's have a look
> > what is at that address:
> >
> > 000100401740 :
> >100401740: ff 25 1a 5a 00 00 jmpq *0x5a1a(%rip)#
> >100407160 <__imp_foo>
> >
> > Address 100407160 is somewhere within the IAT which gets relocated at
> > runtime.
> For most functions I indeed see this trampoline trick within the binary.
> >
> > This is exactly as it's supposed to be.
> >
> > Now, here's the question: Where is your problem different? What
> > exactly makes your code fail? Can you construct your problem from my
> > simple testcase, or can you construct an equally simple testcase which
> > fails?
> Looking a little further, it seems the problematic functions are those
> directly assembled from assembly code.
> That was the case of mpn_store on x86_64.
Just for clarity: mpn_store is an assembler function calling an
external C function, right?
So IIUC, the assembler code in mpn_store contains a fixed callq, like
this:
callq foo
And this crashes when foo is in an external DLL. This is no wonder
at all. x86_64 does not have a callq opcode with 64 bit absolute
addressing. What you get in the example above is 32 bit PC-relative
addressing, so if foo is not part of the same binary, you're likely
to crash because the offset is just wrong.
AFAICS, what you have to do is to change your asse4mbler code to create
your own jump trampoline, or any other method which evaluates the
correct 64 bit address in a place which is accessible via callq:
movq __imp_foo, %rax
callq *%rax
[...]
__imp_foo:
.quad foo
or
callq __jmp_foo
[...]
__jmp_foo
jmp foo
HTH,
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
pgpaFrFjHYQPp.pgp
Description: PGP signature
Re: Possibly wrong address passed to callq asm instruction within MPIR test binaries
Le Mon, 07 Apr 2014 09:14:41 +, Jean-Pierre Flori a écrit : > Looking a little further, it seems the problematic functions are those > directly assembled from assembly code. > That was the case of mpn_store on x86_64. > > And when I remove all dllimport, the call to the function mpn_addadd_n > also gives a segfault when executing t-addadd_n.exe. > > Note that the test t-aors.exe does not segfault, and indeed it only uses > the mpn_add_1 and mpn_sub_1 functions which are not from assembly. > It seems the dll produced at least has different treatment for these tow kinds of functions. jp@napoleon-7 ~ $ nm local/bin/cygmpir-16.dll | grep store 0004ff238170 T __gmpn_store 0004ff238198 t __gmpn_store.1 0004ff2381a0 t __gmpn_store.2 0004ff2381b3 t __gmpn_store.3 0004ff2381bd t __gmpn_store.4 0004ff2381be t __gmpn_store.5 0004ff2381c3 t __gmpn_store.6 0004ff2381c9 t __gmpn_store.7 ... jp@napoleon-7 ~ $ nm local/bin/cygmpir-16.dll | grep addadd_n 0004ff208e10 T __gmpn_addadd_n 0004ff208e50 t __gmpn_addadd_n.1 0004ff208eac t __gmpn_addadd_n.2 0004ff208ebe t __gmpn_addadd_n.3 0004ff208f0f t __gmpn_addadd_n.4 0004ff208f54 t __gmpn_addadd_n.5 0004ff208f6e t __gmpn_addadd_n.6 jp@napoleon-7 ~ $ nm local/bin/cygmpir-16.dll | grep add_1 0004ff207d40 T __gmpn_add_1 And jp@napoleon-7 ~/mpir $ nm .libs/libmpir.dll.a | grep add_1 T __gmpn_add_1 I __imp___gmpn_add_1 jp@napoleon-7 ~/mpir $ nm .libs/libmpir.dll.a | grep addadd_n I __imp___gmpn_addadd_n I __nm___gmpn_addadd_n -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Possibly wrong address passed to callq asm instruction within MPIR test binaries
Le Mon, 07 Apr 2014 11:39:32 +0200, Corinna Vinschen a écrit :
> On Apr 7 09:14, Jean-Pierre Flori wrote:
>> Le Mon, 07 Apr 2014 10:43:12 +0200, Corinna Vinschen a écrit :
>> > On Apr 6 20:20, Jean-Pierre Flori wrote:
>> >> Looking at the exes produced (.libs/t-neg.exe) gives with the
>> >> dllimport magic:
>> >>100401115: 48 89 c1mov%rax,%rcx 100401118:
>> >>48 8b 05 f1 71 00 00mov0x71f1(%rip),%rax#
>> >> 100408310 <__imp___gmpn_store>
>> >>10040111f: ff d0 callq *%rax
>> >> Without it:
>> >>10040: 48 89 c1mov%rax,%rcx 100401114:
>> >>e8 f7 71 00 00 callq 100408310
>> >> <__imp___gmpn_store>
>> >
>> > This is ok. Look closely at the address after the callq. It's the
>> > start address of the executable (0x1:0040) plus an offset. If
>> > you disassemble the executable you will find a jmp statement at this
>> > address. This is the trampoline code which is automatically
>> > generated for external references if they are not marked with
>> > dllimport.
>> >
>> > The problem at this point is that I can't reproduce your issue with a
>> > simple example. Here's the example:
>> >
>> > SNIP
>> > $ cat > lib.c <
>> >
>> > int foo (int a)
>> > {
>> > printf ("a = %d\n", a);
>> > return a;
>> > }
>> > EOF $ cat > app.c <
>> >
>> > extern int foo (int);
>> >
>> > int main ()
>> > {
>> > int x = foo (42); printf ("x = %d\n", x);
>> > return 0;
>> > }
>> > EOF $ gcc -g -shared -o lib.dll lib.c $ gcc -g -o app app.c lib.dll $
>> > ./app a = 42 x = 42 SNAP
>> >
>> > Let's have a look into the executable:
>> >
>> > $ objdump -d app.exe [...]
>> > 0001004010d0 :
>> >1004010d0: 55 push %rbp 1004010d1: 48
>> >89 e5mov%rsp,%rbp 1004010d4: 48 83 ec 30
>> > sub$0x30,%rsp 1004010d8: e8 93 00 00 00 callq
>> >100401170 <__main>
>> >1004010dd: b9 2a 00 00 00 mov$0x2a,%ecx 1004010e2:
>> >e8 59 06 00 00 callq 100401740
>> >1004010e7: 89 45 fcmov%eax,-0x4(%rbp)
>> >[...]
>> >
>> > So the call to foo is a call to address 1:00401740. Let's have a
>> > look what is at that address:
>> >
>> > 000100401740 :
>> >100401740: ff 25 1a 5a 00 00 jmpq *0x5a1a(%rip)#
>> >100407160 <__imp_foo>
>> >
>> > Address 100407160 is somewhere within the IAT which gets relocated at
>> > runtime.
>> For most functions I indeed see this trampoline trick within the
>> binary.
>> >
>> > This is exactly as it's supposed to be.
>> >
>> > Now, here's the question: Where is your problem different? What
>> > exactly makes your code fail? Can you construct your problem from my
>> > simple testcase, or can you construct an equally simple testcase
>> > which fails?
>> Looking a little further, it seems the problematic functions are those
>> directly assembled from assembly code.
>> That was the case of mpn_store on x86_64.
>
> Just for clarity: mpn_store is an assembler function calling an
> external C function, right?
>
Nope, mpn_store is an assembler function indeed, but it's the call to
this function which fails (which a callq which indeed seems to call it
from the external library but that code was generated by gcc).
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Tons of cygserver errors
On Apr 5 02:35, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote: > >> I can’t push this through your list spam filter. Another attempt... > > I was trying a few times, and finally deleted the strace attachment. Let's > see if this will go through. > Excuse me for being a bit straightforward, but the spam filter this list is > using is *really* stupid! > > > Still, you're missing the cygcheck log, > > Cygcheck log was attached to an earlier message from today (thread: > exe.stackdump is always empty). > > > and a simple testcase would be helpful > > Here you go: > [...] > Windows event log immediately recorded 10 new events, like so: > > Error 4/4/2014 10:02:34 PMcygserver 0 None > Error 4/4/2014 10:02:33 PMcygserver 0 None > Error 4/4/2014 10:02:32 PMcygserver 0 None > Error 4/4/2014 10:02:31 PMcygserver 0 None > Error 4/4/2014 10:02:30 PMcygserver 0 None > Error 4/4/2014 10:02:29 PMcygserver 0 None > Error 4/4/2014 10:02:28 PMcygserver 0 None > Error 4/4/2014 10:02:27 PMcygserver 0 None > Error 4/4/2014 10:02:26 PMcygserver 0 None > Error 4/4/2014 10:02:25 PMcygserver 0 None > > (each having exactly the same message: cygserver: PID 1944: cygserver: error > getting signal_arrived to server (6)) Thanks, I can reproduce the issue. I'll investigate. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpIHGQs9TrPi.pgp Description: PGP signature
Re: Possibly wrong address passed to callq asm instruction within MPIR test binaries
Le Mon, 07 Apr 2014 09:49:27 +, Jean-Pierre Flori a écrit : > Le Mon, 07 Apr 2014 09:14:41 +, Jean-Pierre Flori a écrit : >> Looking a little further, it seems the problematic functions are those >> directly assembled from assembly code. >> That was the case of mpn_store on x86_64. >> >> And when I remove all dllimport, the call to the function mpn_addadd_n >> also gives a segfault when executing t-addadd_n.exe. >> >> Note that the test t-aors.exe does not segfault, and indeed it only >> uses the mpn_add_1 and mpn_sub_1 functions which are not from assembly. >> > It seems the dll produced at least has different treatment for these tow > kinds of functions. > > jp@napoleon-7 ~ > $ nm local/bin/cygmpir-16.dll | grep store 0004ff238170 T > __gmpn_store 0004ff238198 t __gmpn_store.1 0004ff2381a0 t > __gmpn_store.2 0004ff2381b3 t __gmpn_store.3 0004ff2381bd t > __gmpn_store.4 0004ff2381be t __gmpn_store.5 0004ff2381c3 t > __gmpn_store.6 0004ff2381c9 t __gmpn_store.7 ... > > jp@napoleon-7 ~ > $ nm local/bin/cygmpir-16.dll | grep addadd_n 0004ff208e10 T > __gmpn_addadd_n 0004ff208e50 t __gmpn_addadd_n.1 0004ff208eac t > __gmpn_addadd_n.2 0004ff208ebe t __gmpn_addadd_n.3 0004ff208f0f > t __gmpn_addadd_n.4 0004ff208f54 t __gmpn_addadd_n.5 > 0004ff208f6e t __gmpn_addadd_n.6 > > jp@napoleon-7 ~ > $ nm local/bin/cygmpir-16.dll | grep add_1 0004ff207d40 T > __gmpn_add_1 > > And > > jp@napoleon-7 ~/mpir $ nm .libs/libmpir.dll.a | grep add_1 > T __gmpn_add_1 I __imp___gmpn_add_1 > > jp@napoleon-7 ~/mpir $ nm .libs/libmpir.dll.a | grep addadd_n > I __imp___gmpn_addadd_n I > __nm___gmpn_addadd_n Note in particular the __nm_ prefix. It is as advertiserd here: http://www.cygwin.com/ml/cygwin/2002-01/ msg00236.html But when looking at the Cygwin32 produced import lib, I don't see any nm prefix. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Possibly wrong address passed to callq asm instruction within MPIR test binaries
Le Mon, 07 Apr 2014 10:42:13 +, Jean-Pierre Flori a écrit : > Le Mon, 07 Apr 2014 09:49:27 +, Jean-Pierre Flori a écrit : > >> Le Mon, 07 Apr 2014 09:14:41 +, Jean-Pierre Flori a écrit : >>> Looking a little further, it seems the problematic functions are those >>> directly assembled from assembly code. >>> That was the case of mpn_store on x86_64. >>> >>> And when I remove all dllimport, the call to the function mpn_addadd_n >>> also gives a segfault when executing t-addadd_n.exe. >>> >>> Note that the test t-aors.exe does not segfault, and indeed it only >>> uses the mpn_add_1 and mpn_sub_1 functions which are not from >>> assembly. >>> >> It seems the dll produced at least has different treatment for these >> tow kinds of functions. >> >> jp@napoleon-7 ~ >> $ nm local/bin/cygmpir-16.dll | grep store 0004ff238170 T >> __gmpn_store 0004ff238198 t __gmpn_store.1 0004ff2381a0 t >> __gmpn_store.2 0004ff2381b3 t __gmpn_store.3 0004ff2381bd t >> __gmpn_store.4 0004ff2381be t __gmpn_store.5 0004ff2381c3 t >> __gmpn_store.6 0004ff2381c9 t __gmpn_store.7 ... >> >> jp@napoleon-7 ~ >> $ nm local/bin/cygmpir-16.dll | grep addadd_n 0004ff208e10 T >> __gmpn_addadd_n 0004ff208e50 t __gmpn_addadd_n.1 0004ff208eac t >> __gmpn_addadd_n.2 0004ff208ebe t __gmpn_addadd_n.3 0004ff208f0f >> t __gmpn_addadd_n.4 0004ff208f54 t __gmpn_addadd_n.5 >> 0004ff208f6e t __gmpn_addadd_n.6 >> >> jp@napoleon-7 ~ >> $ nm local/bin/cygmpir-16.dll | grep add_1 0004ff207d40 T >> __gmpn_add_1 >> >> And >> >> jp@napoleon-7 ~/mpir $ nm .libs/libmpir.dll.a | grep add_1 >> T __gmpn_add_1 I __imp___gmpn_add_1 >> >> jp@napoleon-7 ~/mpir $ nm .libs/libmpir.dll.a | grep addadd_n >> I __imp___gmpn_addadd_n I >> __nm___gmpn_addadd_n > > Note in particular the __nm_ prefix. > It is as advertiserd here: http://www.cygwin.com/ml/cygwin/2002-01/ > msg00236.html But when looking at the Cygwin32 produced import lib, I > don't see any nm prefix. In fact, I see some... but for much fewer functions, strange. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Trouble with running cygwin dll on Vortex86MX+ CPU
Corinna Vinschen cygwin.com> writes: > > On Apr 4 09:44, Colin wrote: > > Corinna Vinschen cygwin.com> writes: > > > > Alternatively, even though I hate to point people to older versions > of Cygwin, you could try the old Cygwin 1.5.25. I'm not quite sure, > but I think it was compiled for i586 or even i386. It's not as > feature-rich as Cygwin 1.7 but it worked, and maybe the set of > POSIX functions is sufficient for you. See the Cygwin time machine > at http://www.fruitbat.org/Cygwin/index.html#cygwincirca > > If you want to go even further back in time, then MSYS may be the > right thing for you. It's a rip-off of Cygwin 1.3.22 with a few > patches to supposedly building native executables a bit better. > Just make sure to grab the old MSYS, not the more recent MSYS2. > See http://www.mingw.org/wiki/MSYS > > HTH, > Corinna > Cygwin 1.5.25 seems like a good option. So I downloaded setup-legacy.exe from fruitbat and ran it on an XP machine which has not previously seen Cygwin. Initially I installed just the base Cygwin files. The process ran as expected, and installed 4,263 files in 472 folders. However the bash shell appears non-functional as far as external commands go. It presents a prompt bash-3.2$, if I type something like ls, it responds command not found. Any ideas? Colin -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Trouble with running cygwin dll on Vortex86MX+ CPU
On Apr 7 11:08, Colin wrote: > Corinna Vinschen cygwin.com> writes: > > > > > On Apr 4 09:44, Colin wrote: > > > Corinna Vinschen cygwin.com> writes: > > > > > > > Alternatively, even though I hate to point people to older versions > > of Cygwin, you could try the old Cygwin 1.5.25. I'm not quite sure, > > but I think it was compiled for i586 or even i386. It's not as > > feature-rich as Cygwin 1.7 but it worked, and maybe the set of > > POSIX functions is sufficient for you. See the Cygwin time machine > > at http://www.fruitbat.org/Cygwin/index.html#cygwincirca > > > > If you want to go even further back in time, then MSYS may be the > > right thing for you. It's a rip-off of Cygwin 1.3.22 with a few > > patches to supposedly building native executables a bit better. > > Just make sure to grab the old MSYS, not the more recent MSYS2. > > See http://www.mingw.org/wiki/MSYS > > > > HTH, > > Corinna > > > > Cygwin 1.5.25 seems like a good option. So I downloaded setup-legacy.exe > from fruitbat and ran it on an XP machine which has not previously seen > Cygwin. Initially I installed just the base Cygwin files. The process ran > as expected, and installed 4,263 files in 472 folders. > > However the bash shell appears non-functional as far as external commands > go. It presents a prompt bash-3.2$, if I type something like ls, it > responds command not found. Any ideas? $PATH? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpMeQqRykqn8.pgp Description: PGP signature
Re: Possibly wrong address passed to callq asm instruction within MPIR test binaries
Le Mon, 07 Apr 2014 10:43:30 +, Jean-Pierre Flori a écrit : >> >> Note in particular the __nm_ prefix. >> It is as advertiserd here: http://www.cygwin.com/ml/cygwin/2002-01/ >> msg00236.html But when looking at the Cygwin32 produced import lib, I >> don't see any nm prefix. > > In fact, I see some... but for much fewer functions, strange. I have troubles understanding when this _nm_ prefix actually gets added, any help welcome :) Is there any dark magic related to inlining? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Possibly wrong address passed to callq asm instruction within MPIR test binaries
On Apr 7 11:26, Jean-Pierre Flori wrote: > Le Mon, 07 Apr 2014 10:43:30 +, Jean-Pierre Flori a écrit : > >> > >> Note in particular the __nm_ prefix. > >> It is as advertiserd here: http://www.cygwin.com/ml/cygwin/2002-01/ > >> msg00236.html But when looking at the Cygwin32 produced import lib, I > >> don't see any nm prefix. > > > > In fact, I see some... but for much fewer functions, strange. > > I have troubles understanding when this _nm_ prefix actually gets added, > any help welcome :) > Is there any dark magic related to inlining? I'm sorry, but I don't know how this works exactly. The nm prefix is only added for external references, not for inlined functions, but I don't know the gory details. You may be better off to ask on the gcc mailing list. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpwGLXEvdhGC.pgp Description: PGP signature
Re: [ANNOUNCEMENT] Updated: mingw64-*-binutils-2.24.0.1.acd6540-1 (x86/x86_64)
m0viefreak wrote: I fixed it for now by placing an empty dummy default-manifest.o file in working directory. May you describe how you have crated it or attach here your empty file? I tried in different ways but always fail in building with: "...default-manifest.o: file not recognized: File format not recognized" Thanks, Angelo. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Tons of cygserver errors
On Apr 7 11:57, Corinna Vinschen wrote: > On Apr 5 02:35, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote: > > >> I can’t push this through your list spam filter. Another attempt... > > > > I was trying a few times, and finally deleted the strace attachment. Let's > > see if this will go through. > > Excuse me for being a bit straightforward, but the spam filter this list is > > using is *really* stupid! > > > > > Still, you're missing the cygcheck log, > > > > Cygcheck log was attached to an earlier message from today (thread: > > exe.stackdump is always empty). > > > > > and a simple testcase would be helpful > > > > Here you go: > > [...] > > Windows event log immediately recorded 10 new events, like so: > > > > Error 4/4/2014 10:02:34 PMcygserver 0 None > > Error 4/4/2014 10:02:33 PMcygserver 0 None > > Error 4/4/2014 10:02:32 PMcygserver 0 None > > Error 4/4/2014 10:02:31 PMcygserver 0 None > > Error 4/4/2014 10:02:30 PMcygserver 0 None > > Error 4/4/2014 10:02:29 PMcygserver 0 None > > Error 4/4/2014 10:02:28 PMcygserver 0 None > > Error 4/4/2014 10:02:27 PMcygserver 0 None > > Error 4/4/2014 10:02:26 PMcygserver 0 None > > Error 4/4/2014 10:02:25 PMcygserver 0 None > > > > (each having exactly the same message: cygserver: PID 1944: cygserver: > > error getting signal_arrived to server (6)) > > Thanks, I can reproduce the issue. I'll investigate. Ok, I see what happens. At fork time, cygserver gets called to fixup the information on XSI shared memory regions. When this fixup call is made, the handle value sent to cygserver is invalid. It's, in fact, the value of this object in the parent process, while the object doesn't exist at this point in the forked child. The child value is set to NULL just a little bit later and created as soon as it's required, but this happens too late for the aforementioned fixup call. I created a fix and I'm just building cygwin 1.7.29 with it. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpWxFVD82nBR.pgp Description: PGP signature
Re: Possibly wrong address passed to callq asm instruction within MPIR test binaries
Le Mon, 07 Apr 2014 13:30:27 +0200, Corinna Vinschen a écrit : > > I'm sorry, but I don't know how this works exactly. The nm prefix is > only added for external references, not for inlined functions, but I > don't know the gory details. You may be better off to ask on the gcc > mailing list. > No problem, I've already learned tons of stuff thanks to your help. I've just posted on gcc-help. http://gcc.gnu.org/ml/gcc-help/2014-04/msg00024.html -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Possibly wrong address passed to callq asm instruction within MPIR test binaries
On Apr 7 11:50, Jean-Pierre Flori wrote: > Le Mon, 07 Apr 2014 13:30:27 +0200, Corinna Vinschen a écrit : > > > > I'm sorry, but I don't know how this works exactly. The nm prefix is > > only added for external references, not for inlined functions, but I > > don't know the gory details. You may be better off to ask on the gcc > > mailing list. > > > No problem, I've already learned tons of stuff thanks to your help. > I've just posted on gcc-help. > http://gcc.gnu.org/ml/gcc-help/2014-04/msg00024.html Thanks. A simple testcase would still be nice, of course. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpn9ZM5HHJIW.pgp Description: PGP signature
[ANNOUNCEMENT] Updated: Cygwin 1.7.29-2
Hi Cygwin friends and users, I just released Cygwin 1.7.29-2. This is a bugfix release. What's new: --- - Allow quoting of arguments to the CYGWIN environment variable, i.e., set CYGWIN=error_start="c:\bin\someprogram -T" Bug Fixes - - Try harder to do the right thing in the presence of console screen buffers, i.e., never clear the screen buffer unless the user asked for it. Also fix screen escape sequences which attempted to scroll the screen. Addresses: http://cygwin.com/ml/cygwin/2014-02/threads.html#00274 - Make "ps -W" report different WINPIDs for processes that have been execed from, e.g., cmd. Addresses: http://cygwin.com/ml/cygwin/2014-02/threads.html#00382 - Avoid error messages from the signal handler if we're exiting. Addresses: A random irc #cygwin complaint. - Fix return value from getgrouplist function to behave like glibc. - Fix initialization of open_memstream which could lead to dropping the entire string. Addresses: http://cygwin.com/ml/cygwin/2014-03/threads.html#00413 - Fix problem where ending chunk of audio was missing when accessing /dev/dsp. Addresses: http://cygwin.com/ml/cygwin/2014-03/threads.html#00117 - Fix exception handling on x86_64. Addresses: http://cygwin.com/ml/cygwin/2014-03/threads.html#00026 - Fix reading extended attributes from files on remote shares. Addresses: A personally encountered spurious error message: mv: listing attributes of `//server/share/file': Invalid argument - Fix sending an invalid pointer to cygserver during fork. Addresses: http://cygwin.com/ml/cygwin/2014-04/msg1.html To install 32-bit Cygwin use http://cygwin.com/setup-x86.exe To install 64 bit Cygwin use http://cygwin.com/setup-x86_64.exe The 64 bit Cygwin distribution doesn't yet come with as many packages as the 32 bit version, but more packages will be available over time. If you're already running a 32 bit version of Cygwin on 64 bit Windows machines, you can continue to do so. If you're planning a new install of Cygwin on a 64 bit Windows machine, consider to use the new 64 bit Cygwin version, unless you need certain packages not yet available in the 64 bit release. Have fun, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Possibly wrong address passed to callq asm instruction within MPIR test binaries
Le Mon, 07 Apr 2014 13:57:30 +0200, Corinna Vinschen a écrit : > On Apr 7 11:50, Jean-Pierre Flori wrote: >> Le Mon, 07 Apr 2014 13:30:27 +0200, Corinna Vinschen a écrit : >> > >> > I'm sorry, but I don't know how this works exactly. The nm prefix is >> > only added for external references, not for inlined functions, but I >> > don't know the gory details. You may be better off to ask on the gcc >> > mailing list. >> > >> No problem, I've already learned tons of stuff thanks to your help. >> I've just posted on gcc-help. >> http://gcc.gnu.org/ml/gcc-help/2014-04/msg00024.html > > Thanks. A simple testcase would still be nice, of course. > > Sure, but it seems the issue is that I cannot get the __nm_ prefix when I elaborate on a minimal problem like you did. I'll still try to get something this afternoon. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Possibly wrong address passed to callq asm instruction within MPIR test binaries
Le Mon, 07 Apr 2014 13:28:19 +, Jean-Pierre Flori a écrit :
> Le Mon, 07 Apr 2014 13:57:30 +0200, Corinna Vinschen a écrit :
>
>> On Apr 7 11:50, Jean-Pierre Flori wrote:
>>> Le Mon, 07 Apr 2014 13:30:27 +0200, Corinna Vinschen a écrit :
>>> >
>>> > I'm sorry, but I don't know how this works exactly. The nm prefix
>>> > is only added for external references, not for inlined functions,
>>> > but I don't know the gory details. You may be better off to ask on
>>> > the gcc mailing list.
>>> >
>>> No problem, I've already learned tons of stuff thanks to your help.
>>> I've just posted on gcc-help.
>>> http://gcc.gnu.org/ml/gcc-help/2014-04/msg00024.html
>>
>> Thanks. A simple testcase would still be nice, of course.
>>
>>
> Sure, but it seems the issue is that I cannot get the __nm_ prefix when
> I elaborate on a minimal problem like you did.
>
> I'll still try to get something this afternoon.
I think I got something:
$ cat > lib.c <
int
foo (int a)
{
printf ("a = %d\n", a);
return a;
}
EOF
$cat > asm.as < app.c <
extern int foo (int);
int
main ()
{
int x = foo (42);
printf ("x = %d\n", x);
nothing();
return 0;
}
EOF
$ gcc -g -c lib.c -o lib.o
$ yasm -fx64 asm.as -o asm.o
$ gcc -shared lib.o ams.o -Wl,--out-implib=lib.dll.a -Wl,--export-all-
symbols -o lib.dll
$ gcc -g -o app app.c -L. -llib
$ ./app
...
Without the export directive (commented above) I get __nm_ prefix and
wrong callq instruction.
With it, the __nm_prefix disappears and the trampoline correctly used.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: long_int vs int byte sizes
On 04/07/2014 02:47 AM, Corinna Vinschen wrote: > > There's no standard which restricts the sizes of the datatypes in > that way. There's only this rule to follow: > > sizeof (char) <= sizeof (short) <= sizeof (int) <= sizeof (long) Well, there IS the C rule that sizeof(char)==1, and also that char holds >= 8 bits, short holds >= 8 bits, int holds >= 16 bits, long holds >= 32 bits. There is also a POSIX rule that CHAR_BITS==8 (so while C allows a 9-bit or 32-bit char [and yes, such machines exist, although rare], POSIX does not allow that). But in general, on most modern porting platforms, 'long' is a redundant type - it will either be equal in size to 'int' (typical for a 32-bit machine) or to a 'long long' (typical for a 64-bit machine); it only mattered on 16-bit machines which are now museum pieces. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
RE: exe.stackdump is always empty
> Hmm, not me. In my case a stackdump is generated... There seems to be an access denied condition "C05" along the lines of the strace output that I've sent. What could have caused that? Can that be a reason for me not getting the core dump at all? Thanks, Anton Lavrentiev Contractor NIH/NLM/NCBI
RE: Tons of cygserver errors
> I created a fix and I'm just building cygwin 1.7.29 with it. That's a good news, and thanks for the quick fix! I'll let you know if the issue is resolved on my end, too. Anton Lavrentiev Contractor NIH/NLM/NCBI
Re: long_int vs int byte sizes
On Apr 7 08:16, Eric Blake wrote: > On 04/07/2014 02:47 AM, Corinna Vinschen wrote: > > > > > There's no standard which restricts the sizes of the datatypes in > > that way. There's only this rule to follow: > > > > sizeof (char) <= sizeof (short) <= sizeof (int) <= sizeof (long) > > Well, there IS the C rule that sizeof(char)==1, and also that char holds > >= 8 bits, short holds >= 8 bits, int holds >= 16 bits, long holds >= 32 > bits. There is also a POSIX rule that CHAR_BITS==8 (so while C allows a > 9-bit or 32-bit char [and yes, such machines exist, although rare], > POSIX does not allow that). Apart from POSIX, where is that defined? The old K&R rules only defined the sizes of the datatypes in comparison to each other, but it never defined minimum sizes. If you have a 7 bit machine and you only use ASCII, you can be happy ever after. And while it *suggested* that short < long, it didn't demand it. > POSIX does not allow that). But in general, on most modern porting > platforms, 'long' is a redundant type - it will either be equal in size > to 'int' (typical for a 32-bit machine) or to a 'long long' (typical for > a 64-bit machine); it only mattered on 16-bit machines which are now > museum pieces. Xstormy16? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpmtXfV4K0C_.pgp Description: PGP signature
Re: Possibly wrong address passed to callq asm instruction within MPIR test binaries
On Apr 7 14:02, Jean-Pierre Flori wrote:
> Le Mon, 07 Apr 2014 13:28:19 +, Jean-Pierre Flori a écrit :
>
> > Le Mon, 07 Apr 2014 13:57:30 +0200, Corinna Vinschen a écrit :
> >
> >> On Apr 7 11:50, Jean-Pierre Flori wrote:
> >>> Le Mon, 07 Apr 2014 13:30:27 +0200, Corinna Vinschen a écrit :
> >>> >
> >>> > I'm sorry, but I don't know how this works exactly. The nm prefix
> >>> > is only added for external references, not for inlined functions,
> >>> > but I don't know the gory details. You may be better off to ask on
> >>> > the gcc mailing list.
> >>> >
> >>> No problem, I've already learned tons of stuff thanks to your help.
> >>> I've just posted on gcc-help.
> >>> http://gcc.gnu.org/ml/gcc-help/2014-04/msg00024.html
> >>
> >> Thanks. A simple testcase would still be nice, of course.
> >>
> >>
> > Sure, but it seems the issue is that I cannot get the __nm_ prefix when
> > I elaborate on a minimal problem like you did.
> >
> > I'll still try to get something this afternoon.
> I think I got something:
> $ cat > lib.c < #include
>
> int
> foo (int a)
> {
> printf ("a = %d\n", a);
> return a;
> }
> EOF
> $cat > asm.as < global nothing
> ;export nothing
> nothing:
> ret
> end
> EOF
> $ cat > app.c < #include
>
> extern int foo (int);
>
> int
> main ()
> {
> int x = foo (42);
> printf ("x = %d\n", x);
> nothing();
> return 0;
> }
> EOF
> $ gcc -g -c lib.c -o lib.o
> $ yasm -fx64 asm.as -o asm.o
> $ gcc -shared lib.o ams.o -Wl,--out-implib=lib.dll.a -Wl,--export-all-
> symbols -o lib.dll
> $ gcc -g -o app app.c -L. -llib
> $ ./app
> ...
>
>
> Without the export directive (commented above) I get __nm_ prefix and
> wrong callq instruction.
> With it, the __nm_prefix disappears and the trampoline correctly used.
I think you must define the export (gas: .def) pseudo op when creating
your own assembler code exporting a symbol from a DLL. If you look
into the code created by gcc from lib.c:
$ gcc -S lib.c
$ cat lib.s
.file "lib.c"
.section .rdata,"dr"
.LC0:
.ascii "a = %d\12\0"
.text
.globl foo
.deffoo;.scl2; .type 32; .endef
.seh_proc foo
foo:
pushq %rbp
.seh_pushreg%rbp
movq%rsp, %rbp
.seh_setframe %rbp, 0
subq$32, %rsp
.seh_stackalloc 32
.seh_endprologue
movl%ecx, 16(%rbp)
movl16(%rbp), %edx
leaq.LC0(%rip), %rcx
callprintf
movl16(%rbp), %eax
addq$32, %rsp
popq%rbp
ret
.seh_endproc
.ident "GCC: (GNU) 4.8.2"
.defprintf; .scl2; .type 32; .endef
At this point gcc doesn't know that foo will get exported from a DLL,
but it generates the .def directive nevertheless. If I create the
same code in gas:
.text
.globl nothing
.def nothing; .scl 2; .type 32; .endef
nothing:
ret
then it works, but crashes if I omit the .def directive. So it seems
to me you don't have to export the symbol using the dllimport/dllexport
directives, but you have to specify the symbol explicitely for export.
Corinna
pgpWzfPq0Vkog.pgp
Description: PGP signature
Re: Possibly wrong address passed to callq asm instruction within MPIR test binaries
Le Mon, 07 Apr 2014 16:36:18 +0200, Corinna Vinschen a écrit :
> On Apr 7 14:02, Jean-Pierre Flori wrote:
>> Le Mon, 07 Apr 2014 13:28:19 +, Jean-Pierre Flori a écrit :
>>
>> > Le Mon, 07 Apr 2014 13:57:30 +0200, Corinna Vinschen a écrit :
>> >
>> >> On Apr 7 11:50, Jean-Pierre Flori wrote:
>> >>> Le Mon, 07 Apr 2014 13:30:27 +0200, Corinna Vinschen a écrit :
>> >>> >
>> >>> > I'm sorry, but I don't know how this works exactly. The nm
>> >>> > prefix is only added for external references, not for inlined
>> >>> > functions, but I don't know the gory details. You may be better
>> >>> > off to ask on the gcc mailing list.
>> >>> >
>> >>> No problem, I've already learned tons of stuff thanks to your help.
>> >>> I've just posted on gcc-help.
>> >>> http://gcc.gnu.org/ml/gcc-help/2014-04/msg00024.html
>> >>
>> >> Thanks. A simple testcase would still be nice, of course.
>> >>
>> >>
>> > Sure, but it seems the issue is that I cannot get the __nm_ prefix
>> > when I elaborate on a minimal problem like you did.
>> >
>> > I'll still try to get something this afternoon.
>> I think I got something:
>> $ cat > lib.c <
>>
>> int foo (int a)
>> {
>> printf ("a = %d\n", a);
>> return a;
>> }
>> EOF $cat > asm.as <> ret end
>> EOF $ cat > app.c <
>>
>> extern int foo (int);
>>
>> int main ()
>> {
>> int x = foo (42); printf ("x = %d\n", x);
>> nothing();
>> return 0;
>> }
>> EOF $ gcc -g -c lib.c -o lib.o $ yasm -fx64 asm.as -o asm.o $ gcc
>> -shared lib.o ams.o -Wl,--out-implib=lib.dll.a -Wl,--export-all-
>> symbols -o lib.dll $ gcc -g -o app app.c -L. -llib $ ./app ...
>>
>>
>> Without the export directive (commented above) I get __nm_ prefix and
>> wrong callq instruction.
>> With it, the __nm_prefix disappears and the trampoline correctly used.
>
> I think you must define the export (gas: .def) pseudo op when creating
> your own assembler code exporting a symbol from a DLL. If you look into
> the code created by gcc from lib.c:
>
> $ gcc -S lib.c $ cat lib.s
> .file "lib.c"
> .section .rdata,"dr"
> .LC0:
> .ascii "a = %d\12\0"
> .text .globl foo .deffoo;.scl2; .type 32;
> .endef .seh_proc foo
> foo:
> pushq %rbp .seh_pushreg%rbp movq%rsp, %rbp
> .seh_setframe %rbp, 0 subq$32, %rsp .seh_stackalloc 32
> .seh_endprologue movl%ecx, 16(%rbp)
> movl16(%rbp), %edx leaq.LC0(%rip), %rcx callprintf
> movl16(%rbp), %eax addq$32, %rsp popq%rbp ret
> .seh_endproc .ident "GCC: (GNU) 4.8.2"
> .defprintf; .scl2; .type 32; .endef
>
> At this point gcc doesn't know that foo will get exported from a DLL,
> but it generates the .def directive nevertheless. If I create the same
> code in gas:
>
> .text .globl nothing .def nothing; .scl 2; .type 32; .endef
> nothing:
> ret
>
> then it works, but crashes if I omit the .def directive. So it seems to
> me you don't have to export the symbol using the dllimport/dllexport
> directives, but you have to specify the symbol explicitely for export.
>
Exactly!
I came to the same conclusion.
On top of that, it seems that including the export stuff does not hurt
when building and linking a static lib.
What's strange is that when we use the dllimport magic then it works even
though the symbol was not explicitely exported.
Thanks for the support.
JP
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: exe.stackdump is always empty
On Apr 7 14:21, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote: > > Hmm, not me. In my case a stackdump is generated... > > There seems to be an access denied condition "C05" along the lines of the > strace output that I've sent. > What could have caused that? Can that be a reason for me not getting the > core dump at all? I have not the faintest idea why this happens for you. It doesn't occur on my machine. I just noticed from your cygcheck output that you're running an old 1.7.26 DLL. Does it still occur after update? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpCF7plSZ9Wa.pgp Description: PGP signature
RE: exe.stackdump is always empty
> Does it still occur after update? Haven't tried it yet; is the new snapshot out already? -- can't see it on the website... Anton Lavrentiev Contractor NIH/NLM/NCBI
Re: long_int vs int byte sizes
On 04/07/2014 08:42 AM, Corinna Vinschen wrote: > On Apr 7 08:16, Eric Blake wrote: >> On 04/07/2014 02:47 AM, Corinna Vinschen wrote: >> >>> >>> There's no standard which restricts the sizes of the datatypes in >>> that way. There's only this rule to follow: >>> >>> sizeof (char) <= sizeof (short) <= sizeof (int) <= sizeof (long) >> >> Well, there IS the C rule that sizeof(char)==1, and also that char holds >>> = 8 bits, short holds >= 8 bits, int holds >= 16 bits, long holds >= 32 >> bits. There is also a POSIX rule that CHAR_BITS==8 (so while C allows a >> 9-bit or 32-bit char [and yes, such machines exist, although rare], >> POSIX does not allow that). > > Apart from POSIX, where is that defined? C99 5.2.4.2.1 Sizes of integer types requires CHAR_BIT to be 8 or larger, UCHAR_MAX to be 255 or larger, USHRT_MAX to be 65535 or larger (oh, so I was wrong above; 8-bit short is not allowed), UINT_MAX to be 65535 or larger, ULONG_MAX to be 4294967295 or larger, and ULLONG_MAX to be 18446744073709551615 or larger. POSIX then requires CHAR_BIT to be exactly 8. > The old K&R rules only defined > the sizes of the datatypes in comparison to each other, but it never > defined minimum sizes. If you have a 7 bit machine and you only use > ASCII, you can be happy ever after. And while it *suggested* that short > < long, it didn't demand it. K&R C probably did allow for 7-bit char. I'm not sure off-hand what C89 required, but C99 definitely prohibits a 7-bit char type. However, you ARE correct that C99 allows sizeof(short)==sizeof(long)==1 for platforms with 32-bit char. Again, all that C requires is a <= relationship between each progressively higher rank type, so the only thing we can't have is sizeof(short)>sizeof(long). > >> POSIX does not allow that). But in general, on most modern porting >> platforms, 'long' is a redundant type - it will either be equal in size >> to 'int' (typical for a 32-bit machine) or to a 'long long' (typical for >> a 64-bit machine); it only mattered on 16-bit machines which are now >> museum pieces. > > Xstormy16? Okay, so maybe 16-bit machines aren't all museum pieces - but they also aren't portability targets for the majority of programs run on cygwin :) -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: Possibly wrong address passed to callq asm instruction within MPIR test binaries
On Apr 7 14:47, Jean-Pierre Flori wrote: > Le Mon, 07 Apr 2014 16:36:18 +0200, Corinna Vinschen a écrit : > > At this point gcc doesn't know that foo will get exported from a DLL, > > but it generates the .def directive nevertheless. If I create the same > > code in gas: > > > > .text .globl nothing .def nothing; .scl 2; .type 32; .endef > > nothing: > > ret > > > > then it works, but crashes if I omit the .def directive. So it seems to > > me you don't have to export the symbol using the dllimport/dllexport > > directives, but you have to specify the symbol explicitely for export. > > > Exactly! > I came to the same conclusion. > On top of that, it seems that including the export stuff does not hurt > when building and linking a static lib. > > What's strange is that when we use the dllimport magic then it works even > though the symbol was not explicitely exported. Perhaps not. With dllimport, the calling code expects having to import a symbol from the DLL, so it generates an IAT entry and everything works as expected. Along these lines, at least. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpvm2WhOq_tV.pgp Description: PGP signature
Re: exe.stackdump is always empty
On Apr 7 15:03, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote: > > Does it still occur after update? > > Haven't tried it yet; is the new snapshot out already? -- can't see it on > the website... http://cygwin.com/ml/cygwin-announce/2014-04/msg5.html Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpMl06uAIM5y.pgp Description: PGP signature
Re: long_int vs int byte sizes
On Apr 7 09:39, Eric Blake wrote: > On 04/07/2014 08:42 AM, Corinna Vinschen wrote: > > On Apr 7 08:16, Eric Blake wrote: > >> On 04/07/2014 02:47 AM, Corinna Vinschen wrote: > >> > >>> > >>> There's no standard which restricts the sizes of the datatypes in > >>> that way. There's only this rule to follow: > >>> > >>> sizeof (char) <= sizeof (short) <= sizeof (int) <= sizeof (long) > >> > >> Well, there IS the C rule that sizeof(char)==1, and also that char holds > >>> = 8 bits, short holds >= 8 bits, int holds >= 16 bits, long holds >= 32 > >> bits. There is also a POSIX rule that CHAR_BITS==8 (so while C allows a > >> 9-bit or 32-bit char [and yes, such machines exist, although rare], > >> POSIX does not allow that). > > > > Apart from POSIX, where is that defined? > > C99 5.2.4.2.1 Sizes of integer types > > requires CHAR_BIT to be 8 or larger, UCHAR_MAX to be 255 or larger, > USHRT_MAX to be 65535 or larger (oh, so I was wrong above; 8-bit short > is not allowed), UINT_MAX to be 65535 or larger, ULONG_MAX to be > 4294967295 or larger, and ULLONG_MAX to be 18446744073709551615 or larger. C99 actually requires that? Wow. Modern times... > > Xstormy16? > > Okay, so maybe 16-bit machines aren't all museum pieces - but they also > aren't portability targets for the majority of programs run on cygwin :) Probably not, but I don't know a Cygwin application to control a washing machine either :) Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp7kLSZCVf5z.pgp Description: PGP signature
Re: Trouble with running cygwin dll on Vortex86MX+ CPU
On 4/7/2014 7:23 AM, Corinna Vinschen wrote: On Apr 7 11:08, Colin wrote: Corinna Vinschen cygwin.com> writes: On Apr 4 09:44, Colin wrote: Corinna Vinschen cygwin.com> writes: Alternatively, even though I hate to point people to older versions of Cygwin, you could try the old Cygwin 1.5.25. I'm not quite sure, but I think it was compiled for i586 or even i386. It's not as feature-rich as Cygwin 1.7 but it worked, and maybe the set of POSIX functions is sufficient for you. See the Cygwin time machine at http://www.fruitbat.org/Cygwin/index.html#cygwincirca If you want to go even further back in time, then MSYS may be the right thing for you. It's a rip-off of Cygwin 1.3.22 with a few patches to supposedly building native executables a bit better. Just make sure to grab the old MSYS, not the more recent MSYS2. See http://www.mingw.org/wiki/MSYS HTH, Corinna Cygwin 1.5.25 seems like a good option. So I downloaded setup-legacy.exe from fruitbat and ran it on an XP machine which has not previously seen Cygwin. Initially I installed just the base Cygwin files. The process ran as expected, and installed 4,263 files in 472 folders. However the bash shell appears non-functional as far as external commands go. It presents a prompt bash-3.2$, if I type something like ls, it responds command not found. Any ideas? $PATH? Indeed. And if your path under bash doesn't include /usr/bin, then I'll wager your postinstall scripts didn't run or at least completely/correctly. See /etc/postinstall for the scripts. If you aren't able to figure out what didn't run properly, you can either try rerunning everything manually and looking for faults (if any) or just rerun setup.exe and hope that it has better luck with the scripts the second time around. -- Larry _ A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting annoying in email? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin 1.7.25-1.7.28 - the perl process couldn't wake up after system call
On 4/7/2014 8:03 AM, Eduard wrote: Hi, We run Cygwin 1.7.25-1.7.28 on Win7-64bit. perl version is v5.14.2. Sometimes during system call from perl we see the following error: 0 [sig] perl 9852 stopped_or_terminated: couldn't wake up wait event 0x110, Win32 error 6 The process hangs and cannot be terminated by kill command. The only way to kill process is with windows task manager. Our tasks require many system calls to complete Please advise how to resolve this. Is it any better or worse with Cygwin 1.7.29 that was just released? -- Larry _ A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting annoying in email? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Request for Junctions be treated consistently
Greetings, Corinna Vinschen! >> I don't think your original concern is as big a problem as you >> think, as is indicated by the above setup on linux. >> >> I.e. is there some other reason to not treat "linkd" mounts >> the same as "mountvol" mounts -- in a manner equivalent to linux's >> 'bind' mounts? >> >> I.e. I don't see that that linkd which creates a junction-mount >> point, should be treated as a symlink. It would provide valuable >> benefit in cygwin terms in being able to setup directories at >> multiple place like 'bind' does on linux, and be resistant to being >> overwritten like symlinks. > Look, directory reparse points are, by and large, symlinks to another, > real directory entry. The directory has a primary path, which is its > own path under which it has been created, and the reparse point is just > a pointer to this directory. If that's not a symlink, what is? Uhm, there's two ways to look at it. You may call it a "symlink", but in fact, Linux equivalent of a reparse point is a mount --bind, or, perhaps, a block-type device mounted at specific directory. It's a [literal] filesystem junction (in common meaning of "junction"), while symlink is more like conventional language construct. I.e., you can make a reparse point to local resource, that was not assigned a drive letter. Enough that it's a local filesystem, and you know it's UUID. But you can't make a reparse point to a network share, for example, even if that share is mapped to a drive letter. But you can make a [native] symlink to it. -- WBR, Andrey Repin (anrdae...@yandex.ru) 07.04.2014, <21:55> Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Request for Junctions be treated consistently
Corinna Vinschen wrote: Look, directory reparse points are, by and large, symlinks to another, real directory entry. The directory has a primary path, which is its own path under which it has been created, and the reparse point is just a pointer to this directory. If that's not a symlink, what is? --- What is a mount 'bind' on linux? You could call it a symlink, but it acts like a mount. Since both mountd and mountvol form "junctions", and not "symlinks ( as when you use 'mklink'), I'm asking the the junctions be treated as volume mount points -- or like 'bind' on linux. That way, I can mount parts of the file system in common in multiple locations and not have to worry about all the utilities that overwrite symlinks instead of following them. But it was intended to allow grafting of the file system into different locations for ease of administration. Treating them the same as symlinks removes that ability because most or many of the linux utils will overwrite symlinks rather than follow them as they would if it was a mount. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin 1.7.25-1.7.28 - the perl process couldn't wake up after system call
On Mon, Apr 7, 2014 at 11:37 AM, Larry Hall (Cygwin) wrote: > On 4/7/2014 8:03 AM, Eduard wrote: >> >> Hi, >> We run >> Cygwin 1.7.25-1.7.28 on Win7-64bit. >> perl version is v5.14.2. >> >> Sometimes during system call from perl we see the following error: >> 0 [sig] perl 9852 stopped_or_terminated: couldn't wake up wait event >> 0x110, Win32 error 6 >> >> The process hangs and cannot be terminated by kill command. The only >> way to kill process is with windows task manager. >> Our tasks require many system calls to complete >> Please advise how to resolve this. Eduard: Please advise (off-list if too much data) how I could reproduce this problem. I never stumbled on that. Esp. the 64 bit version is much safer than the 32bit version. > Is it any better or worse with Cygwin 1.7.29 that was just released? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: 1.7.29-2: Exception from cygwin_gethostname
On Apr 7 11:49, David Rothenberger wrote: > I'm having a problem doing hostname resolution on one of my Windows > 7 64 machines after updating cygwin to 1.7.29-2. I first noticed it > with ssh. I get an error whenever I try to ssh to any machine using > a hostname; it complains the hostname cannot be resolved. > > An strace of ssh shows an exception occuring right after the call to > cygwin_gethostname is logged. > >96 58624 [main] ssh 3536 cygwin_gethostname: name daver-pc > --- Process 3536, exception 06ba at 07FEFDD4940D > 860 59484 [main] ssh 3536 __set_errno: void san::leave():315 setting > errno 14 Exception 0x6ba is "The RPC server is unavailable". I have no idea why this exception is generated at all on your machine. Usually this is a first-chance exception only, which can be ignored, but this is the first time I ever saw this and in the above scenario there's no such exception expected, so it doesn't get ignored. Oh well, it would have been helpful if this had been encountered last week :( Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgptCbxHC1_fo.pgp Description: PGP signature
Re: [ANNOUNCEMENT] Updated: mingw64-*-binutils-2.24.0.1.acd6540-1 (x86/x86_64)
>> I fixed it for now by placing an empty dummy default-manifest.o file in >> working directory. > > May you describe how you have crated it or attach here your empty file? > I tried in different ways but always fail in building with: > > "...default-manifest.o: file not recognized: File format not recognized" $ touch default-manifest.c $ gcc -c default-manifest.c Instead of 'gcc' use the appropriate (i.e. i686-w64-mingw32-gcc) That will give you a default-manifest.o that the linker will recognize. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: 1.7.29-2: Exception from cygwin_gethostname
On 4/7/2014 3:09 PM, Corinna Vinschen wrote: On Apr 7 11:49, David Rothenberger wrote: I'm having a problem doing hostname resolution on one of my Windows 7 64 machines after updating cygwin to 1.7.29-2. I first noticed it with ssh. I get an error whenever I try to ssh to any machine using a hostname; it complains the hostname cannot be resolved. An strace of ssh shows an exception occuring right after the call to cygwin_gethostname is logged. 96 58624 [main] ssh 3536 cygwin_gethostname: name daver-pc --- Process 3536, exception 06ba at 07FEFDD4940D 860 59484 [main] ssh 3536 __set_errno: void san::leave():315 setting errno 14 Exception 0x6ba is "The RPC server is unavailable". I have no idea why this exception is generated at all on your machine. Usually this is a first-chance exception only, which can be ignored, but this is the first time I ever saw this and in the above scenario there's no such exception expected, so it doesn't get ignored. Oh well, it would have been helpful if this had been encountered last week :( Good point. David, can you go back to last week and see if you can still reproduce it? ;-) -- Larry _ A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting annoying in email? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: 1.7.29-2: Exception from cygwin_gethostname
Larry Hall (Cygwin) wrote: > On 4/7/2014 3:09 PM, Corinna Vinschen wrote: >> On Apr 7 11:49, David Rothenberger wrote: >>> I'm having a problem doing hostname resolution on one of my Windows >>> 7 64 machines after updating cygwin to 1.7.29-2. I first noticed it >>> with ssh. I get an error whenever I try to ssh to any machine using >>> a hostname; it complains the hostname cannot be resolved. >>> >>> An strace of ssh shows an exception occuring right after the call to >>> cygwin_gethostname is logged. >>> >>> 96 58624 [main] ssh 3536 cygwin_gethostname: name daver-pc >>> --- Process 3536, exception 06ba at 07FEFDD4940D >>>860 59484 [main] ssh 3536 __set_errno: void san::leave():315 >>> setting errno 14 >> >> Exception 0x6ba is "The RPC server is unavailable". I have no idea why >> this exception is generated at all on your machine. Usually this is a >> first-chance exception only, which can be ignored, but this is the first >> time I ever saw this and in the above scenario there's no such exception >> expected, so it doesn't get ignored. >> >> Oh well, it would have been helpful if this had been encountered last >> week :( > > Good point. David, can you go back to last week and see if you can still > reproduce it? ;-) I wish! There were a few important changes to the system starting last Friday and I dearly wish I could go back to before those changes. On Friday, I accidentally installed OpenCandy, a PUP adware "program". I spent some time on Saturday cleaning that with a host of free malware removals. This removed some registry keys, but I'm pretty sure it was all safe. Pretty sure... Also on Saturday I replaced two old HDDs with SSDs. This made my system a lot faster, but I haven't seen any problems associated with it aside from the OS complaining about not getting a network connection right after it boots. I think this is just because it boots so much faster now. I /should/ have tested the snapshots when the call went out. I wished I did now, because then I would know if this issue was related to any of the problems I had late last week. This is a work machine and we're super-busy, so I was hesitant to experiment with snapshots. But I learned my lesson; I'll be testing snapshots when Chris or Corinna ask for testing from now on, on all my machines. -- David Rothenberger daver...@acm.org "It's when they say 2 + 2 = 5 that I begin to argue." -- Eric Pepke -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] Updated: mingw64-*-binutils-2.24.0.1.acd6540-1 (x86/x86_64)
Ciao m0viefreak, Il 07/04/2014 21:09, m0viefreak ha scritto: I fixed it for now by placing an empty dummy default-manifest.o file in working directory. May you describe how you have crated it or attach here your empty file? I tried in different ways but always fail in building with: "...default-manifest.o: file not recognized: File format not recognized" $ touch default-manifest.c $ gcc -c default-manifest.c Instead of 'gcc' use the appropriate (i.e. i686-w64-mingw32-gcc) That will give you a default-manifest.o that the linker will recognize. I can confirm that with the above workaround all my applications (using binutils, mingw-w64-*-binutils 2.24) work as expected. Thanks, Angelo. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Trouble with running cygwin dll on Vortex86MX+ CPU
Larry Hall (Cygwin cygwin.com> writes: >>> > >> > >> Cygwin 1.5.25 seems like a good option. So I downloaded setup- legacy.exe > >> from fruitbat and ran it on an XP machine which has not previously seen > >> Cygwin. Initially I installed just the base Cygwin files. The process ran > >> as expected, and installed 4,263 files in 472 folders. > >> > >> However the bash shell appears non-functional as far as external commands > >> go. It presents a prompt bash-3.2$, if I type something like ls, it > >> responds command not found. Any ideas? > > > > $PATH? > > Indeed. And if your path under bash doesn't include /usr/bin, then I'll > wager your postinstall scripts didn't run or at least completely/correctly. > See /etc/postinstall for the scripts. If you aren't able to figure out > what didn't run properly, you can either try rerunning everything manually > and looking for faults (if any) or just rerun setup.exe and hope that it > has better luck with the scripts the second time around. > Spot on, Larry. $PATH is empty. I 'Reinstall'ed Cygwin, but the result is the same. I did take note of setup complaining that there is a more recent version available according to the ini file (2.774 vs 2.674) but I'm picking that isn't the problem. /etc/postinstall contains the following "done" script files: base-files-mketc.sh.done base-files-profile.sh.done bash.sh.done coreutils.sh.done cygwin-doc.sh.done man.sh.done passwd-grp.sh.done terminfo.sh.done terminfo0.sh.done update-info-dir.sh.done Is there something missing from that list? What's my next step? I haven't yet tried running them manually, that will have to wait until tonight (gmt + 12). Thanks, Colin -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Trouble with running cygwin dll on Vortex86MX+ CPU
On 4/7/2014 5:09 PM, Colin wrote: Indeed. And if your path under bash doesn't include /usr/bin, then I'll wager your postinstall scripts didn't run or at least completely/correctly. See /etc/postinstall for the scripts. If you aren't able to figure out what didn't run properly, you can either try rerunning everything manually and looking for faults (if any) or just rerun setup.exe and hope that it has better luck with the scripts the second time around. Spot on, Larry. $PATH is empty. I 'Reinstall'ed Cygwin, but the result is the same. I did take note of setup complaining that there is a more recent version available according to the ini file (2.774 vs 2.674) but I'm picking that isn't the problem. I do find it interesting that the Cygwin Time Machine wouldn't have the setup version and the archive in sync. You'd have to check with that site to understand why you're seeing that. /etc/postinstall contains the following "done" script files: base-files-mketc.sh.done base-files-profile.sh.done bash.sh.done coreutils.sh.done cygwin-doc.sh.done man.sh.done passwd-grp.sh.done terminfo.sh.done terminfo0.sh.done update-info-dir.sh.done Is there something missing from that list? What's my next step? I haven't yet tried running them manually, that will have to wait until tonight (gmt + 12). That list seems a bit limited to me, unless you specifically asked for just those packages to install. Allowing setup to install a default installation should get you several dozen packages I believe, in 1.5 days. So I'd say start there and check that. If that doesn't help, check with the Cygwin Time Machine site for help. -- Larry _ A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting annoying in email? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Possible bug with chere 1.4 when configuring for fish
On 07/04/2014 13:02, Ronald Fischer wrote: I have installed fish 2.1.0. Works fine, when invoking a new fish shell manually. However, when doing a chere -ifcm -t mintty -s fish and invoke the new fish shell from the Windows Explorer context menu, I get plenty of error messages, like this: (more of this kind follow). This looks like there is a problem the PATH, but this happens even when I use the -2 on chere when installing the shell. Note that bash or zsh shells installed via cygwin work fine. In this 'broken' fish shell, I enter echo $PATH; uname and get the following output: /cygdrive/c/windows/system32 /cygdrive/c/windows /cygdrive/c/windows/System32/Wbem /cygdrive/c/windows/System32/WindowsPowerShell/v1.0 /cygdrive/c/windows/System32/WindowsPowerShell/v1.0 /cygdrive/c/Program Files (x86)/Common Files/Citrix/System32 /cygdrive/c/Program Files (x86)/Citrix/ICAService /cygdrive/c/Program Files (x86)/Citrix/System32 To compare with, when I output the PATH from a "normal" fish shell (i.e. one which I have invoked from, say, a bash shell), I get: echo $PATH .:/home/ronald.fischer/bin:/usr/local/bin:/usr/bin:/cygdrive/c/windows/system32:/cygdrive/c/windows:/cygdrive/c/windows/System32/Wbem:/cygdrive/c/windows/System32/WindowsPowerShell/v1.0:/cygdrive/c/windows/System32/WindowsPowerShell/v1.0:/cygdrive/c/Program Files (x86)/Common Files/Citrix/System32:/cygdrive/c/Program Files (x86)/Citrix/ICAService:/cygdrive/c/Program Files (x86)/Citrix/System32:/usr/lib/lapack We see that in fish, /usr/bin is missing from the PATH. This is strange, in particular if I install chere fish with option -2, because in this case, fish will be invoked via bash. Ronald Thanks for the report. I've just checked my x86_64 and x86 installation. Things are working on my installation as I have c:\cygwin\bin on my standard windows path. When I remove it and invoke fish, I get the errors that you highlight. Similarly when echo'ing $PATH under the broken fish, /usr/bin is not one of the entries. I need to have a play around to see how I can fix this, but I thought cygwin prepended /usr/bin to the path... Regards, Dave. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Trouble with running cygwin dll on Vortex86MX+ CPU
On Mon, 7 Apr 2014, Larry Hall (Cygwin) wrote: On 4/7/2014 5:09 PM, Colin wrote: Indeed. And if your path under bash doesn't include /usr/bin, then I'll wager your postinstall scripts didn't run or at least completely/correctly. See /etc/postinstall for the scripts. If you aren't able to figure out what didn't run properly, you can either try rerunning everything manually and looking for faults (if any) or just rerun setup.exe and hope that it has better luck with the scripts the second time around. Spot on, Larry. $PATH is empty. I 'Reinstall'ed Cygwin, but the result is the same. I did take note of setup complaining that there is a more recent version available according to the ini file (2.774 vs 2.674) but I'm picking that isn't the problem. I do find it interesting that the Cygwin Time Machine wouldn't have the setup version and the archive in sync. You'd have to check with that site to understand why you're seeing that. Geetings, Larry, Some comments about this (sorry if this is off-tipic): 1) There used to be a directory to pull the snapshots, but that's been removed or otherwise made inaccessable a while ago, so archving the snapshots has been impossible for me. 2) Packaging changes of setup.exe have made extracting the version string impossible, save for actually running setup, which isn't something I'm going to do on a daily basis. If there is a method of extracting this info from it, please do tell me how. 3) The format of setup.ini hasn't changed in any significant way that prevents newer versions of setup from working with older versions of the achive, and vise-versa, so it hasn't been worth doing regular achives of setup. Mostly I tell people to grab the lastest setup and try it first. The exceptions are for the Legacy release (hard coded for -legacy) as well as the preview (-2) release, but that, again, was most about the name of the setup file and the initial release path names. So, there really hasn't been much incentive to archive setup. That being said, I do have a Legacy and a -2 setup versions available for those that need them, as well as some other older releases of setup, just in case. If someone can tell me how to extract the version id from setup.exe, I'll start archiving specific versions of it again. /etc/postinstall contains the following "done" script files: base-files-mketc.sh.done base-files-profile.sh.done bash.sh.done coreutils.sh.done cygwin-doc.sh.done man.sh.done passwd-grp.sh.done terminfo.sh.done terminfo0.sh.done update-info-dir.sh.done Is there something missing from that list? What's my next step? I haven't yet tried running them manually, that will have to wait until tonight (gmt + 12). That list seems a bit limited to me, unless you specifically asked for just those packages to install. Allowing setup to install a default installation should get you several dozen packages I believe, in 1.5 days. So I'd say start there and check that. If that doesn't help, check with the Cygwin Time Machine site for help. -- --=> Peter A. Castro Email: doctor at fruitbat dot org / Peter dot Castro at oracle dot com "Cats are just autistic Dogs" -- Dr. Tony Attwood -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Trouble with running cygwin dll on Vortex86MX+ CPU
On Mon, Apr 07, 2014 at 06:12:56PM -0400, Larry Hall (Cygwin) wrote: > On 4/7/2014 5:09 PM, Colin wrote: > > > > >>Indeed. And if your path under bash doesn't include /usr/bin, then I'll > >>wager your postinstall scripts didn't run or at least > >completely/correctly. > >>See /etc/postinstall for the scripts. If you aren't able to figure out > >>what didn't run properly, you can either try rerunning everything > >manually > >>and looking for faults (if any) or just rerun setup.exe and hope that it > >>has better luck with the scripts the second time around. > >> > > > >Spot on, Larry. $PATH is empty. > >I 'Reinstall'ed Cygwin, but the result is the same. I did take note of > >setup complaining that there is a more recent version available according > >to the ini file (2.774 vs 2.674) but I'm picking that isn't the problem. > > I do find it interesting that the Cygwin Time Machine wouldn't have the > setup version and the archive in sync. You'd have to check with that site > to understand why you're seeing that. > > >/etc/postinstall contains the following "done" script files: > >base-files-mketc.sh.done > >base-files-profile.sh.done > >bash.sh.done > >coreutils.sh.done > >cygwin-doc.sh.done > >man.sh.done > >passwd-grp.sh.done > >terminfo.sh.done > >terminfo0.sh.done > >update-info-dir.sh.done > > > >Is there something missing from that list? What's my next step? I haven't > >yet tried running them manually, that will have to wait until tonight (gmt > >+ 12). > > That list seems a bit limited to me, unless you specifically asked for just > those packages to install. Allowing setup to install a default installation > should get you several dozen packages I believe, in 1.5 days. So I'd say > start there and check that. If that doesn't help, check with the Cygwin > Time Machine site for help. > I have an older install at work, and thought that behaviour was normal (empty $PATH). I just set the PATH in .bashrc in the initial directory - then everything "just worked". Cheers ... Duncan. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: long_int vs int byte sizes
On 2014-04-08 03:51, Corinna Vinschen wrote: On Apr 7 09:39, Eric Blake wrote: C99 5.2.4.2.1 Sizes of integer types requires CHAR_BIT to be 8 or larger, UCHAR_MAX to be 255 or larger, USHRT_MAX to be 65535 or larger (oh, so I was wrong above; 8-bit short is not allowed), UINT_MAX to be 65535 or larger, ULONG_MAX to be 4294967295 or larger, and ULLONG_MAX to be 18446744073709551615 or larger. C99 actually requires that? Wow. Modern times... It was already required in C89; the only change in C99 was the addition of long long. Ross Smith -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Request for Junctions be treated consistently
On Mon, Apr 07, 2014 at 11:34:02AM -0700, Linda Walsh wrote: > Corinna Vinschen wrote: > >Look, directory reparse points are, by and large, symlinks to another, > >real directory entry. The directory has a primary path, which is its > >own path under which it has been created, and the reparse point is just > >a pointer to this directory. If that's not a symlink, what is? > --- > What is a mount 'bind' on linux? > This extract from the Linux man page explains it: The bind mounts. Since Linux 2.4.0 it is possible to remount part of the file hierarchy somewhere else. The call is mount --bind olddir newdir or shortoption mount -B olddir newdir or fstab entry is: /olddir /newdir none bind After this call the same contents is accessible in two places. Cheers ... Duncan. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Trouble with running cygwin dll on Vortex86MX+ CPU
On 4/7/2014 6:41 PM, Peter A. Castro wrote: Geetings, Larry, Some comments about this (sorry if this is off-tipic): Since you're providing this Cygwin service, I don't consider information about this service to be off-topic. And, of course, if *I* don't consider it off-topic, it certainly can't be. ;-) 1) There used to be a directory to pull the snapshots, but that's been removed or otherwise made inaccessable a while ago, so archving the snapshots has been impossible for me. Understood. Yeah, access to "snapshots", among others, is turned off to robots. I'd say check with Chris on this one to see if there could be some accommodation here. 2) Packaging changes of setup.exe have made extracting the version string impossible, save for actually running setup, which isn't something I'm going to do on a daily basis. If there is a method of extracting this info from it, please do tell me how. I'm assuming it used to just be in the RC file in the past. Didn't look in the history to trace it back. But now it is generated and put in setup_version.c as a global constant setup_version. 3) The format of setup.ini hasn't changed in any significant way that prevents newer versions of setup from working with older versions of the achive, and vise-versa, so it hasn't been worth doing regular achives of setup. Mostly I tell people to grab the lastest setup and try it first. Yes, generally, this should work and I agree that this is the first, easiest answer if there is no corresponding setup for a particular date. I was under the impression that you were also pulling setups with each release. That, of course, is no guarantee of direct correspondence either but it's close. No matter. The exceptions are for the Legacy release (hard coded for -legacy) as well as the preview (-2) release, but that, again, was most about the name of the setup file and the initial release path names. So, there really hasn't been much incentive to archive setup. That being said, I do have a Legacy and a -2 setup versions available for those that need them, as well as some other older releases of setup, just in case. Yes, I noticed. That's a "Good Thing"(tm). :-) Thanks, -- Larry _ A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting annoying in email? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Trouble with running cygwin dll on Vortex86MX+ CPU
On Mon, Apr 07, 2014 at 09:28:29PM -0400, Larry Hall (Cygwin) wrote: >On 4/7/2014 6:41 PM, Peter A. Castro wrote: > > >> Geetings, Larry, >> >> Some comments about this (sorry if this is off-tipic): > >Since you're providing this Cygwin service, I don't consider information >about this service to be off-topic. And, of course, if *I* don't consider >it off-topic, it certainly can't be. ;-) > >> 1) There used to be a directory to pull the snapshots, but that's been >> removed or otherwise made inaccessable a while ago, so archving the >> snapshots has been impossible for me. > >Understood. Yeah, access to "snapshots", among others, is turned off to >robots. I'd say check with Chris on this one to see if there could be >some accommodation here. The only thing that has changed in the last year is that the snapshots are now in an architecture specific directory. I'm not aware of sourceware offering any method for accessing snapshots other than the snapshot web page. >> 2) Packaging changes of setup.exe have made extracting the version string >> impossible, save for actually running setup, which isn't something I'm >> going to do on a daily basis. If there is a method of extracting this >> info from it, please do tell me how. > >I'm assuming it used to just be in the RC file in the past. Didn't look >in the history to trace it back. But now it is generated and put in >setup_version.c as a global constant setup_version. setup.exe is packed with upx. If you want to see the version string I suppose you could unpack it with upx. >> 3) The format of setup.ini hasn't changed in any significant way that >> prevents newer versions of setup from working with older versions of >> the achive, and vise-versa, so it hasn't been worth doing regular >> achives of setup. Mostly I tell people to grab the lastest setup and >> try it first. > >Yes, generally, this should work and I agree that this is the first, >easiest answer if there is no corresponding setup for a particular date. I >was under the impression that you were also pulling setups with each >release. That, of course, is no guarantee of direct correspondence >either but it's close. No matter. It is entirely possible that a new field could show up in setup.ini eventually but I don't see the syntax changing so it's likely, but not guaranteed, that new setup.exe's will work with old setup.ini's. >> The exceptions are for the Legacy release (hard coded for -legacy) >> as well as the preview (-2) release, but that, again, was most about >> the name of the setup file and the initial release path names. >> So, there really hasn't been much incentive to archive setup. >> >> That being said, I do have a Legacy and a -2 setup versions available >> for those that need them, as well as some other older releases of >> setup, just in case. > >Yes, I noticed. That's a "Good Thing"(tm). :-) > >Thanks, > > >-- >Larry > >_ > >A: Yes. > > Q: Are you sure? > >> A: Because it reverses the logical flow of conversation. > >>> Q: Why is top posting annoying in email? > >-- >Problem reports: http://cygwin.com/problems.html >FAQ: http://cygwin.com/faq/ >Documentation: http://cygwin.com/docs.html >Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple > > -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Request for Junctions be treated consistently
On Tue, Apr 08, 2014 at 09:52:02AM +1000, Duncan Roe wrote: >On Mon, Apr 07, 2014 at 11:34:02AM -0700, Linda Walsh wrote: >> Corinna Vinschen wrote: >> >Look, directory reparse points are, by and large, symlinks to another, >> >real directory entry. The directory has a primary path, which is its >> >own path under which it has been created, and the reparse point is just >> >a pointer to this directory. If that's not a symlink, what is? >> --- >> What is a mount 'bind' on linux? >> >This extract from the Linux man page explains it: > > The bind mounts. >Since Linux 2.4.0 it is possible to remount part of the file >hierarchy somewhere else. The call is > mount --bind olddir newdir >or shortoption > mount -B olddir newdir >or fstab entry is: > /olddir /newdir none bind > >After this call the same contents is accessible in two places. Or even: http://lmgtfy.com/?q=linux+bind+mount -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Trouble with running cygwin dll on Vortex86MX+ CPU
On 4/7/2014 9:50 PM, Christopher Faylor wrote: On Mon, Apr 07, 2014 at 09:28:29PM -0400, Larry Hall (Cygwin) wrote: 2) Packaging changes of setup.exe have made extracting the version string impossible, save for actually running setup, which isn't something I'm going to do on a daily basis. If there is a method of extracting this info from it, please do tell me how. I'm assuming it used to just be in the RC file in the past. Didn't look in the history to trace it back. But now it is generated and put in setup_version.c as a global constant setup_version. setup.exe is packed with upx. If you want to see the version string I suppose you could unpack it with upx. Of course! Why didn't I think of that? strings setup*.exe | grep setup-version This returns the version for a _decompressed_ setup executable. -- Larry _ A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting annoying in email? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Trouble with running cygwin dll on Vortex86MX+ CPU
On Mon, 7 Apr 2014, Christopher Faylor wrote: Greetings, Chris, On Mon, Apr 07, 2014 at 09:28:29PM -0400, Larry Hall (Cygwin) wrote: On 4/7/2014 6:41 PM, Peter A. Castro wrote: Geetings, Larry, Some comments about this (sorry if this is off-tipic): Since you're providing this Cygwin service, I don't consider information about this service to be off-topic. And, of course, if *I* don't consider it off-topic, it certainly can't be. ;-) Good to know! :-) 1) There used to be a directory to pull the snapshots, but that's been removed or otherwise made inaccessable a while ago, so archving the snapshots has been impossible for me. Understood. Yeah, access to "snapshots", among others, is turned off to robots. I'd say check with Chris on this one to see if there could be some accommodation here. The only thing that has changed in the last year is that the snapshots are now in an architecture specific directory. I'm not aware of sourceware offering any method for accessing snapshots other than the snapshot web page. Hmm... Perhaps I've been trying to wget the wrong directory. I'll check on that and get back to you. 2) Packaging changes of setup.exe have made extracting the version string impossible, save for actually running setup, which isn't something I'm going to do on a daily basis. If there is a method of extracting this info from it, please do tell me how. I'm assuming it used to just be in the RC file in the past. Didn't look in the history to trace it back. But now it is generated and put in setup_version.c as a global constant setup_version. setup.exe is packed with upx. If you want to see the version string I suppose you could unpack it with upx. I have an old version of upx, so perhaps it's just out of date, but even when I could extract it, at some point the version string was moved to setup_version.c and became difficult to extract from the binary. I'd largely given up, but I'll take another crack at it. 3) The format of setup.ini hasn't changed in any significant way that prevents newer versions of setup from working with older versions of the achive, and vise-versa, so it hasn't been worth doing regular achives of setup. Mostly I tell people to grab the lastest setup and try it first. Yes, generally, this should work and I agree that this is the first, easiest answer if there is no corresponding setup for a particular date. I was under the impression that you were also pulling setups with each release. That, of course, is no guarantee of direct correspondence either but it's close. No matter. It is entirely possible that a new field could show up in setup.ini eventually but I don't see the syntax changing so it's likely, but not guaranteed, that new setup.exe's will work with old setup.ini's. Yes, there's no guarantee, I knowledge that. That's why I randomly keep a copy of various versions of setup, just in case. But, until something does change, it "WJFFM". :-) Once I have an ability to extract versions from setup again, I'll see about doing it more regularly. The exceptions are for the Legacy release (hard coded for -legacy) as well as the preview (-2) release, but that, again, was most about the name of the setup file and the initial release path names. So, there really hasn't been much incentive to archive setup. That being said, I do have a Legacy and a -2 setup versions available for those that need them, as well as some other older releases of setup, just in case. Yes, I noticed. That's a "Good Thing"(tm). :-) Thanks, Thanks, to both of you, for replying. I really apprecite it. -- Larry _ Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple -- --=> Peter A. Castro Email: doctor at fruitbat dot org / Peter dot Castro at oracle dot com "Cats are just autistic Dogs" -- Dr. Tony Attwood -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Cygwin kill utility //Was: cgwin_internal(): difference b/w CW_CYGWIN_PID_TO_WINPID and CW_GETPINFO_FULL for taking only dwProcessId ?
Hello,
It looks like in order to effectively kill the process by Windows means (i.e.
what Cygwin "kill -f" is supposed to do),
the process handle must be obtained with the SYNCHRONIZE right (in addition to
PROCESS_TERMINATE), otherwise
WaitForSingleObject() fails with code 5, permission denied (at least for a
regular user, i.e. not an administrator).
That's about this portion of kill.cc located at winsup\utils:
HANDLE h = OpenProcess (PROCESS_TERMINATE, FALSE, (DWORD) dwpid);
if (!h)
{
if (!wait || GetLastError () != ERROR_INVALID_PARAMETER)
fprintf (stderr, "%s: couldn't open pid %u\n",
prog_name, (unsigned) dwpid);
return;
}
if (!wait || WaitForSingleObject (h, 200) != WAIT_OBJECT_0)
if (sig && !TerminateProcess (h, sig << 8)
&& WaitForSingleObject (h, 200) != WAIT_OBJECT_0)
fprintf (stderr, "%s: couldn't kill pid %u, %lu\n",
prog_name, (unsigned) dwpid, GetLastError ());
MSDN is in agreement with the observed behavior (access denied),
http://msdn.microsoft.com/en-us/library/windows/desktop/ms684320%28v=vs.85%29.aspx
The handle returned by the OpenProcess function can be used in any function
that requires a handle to a process, such as the wait functions, provided the
appropriate access rights were requested.
http://msdn.microsoft.com/en-us/library/windows/desktop/ms684880%28v=vs.85%29.aspx
HTH,
Anton Lavrentiev
Contractor NIH/NLM/NCBI
Re: Cygwin kill utility //Was: cgwin_internal(): difference b/w CW_CYGWIN_PID_TO_WINPID and CW_GETPINFO_FULL for taking only dwProcessId ?
On Tue, Apr 08, 2014 at 03:01:18AM +, Lavrentiev, Anton (NIH/NLM/NCBI) [C]
wrote:
>Hello,
>
>It looks like in order to effectively kill the process by Windows means (i.e.
>what Cygwin "kill -f" is supposed to do),
>the process handle must be obtained with the SYNCHRONIZE right (in addition to
>PROCESS_TERMINATE), otherwise
>WaitForSingleObject() fails with code 5, permission denied (at least for a
>regular user, i.e. not an administrator).
>
>That's about this portion of kill.cc located at winsup\utils:
>
> HANDLE h = OpenProcess (PROCESS_TERMINATE, FALSE, (DWORD) dwpid);
> if (!h)
>{
> if (!wait || GetLastError () != ERROR_INVALID_PARAMETER)
> fprintf (stderr, "%s: couldn't open pid %u\n",
>prog_name, (unsigned) dwpid);
> return;
>}
> if (!wait || WaitForSingleObject (h, 200) != WAIT_OBJECT_0)
>if (sig && !TerminateProcess (h, sig << 8)
> && WaitForSingleObject (h, 200) != WAIT_OBJECT_0)
> fprintf (stderr, "%s: couldn't kill pid %u, %lu\n",
> prog_name, (unsigned) dwpid, GetLastError ());
>
>MSDN is in agreement with the observed behavior (access denied),
>
>http://msdn.microsoft.com/en-us/library/windows/desktop/ms684320%28v=vs.85%29.aspx
>
>
>The handle returned by the OpenProcess function can be used in any function
>that requires a handle to a process, such as the wait functions, provided the
>appropriate access rights were requested.
>
>
>http://msdn.microsoft.com/en-us/library/windows/desktop/ms684880%28v=vs.85%29.aspx
If only there was some way to programatically supply a change in source
code from party A which could be applied to the source code by party B,
along with a description which logs the change. Nah. Maybe we'll have
something when the Singularity finally occurs.
cgf
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
RE: Cygwin kill utility //Was: cgwin_internal(): difference b/w CW_CYGWIN_PID_TO_WINPID and CW_GETPINFO_FULL for taking only dwProcessId ?
> Nah. Maybe we'll have something when the Singularity finally occurs. I cannot supply patches for you guys because of the GPL. No need to be sarcastic all the time -- for the project lead it does not sound witty. Anton Lavrentiev Contractor NIH/NLM/NCBI -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
