From: Andrew Cagney <ac131313@cygnus.com>
To: Dan Nicolaescu <dann@godzilla.ICS.UCI.EDU>
Cc: gdb@sources.redhat.com
Subject: Re: BYTE_BITFIELD in symtab.h
Date: Tue, 27 Nov 2001 23:08:00 -0000 [thread overview]
Message-ID: <3C048D4B.6050009@cygnus.com> (raw)
In-Reply-To: <200111241235.aa09546@gremlin-relay.ics.uci.edu>
> Hi!
>
> Is the following thing in symtab.h realy useful?
>
>
> /* Don't do this; it means that if some .o's are compiled with GNU C
> and some are not (easy to do accidentally the way we configure
> things; also it is a pain to have to "make clean" every time you
> want to switch compilers), then GDB dies a horrible death. */
> /* GNU C supports enums that are bitfields. Some compilers don't. */
> #if 0 && defined(__GNUC__) && !defined(BYTE_BITFIELD)
> #define BYTE_BITFIELD :8;
> #else
> #define BYTE_BITFIELD /*nothing */
> #endif
>
> if BYTE_BITFIELD was defined to :8 the size of
> "struct general_symbol_info" would decrease from 24 bytes to 20 bytes
> for a tipical 32 bit machine.
> And gdb uses quite a few of those...
>
> Isn't the price payed for being able to switch compilers too high in
> this case?
> How common are compilers that don't support enum bitfields?
Oh, what the heck I'll name names. ``gnu'' added this 1994-01-12 only to
have ``kingdon'' disable it less than a month later (1994-02-07). I
agree with JimK. I think that #if is nasty asking for trouble.
A quick glance at my (very old) tartan labs book suggests a compiler
need only support unsigned bit fields. If you think about it, that is
probably the only thing with vaguely well defined and fairly portable
semantics.
For the above my personal preference would be to zap that macro and then
investigate some explicit pack/unpack or explicit (i.e. no macro)
unsigned bitfields.
Fortuantly, that isn't my file :-)
enjoy,
Andrew
PS: JimB, did you know ``struct { unsigned :1; } foo'' is valid?
WARNING: multiple messages have this Message-ID
From: Andrew Cagney <ac131313@cygnus.com>
To: Dan Nicolaescu <dann@godzilla.ICS.UCI.EDU>
Cc: gdb@sources.redhat.com
Subject: Re: BYTE_BITFIELD in symtab.h
Date: Sun, 18 Nov 2001 23:08:00 -0000 [thread overview]
Message-ID: <3C048D4B.6050009@cygnus.com> (raw)
Message-ID: <20011118230800.-3fx8WZu9C4US80r15T5j2X3KcREsddTwvDrKuzaxj4@z> (raw)
In-Reply-To: <200111241235.aa09546@gremlin-relay.ics.uci.edu>
> Hi!
>
> Is the following thing in symtab.h realy useful?
>
>
> /* Don't do this; it means that if some .o's are compiled with GNU C
> and some are not (easy to do accidentally the way we configure
> things; also it is a pain to have to "make clean" every time you
> want to switch compilers), then GDB dies a horrible death. */
> /* GNU C supports enums that are bitfields. Some compilers don't. */
> #if 0 && defined(__GNUC__) && !defined(BYTE_BITFIELD)
> #define BYTE_BITFIELD :8;
> #else
> #define BYTE_BITFIELD /*nothing */
> #endif
>
> if BYTE_BITFIELD was defined to :8 the size of
> "struct general_symbol_info" would decrease from 24 bytes to 20 bytes
> for a tipical 32 bit machine.
> And gdb uses quite a few of those...
>
> Isn't the price payed for being able to switch compilers too high in
> this case?
> How common are compilers that don't support enum bitfields?
Oh, what the heck I'll name names. ``gnu'' added this 1994-01-12 only to
have ``kingdon'' disable it less than a month later (1994-02-07). I
agree with JimK. I think that #if is nasty asking for trouble.
A quick glance at my (very old) tartan labs book suggests a compiler
need only support unsigned bit fields. If you think about it, that is
probably the only thing with vaguely well defined and fairly portable
semantics.
For the above my personal preference would be to zap that macro and then
investigate some explicit pack/unpack or explicit (i.e. no macro)
unsigned bitfields.
Fortuantly, that isn't my file :-)
enjoy,
Andrew
PS: JimB, did you know ``struct { unsigned :1; } foo'' is valid?
next prev parent reply other threads:[~2001-11-27 23:08 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-11-11 21:40 Dan Nicolaescu
2001-11-27 23:08 ` Andrew Cagney [this message]
2001-11-18 23:08 ` Andrew Cagney
2001-11-22 5:12 ` Dan Nicolaescu
2001-11-28 14:56 ` Dan Nicolaescu
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=3C048D4B.6050009@cygnus.com \
--to=ac131313@cygnus.com \
--cc=dann@godzilla.ICS.UCI.EDU \
--cc=gdb@sources.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