perl-5.14.4

perl-5.14.4

[Achim Gratz]

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

[David Stacey]

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.

Re: perl-5.14.4

[Achim Gratz]

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

Re: perl-5.14.4

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2598 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: perl-5.14.4

[Achim Gratz]

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

[Reini Urban]

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

[Reini Urban]

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

[Achim Gratz]

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

[Achim Gratz]

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

[Achim Gratz]

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

[Achim Gratz]

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

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1237 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: perl-5.14.4

[Achim Gratz]

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

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1781 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: perl-5.14.4

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2123 bytes --]

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 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.

Also, is it possible that we have relocation types in the file which
are not handled by rebase?  I just had a quick look into the sources
and there's a type IMAGE_REL_BASED_ABSOLUTE which is skipped.  Or,
what if e.g. the expression

  *patch_adr += difference;

in imagehelper/sections.cc is mistreated because of a missing gcc
-fwrapv option on the command line?

There might be quite a few problems lurking here...


Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: perl-5.14.4

[Achim Gratz]

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]

[-- Attachment #1: Type: text/plain, Size: 636 bytes --]

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 on that list (consisting
> mostly of patches) I'm not sure it is the right venue…

It is.  Where else?  Those are the guys deep inside the object file
formats...


Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: perl-5.14.4

[Achim Gratz]

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

[David Stacey]

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]

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

[Achim Gratz]

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]

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

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1658 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: perl-5.14.4

[Achim Gratz]

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 with an
adress of 0x46628f000 and no amount of fiddling gets it any larger.  If
I try with an address of -1 then the resulting section address is
0x3ffffffff.  The info manual is close to useless and doesn't even try
to talk about how one is supposed to specify larger numbers ("L", "LL"
and "ULL" suffixes don't work, I've tried that).

>> 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_"

I don't see how, but maybe I'm not looking at it right.  The rebasing is
done by some windows function AFICS 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.


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]

[-- Attachment #1: Type: text/plain, Size: 2646 bytes --]

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 limited somehow.  So instead of 0x56628f000 I end up with an
> adress of 0x46628f000 and no amount of fiddling gets it any larger.  If
> I try with an address of -1 then the resulting section address is
> 0x3ffffffff.  The info manual is close to useless and doesn't even try
> to talk about how one is supposed to specify larger numbers ("L", "LL"
> and "ULL" suffixes don't work, I've tried that).
> 
> >> 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_"
> 
> I don't see how, but maybe I'm not looking at it right.  The rebasing is
> done by some windows function AFICS

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.

> 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;


Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: perl-5.14.4

[Achim Gratz]

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

[Achim Gratz]

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

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1077 bytes --]

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 imagehelper/sections.cc.  This function
> > performs the actual relocation.
> 
> Back to the drawing board…  The section names in rebase are completely
> different,

"completely different"?  -v, please?

> not sure how I should get objdump to display them.

objdump -h?

> 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.  :-(

So it's not about the debug sections, apparently.  It was just a guess
anyway.


Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: perl-5.14.4

[Achim Gratz]

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         00000b98  00000003e5411000  00000003e5411000  00000600  2**4
                  CONTENTS, ALLOC, LOAD, READONLY, CODE, DATA
  1 .data         00000068  00000003e5412000  00000003e5412000  00001200  2**5
                  CONTENTS, ALLOC, LOAD, DATA
  2 .rdata        00003800  00000003e5413000  00000003e5413000  00001400  2**6
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  3 .buildid      00000035  00000003e5417000  00000003e5417000  00004c00  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  4 .pdata        000000cc  00000003e5418000  00000003e5418000  00004e00  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  5 .xdata        0000008c  00000003e5419000  00000003e5419000  00005000  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  6 .bss          000001d0  00000003e541a000  00000003e541a000  00000000  2**5
                  ALLOC
  7 .edata        0000012b  00000003e541b000  00000003e541b000  00005200  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  8 .idata        000004fc  00000003e541c000  00000003e541c000  00005400  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  9 .reloc        000006b4  00000003e541d000  00000003e541d000  00005a00  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
 10 .debug_aranges 00000220  00000003e541e000  00000003e541e000  00006200  2**0
                  CONTENTS, READONLY, DEBUGGING
 11 .debug_info   0000cc86  00000003e541f000  00000003e541f000  00006600  2**0
                  CONTENTS, READONLY, DEBUGGING
 12 .debug_abbrev 00000e74  00000003e542c000  00000003e542c000  00013400  2**0
                  CONTENTS, READONLY, DEBUGGING
 13 .debug_line   00000e93  00000003e542d000  00000003e542d000  00014400  2**0
                  CONTENTS, READONLY, DEBUGGING
 14 .debug_frame  00000350  00000003e542e000  00000003e542e000  00015400  2**3
                  CONTENTS, READONLY, DEBUGGING
 15 .debug_loc    00000b22  00000003e5430000  00000003e5430000  00015800  2**0
                  CONTENTS, READONLY, DEBUGGING
 16 .debug_ranges 000000c0  00000003e5431000  00000003e5431000  00016400  2**0
                  CONTENTS, READONLY, DEBUGGING
 17 .debug_str    000001a8  0000000400000000  0000000400000000  00016600  2**0
                  CONTENTS, READONLY, DEBUGGING

While rebase thinks:

Base:       0x0x2f0000
ImageBase:  0x3e2660000
ImageBase: 0x3e2660000 ImageSize: 0x22000
   section name:    .text base: 0x00001000 size: 0x00000c00 file offset: 0x00000600 offset: 0x002ef600
   section name:    .data base: 0x00002000 size: 0x00000200 file offset: 0x00001200 offset: 0x002ef200
   section name:   .rdata base: 0x00003000 size: 0x00003800 file offset: 0x00001400 offset: 0x002ee400
   section name: .buildid base: 0x00007000 size: 0x00000200 file offset: 0x00004c00 offset: 0x002edc00
   section name:   .pdata base: 0x00008000 size: 0x00000200 file offset: 0x00004e00 offset: 0x002ece00
   section name:   .xdata base: 0x00009000 size: 0x00000200 file offset: 0x00005000 offset: 0x002ec000
   section name:     .bss base: 0x0000a000 size: 0x00000000 file offset: 0x00000000 offset: 0x002e6000
   section name:   .edata base: 0x0000b000 size: 0x00000200 file offset: 0x00005200 offset: 0x002ea200
   section name:   .idata base: 0x0000c000 size: 0x00000600 file offset: 0x00005400 offset: 0x002e9400
   section name:   .reloc base: 0x0000d000 size: 0x00000800 file offset: 0x00005a00 offset: 0x002e8a00
   section name:       /4 base: 0x0000e000 size: 0x00000400 file offset: 0x00006200 offset: 0x002e8200
   section name:      /19 base: 0x0000f000 size: 0x0000ce00 file offset: 0x00006600 offset: 0x002e7600
   section name:      /31 base: 0x0001c000 size: 0x00001000 file offset: 0x00013400 offset: 0x002e7400
   section name:      /45 base: 0x0001d000 size: 0x00001000 file offset: 0x00014400 offset: 0x002e7400
   section name:      /57 base: 0x0001e000 size: 0x00000400 file offset: 0x00015400 offset: 0x002e7400
   section name:      /70 base: 0x0001f000 size: 0x00000200 file offset: 0x00015800 offset: 0x002e6800
   section name:      /81 base: 0x00020000 size: 0x00000c00 file offset: 0x00015a00 offset: 0x002e5a00
   section name:      /92 base: 0x00021000 size: 0x00000200 file offset: 0x00016600 offset: 0x002e5600

>> 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.  :-(
>
> 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.


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]

[-- Attachment #1: Type: text/plain, Size: 4076 bytes --]

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 00000220  00000003e541e000  00000003e541e000  00006200  2**0
>                   CONTENTS, READONLY, DEBUGGING
>  11 .debug_info   0000cc86  00000003e541f000  00000003e541f000  00006600  2**0
>                   CONTENTS, READONLY, DEBUGGING
>  12 .debug_abbrev 00000e74  00000003e542c000  00000003e542c000  00013400  2**0
>                   CONTENTS, READONLY, DEBUGGING
>  13 .debug_line   00000e93  00000003e542d000  00000003e542d000  00014400  2**0
>                   CONTENTS, READONLY, DEBUGGING
>  14 .debug_frame  00000350  00000003e542e000  00000003e542e000  00015400  2**3
>                   CONTENTS, READONLY, DEBUGGING
>  15 .debug_loc    00000b22  00000003e5430000  00000003e5430000  00015800  2**0
>                   CONTENTS, READONLY, DEBUGGING
>  16 .debug_ranges 000000c0  00000003e5431000  00000003e5431000  00016400  2**0
>                   CONTENTS, READONLY, DEBUGGING
>  17 .debug_str    000001a8  0000000400000000  0000000400000000  00016600  2**0
>                   CONTENTS, READONLY, DEBUGGING
> 
> While rebase thinks:
> 
> Base:       0x0x2f0000
> ImageBase:  0x3e2660000
> ImageBase: 0x3e2660000 ImageSize: 0x22000
> [...]
>    section name:       /4 base: 0x0000e000 size: 0x00000400 file offset: 0x00006200 offset: 0x002e8200
>    section name:      /19 base: 0x0000f000 size: 0x0000ce00 file offset: 0x00006600 offset: 0x002e7600
>    section name:      /31 base: 0x0001c000 size: 0x00001000 file offset: 0x00013400 offset: 0x002e7400
>    section name:      /45 base: 0x0001d000 size: 0x00001000 file offset: 0x00014400 offset: 0x002e7400
>    section name:      /57 base: 0x0001e000 size: 0x00000400 file offset: 0x00015400 offset: 0x002e7400
>    section name:      /70 base: 0x0001f000 size: 0x00000200 file offset: 0x00015800 offset: 0x002e6800
>    section name:      /81 base: 0x00020000 size: 0x00000c00 file offset: 0x00015a00 offset: 0x002e5a00
>    section name:      /92 base: 0x00021000 size: 0x00000200 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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: perl-5.14.4

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2019 bytes --]

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 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.

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.

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?

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.

If the /usr/lib/debug/usr/bin/foo.dll.dbg file is rebased to the same
address as /usr/bin/foo.dll, shouldn't that "fix" the issue?

If that's really the issue, I'm wondering if that can be fixed or
worked around in GDB.  If that's too much hassle, we should probably
start rebasing the debug info in /usr/lib/debug as well.  That
only requires some small hacking of rebase.


Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: perl-5.14.4

[Achim Gratz]

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  00000003ed741000  00000003ed741000  00000400  2**4
                  CONTENTS, ALLOC, LOAD, READONLY, CODE, DATA
  1 .data         00003028  00000003ed88d000  00000003ed88d000  0014b800  2**6
                  CONTENTS, ALLOC, LOAD, DATA
  2 .rdata        00021a24  00000003ed891000  00000003ed891000  0014ea00  2**6
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  3 .buildid      00000035  00000003ed8b3000  00000003ed8b3000  00170600  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  4 .pdata        00005364  00000003ed8b4000  00000003ed8b4000  00170800  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  5 .xdata        000064c0  00000003ed8ba000  00000003ed8ba000  00175c00  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  6 .bss          000002b0  00000003ed8c1000  00000003ed8c1000  00000000  2**6
                  ALLOC
  7 .edata        0000b3e9  00000003ed8c2000  00000003ed8c2000  0017c200  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  8 .idata        00002008  00000003ed8ce000  00000003ed8ce000  00187600  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  9 .reloc        00001464  00000003ed8d1000  00000003ed8d1000  00189800  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
 10 .gnu_debuglink 00000018  00000003ed8d3000  00000003ed8d3000  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  00000004d1891000  00000004d1891000  00000000  2**4
                  ALLOC, LOAD, READONLY, CODE, DATA
  1 .data         00003028  00000004d19dd000  00000004d19dd000  00000000  2**6
                  ALLOC, LOAD, DATA
  2 .rdata        00021a24  00000004d19e1000  00000004d19e1000  00000000  2**6
                  ALLOC, LOAD, READONLY, DATA
  3 .buildid      00000035  00000004d1a03000  00000004d1a03000  00000600  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  4 .pdata        00005364  00000004d1a04000  00000004d1a04000  00000000  2**2
                  ALLOC, LOAD, READONLY, DATA
  5 .xdata        000064c0  00000004d1a0a000  00000004d1a0a000  00000000  2**2
                  ALLOC, LOAD, READONLY, DATA
  6 .bss          000002b0  00000004d1a11000  00000004d1a11000  00000000  2**6
                  ALLOC
  7 .edata        0000b3e9  00000004d1a12000  00000004d1a12000  00000000  2**2
                  ALLOC, LOAD, READONLY, DATA
  8 .idata        00002008  00000004d1a1e000  00000004d1a1e000  00000000  2**2
                  ALLOC, LOAD, DATA
  9 .reloc        00001464  00000004d1a21000  00000004d1a21000  00000000  2**2
                  ALLOC, LOAD, READONLY, DATA
 10 .debug_aranges 000009b0  00000004d1a23000  00000004d1a23000  00000800  2**4
                  CONTENTS, READONLY, DEBUGGING
 11 .debug_info   00261e08  00000004d1a24000  00000004d1a24000  00001200  2**0
                  CONTENTS, READONLY, DEBUGGING
 12 .debug_abbrev 0000ddc9  00000004d1c86000  00000004d1c86000  00263200  2**0
                  CONTENTS, READONLY, DEBUGGING
 13 .debug_line   0004ed6e  00000004d1c94000  00000004d1c94000  00271000  2**0
                  CONTENTS, READONLY, DEBUGGING
 14 .debug_frame  00022378  00000004d1ce3000  00000004d1ce3000  002bfe00  2**3
                  CONTENTS, READONLY, DEBUGGING
 15 .debug_str    00004ebb  00000004d1d06000  00000004d1d06000  002e2200  2**0
                  CONTENTS, READONLY, DEBUGGING
 16 .debug_loc    00289775  00000004d1d0b000  00000004d1d0b000  002e7200  2**0
                  CONTENTS, READONLY, DEBUGGING
 17 .debug_ranges 000568b0  00000004d1f95000  00000004d1f95000  00570a00  2**0
                  CONTENTS, READONLY, DEBUGGING
 18 .gnu_debuglink 0000000c  00000004d1fec000  00000004d1fec000  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 changes the image base.

> If the /usr/lib/debug/usr/bin/foo.dll.dbg file is rebased to the same
> address as /usr/bin/foo.dll, shouldn't that "fix" the issue?

I would rather suspect it produces exactly the same problem it does with
the full DLL.

> If that's really the issue, I'm wondering if that can be fixed or
> worked around in GDB.  If that's too much hassle, we should probably
> start rebasing the debug info in /usr/lib/debug as well.  That
> only requires some small hacking of rebase.

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.  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).


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]

[-- Attachment #1: Type: text/plain, Size: 3411 bytes --]

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}'
  00000003fd3b1000
  $ objdump -h /usr/lib/debug/usr/bin/cygattr-1.dll.dbg | awk '/text/{print $4}'
  0000000586301000

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, 0x0000000100401120 in attr_list ()
  (gdb)
  Continuing.

  Breakpoint 2, 0x00000003fd3b16f9 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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: perl-5.14.4

[Achim Gratz]

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]

[-- Attachment #1: Type: text/plain, Size: 1433 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: perl-5.14.4

[Achim Gratz]

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 the workaround is confined to EUMM and I'm going to
release an updated standalone version when unbundling perl_vendor this
will not need to hold up the promotion of perl from test to current.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: perl-5.14.4

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1633 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: perl-5.14.4

[Achim Gratz]

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

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 564 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]