This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [rfa] Change line to long
- To: Kevin Buettner <kevinb at cygnus dot com>
- Subject: Re: [rfa] Change line to long
- From: Michael Snyder <msnyder at cygnus dot com>
- Date: Thu, 01 Feb 2001 17:04:49 -0800
- CC: Michael Elizabeth Chastain <chastain at cygnus dot com>, ac131313 at cygnus dot com, gdb-patches at sourceware dot cygnus dot com
- Organization: Red Hat
- References: <200102012036.MAA01098@bosch.cygnus.com> <1010201232140.ZM24474@ocotillo.lan>
Kevin Buettner wrote:
>
> On Feb 1, 12:36pm, Michael Elizabeth Chastain wrote:
>
> > Kevin Buettner:
> > > Is there any reason not to make the type of ``line'' an unsigned long?
> >
> > Looking at 'struct symbol', the type of ``line'' is an unsigned short
> > so that it will pack well with 'namespace' and 'aclass', which are of
> > type BYTE_BITFIELD.
> >
> > However, some time ago, BYTE_BITFELD was nerfed anyways. So I believe
> > that sizeof(symbol) will not increase if you change ``line'' to a
> > 32-bit type.
> >
> > I like unsigned int better than unsigned long because it takes less
> > space on 64-bit hosts.
>
> Your concerns about the amount of space required by these data
> structures are certainly valid. One of gdb's current problems
> is its memory footprint.
>
> As a rule of thumb, the type of the "thing" in the data structure
> should be at least as wide as any of the inputs used to populate the
> data structure. In this case, the rule would mean that the type of
> ``line'' should be at least as wide as an unsigned long (because
> that's what is used in dwarf2read.c).
Would a cast to (unsigned int) in dwarf2read.c answer this objection?
>
> However, from a more practical perspective, having the type of line
> be either a signed or unsigned 32-bit integer is probably more than
> adequate. (These represent line numbers and it seems unlikely to
> me that anyone would want to debug a file with over 2 billion lines
> in it.)
>
> I'll leave it up to Andrew to decide what to do about it. If gdb had
> something like uint32_t available, I'd suggest using that.
>
> Kevin