| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 846.1 | | GEMGRP::MONTELEONE | | Wed Feb 19 1997 17:26 | 14 |
|
Currently, there is no way to express the size of an enumerand in
the symbol table, which shows a deficiency in it.
Dbx uses a default of 4 bytes, which is a more reasonable default than
1 byte. So, in the short term, I believe that ladebug should change the
default. For the long term, I will put together a proposal to
modify the symbol table representation for enums so that the length
is expressable. Since it takes a coordinated effort to role out most
symbol table format modifications, the benefit of using a new format
is a longer term solution.
Bob
|
| 846.2 | | TLE::MURRAY | Wanfang Murray | Mon Feb 24 1997 07:58 | 4 |
|
Bob's suggestion sounds reasonable. We will fix this.
Wanfang
|
| 846.3 | Upon further consideration... | GEMGRP::MONTELEONE | | Mon Feb 24 1997 15:50 | 16 |
|
On further consideration, it is probably not necessary to modify
the symbol table to express the datatype of the enumeration. I had
originally thought that with some languages, other than C, C++ etc.,
there was a way for a user to specify the datatype associated with
a enumeration. I haven't been able to find such a language, so I am
not going to bother to modify the symbol table specification.
All that needs to be done, then, is to fix the debugger.
FYI,
Bob
|
| 846.4 | | ADA9X::BRETT | | Mon Feb 24 1997 22:47 | 3 |
| Ada can indeed specify {8,16,32} bit {signed,unsigned} enums
/Bevin
|
| 846.5 | | GEMGRP::MONTELEONE | | Tue Feb 25 1997 10:15 | 28 |
|
Pascal has that capability too.
Dennis has been doing some investigation on this subject. It appears
that a symbol table change may not be needed afterall anyway !
The acc compilers would put what appears to be the size of the type
of the enumerand in the value field of the opening block:
1. ( 1)( 0x4) foobar Block Info symref 5
***
2. ( 2)( 0) eRftFalse Member Info [14] btNil
3. ( 2)( 0x1) eRftTrue Member Info [14] btNil
4. ( 1)( 0) End Info symref 1
The GEM compilers don't and probably should.
The complication is that another "unknown" compiler, which produced an
object/executable in the ladebug test system uses that field as a count
of the number of enumerands. Since this information is redundant, I
believe that we should use the field as the acc compiler does, for the
length of the underlying datatype of the enumeration.
We will work this issue thru the Symbol Table Working Group to reach
an agreement as to what the field should actually represent...
Bob
|
| 846.6 | | TLE::DMURPHY | | Fri Feb 28 1997 09:19 | 16 |
|
Bob has indicated thatI've been doing some symbol table archeology
related to enumerations.
There have been a number of differing representations used by
various compilers c (acc, vc89, gem c) and c++ compilers.
Ladebug always got the C++ enumeration size correct so it was mostly
a matter of correcting our c enumeration processing.
I've made some corrections that tune and clean enum processing.
This is available in the 4.0-31 debugger.
Dennis
|
| 846.7 | Issue resolved | GEMGRP::MONTELEONE | | Thu Mar 06 1997 13:49 | 28 |
|
I have modified the symbol table produced by GEM as well.
GEM will now emit the size of the underlying datatype, in bytes, of an
enum in the value field of the stBlock scInfo local entry associated
with the enum, e.g.
enum uio_rw { UIO_READ, UIO_WRITE, UIO_AIORW };
2. ( 1)( 0x4) uio_rw Block Info symref 7
***
3. ( 2)( 0) UIO_READ Member Info [ 2] btNil
4. ( 2)( 0x1) UIO_WRITE Member Info [ 2] btNil
5. ( 2)( 0x2) UIO_AIORW Member Info [ 2] btNil
6. ( 1)( 0) uio_rw End Info symref 2
With older compilers, without this modification, nothing is emitted
in this part of the entry. Dennis modified ladebug to default to a
size of 4 bytes in this case.
With this change to GEM, languages which allow enum sizes other than 4
bytes will work correctly for those cases. For C, C++ etc. this change
will have no effect.
Bob
|