Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: "Metzger, Markus T" <markus.t.metzger@intel.com>
To: Pedro Alves <palves@redhat.com>
Cc: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Subject: RE: [PATCH v3 3/3] btrace, vdso: add vdso target sections
Date: Mon, 02 Jun 2014 09:43:00 -0000	[thread overview]
Message-ID: <A78C989F6D9628469189715575E55B230C182BEA@IRSMSX104.ger.corp.intel.com> (raw)
In-Reply-To: <A78C989F6D9628469189715575E55B230C182B51@IRSMSX104.ger.corp.intel.com>

> -----Original Message-----
> From: Metzger, Markus T
> Sent: Monday, June 2, 2014 10:21 AM
> To: Pedro Alves
> Cc: gdb-patches@sourceware.org
> Subject: RE: [PATCH v3 3/3] btrace, vdso: add vdso target sections
> 
> Thanks for reporting this crash.  I'll look into it.  I thought I ran all tests
> for each patch in the vdso series.
> 
> It seems btrace got broken, as well.  I now get an assertion: "
> to_execution_direction must be implemented ...".  The trivial solution
> of providing a to_execution_direction method that just returns
> execution_direction does not seem to work - or there's another
> bug underneath.

Looks like btrace got broken when async was made default and btrace
did not support it.  I took the async bits from record-full and now at
least the btrace tests are running again.  I'll send the patch in a separate
email.

Regards,
Markus.


> 
> Regards,
> Markus.
> 
> > -----Original Message-----
> > From: Pedro Alves [mailto:palves@redhat.com]
> > Sent: Thursday, May 29, 2014 7:04 PM
> > To: Metzger, Markus T
> > Cc: gdb-patches@sourceware.org
> > Subject: Re: [PATCH v3 3/3] btrace, vdso: add vdso target sections
> >
> > On 05/29/2014 05:54 PM, Pedro Alves wrote:
> > > Hi Markus,
> > >
> > > On 05/21/2014 08:01 AM, Markus Metzger wrote:
> > >> When loading symbols for the vdso, also add its sections to
> > target_sections.
> > >>
> > >> This fixes an issue with record btrace where vdso instructions could not
> be
> > >> disassembled during replay.
> > >>
> > >> 2014-05-21  Markus Metzger  <markus.t.metzger@intel.com>
> > >>
> > >> 	* symfile-mem.c (symbol_file_add_from_memory): Add BFD
> > sections.
> > >
> > > Unfortunately this caused regressions in break-interp.exp:
> > >
> > >  Running ../../../src/gdb/testsuite/gdb.base/break-interp.exp ...
> > >  ERROR: Process no longer exists
> > >
> > > That is GDB crashing.
> > >
> > > 589fdceb99db9868e34bc976b7e234dbfaf327e2 is the first bad commit
> > > commit 589fdceb99db9868e34bc976b7e234dbfaf327e2
> > > Author: Markus Metzger <markus.t.metzger@intel.com>
> > > Date:   Wed Apr 2 09:54:11 2014 +0200
> > >
> > >     btrace, vdso: add vdso target sections
> > >
> > >     When loading symbols for the vdso, also add its sections to
> > target_sections.
> > >
> > >     This fixes an issue with record btrace where vdso instructions could not
> > be
> > >     disassembled during replay.
> > >
> > >         * symfile-mem.c (symbol_file_add_from_memory): Add BFD
> sections.
> > >
> > >     testsuite/
> > >         * gdb.btrace/vdso.c: New.
> > >         * gdb.btrace/vdso.exp: New.
> > >
> > >
> > > Core was generated by
> > `/home/pedro/gdb/mygit/build/gdb/testsuite/../../gdb/gdb -nw -nx -data-
> > directory'.
> > > Program terminated with signal SIGSEGV, Segmentation fault.
> > > #0  0x0000000000647bce in exec_set_section_address
> > (filename=0x27bb1f0
> > "/home/pedro/gdb/mygit/build/gdb/testsuite/gdb.base/break-interp-
> > LDprelinkNOdebugNO", index=0,
> > >     address=139930618982856) at ../../src/gdb/exec.c:919
> > > 919           if (filename_cmp (filename, p->the_bfd_section->owner-
> > >filename) == 0
> >
> > 'p', a target section, points at garbage.
> >
> > Hmm, wait, nothing is removing the vdso symbols target sections, like ever,
> > not even when the process dies, isn't it?  I guess that's it.
> >
> > --
> > Pedro Alves

Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen, Deutschland
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk
Registergericht: Muenchen HRB 47456
Ust.-IdNr./VAT Registration No.: DE129385895
Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052


  reply	other threads:[~2014-06-02  9:43 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-21  7:01 [PATCH v3 1/3] btrace: control memory access during replay Markus Metzger
2014-05-21  7:01 ` [PATCH v3 3/3] btrace, vdso: add vdso target sections Markus Metzger
2014-05-21  9:55   ` Pedro Alves
2014-05-29 16:54   ` Pedro Alves
2014-05-29 17:03     ` Pedro Alves
2014-06-02  8:20       ` Metzger, Markus T
2014-06-02  9:43         ` Metzger, Markus T [this message]
2014-06-02 12:41       ` Metzger, Markus T
2014-06-04 12:37         ` Metzger, Markus T
2014-05-21  7:02 ` [PATCH v3 2/3] test, gcore: move capture_command_output into lib/gdb.exp Markus Metzger
2014-05-21  9:55   ` Pedro Alves
2014-05-21  9:55 ` [PATCH v3 1/3] btrace: control memory access during replay Pedro Alves

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=A78C989F6D9628469189715575E55B230C182BEA@IRSMSX104.ger.corp.intel.com \
    --to=markus.t.metzger@intel.com \
    --cc=gdb-patches@sourceware.org \
    --cc=palves@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