Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Tom Tromey <tromey@redhat.com>
To: Yao Qi <yao@codesourcery.com>
Cc: <gdb-patches@sourceware.org>
Subject: Re: [PATCH 3/5] Read CTF by the ctf target
Date: Fri, 01 Mar 2013 15:51:00 -0000	[thread overview]
Message-ID: <87txovunji.fsf@fleche.redhat.com> (raw)
In-Reply-To: <1361931459-3953-4-git-send-email-yao@codesourcery.com> (Yao Qi's	message of "Wed, 27 Feb 2013 10:17:37 +0800")

>>>>> "Yao" == Yao Qi <yao@codesourcery.com> writes:

Yao> +# Where is libbabeltrace? This will be empty if lzma was not available.
Yao> +LIBBABELTRACE = @btlibs@
Yao> +LIBBABELTRACE_CFLAGS = @btinc@

This mentions "lzma", but I didn't see a link... maybe just a
cut-and-pasto.

It is clearer to use the same variable names in configure.ac and
Makefile.in.  I'd suggest @LIBBABELTRACE@ and @LIBBABELTRACE_CFLAGS@ and
then change configure.ac.

Yao> +AC_ARG_WITH(babeltrace, [  --with-babeltrace=PATH       Specify prefix directory for the installed BABELTRACE package
Yao> +                          Equivalent to --with-babeltrace-include=PATH/include
Yao> +                          plus --with-babeltrace-lib=PATH/lib])

It's better to use AS_HELP_STRING.

Yao> +AC_ARG_WITH(bt_include, [  --with-babeltrace-include=PATH Specify directory for installed babeltrace include files])

Lines are too long.  AS_HELP_STRING will help with that :)

Yao> +AC_ARG_WITH(bt_lib, [  --with-babeltrace-lib=PATH   Specify the directory for the installed babeltrace library])
Yao> +
Yao> +case $with_babeltrace in
Yao> +  no)
Yao> +    btlibs=
Yao> +    btinc=
Yao> +    ;;
Yao> +  "" | yes)
Yao> +    btlibs=" -lbabeltrace -lbabeltrace-ctf "
Yao> +    btinc=""
Yao> +    ;;
Yao> +  *)
Yao> +    btlibs="-L$with_babeltrace/lib -lbabeltrace -lbabeltrace-ctf"
Yao> +    btinc="-I$with_babeltrace/include "
Yao> +    ;;
Yao> +esac

Earlier code initialized the output variables, but it turns out there
was no need to do that.

Yao> +  [AC_MSG_RESULT([yes]); AC_DEFINE(HAVE_LIBBABELTRACE, 1, [Define if libbabeltrace is available])],

Needs some line breaks.

Yao> +extern int trace_regblock_size;

Maybe in tracepoint.h instead?
I see other instances of this (in tracepoint.c and remote.c).
In most cases I think extern declarations belong in headers.
(There can be exceptions, IMO, but this doesn't seem like one.)

Yao> +	  const struct bt_definition *scope
Yao> +	    = bt_ctf_get_top_level_scope(event,
Yao> +					 BT_EVENT_FIELDS);
Yao> +	  const struct bt_definition *array
Yao> +	    = bt_ctf_get_field(event, scope, "contents");
Yao> +
Yao> +	  trace_regblock_size
Yao> +	    = bt_ctf_get_array_len (bt_ctf_get_decl_from_def (array));

Some spaces missing before "(".

Yao> +  /* Restore the position.  */
Yao> +  bt_iter_set_pos(bt_ctf_get_iter (ctf_iter), pos);

Likewise.

There are more too, I didn't mark them all.

Yao> +      /* xfree (regs); */

It seems like this should be deleted.
I don't really know, though.

Yao> +	  unsigned short mlen;

I'm curious about the rationale for the type here.
And a bit later:

Yao> +	  mlen = (uint16_t) bt_ctf_get_uint64 (def);

Why use uint16_t here and not mlen's real type?
But I don't understand why this has a shorter type anyhow.

Yao> +  /* It's unduly pedantic to refuse to look at the executable for
Yao> +     read-only pieces; so do the equivalent of readonly regions aka
Yao> +     QTro packet.  */
Yao> +  /* FIXME account for relocation at some point.  */

There's a rule against adding new FIXME comments.  Sometimes I think
maybe we're too strict about this; though in practice it does seem to me
that these are rarely fixed for their own sake, but instead just as a
side effect of something else.

I suppose you could rephrase it to be a note.
Or is it fixable?  It isn't clear to me in what situation this code is
invoked.

I was curious why this looks directly at the exec_bfd rather than using
something like ALL_OBJFILE_OSECTIONS.  It seemed like this might help
with the relocation problem.

Yao> +  if (exec_bfd)

A while ago we agreed to use the more explicit `exec_bfd != NULL' form.

Yao> +  /* Didn't find anything.  */
Yao> +  return found;

I think this can be reached in the "did find something" case as well, so
I suggest just dropping the comment.

Yao> +/* Return what address the current frame was collected at.  */

I think "Return the address at which the current frame was collected".

Yao> +      /* FIXME this is a poor heuristic if multiple locations.  */
Yao> +      if (tp && tp->base.loc)
Yao> +	addr = tp->base.loc->address;

The FIXME rule again.
Elsewhere the code just rejects multiple locations; but I'm not sure if
that is appropriate here.

Tom


  parent reply	other threads:[~2013-03-01 15:51 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-27  2:18 [PATCH 0/5, 2nd try] CTF Support Yao Qi
2013-02-27  2:18 ` [PATCH 1/5] Refactor 'tsave' Yao Qi
2013-02-28 16:49   ` Pedro Alves
2013-03-01  8:58     ` Yao Qi
2013-03-01 10:05       ` Pedro Alves
2013-03-01 10:41         ` Pedro Alves
2013-03-01 11:26         ` Yao Qi
2013-03-01 12:13           ` Pedro Alves
2013-03-01 15:55             ` Yao Qi
2013-03-05 20:59               ` Pedro Alves
2013-03-03  8:45         ` Yao Qi
2013-02-27  2:19 ` [PATCH 4/5] ctf doc and NEWS Yao Qi
2013-02-27 18:39   ` Eli Zaretskii
2013-02-27  2:19 ` [PATCH 2/5] Save trace into CTF format Yao Qi
2013-02-28 13:17   ` Yao Qi
2013-02-28 13:17     ` Andreas Schwab
2013-02-28 17:19       ` Pedro Alves
2013-03-01 19:22     ` Tom Tromey
2013-03-03 10:19       ` Yao Qi
2013-03-07 21:29         ` Tom Tromey
2013-03-16  2:30         ` Joel Brobecker
2013-03-16  4:22           ` Yao Qi
2013-02-27  2:19 ` [PATCH 3/5] Read CTF by the ctf target Yao Qi
2013-02-28 17:59   ` Pedro Alves
2013-03-01  2:38     ` Hui Zhu
2013-05-07 13:07       ` Mathieu Desnoyers
2013-05-07 13:24         ` Yao Qi
2013-05-07 13:28           ` Mathieu Desnoyers
2013-03-01  7:55     ` Yao Qi
2013-03-01  9:15       ` Pedro Alves
2013-03-01 15:51   ` Tom Tromey [this message]
2013-03-03 10:39     ` Yao Qi
2013-03-03 10:46       ` Yao Qi
2013-02-27  2:19 ` [PATCH 5/5] ctf test: report.exp Yao Qi
2013-02-27 18:48   ` Pedro Alves
2013-02-28  1:36     ` Yao Qi
2013-02-28 18:30       ` 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=87txovunji.fsf@fleche.redhat.com \
    --to=tromey@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=yao@codesourcery.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