From: Doug Evans <dje@google.com>
To: Jan Kratochvil <jan.kratochvil@redhat.com>
Cc: Sergio Durigan Junior <sergiodj@redhat.com>,
gdb-patches <gdb-patches@sourceware.org>,
Aleksandar Ristovski <ARistovski@qnx.com>
Subject: Re: [PATCH v5 1/8] Move utility functions to common/
Date: Mon, 19 May 2014 22:46:00 -0000 [thread overview]
Message-ID: <CADPb22Qn-vSm_NcfwgNAtaCBxocZw5rJB4DWZ+aFWr_bqPvqaA@mail.gmail.com> (raw)
In-Reply-To: <20140518190534.GA19591@host2.jankratochvil.net>
On Sun, May 18, 2014 at 12:05 PM, Jan Kratochvil
<jan.kratochvil@redhat.com> wrote:
> On Mon, 24 Mar 2014 20:59:48 +0100, Sergio Durigan Junior wrote:
>> On Wednesday, March 19 2014, Jan Kratochvil wrote:
>> > some parts of the former patch have been reimplemented in the meantime by
>> > other patches so this is only a part of the former cleanup.
>>
>> Can't this go in independently? I think they are nice cleanups.
>
> I do not think it is right without the later parts of the patchset - code
> in gdb/common/ should be used by both gdb and gdbserver. Otherwise the code
> could remain in gdb/ only.
Hi.
I don't have a strong opinion on whether this particular patch can go
in right away, but I do have a comment.
I think we're building gdb wrong (where by "gdb" I mean
gdb+gdbserver+gdbreplay+...) if things can't go in common if they're
only used by gdb.
We should be building gdb out of useful building blocks, and it's just
easier to hack if said building blocks are already available, without
having to go through all the administrivia of moving them about or
what not.
If something like skip_spaces isn't used by gdbserver today, that
doesn't mean it won't be tomorrow.
IOW, I think of "common" as a collection of application-independent
routines, not dissimilar from libiberty, but for whatever reason
doesn't/can't live there instead. [btw, I'm not suggesting moving
routines from common to libiberty, but I'm guessing a quick glance
would find a few that should just as well live in libiberty - and be
usable by more people too]
Plus, I guess I have to ask, if down the road we find some routine in
common only used by a particular app, do we need to move it out of
common and into that app's directory?
My $0.02 anyways.
next prev parent reply other threads:[~2014-05-19 22:46 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-19 23:12 [PATCH v5 0/8] Validate binary before use Jan Kratochvil
2014-03-19 22:30 ` [PATCH v5 1/8] Move utility functions to common/ Jan Kratochvil
2014-03-24 20:00 ` Sergio Durigan Junior
2014-05-18 19:05 ` Jan Kratochvil
2014-05-19 18:22 ` Tom Tromey
2014-05-19 22:48 ` Doug Evans
2014-05-19 22:46 ` Doug Evans [this message]
2014-05-19 18:21 ` Tom Tromey
2014-03-19 22:31 ` [PATCH v5 3/8] Create empty common/linux-maps.[ch] and common/target-utils.[ch] Jan Kratochvil
2014-05-19 18:29 ` Tom Tromey
2014-03-19 22:31 ` [PATCH v5 2/8] Merge multiple hex conversions Jan Kratochvil
2014-05-19 18:24 ` Tom Tromey
2014-03-19 22:31 ` [PATCH v5 8/8] Tests for validate symbol file using build-id Jan Kratochvil
2014-05-20 14:57 ` Tom Tromey
2014-05-20 15:29 ` Jan Kratochvil
2014-03-19 22:31 ` [PATCH v5 6/8] gdbserver build-id attribute generator Jan Kratochvil
2014-05-20 14:40 ` Tom Tromey
2014-05-21 12:24 ` Jan Kratochvil
2014-05-21 16:48 ` Tom Tromey
2014-03-19 22:31 ` [PATCH v5 4/8] Prepare linux_find_memory_regions_full & co. for move Jan Kratochvil
2014-05-19 19:15 ` Tom Tromey
2014-03-19 22:31 ` [PATCH v5 5/8] Move linux_find_memory_regions_full & co Jan Kratochvil
2014-05-19 19:19 ` Tom Tromey
2014-03-19 22:31 ` [PATCH v5 7/8] Validate symbol file using build-id Jan Kratochvil
2014-03-20 3:51 ` Eli Zaretskii
2014-03-20 13:07 ` Jan Kratochvil
2014-03-20 17:28 ` Eli Zaretskii
2014-03-21 16:58 ` Jan Kratochvil
2014-03-20 13:13 ` Aleksandar Ristovski
2014-03-21 16:58 ` Jan Kratochvil
2014-03-21 17:08 ` Aleksandar Ristovski
2014-03-21 16:34 ` [PATCH v5 7/8] Validate symbol file using build-id [updated] Jan Kratochvil
2014-03-21 16:52 ` Eli Zaretskii
2014-05-20 14:51 ` [PATCH v5 7/8] Validate symbol file using build-id Tom Tromey
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=CADPb22Qn-vSm_NcfwgNAtaCBxocZw5rJB4DWZ+aFWr_bqPvqaA@mail.gmail.com \
--to=dje@google.com \
--cc=ARistovski@qnx.com \
--cc=gdb-patches@sourceware.org \
--cc=jan.kratochvil@redhat.com \
--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