Re: perl-5.14.4
On Mar 14 21:30, Achim Gratz wrote: Corinna Vinschen writes: So the binutils problem is fixed upstream, we're just waiting for GDB to catch up. Another collegue of mine will have a look as soon as time permits. Here's one for testing, Achim: https://cygwin.com/ml/cygwin-announce/2015-03/msg00020.html That works correctly now. Thanks for testing. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpe0Pfurno2R.pgp Description: PGP signature
Re: perl-5.14.4
Corinna Vinschen writes: So the binutils problem is fixed upstream, we're just waiting for GDB to catch up. Another collegue of mine will have a look as soon as time permits. Here's one for testing, Achim: https://cygwin.com/ml/cygwin-announce/2015-03/msg00020.html That works correctly now. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Factory and User Sound Singles for Waldorf Q+, Q and microQ: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: perl-5.14.4
On Mar 5 14:20, Corinna Vinschen wrote: On Feb 16 16:42, Achim Gratz wrote: Corinna Vinschen writes: Uh oh, the debug information is either broken (which is unlikely) or GDB doesn't use it anymore due to the CRC mismatch. Maybe the same CRC mismatch breaks objcopy in cygport, given that both are based on the same BFD code? Maybe, but none of the tools ever complained about the CRC (I remember that GDB checks it though). A CRC should be a fixable thing, though. For the time being, is it really required to rebase the DLLs for testing before the debug information is split off? If you could do the rebase and test cycle after splitting off the debug info, the problem should be neglectable. For the moment I've changed the patch to EUMM to check if it's run from cygport and not rebase the just produced DLL in that case. I only need to remember to package the module before testing instead of the other way around (and do a manual rebase before testing, but that isn't difficult). So, I have a workaround. FYI: https://sourceware.org/bugzilla/show_bug.cgi?id=18025 So the binutils problem is fixed upstream, we're just waiting for GDB to catch up. Another collegue of mine will have a look as soon as time permits. Here's one for testing, Achim: https://cygwin.com/ml/cygwin-announce/2015-03/msg00020.html Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpp_Yw56UHh9.pgp Description: PGP signature
Re: perl-5.14.4
On Feb 16 16:42, Achim Gratz wrote: Corinna Vinschen writes: Uh oh, the debug information is either broken (which is unlikely) or GDB doesn't use it anymore due to the CRC mismatch. Maybe the same CRC mismatch breaks objcopy in cygport, given that both are based on the same BFD code? Maybe, but none of the tools ever complained about the CRC (I remember that GDB checks it though). A CRC should be a fixable thing, though. For the time being, is it really required to rebase the DLLs for testing before the debug information is split off? If you could do the rebase and test cycle after splitting off the debug info, the problem should be neglectable. For the moment I've changed the patch to EUMM to check if it's run from cygport and not rebase the just produced DLL in that case. I only need to remember to package the module before testing instead of the other way around (and do a manual rebase before testing, but that isn't difficult). So, I have a workaround. FYI: https://sourceware.org/bugzilla/show_bug.cgi?id=18025 So the binutils problem is fixed upstream, we're just waiting for GDB to catch up. Another collegue of mine will have a look as soon as time permits. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp9ZcHa5P7R7.pgp Description: PGP signature
Re: perl-5.14.4
Corinna Vinschen writes: Hang on. Perhaps I just missed the crucial point here, but it just occured to me that the DLLs are rebased as part of the autorebase script. Yes, they routinely are. Even on 64bit when they have been auto-image-based originally. So what you have is a DLL which gets some automatic address at build time. Then the debug information is split off. At this point, is the debug information usable? I assume yes, but I don't really know how to check. In any case, that's the way it has been for quite some time. /usr/bin/cygperl5_14.dll: file format pei-x86-64 Sections: Idx Name Size VMA LMA File off Algn 0 .text 0014b2a0 0003ed741000 0003ed741000 0400 2**4 CONTENTS, ALLOC, LOAD, READONLY, CODE, DATA 1 .data 3028 0003ed88d000 0003ed88d000 0014b800 2**6 CONTENTS, ALLOC, LOAD, DATA 2 .rdata00021a24 0003ed891000 0003ed891000 0014ea00 2**6 CONTENTS, ALLOC, LOAD, READONLY, DATA 3 .buildid 0035 0003ed8b3000 0003ed8b3000 00170600 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 4 .pdata5364 0003ed8b4000 0003ed8b4000 00170800 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 5 .xdata64c0 0003ed8ba000 0003ed8ba000 00175c00 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 6 .bss 02b0 0003ed8c1000 0003ed8c1000 2**6 ALLOC 7 .edatab3e9 0003ed8c2000 0003ed8c2000 0017c200 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 8 .idata2008 0003ed8ce000 0003ed8ce000 00187600 2**2 CONTENTS, ALLOC, LOAD, DATA 9 .reloc1464 0003ed8d1000 0003ed8d1000 00189800 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 10 .gnu_debuglink 0018 0003ed8d3000 0003ed8d3000 0018ae00 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA /usr/lib/debug/usr/bin/cygperl5_14.dll.dbg: file format pei-x86-64 Sections: Idx Name Size VMA LMA File off Algn 0 .text 0014b2a0 0004d1891000 0004d1891000 2**4 ALLOC, LOAD, READONLY, CODE, DATA 1 .data 3028 0004d19dd000 0004d19dd000 2**6 ALLOC, LOAD, DATA 2 .rdata00021a24 0004d19e1000 0004d19e1000 2**6 ALLOC, LOAD, READONLY, DATA 3 .buildid 0035 0004d1a03000 0004d1a03000 0600 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 4 .pdata5364 0004d1a04000 0004d1a04000 2**2 ALLOC, LOAD, READONLY, DATA 5 .xdata64c0 0004d1a0a000 0004d1a0a000 2**2 ALLOC, LOAD, READONLY, DATA 6 .bss 02b0 0004d1a11000 0004d1a11000 2**6 ALLOC 7 .edatab3e9 0004d1a12000 0004d1a12000 2**2 ALLOC, LOAD, READONLY, DATA 8 .idata2008 0004d1a1e000 0004d1a1e000 2**2 ALLOC, LOAD, DATA 9 .reloc1464 0004d1a21000 0004d1a21000 2**2 ALLOC, LOAD, READONLY, DATA 10 .debug_aranges 09b0 0004d1a23000 0004d1a23000 0800 2**4 CONTENTS, READONLY, DEBUGGING 11 .debug_info 00261e08 0004d1a24000 0004d1a24000 1200 2**0 CONTENTS, READONLY, DEBUGGING 12 .debug_abbrev ddc9 0004d1c86000 0004d1c86000 00263200 2**0 CONTENTS, READONLY, DEBUGGING 13 .debug_line 0004ed6e 0004d1c94000 0004d1c94000 00271000 2**0 CONTENTS, READONLY, DEBUGGING 14 .debug_frame 00022378 0004d1ce3000 0004d1ce3000 002bfe00 2**3 CONTENTS, READONLY, DEBUGGING 15 .debug_str4ebb 0004d1d06000 0004d1d06000 002e2200 2**0 CONTENTS, READONLY, DEBUGGING 16 .debug_loc00289775 0004d1d0b000 0004d1d0b000 002e7200 2**0 CONTENTS, READONLY, DEBUGGING 17 .debug_ranges 000568b0 0004d1f95000 0004d1f95000 00570a00 2**0 CONTENTS, READONLY, DEBUGGING 18 .gnu_debuglink 000c 0004d1fec000 0004d1fec000 005c7400 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA Then somebody installs the package and autorebase rebases the DLL /usr/bin/foo.dll. But it does not rebase the debug info for the DLL /usr/lib/debug/usr/bin/foo.dll.dbg. Again, my impression so far had been that there is nothing to rebase there. Even if you did, rebase doesn't touch the data in those sections, it just
Re: perl-5.14.4
On Feb 16 15:29, Achim Gratz wrote:
As long as the debug information is made unuseable by doing the rebase,
I don't see why we should start rebasing the debug files. AFAIK, if we
keep them non-rebased then everything works fine or we'd have heard
complaints by now.
Ok, I took the opportunity to check. I tested this with the attr(1)
tool which links against cygattr-1.dll:
$ objdump -h /usr/bin/cygattr-1.dll | awk '/text/{print $4}'
0003fd3b1000
$ objdump -h /usr/lib/debug/usr/bin/cygattr-1.dll.dbg | awk '/text/{print $4}'
000586301000
That's the usual result of a rebase. I started GDB, set a breakpoint to
attr_list in the DLL, and then ran the thingy with
(gdb) r -l /usr/bin/attr
Breakpoint 1, attr_list (path=0x23cad8 /usr/bin/attr, buffer=0x600039750 ,
buffersize=61440, flags=1, cursor=0x23ca10) at libattr.c:269
269 {
Stepping through the code works nicely. Checking variables works
nicely. So the debug information in cygattr-0.dll.dbg is not only still
in the file, it's also completely usable.
So this isn't a generic problem with DLL debug symbols...
I only recognized that there was something going on
because I need to rebase the DLL for Perl modules before I can test them
(on 32bit at least) and when cygport later packaged the files it didn't
find any debug information in them anymore (again the information is
still there and has indeed not been altered, but nm doesn't output it
along with the symbols and so cygport assumes they aren't there).
...it's this one step further, when you rebase the DLL while the
debug symbols are still attached:
I tried again with cygattr-1.dll.dbg. I rebased it and called nm.
No problem. However, GDB suddenly complains:
$ gdb /usr/bin/attr
[...blah...]
(gdb) sta -l ./attr
Temporary breakpoint 1 at 0x100401810: file attr.c, line 83.
Starting program: /usr/bin/attr -l ./attr
[New Thread 3208.0xe44]
warning: the debug information found in
/usr/lib/debug//usr/bin/cygattr-1.dll.dbg does not match
/usr/bin/cygattr-1.dll (CRC mismatch).
warning: the debug information found in
/usr/lib/debug/usr/bin/cygattr-1.dll.dbg does not match
/usr/bin/cygattr-1.dll (CRC mismatch).
[New Thread 3208.0x8b4]
[New Thread 3208.0x8c8]
[New Thread 3208.0xaa8]
Temporary breakpoint 1, main (argc=3, argv=0x23caa0) at attr.c:83
83 switch (ch) {
(gdb) br attr_list
Breakpoint 2 at 0x100401120 (2 locations)
(gdb) c
Continuing.
[New Thread 3208.0xf64]
Breakpoint 2, 0x000100401120 in attr_list ()
(gdb)
Continuing.
Breakpoint 2, 0x0003fd3b16f9 in cygattr-1!attr_list ()
from /usr/bin/cygattr-1.dll
(gdb)
Uh oh, the debug information is either broken (which is unlikely) or GDB
doesn't use it anymore due to the CRC mismatch. Maybe the same CRC
mismatch breaks objcopy in cygport, given that both are based on the
same BFD code?
For the time being, is it really required to rebase the DLLs for testing
before the debug information is split off? If you could do the rebase
and test cycle after splitting off the debug info, the problem should be
neglectable.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
pgpXtqyWghs5K.pgp
Description: PGP signature
Re: perl-5.14.4
Corinna Vinschen writes: Uh oh, the debug information is either broken (which is unlikely) or GDB doesn't use it anymore due to the CRC mismatch. Maybe the same CRC mismatch breaks objcopy in cygport, given that both are based on the same BFD code? Maybe, but none of the tools ever complained about the CRC (I remember that GDB checks it though). A CRC should be a fixable thing, though. For the time being, is it really required to rebase the DLLs for testing before the debug information is split off? If you could do the rebase and test cycle after splitting off the debug info, the problem should be neglectable. For the moment I've changed the patch to EUMM to check if it's run from cygport and not rebase the just produced DLL in that case. I only need to remember to package the module before testing instead of the other way around (and do a manual rebase before testing, but that isn't difficult). So, I have a workaround. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Wavetables for the Terratec KOMPLEXER: http://Synth.Stromeko.net/Downloads.html#KomplexerWaves
Re: perl-5.14.4
Corinna Vinschen writes: Back to the drawing board… The section names in rebase are completely different, completely different? -v, please? I gave up in disgust… anyway, instead of the .debug_* section names, rebase finds something like /19. I can't find a way to have objdump use the same format. Objcopy does have an option that hints at some long section names that can be present and I surmise that the debug sections use such names. not sure how I should get objdump to display them. objdump -h? Nope. That tells you: Sections: Idx Name Size VMA LMA File off Algn 0 .text 0b98 0003e5411000 0003e5411000 0600 2**4 CONTENTS, ALLOC, LOAD, READONLY, CODE, DATA 1 .data 0068 0003e5412000 0003e5412000 1200 2**5 CONTENTS, ALLOC, LOAD, DATA 2 .rdata3800 0003e5413000 0003e5413000 1400 2**6 CONTENTS, ALLOC, LOAD, READONLY, DATA 3 .buildid 0035 0003e5417000 0003e5417000 4c00 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 4 .pdata00cc 0003e5418000 0003e5418000 4e00 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 5 .xdata008c 0003e5419000 0003e5419000 5000 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 6 .bss 01d0 0003e541a000 0003e541a000 2**5 ALLOC 7 .edata012b 0003e541b000 0003e541b000 5200 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 8 .idata04fc 0003e541c000 0003e541c000 5400 2**2 CONTENTS, ALLOC, LOAD, DATA 9 .reloc06b4 0003e541d000 0003e541d000 5a00 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 10 .debug_aranges 0220 0003e541e000 0003e541e000 6200 2**0 CONTENTS, READONLY, DEBUGGING 11 .debug_info cc86 0003e541f000 0003e541f000 6600 2**0 CONTENTS, READONLY, DEBUGGING 12 .debug_abbrev 0e74 0003e542c000 0003e542c000 00013400 2**0 CONTENTS, READONLY, DEBUGGING 13 .debug_line 0e93 0003e542d000 0003e542d000 00014400 2**0 CONTENTS, READONLY, DEBUGGING 14 .debug_frame 0350 0003e542e000 0003e542e000 00015400 2**3 CONTENTS, READONLY, DEBUGGING 15 .debug_loc0b22 0003e543 0003e543 00015800 2**0 CONTENTS, READONLY, DEBUGGING 16 .debug_ranges 00c0 0003e5431000 0003e5431000 00016400 2**0 CONTENTS, READONLY, DEBUGGING 17 .debug_str01a8 0004 0004 00016600 2**0 CONTENTS, READONLY, DEBUGGING While rebase thinks: Base: 0x0x2f ImageBase: 0x3e266 ImageBase: 0x3e266 ImageSize: 0x22000 section name:.text base: 0x1000 size: 0x0c00 file offset: 0x0600 offset: 0x002ef600 section name:.data base: 0x2000 size: 0x0200 file offset: 0x1200 offset: 0x002ef200 section name: .rdata base: 0x3000 size: 0x3800 file offset: 0x1400 offset: 0x002ee400 section name: .buildid base: 0x7000 size: 0x0200 file offset: 0x4c00 offset: 0x002edc00 section name: .pdata base: 0x8000 size: 0x0200 file offset: 0x4e00 offset: 0x002ece00 section name: .xdata base: 0x9000 size: 0x0200 file offset: 0x5000 offset: 0x002ec000 section name: .bss base: 0xa000 size: 0x file offset: 0x offset: 0x002e6000 section name: .edata base: 0xb000 size: 0x0200 file offset: 0x5200 offset: 0x002ea200 section name: .idata base: 0xc000 size: 0x0600 file offset: 0x5400 offset: 0x002e9400 section name: .reloc base: 0xd000 size: 0x0800 file offset: 0x5a00 offset: 0x002e8a00 section name: /4 base: 0xe000 size: 0x0400 file offset: 0x6200 offset: 0x002e8200 section name: /19 base: 0xf000 size: 0xce00 file offset: 0x6600 offset: 0x002e7600 section name: /31 base: 0x0001c000 size: 0x1000 file offset: 0x00013400 offset: 0x002e7400 section name: /45 base: 0x0001d000 size: 0x1000 file offset: 0x00014400 offset: 0x002e7400 section name: /57 base: 0x0001e000 size: 0x0400 file offset: 0x00015400 offset: 0x002e7400 section name: /70 base: 0x0001f000 size: 0x0200 file offset: 0x00015800 offset: 0x002e6800 section name: /81 base: 0x0002 size: 0x0c00 file offset: 0x00015a00 offset: 0x002e5a00 section name: /92 base: 0x00021000 size: 0x0200 file offset: 0x00016600 offset: 0x002e5600 Also, rebase does not seem to touch the debug sections in any
Re: perl-5.14.4
On Feb 16 10:46, Achim Gratz wrote: Corinna Vinschen writes: Back to the drawing board… The section names in rebase are completely different, completely different? -v, please? I gave up in disgust… anyway, instead of the .debug_* section names, rebase finds something like /19. I can't find a way to have objdump use the same format. Objcopy does have an option that hints at some long section names that can be present and I surmise that the debug sections use such names. not sure how I should get objdump to display them. objdump -h? Nope. That tells you: Sections: Idx Name Size VMA LMA File off Algn [...] 10 .debug_aranges 0220 0003e541e000 0003e541e000 6200 2**0 CONTENTS, READONLY, DEBUGGING 11 .debug_info cc86 0003e541f000 0003e541f000 6600 2**0 CONTENTS, READONLY, DEBUGGING 12 .debug_abbrev 0e74 0003e542c000 0003e542c000 00013400 2**0 CONTENTS, READONLY, DEBUGGING 13 .debug_line 0e93 0003e542d000 0003e542d000 00014400 2**0 CONTENTS, READONLY, DEBUGGING 14 .debug_frame 0350 0003e542e000 0003e542e000 00015400 2**3 CONTENTS, READONLY, DEBUGGING 15 .debug_loc0b22 0003e543 0003e543 00015800 2**0 CONTENTS, READONLY, DEBUGGING 16 .debug_ranges 00c0 0003e5431000 0003e5431000 00016400 2**0 CONTENTS, READONLY, DEBUGGING 17 .debug_str01a8 0004 0004 00016600 2**0 CONTENTS, READONLY, DEBUGGING While rebase thinks: Base: 0x0x2f ImageBase: 0x3e266 ImageBase: 0x3e266 ImageSize: 0x22000 [...] section name: /4 base: 0xe000 size: 0x0400 file offset: 0x6200 offset: 0x002e8200 section name: /19 base: 0xf000 size: 0xce00 file offset: 0x6600 offset: 0x002e7600 section name: /31 base: 0x0001c000 size: 0x1000 file offset: 0x00013400 offset: 0x002e7400 section name: /45 base: 0x0001d000 size: 0x1000 file offset: 0x00014400 offset: 0x002e7400 section name: /57 base: 0x0001e000 size: 0x0400 file offset: 0x00015400 offset: 0x002e7400 section name: /70 base: 0x0001f000 size: 0x0200 file offset: 0x00015800 offset: 0x002e6800 section name: /81 base: 0x0002 size: 0x0c00 file offset: 0x00015a00 offset: 0x002e5a00 section name: /92 base: 0x00021000 size: 0x0200 file offset: 0x00016600 offset: 0x002e5600 Uh, ok. These look like decimal offsets into a string table. I'm just not sure where the base (the string table) is. I'll ask a collegue. So it's not about the debug sections, apparently. It was just a guess anyway. It still is about the debug sections… They are still present in the rebased object files, but nm and objdump don't associate the information in them with the code anymore. The same thing already happens when I just change the ImageBase, so it seems that rebase would somehow also have to change something in the debug records, albeit it's entirely unclear what that might be. The only thing I can think of: The debug sections contain pointers to symbols, code, etc. Either these are absolute, which makes them depend on the executable being loaded exactly in the same spot as it were based to when building the executable, or they are relative to a base and the base is stored separately from the VMA. I don't know the internals of the dwarf2 format well enough, so this is just an (un?)educated guess. Again, I'll ask a collegue. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpylTBK9gYgC.pgp Description: PGP signature
Re: perl-5.14.4
Corinna Vinschen writes: Where? rebase.c calls ReBaseImage64, which is a) a Windows function in imagehlp.dll and b) the function name of a function in the imagebase library, implemented in rebaseimage.cc. We're going path b. The core of imagebase's implementation of ReBaseImage64 is the call to LinkedObjectFile::performRelocation (line 123 in imagehelper/rebaseimage.cc), which in turn calls Relocations::relocate in imagehelper/sections.cc. This function performs the actual relocation. OK, I hadn't realized there were two implementations. that doesn't seem to allow individual sections to be skipped. The code you pointed at seems just to be checking if any sections need additional fixups. Well, it's the code doing the actual relocation. The outer for-loop jumps from relocation block to relocation block. Line 391 Section *cursec = sections-find(va); computes the actual section the relocation block is pointing to. Then it checks if it points to a valid section and if not it bails out. Otherwise it loops over the relocation entries in the block and performas the actual relocation. The idea is to add something along the lines of if (cursec !strncmp (cursec-getName (), .debug_, 7)) continue; I'll try later. Let's see what happens. 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
Re: perl-5.14.4
Corinna Vinschen writes: We're going path b. The core of imagebase's implementation of ReBaseImage64 is the call to LinkedObjectFile::performRelocation (line 123 in imagehelper/rebaseimage.cc), which in turn calls Relocations::relocate in imagehelper/sections.cc. This function performs the actual relocation. Back to the drawing board… The section names in rebase are completely different, not sure how I should get objdump to display them. Also, rebase does not seem to touch the debug sections in any way (either it does not recognize them or already ignores them). The apparent changes that I saw in objdump are purely the result of rebase changing the ImageBase. :-( Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Wavetables for the Terratec KOMPLEXER: http://Synth.Stromeko.net/Downloads.html#KomplexerWaves
Re: perl-5.14.4
On Feb 14 22:12, Achim Gratz wrote: Achim Gratz writes: Achim Gratz writes: It turns out that doing so damages the debug information in the library and then it can't be extracted later, so I'll have to skip this step when building with cygport. I have no idea how and why this happens; the debug information is still there, but quite obviously it can't be correctly associated with the code after rebasing. Is that something that can be fixed in rebase or objcopy? Specifically, running nm -l does not output the source files and line numbers any more. The entries are still in the object file, but the association with the symbols has been lost. Looking at the DWARF dump it seems that the .debug_str section has been relocated in the rebased image. If any body knows how to inject this section from the original DLL into the rebased image I could test if the debug information would show up again, objcopy might be able to do that, but the pe/coff format is fiddly. but I think that this section should not be rebased. Provided that this *is* the problem, this should be easily doable in rebase. The core is a function Relocations::relocate in imagehelper/sections.cc. At one point in the loop it calls Section *cursec = sections-find(va); At this point it should be possible to check against the section name and filter out all sections starting with .debug_ Care to try? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpQav96AujBv.pgp Description: PGP signature
Re: perl-5.14.4
Achim Gratz writes: It turns out that doing so damages the debug information in the library and then it can't be extracted later, so I'll have to skip this step when building with cygport. I have no idea how and why this happens; the debug information is still there, but quite obviously it can't be correctly associated with the code after rebasing. Is that something that can be fixed in rebase or objcopy? Specifically, running nm -l does not output the source files and line numbers any more. The entries are still in the object file, but the association with the symbols has been lost. 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
Re: perl-5.14.4
Achim Gratz writes: Achim Gratz writes: It turns out that doing so damages the debug information in the library and then it can't be extracted later, so I'll have to skip this step when building with cygport. I have no idea how and why this happens; the debug information is still there, but quite obviously it can't be correctly associated with the code after rebasing. Is that something that can be fixed in rebase or objcopy? Specifically, running nm -l does not output the source files and line numbers any more. The entries are still in the object file, but the association with the symbols has been lost. Looking at the DWARF dump it seems that the .debug_str section has been relocated in the rebased image. If any body knows how to inject this section from the original DLL into the rebased image I could test if the debug information would show up again, but I think that this section should not be rebased. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ SD adaptation for Waldorf Blofeld V1.15B11: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: perl-5.14.4
David Stacey writes: In readiness for the new perl test package, I've removed the test version of perl-Text-CSV_XS that was linked against perl-5.18.2. Thanks. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada
Re: perl-5.14.4
On 04/02/15 20:41, Achim Gratz wrote: If this sounds like a good idea to everybody else I'd remove the current test package for 5.18.4 on 32bit and replace it with another test package for 5.14.4, likely in about two weeks. In readiness for the new perl test package, I've removed the test version of perl-Text-CSV_XS that was linked against perl-5.18.2. Dave.
Re: perl-5.14.4
Achim Gratz writes:
If this sounds like a good idea to everybody else I'd remove the current
test package for 5.18.4 on 32bit and replace it with another test
package for 5.14.4, likely in about two weeks. Comments or suggestions?
While I have to do some more polishing of the cygport file and patches,
I've just tested that the builds actually work as drop-in replacements
for the current perl in Cygwin. All existing perl modules should work
with the new version. I have successfully built and tested a dozen or
so modules with the help of the existing modules, both with and without
XS. I'll be away for the rest of the week, but if anybody wants to try
the new packages out before they hit the mirrors some time next week,
please run
setup-{x86,x86_64}.exe -XOs http://cygwin.stromeko.net/
to install/update the test packages perl, perl_base, perl_manpages,
perl_pods and perl-debuginfo as appropriate (they should all be at
version 5.14.4-2). Leave perl_vendor on 32bit alone for now, I'll take
care of the unbundling later.
Regards,
Achim.
--
+[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+
SD adaptation for Waldorf microQ V2.22R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: perl-5.14.4
Corinna Vinschen writes: Would you mind to discuss your problem on the binutils mailing list? Hopefully they know if there's a way which preserves the info so that GDB doesn't fish in muddy waters. Looking at the traffic of the past few weeks on that list (consisting mostly of patches) I'm not sure it is the right venue… Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: perl-5.14.4
Corinna Vinschen writes: I think it's important to keep the information in sync while building the packages. A later rebase will break the connection between debug symbols and runtime symbols as well, obviously. Obviously? I have no indication that the debug information is damaged once it's been stripped off into a separate file. Which may be a hint on what rebase might do wrong. Maybe we should think of rebasing the actual binaries as well as their debugging counterparts to keep everything in sync, but that's a bit much effort... I may not understand what is really going on, but the way I see it, rebase does exactly that while the debug information is still part of the object file. It seems to do something extra or wrong, since objcopy will the not be able to copy out that information. Looking with objdump reveals the section is still there ans has contents, but it doesn't get associated with the code in the correct manner anymore. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ SD adaptation for Waldorf Blofeld V1.15B11: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: perl-5.14.4
On Feb 9 18:15, Achim Gratz wrote: Corinna Vinschen writes: I think it's important to keep the information in sync while building the packages. A later rebase will break the connection between debug symbols and runtime symbols as well, obviously. Obviously? I have no indication that the debug information is damaged once it's been stripped off into a separate file. Which may be a hint on what rebase might do wrong. What I mean is this. If the debug info file does not refer to the same addresses than the file in memory, then GDB doesn't resolve the symbols correctly. Maybe we should think of rebasing the actual binaries as well as their debugging counterparts to keep everything in sync, but that's a bit much effort... I may not understand what is really going on, but the way I see it, rebase does exactly that while the debug information is still part of the object file. It seems to do something extra or wrong, since objcopy will the not be able to copy out that information. Looking with objdump reveals the section is still there ans has contents, but it doesn't get associated with the code in the correct manner anymore. I'm not an expert on this stuff either, so I can just assume that the rebasing doesn't catch the debug info and that the debug info then points into nirvana. I also don't know if there's a way around that. Would you mind to discuss your problem on the binutils mailing list? Hopefully they know if there's a way which preserves the info so that GDB doesn't fish in muddy waters. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpMcETjX_k5i.pgp Description: PGP signature
Re: perl-5.14.4
On Feb 8 21:19, Achim Gratz wrote: Achim Gratz writes: Major progress: the cygport file starts to look sane. I've ripped out the rebase changes in EU::MM and replaced them with an oblivious rebase, which is the first time I could compile and test on 32bit without manual intervention. It turns out that doing so damages the debug information in the library and then it can't be extracted later, so I'll have to skip this step when building with cygport. I have no idea how and why this happens; the debug information is still there, but quite obviously it can't be correctly associated with the code after rebasing. Is that something that can be fixed in rebase or objcopy? I think it's important to keep the information in sync while building the packages. A later rebase will break the connection between debug symbols and runtime symbols as well, obviously. Maybe we should think of rebasing the actual binaries as well as their debugging counterparts to keep everything in sync, but that's a bit much effort... Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpSRZGzeCgPA.pgp Description: PGP signature
Re: perl-5.14.4
Achim Gratz writes: Major progress: the cygport file starts to look sane. I've ripped out the rebase changes in EU::MM and replaced them with an oblivious rebase, which is the first time I could compile and test on 32bit without manual intervention. It turns out that doing so damages the debug information in the library and then it can't be extracted later, so I'll have to skip this step when building with cygport. I have no idea how and why this happens; the debug information is still there, but quite obviously it can't be correctly associated with the code after rebasing. Is that something that can be fixed in rebase or objcopy? Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra
Re: perl-5.14.4
Achim Gratz writes: If this sounds like a good idea to everybody else I'd remove the current test package for 5.18.4 on 32bit and replace it with another test package for 5.14.4, likely in about two weeks. Major progress: the cygport file starts to look sane. I've ripped out the rebase changes in EU::MM and replaced them with an oblivious rebase, which is the first time I could compile and test on 32bit without manual intervention. That might even be acceptable upstream… and it's small enough to carry it forward for a while. I also grabbed a change from Yaakov to not fix the base address of the perl DLL so that cygport doesn't complain about not having used auto-image-base anymore. Cygport still complains about a site_perl instance that it fixes to vendor_perl during install. Unless anybody knows what this is about I'll have to investigate that cygport isn't trying to be too clever here. I also have to clean up the patches some more, especially those dealing with documentation. But all in all it looks like things are pretty much on track for a test release in about two weeks at the moment. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: perl-5.14.4
Reini Urban writes: Which SHA1? In the filenames of my patches? Yes. Probably old rebased away commits in rurban/perl.git branch cygwin, sorry. Do you need them? OK, that would explain things. I guess I can still find them by the title... Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: perl-5.14.4
Reini Urban writes: I expect them to be compatible, but I haven't tested that assumption yet. You need to keep the useint* and usemymalloc settings from 5.14.2, then it should be ok. I'll check again but I don't think these have been altered for 5.14.4. For the new 5.22 one you need to disable usemymalloc and remove the _0/.0 suffix in the dll and archname directory name to provide seemless upgrades to 5.22.1 and 5.22.2 I'll get to that later, but I expect that eercise to be roughly the same as what we have to do now? Or has the build system changed that much? later, to fix the .0 bugs. Typically a .0 perl release is of very poor quality. I'll only put the .0 out for testing, the first non-test release will likely be .1 -- but let's see what happens. In any case this is why I wanted to have a solid 5.14.4 base in case it takes a while for things to get in order. 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
Re: perl-5.14.4
On Feb 4 21:41, Achim Gratz wrote: As I said in another thread I intend to skip directly to version 5.22 shortly after it becomes available in May (assuming the release schedule is still holds). While looking into some of the test fails on 5.18.4 I've moved back to 5.14.4 for comparison (the fail turned out to be a combination of new optimizations in gcc-4.9 and undefined behaviour in Perl code). The fix in this case was to add a compiler flag (-fwrapv) that disables those optimizations and I'm now back to having roughly the same test fails as the old 5.14.2 from Reini: Failed 9 tests out of 2048, 99.56% okay. ../cpan/Win32/t/GetShortPathName.t -- returns a long path name when called from mintty ../cpan/Win32/t/Names.t -- this old version of Win32 does not know about Windows 8.1 ../cpan/Win32/t/Unicode.t -- ANSI path functions do not return the expected results ../dist/Net-Ping/t/510_ping_udp.t -- same as 5.14.2 ../ext/XS-APItest/t/call_checker.t -- same as 5.14.2 ../lib/File/stat.t -- works if test is not run as Administrator (but then other tests fail) op/filetest.t -- works if test is not run as Administrator (but then other tests fail) porting/exec-bit.t -- global.sym has exec bit set, but not registered as such porting/regen.t -- also something to do with global.sym I'll probably keep the Win32 and other bundled CPAN modules as released with 5.14 and provide the latest versions as unbundled perl-* packages so that Module::CoreList doesn't lie to the user. So, it looks like I'm ready to bring Perl on both 32bit and 64bit to the same (final 5.14.4) version plus I can already do the packaging changes planned for the 5.22 release (dissolution of perl_vendor and creation of perl_base as a minimal install variant) for both architectures. I hope that this would enable a much smoother transition when that version gets released since the dependencies of those packages relying on Perl should be fixable until then. If this sounds like a good idea to everybody else I'd remove the current test package for 5.18.4 on 32bit and replace it with another test package for 5.14.4, likely in about two weeks. Comments or suggestions? Sounds perfect to me. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpT02KLk2Wzy.pgp Description: PGP signature
Re: perl-5.14.4
BTW, does anyone know what repository the SHA1 in the patch files refer to? One of them is in the official perl.git, but the rest I cannot find in either rurban/perl.git nor the Cygports repository. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ SD adaptation for Waldorf microQ V2.22R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: perl-5.14.4
On 02/05/2015 05:13 PM, Achim Gratz wrote: BTW, does anyone know what repository the SHA1 in the patch files refer to? One of them is in the official perl.git, but the rest I cannot find in either rurban/perl.git nor the Cygports repository. Regards, Achim. Which SHA1? In the filenames of my patches? Probably old rebased away commits in rurban/perl.git branch cygwin, sorry. Do you need them?
Re: perl-5.14.4
On 02/04/2015 11:10 PM, Achim Gratz wrote: David Stacey writes: On 04/02/15 20:41, Achim Gratz wrote: If this sounds like a good idea to everybody else I'd remove the current test package for 5.18.4 on 32bit and replace it with another test package for 5.14.4, likely in about two weeks. Comments or suggestions? Do you expect the XS modules built against 5.14.2 to be compatible with 5.14.4, or would you like them rebuilt? I expect them to be compatible, but I haven't tested that assumption yet. You need to keep the useint* and usemymalloc settings from 5.14.2, then it should be ok. For the new 5.22 one you need to disable usemymalloc and remove the _0/.0 suffix in the dll and archname directory name to provide seemless upgrades to 5.22.1 and 5.22.2 later, to fix the .0 bugs. Typically a .0 perl release is of very poor quality. The plan sounds good.
Re: perl-5.14.4
David Stacey writes: On 04/02/15 20:41, Achim Gratz wrote: If this sounds like a good idea to everybody else I'd remove the current test package for 5.18.4 on 32bit and replace it with another test package for 5.14.4, likely in about two weeks. Comments or suggestions? Do you expect the XS modules built against 5.14.2 to be compatible with 5.14.4, or would you like them rebuilt? I expect them to be compatible, but I haven't tested that assumption yet. 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
perl-5.14.4
As I said in another thread I intend to skip directly to version 5.22 shortly after it becomes available in May (assuming the release schedule is still holds). While looking into some of the test fails on 5.18.4 I've moved back to 5.14.4 for comparison (the fail turned out to be a combination of new optimizations in gcc-4.9 and undefined behaviour in Perl code). The fix in this case was to add a compiler flag (-fwrapv) that disables those optimizations and I'm now back to having roughly the same test fails as the old 5.14.2 from Reini: Failed 9 tests out of 2048, 99.56% okay. ../cpan/Win32/t/GetShortPathName.t -- returns a long path name when called from mintty ../cpan/Win32/t/Names.t -- this old version of Win32 does not know about Windows 8.1 ../cpan/Win32/t/Unicode.t -- ANSI path functions do not return the expected results ../dist/Net-Ping/t/510_ping_udp.t -- same as 5.14.2 ../ext/XS-APItest/t/call_checker.t -- same as 5.14.2 ../lib/File/stat.t -- works if test is not run as Administrator (but then other tests fail) op/filetest.t -- works if test is not run as Administrator (but then other tests fail) porting/exec-bit.t -- global.sym has exec bit set, but not registered as such porting/regen.t -- also something to do with global.sym I'll probably keep the Win32 and other bundled CPAN modules as released with 5.14 and provide the latest versions as unbundled perl-* packages so that Module::CoreList doesn't lie to the user. So, it looks like I'm ready to bring Perl on both 32bit and 64bit to the same (final 5.14.4) version plus I can already do the packaging changes planned for the 5.22 release (dissolution of perl_vendor and creation of perl_base as a minimal install variant) for both architectures. I hope that this would enable a much smoother transition when that version gets released since the dependencies of those packages relying on Perl should be fixable until then. If this sounds like a good idea to everybody else I'd remove the current test package for 5.18.4 on 32bit and replace it with another test package for 5.14.4, likely in about two weeks. Comments or suggestions? Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Wavetables for the Terratec KOMPLEXER: http://Synth.Stromeko.net/Downloads.html#KomplexerWaves
Re: perl-5.14.4
On 04/02/15 20:41, Achim Gratz wrote: If this sounds like a good idea to everybody else I'd remove the current test package for 5.18.4 on 32bit and replace it with another test package for 5.14.4, likely in about two weeks. Comments or suggestions? Do you expect the XS modules built against 5.14.2 to be compatible with 5.14.4, or would you like them rebuilt? Dave.
