RE: [RFC] Add support for printing pdata for x86_64 pe coff objects

["Pierre Muller" <pierre dot muller at ics-cnrs dot unistra dot fr>]

> -----Message d'origine-----
> De : binutils-owner@sourceware.org [mailto:binutils-
> owner@sourceware.org] De la part de Andreas Schwab
> Envoyé : mercredi 24 décembre 2014 12:24
> À : Pierre Muller
> Cc : 'Nicholas Clifton'; binutils@sourceware.org
> Objet : Re: [RFC] Add support for printing pdata for x86_64 pe coff
> objects
> 
> "Pierre Muller" <pierre.muller@ics-cnrs.unistra.fr> writes:
> 
> > The missing newline, is explained by the comment below:
> >
> > 2719      /* ctime implies '\n'.  */
> > 2720      {
> > 2721        time_t t = pe->coff.timestamp;
> > 2722        fprintf (file, "\nTime/Date\t\t%s", ctime (&t));
> > 2723      }
> > 2724
> > but I don't know why t returns "(null)"
> 
> ctime(&t) returned NULL.
> 
> > (gdb) ptyp t
> > type = long long
> > (gdb) p /x t
> > $4 = 0xffffffff806f8040
> >
> > Is this some magical number?
> 
> What happens if you clear the top 32 bits?

 It does help indeed...
The problemis that too much code assumes that sizeof(long) == sizeof (long
long)
which is wrong for mingw64-w64-mingw32.

Nevertheless, I still don't get the same result.

Breakpoint 2, _bfd_pex64_print_private_bfd_data_common (abfd=0x1ac2eb0,
    vfile=0x7fefe152ab0 <msvcrt!_iob+48>) at pex64igen.c:2722
2722        fprintf (file, "\nTime/Date\t\t%s", ctime (&t));
(gdb) disab 1
(gdb) set var t = t & 0xffffffff
(gdb) call ctime (&t)
$3 = 28106384
(gdb) x /s $
0x1acde90:      "Tue Apr 13 18:02:56 2038\n"
(instead of getting 0, which explains the (null) output.

Pierre@E6510-Muller cygwin-32 ~/git/build/binu-gdb-mingw64/binutils
$ x86_64-w64-mingw32-objdump.exe -p ./objdump.exe | grep Time
Time/Date               Sat Mar  8 10:44:01 1902

  pecoff_v83.docx seems to indicate that this field is a
4-byte field indicating the low 32-bit part of number of seconds 
  since January 1. 1970.
  In the view of this information, it seems clear that
this number is treated as a negative number (1902 is 68 years before 1970),
while it now treated as a positive number (2038 is 68 years after 1970).

  But in fact, none of those two values are correct...
Is this due to the fact that the linker does not set this field?

Pierre