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/c
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 cor
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 cygpo
Corinna Vinschen writes:
> FYI: https://sourceware.org/bugzilla/show_bug.cgi?id=18025
Thanks for driving that to a solution.
> 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.
OK, but since
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 c
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 compla
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 opportun
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 g
On Feb 16 11:25, Corinna Vinschen wrote:
> On Feb 16 10:46, Achim Gratz wrote:
> > 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 whe
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
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
On Feb 15 20:14, Achim Gratz wrote:
> 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 image
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
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
> ReBaseImage
On Feb 15 14:18, Achim Gratz wrote:
> Corinna Vinschen writes:
> > objcopy might be able to do that, but the pe/coff format is fiddly.
>
> Well, the problem is that I can't set the section address back to what
> it was since the interpretation of the numbers on the command line seems
> to be limit
Corinna Vinschen writes:
> objcopy might be able to do that, but the pe/coff format is fiddly.
Well, the problem is that I can't set the section address back to what
it was since the interpretation of the numbers on the command line seems
to be limited somehow. So instead of 0x56628f000 I end up
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
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 the
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
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-80
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
vers
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 a
On Feb 9 20:41, Achim Gratz wrote:
> 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 o
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 n
On Feb 9 19:49, Corinna Vinschen wrote:
> 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 we
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 indicatio
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'
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
> > interven
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
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 chan
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
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
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 w
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 filena
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 ada
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 comparis
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
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.
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
39 matches
Mail list logo
