This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [Patch] XCOFF: add objdump -P ldinfo
- From: Tristan Gingold <gingold at adacore dot com>
- To: Richard Sandiford <rsandifo at linux dot vnet dot ibm dot com>
- Cc: "binutils\ at sourceware dot org Development" <binutils at sourceware dot org>
- Date: Wed, 10 Jul 2013 10:26:48 +0200
- Subject: Re: [Patch] XCOFF: add objdump -P ldinfo
- References: <3D1C5A9D-D79E-4342-9B72-CF36BDC5E5A3 at adacore dot com> <87fvvnn4n2 dot fsf at sandifor-thinkpad dot stglab dot manchester dot uk dot ibm dot com>
On Jul 9, 2013, at 5:18 PM, Richard Sandiford wrote:
> Tristan Gingold <gingold@adacore.com> writes:
>> include/coff/
>> 2013-07-09 Tristan Gingold <gingold@adacore.com>
>>
>> * rs6000.h (external_core_dumpx): New structure.
>> (external_ld_info32): Ditto.
>>
>>
>> binutils/
>> 2013-07-09 Tristan Gingold <gingold@adacore.com>
>>
>> * rs6000.h (external_core_dumpx): New structure.
>> (external_ld_info32): Ditto.
>
> Second changelog entry needs updating :-)
Yes, cut-and-past error
>> @@ -85,6 +87,7 @@ For XCOFF files:\n\
>> typchk Display type-check section\n\
>> traceback Display traceback tags\n\
>> toc Display toc symbols\n\
>> + ldinfo Display loader info in core files\n\
>> "));
>> }
>
> This should be added to the list in doc/binutils.texi.
Sure.
>> +/* Handle an AIX dumpx core file. */
>> +
>> +static void
>> +dump_dumpx_core (bfd *abfd, struct external_core_dumpx *hdr)
>> +{
>> + if (options[OPT_FILE_HEADER].selected)
>> + {
>> + printf (" signal: %u\n", bfd_h_get_8 (abfd, hdr->c_signo));
>> + printf (" flags: 0x%02x\n", bfd_h_get_8 (abfd, hdr->c_flag));
>> + printf (" entries: %u\n",
>> + (unsigned) bfd_h_get_16 (abfd, hdr->c_entries));
>> +#ifdef BFD64
>> + printf (" fdsinfox: offset: 0x%08" BFD_VMA_FMT "x\n",
>> + bfd_h_get_64 (abfd, hdr->c_fdsinfox));
>> + printf (" loader: offset: 0x%08" BFD_VMA_FMT "x, "
>> + "size: 0x%" BFD_VMA_FMT"x\n",
>> + bfd_h_get_64 (abfd, hdr->c_loader),
>> + bfd_h_get_64 (abfd, hdr->c_lsize));
>> + printf (" thr: offset: 0x%08" BFD_VMA_FMT "x, nbr: %u\n",
>> + bfd_h_get_64 (abfd, hdr->c_thr),
>> + (unsigned) bfd_h_get_32 (abfd, hdr->c_n_thr));
>> + printf (" segregions: offset: 0x%08" BFD_VMA_FMT "x, "
>> + "nbr: %" BFD_VMA_FMT "u\n",
>> + bfd_h_get_64 (abfd, hdr->c_segregion),
>> + bfd_h_get_64 (abfd, hdr->c_segs));
>> + printf (" stack: offset: 0x%08" BFD_VMA_FMT "x, "
>> + "org: 0x%" BFD_VMA_FMT"x, "
>> + "size: 0x%" BFD_VMA_FMT"x\n",
>> + bfd_h_get_64 (abfd, hdr->c_stack),
>> + bfd_h_get_64 (abfd, hdr->c_stackorg),
>> + bfd_h_get_64 (abfd, hdr->c_size));
>> + printf (" data: offset: 0x%08" BFD_VMA_FMT "x, "
>> + "org: 0x%" BFD_VMA_FMT"x, "
>> + "size: 0x%" BFD_VMA_FMT"x\n",
>> + bfd_h_get_64 (abfd, hdr->c_data),
>> + bfd_h_get_64 (abfd, hdr->c_dataorg),
>> + bfd_h_get_64 (abfd, hdr->c_datasize));
>> + printf (" sdata: org: 0x%" BFD_VMA_FMT"x, "
>> + "size: 0x%" BFD_VMA_FMT"x\n",
>> + bfd_h_get_64 (abfd, hdr->c_sdorg),
>> + bfd_h_get_64 (abfd, hdr->c_sdsize));
>> + printf (" vmmregions: offset: 0x%" BFD_VMA_FMT"x, "
>> + "num: 0x%" BFD_VMA_FMT"x\n",
>> + bfd_h_get_64 (abfd, hdr->c_vmm),
>> + bfd_h_get_64 (abfd, hdr->c_vmmregions));
>> + printf (" impl: 0x%08x\n",
>> + (unsigned) bfd_h_get_32 (abfd, hdr->c_impl));
>> + printf (" cprs: 0x%" BFD_VMA_FMT "x\n",
>> + bfd_h_get_64 (abfd, hdr->c_cprs));
>
> I wasn't sure offhand why 0x%08 was used for some lines and not others,
> especially with the underlying value being 64 bits. I'm not asking you
> to change it though. If this looks best then that's fine.
This is for looking aspect, and I didn't have big enough core files to
detect overflows!
>> + ldr = xmalloc (len);
>> + if (bfd_seek (abfd, off, SEEK_SET) != 0
>> + || bfd_bread (ldr, len, abfd) != len)
>> + {
>> + non_fatal (_("cannot read loader info table"));
>> + }
>
> Nit-pick: no braces for a single line.
Done.
>> + printf (_("\n"
>> + "ld info dump not supported in 32 bits environments\n"));
>
> Maybe "ldinfo" to be consistent with the option.
Sure.
> OK with those changes, thanks.
Committed with the suggested changes. Thank you for the review.
Tristan.