From: Joel Brobecker <brobecker@adacore.com>
To: Pierre Muller <pierre.muller@ics-cnrs.unistra.fr>
Cc: gdb-patches@sourceware.org
Subject: Re: [RFC] Fix hpux_major_release variable setting
Date: Fri, 14 Jan 2011 16:32:00 -0000 [thread overview]
Message-ID: <20110114163035.GQ2504@adacore.com> (raw)
In-Reply-To: <000f01cbb401$1093cdc0$31bb6940$@muller@ics-cnrs.unistra.fr>
> The patch below fixes that problem by moving the call to uname to
> hppa-hpux-nat.c
>
> Is this patch OK?
I think that for a platform such as pa-hpux, this is fine (MarkK,
who just informed us that he has access to HP-UX hardware as well,
might want to coment as well). But I've since learnt that the correct
way of doing this is to use target_xfer_partial routine. The reason
why I think it's OK this way is that the fix seems contains to pa/hp-ux
and I don't see a lot of benefit in spending time and energy into trying
to support HP-UX 10.x.
> I am unsure about the way to move it to the header... Would it be
> better to declare it without external in the header?
I don't think that this would work. You'd end up with multiple definitions
of the same global variable.
> This would then mean that I should also move
> DEFAULT_HPUX_MAJOR_RELEASE macro to the header, but it would have
> the advantage of allowing to not use hard-coded 11 in
> _initialize_hppa_hpux_nat.
You can just leave the variable untouched instead of setting it to 11...
> 2011-01-14 Pierre Muller <muller@ics.u-strasbg.fr>
>
> * solib-som.h (hpux_major_release): Declare variable here.
> * solib-som.c: Remove <sys/utsname.h> header.
> (DEFAULT_HPUX_MAJOR_RELEASE): New macro.
> (hpux_major_release): Make global, change default value to
> DEFAULT_HPUX_MAJOR_RELEASE.
> (get_hpux_major_release): Simply return HPUX_MAJOR_RELEASE.
> * hppa-hpux-nat.c: Add <sys/utsname.h> include.
> Add "solib-som.h" header.
> (_initialize_hppa_hpux_nat): Set hpux_major_release variable by
> analyzis of uname call return.
> +/* Variable storing HP-UX major release number.
> + On non native system, simply suppose that the major release number is
^^^^^^^^
assume
> 11.
> + hppa-hpux-nat.c initialization code sets this number to
> + the real one on startup in native conditions. */
Suggest the following formatting (following the 70 characters guideline,
as well as an empty line for better clarity (personal opinion, can be
ignored). I'd also add a comment explaining why this value is computed
elsewhere. So here is a suggested rewordin:
/* Variable storing HP-UX major release number.
On non-native system, simply assume that the major release number
is 11. On native systems, hppa-hpux-nat.c initialization code
sets this number to the real one on startup in native conditions.
We cannot compute this value here, because we need to make a native
call to "uname". We are are not allowed to do that from here, as
this file is used for both native and cross debugging. */
> +#define DEFAULT_HPUX_MAJOR_RELEASE 11
> +int
> +hpux_major_release = DEFAULT_HPUX_MAJOR_RELEASE;
Formatting:
int hpux_major_release = DEFAULT_HPUX_MAJOR_RELEASE;
(I'm wondering if the DEFAULT_HPUX_MAJOR_RELEASE macro really brings much).
> static int
> get_hpux_major_release (void)
Let's get rid of this function at the same time, WDYT? It should be
a simple search-and-replace...
> + struct utsname x;
> + char *p;
>
> + uname (&x);
> + p = strchr (x.release, '.');
> + hpux_major_release = p ? atoi (p + 1) : 11;
Let's make that a function, and call the function from the
initialization code. I think it'll be easier to understand.
Otherwise, a small comment, and a new-line after the code block
would help visually separate this operation from the rest.
--
Joel
next prev parent reply other threads:[~2011-01-14 16:30 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-14 16:09 Pierre Muller
2011-01-14 16:32 ` Joel Brobecker [this message]
2011-01-14 16:59 ` [RFC-v2] " Pierre Muller
2011-01-14 17:58 ` Joel Brobecker
2011-01-14 18:17 ` Pedro Alves
2011-01-14 18:52 ` Pierre Muller
2011-01-14 18:54 ` Michael Snyder
2011-01-14 19:22 ` Paul Koning
2011-01-14 19:52 ` Joel Brobecker
2011-01-14 21:49 ` [RFA] remove form feeds Michael Snyder
2011-01-14 21:51 ` Tom Tromey
2011-01-14 21:54 ` Doug Evans
2011-01-14 22:31 ` Joel Brobecker
2011-01-14 23:55 ` Michael Snyder
2011-01-15 11:42 ` [RFC-v2] Fix hpux_major_release variable setting Mark Kettenis
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=20110114163035.GQ2504@adacore.com \
--to=brobecker@adacore.com \
--cc=gdb-patches@sourceware.org \
--cc=pierre.muller@ics-cnrs.unistra.fr \
/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