Re: perl-5.14.4

[Corinna Vinschen <corinna-cygwin at cygwin dot com>]

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: pgpqzue00Mzwp.pgp
Description: PGP signature