public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Jan Kratochvil <jan.kratochvil@redhat.com>
To: Sergio Durigan Junior <sergiodj@redhat.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH] Implement new `info core mappings' command
Date: Mon, 31 Oct 2011 08:13:00 -0000	[thread overview]
Message-ID: <20111031070012.GA32610@host1.jankratochvil.net> (raw)
In-Reply-To: <m3vcr5u9y4.fsf@redhat.com>

On Mon, 31 Oct 2011 04:16:51 +0100, Sergio Durigan Junior wrote:
> > I think they are pretty useful, for Linux kernel dumped core files with
> > MMF_DUMP_ELF_HEADERS
> > /usr/share/doc/kernel-doc-*/Documentation/filesystems/proc.txt
> >   - (bit 4) ELF header pages in file-backed private memory areas (it is
> >             effective only if the bit 2 is cleared)
> >
> > Program Headers:
> >   Type           Offset   VirtAddr           PhysAddr           FileSiz  MemSiz   Flg Align
> >   NOTE           0x001508 0x0000000000000000 0x0000000000000000 0x0008d0 0x000000     0
> >   LOAD           0x002000 0x0000000000400000 0x0000000000000000 0x001000 0x008000 R E 0x1000
> >   LOAD           0x003000 0x0000000000607000 0x0000000000000000 0x002000 0x002000 RW  0x1000
> >
> > (gdb) info files
> > Local core dump file:
> > 	0x0000000000400000 - 0x0000000000401000 is load1a
> > 	0x0000000000401000 - 0x0000000000401000 is load1b
> > 	0x0000000000607000 - 0x0000000000609000 is load2
> >
> > But one does not see the ending address 0x408000 anywhere, one IMO has to use
> > readelf/objdump now to get the full information.
> >
> >
> > I think this function should not be based on sections at all, it should just
> > read the segments.  Linux kernel does not dump any sections.  bfd creates some
> > some sections from those segments (_bfd_elf_make_section_from_phdr) but they
> > cannot / do not contain any additional info, those are there IMO only for
> > better compatibility with sections-only consuming code.
> 
> Just to be clear, you're saying that I should actually forget about the
> part of the code which checks inside (possible non-empty) sections in
> the corefile, and just check immediately for segments?

Yes.  Otherwise you need the tricks combining it with segments you do below
anyway, moreover you can read in sections in core file generated by gcore
which are completely useless,


> >> +  /* Fields to be printed for the proc map.  */
> >> +  unsigned long start = 0, end = 0;
> >> +  unsigned int size = 0;
> >
> > On 32bit host with --enable-64-bit-bfd: sizeof (bfd_vma) > sizeof (long)
> > moreover for sizeof (int) of `size'.
> 
> Ok, I'll replace that by unsigned long too, thanks.

I meant you should use bfd_vma.  Even `unsigned long' is too short.  You would
need to use `unsigned long long' but that has compatibility issues already
resolved if you just use `bfd_vma'.


> >> +  /* Unfortunately, some sections in the corefile don't have any
> >> +     content inside.  This is bad because we need to print, among
> >> +     other things, its final address in the memory (which is
> >> +     impossible to know if we don't have a size).  That's why we
> >> +     first need to check if the section's got anything inside it.  */
> >> +  secsize = bfd_section_size (bfd, sect);
> >> +
> >> +  if (secsize == 0)
> >> +    {
> >> +      /* Ok, the section is empty.  In this case, we must look inside
> >> +	 ELF's Program Header, because (at least) there we have
> >> +	 information about the section's size.  That's what we're doing
> >> +	 here.  */
> >> +      Elf_Internal_Phdr *p = elf_tdata (bfd)->phdr;
> >> +      if (p != NULL)
> >> +	{
> >> +	  int i;
> >> +	  unsigned int n = elf_elfheader (bfd)->e_phnum;
> >> +	  for (i = 0; i < n; i++, p++)
> >> +	    /* For each entry in the Program Header, we have to
> >> +	       check if the section's initial address is equal to
> >> +	       the entry's virtual address.  If it is, then we
> >> +	       have just found the section's entry in the Program
> >> +	       Header, and can use the entry's information to
> >> +	       complete missing data from the section.  */
> >> +	    if (sect->vma == p->p_vaddr)
> >> +	      {
> >> +		found = 1;
> >> +		break;
> >> +	      }
> >
> > I do not understand what is a goal of this part.  Isn't it related to the
> > pairtally omitted segments above?  But those are named "load..." so they are
> > already skipped.
> 
> I'm not sure I understood what you said.  The sections named "load..."
> are not skipped.  It's the sections *not* named "load..." which are.

Sorry, OK.  But still I do not understand why to look at sections of core file
at all.  Another question is to handle non-ELF core files but that could be
a completely separate code path.


> 
> >> +  ALL_OBJSECTIONS (objfile, s)
> >> +    if (obj_section_addr (s) >= start
> >> +	&& obj_section_addr (s) <= end)
> >
> > I think it should ignore S which is section_is_overlay.
> 
> You mean I should check for `!section_is_overlay (s)' here?

Yes.


> >> @@ -450,6 +636,11 @@ _initialize_core (void)
> >>  {
> >>    struct cmd_list_element *c;
> >>  
> >> +  add_info ("core", info_core_cmd, _("\
> >> +Show information about a corefile.\n\
> >> +Specify any of the following keywords for detailed info:\n\
> >> +  mappings -- list of mapped memory regions."));
> >
> > I think it should be add_prefix_cmd so that tab completion works.  "mappings
> > / "all" should be commands, not parameters.  "info proc" already has this bug.
> 
> Yeah, `info proc' is buggy indeed.  I'll see if I send a patch fixing it
> tomorrow.  Thanks for the tip.

Or it should be a single command using add_setshow_enum_cmd, not sure which
approach is better.  Still I think the separate commands are better as they
can have each specific help text.


Thanks,
Jan

  reply	other threads:[~2011-10-31  7:00 UTC|newest]

Thread overview: 83+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-26 21:08 Sergio Durigan Junior
2011-10-26 21:25 ` Sergio Durigan Junior
2011-10-27  7:30   ` Eli Zaretskii
2011-10-27 18:09     ` Sergio Durigan Junior
2011-10-29 19:48       ` Eli Zaretskii
2011-10-31  0:34 ` Jan Kratochvil
2011-10-31  7:00   ` Sergio Durigan Junior
2011-10-31  8:13     ` Jan Kratochvil [this message]
2011-10-31 12:57       ` Pedro Alves
2011-11-01 11:54         ` [patch] `info proc ' completion [Re: [PATCH] Implement new `info core mappings' command] Jan Kratochvil
2011-11-01 16:23           ` Eli Zaretskii
2011-11-03 14:12             ` [patch] `info proc *' help fix [Re: [patch] `info proc ' completion] Jan Kratochvil
2011-11-03 16:57               ` Eli Zaretskii
2011-11-03 17:07                 ` Jan Kratochvil
2011-11-03 18:08                   ` Eli Zaretskii
2011-11-03 18:25                     ` Jan Kratochvil
2011-11-02 18:30           ` [patch] `info proc ' completion [Re: [PATCH] Implement new `info core mappings' command] Pedro Alves
2011-11-02 18:48             ` [commit] " Jan Kratochvil
2011-11-03 20:01       ` [PATCH] Implement new `info core mappings' command Sergio Durigan Junior
2011-11-04 10:38         ` Eli Zaretskii
2011-11-04 16:27         ` Jan Kratochvil
2011-11-08  1:49           ` Sergio Durigan Junior
2011-11-08 21:47             ` Jan Kratochvil
2011-11-09 20:32             ` Jan Kratochvil
2011-11-16  4:10               ` Sergio Durigan Junior
2011-11-21 16:15                 ` Sergio Durigan Junior
2011-11-23 16:32                   ` [rfc] Options for "info mappings" etc. (Re: [PATCH] Implement new `info core mappings' command) Ulrich Weigand
2011-11-23 23:37                     ` Sergio Durigan Junior
2011-12-01 19:51                       ` Ulrich Weigand
2011-12-05 12:59                     ` Pedro Alves
2011-12-05 15:02                       ` Ulrich Weigand
2011-12-06 16:01                         ` Pedro Alves
2011-12-06 17:19                           ` Ulrich Weigand
2011-12-07 16:29                             ` Pedro Alves
2011-12-07 17:24                               ` Pedro Alves
2011-12-07 20:14                               ` Ulrich Weigand
2011-12-09 13:28                                 ` Pedro Alves
2011-12-09 14:10                                   ` Pedro Alves
2011-12-20 23:08                                 ` Ulrich Weigand
2011-12-21 22:36                                   ` Jan Kratochvil
2011-12-22 16:15                                     ` Ulrich Weigand
2012-01-05 16:02                                   ` Pedro Alves
2012-01-05 18:03                                     ` Ulrich Weigand
2012-01-05 18:20                                       ` Pedro Alves
2012-01-05 19:54                                         ` Ulrich Weigand
2012-01-06  6:41                                           ` Joel Brobecker
2012-01-06 12:29                                             ` Pedro Alves
2012-01-06 12:27                                           ` Pedro Alves
2012-01-09 15:44                                             ` Ulrich Weigand
2012-01-11 16:38                                               ` Pedro Alves
2012-01-11 18:32                                                 ` Ulrich Weigand
2012-01-05 18:37                                       ` Mark Kettenis
2012-01-05 19:35                                         ` Ulrich Weigand
  -- strict thread matches above, loose matches on Subject: below --
2012-04-06  3:28 [PATCH 0/4 v2] Implement support for SystemTap probes on userspace Sergio Durigan Junior
2012-04-06  3:32 ` [PATCH 1/4 v2] Refactor internal variable mechanism Sergio Durigan Junior
2012-04-06  3:36 ` [PATCH 2/4 v2] Implement new features needed for handling SystemTap probes Sergio Durigan Junior
2012-04-11 19:06   ` Jan Kratochvil
2012-04-11 22:14     ` Sergio Durigan Junior
2012-04-11 23:33       ` Jan Kratochvil
2012-04-06  3:37 ` [PATCH 4/4 v2] Documentation and testsuite changes Sergio Durigan Junior
2012-04-06  9:27   ` Eli Zaretskii
2012-04-09 21:37     ` Sergio Durigan Junior
2012-04-06  4:11 ` [PATCH 3/4 v2] Use longjmp and exception probes when available Sergio Durigan Junior
2011-04-04  3:09 [PATCH 4/6] Implement support for SystemTap probes Sergio Durigan Junior
2011-04-04 19:06 ` Eli Zaretskii
2011-04-06 20:20 ` Tom Tromey
2011-04-06 20:52   ` Sergio Durigan Junior
2011-04-07  2:41 ` Yao Qi
2011-04-07  3:32   ` Sergio Durigan Junior
2011-04-07 17:04   ` Tom Tromey
2011-04-11  3:21     ` Yao Qi
2011-04-08 12:38   ` Sergio Durigan Junior
2011-04-11  3:52     ` Yao Qi
2011-08-12 15:45     ` Jan Kratochvil
2011-08-12 17:22       ` Frank Ch. Eigler
2011-08-12 21:33         ` Sergio Durigan Junior
2011-04-19 16:42 ` Jan Kratochvil
2012-05-07 19:36   ` Jan Kratochvil
2012-05-07 19:54     ` Sergio Durigan Junior
2012-05-07 19:58       ` Jan Kratochvil
2012-05-07 20:26         ` Sergio Durigan Junior
2012-05-07 20:38           ` Jan Kratochvil
2012-05-08  1:36             ` Sergio Durigan Junior

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20111031070012.GA32610@host1.jankratochvil.net \
    --to=jan.kratochvil@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=sergiodj@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).