[M3devel] merging gdb from 6.4 to 7.1? More info on LHS_SYMBOL_TYPE

[Rodney M. Bates]

Rodney M. Bates wrote:
> I have been thinking about doing this myself for some time, but up to
> now, have not had the time.  I can certainly help, if you want to do it,
> or maybe take it on myself.  I think I will be having more time soon.
> I have done it a couple of times before.  A few things can be hard to
> figure out, because they rework existing stuff in gdb and it's hard to
> dig out what the new equivalent of the old mechanism is.  A lot of the
> M3-specific code I either heavily modified or wrote.
> 
> Jay K wrote:
>> The merge of m3cc/gcc from 4.3.0 to 4.3.5 went well enough.
>>
>> I'll volunteer to merge m3gdb from 6.4 to 7.1.
> 
> BTW, there is now or will be very soom, a 7.2 gdb.
> Also, the latest gdb does reverse debugging, by recording
> snapshots during the forward run.  This would be a *very*
> nice feature to have for Modula-3.
> 
> 
>>
>> Are people interested?
>>
>> I saw some mention of 6.4.3 in our history.
>> But there's no release called that.
>> What is it?
> 
> I don't remember anything about this.
> 
>>
>> Some of the conflicts are about  SYMBOL_TYP vs. LHS_SYMBOL_TYPE.
>> What that a deliberate important change on our port?
> 
> Yes, this is my change, very deliberate, and gets around a nasty
> group of dangling pointer bugs.  I would have to took at it again,
> but it used to cache a pointer to a gdb type struct, lazily looked-
> up the first time, right into an existing field of another gdb struct.
> When you rerun, gdb reloads the referent structs of such pointers,
> leaving them dangling.  Or maybe I am mixing up two different
> problems.  Anyway, the two macros are essential.
> 
> I have long thought it might be nice to design a better mechanism,
> but it's not simple.  I strongly recommend not messing with it during
> merging to a newer gdb.  Save that for a subsequent job with a separate
> CVS tag.  It's only a performance matter, and except for debugging work
> that proceeds without requiring user-types commands all the time, it
> scarcely matters.

I looked back at this.  Actually, I am not sure the split of SYMBOL_TYPE
into LHS_SYMBOL_TYPE and SYMBOL_TYPE was my original doing, but
part of the original mods from stock gdb to m3gdb.  I just remember
having to figure out in a number of places, which occurrences should
be which macro.

In stock gdb, there is only SYMBOL_TYPE.  It expands to an lvalue that
denotes the type member of a symbol.  It is used both to assign to and
to fetch that member.

SYMBOL_TYPE, in m3gdb is effectively an accessor or getter function,
but it does some computation to resolve the type using a UID, rather
than just fetching a field.  it expands to a non-lvalue.  Use it to get
the type when you have a symbol.

In m3gdb, LHS_SYMBOL_TYPE is the corresponding mutator or setter function.
I think it's actually the same macro as SYMBOL_TYPE is in gdb.  Places in
stock gdb that assign to the type field need to be changed to use
LHS_SYMBOL_TYPE in m3gdb, to work.  Except for a couple of places
where a null is assigned, all uses of LHS_SYMBOL_TYPE are in code
that is non-m3gdb-specific.

I guess it would make future merges easier if LHS_SYMBOL_TYPE were
changed back to the original SYMBOL_TYPE and the M3-specific accessor
were renamed to something else, perhaps M3_SYMBOL_TYPE or
M3_RESOLVE_SYMBOL_TYPE.  This would move the changes to be merged
out of gdb source files that are not m3gdb-specific.

The caching that caused the dangling pointer bugs can be seen in the
m3gdb version of the definition of SYMBOL_TYPE, but is it commented
out.  The resolution is always done over every time.

If only gdb had a garbage collector, this would be easier.  Actually,
I suppose it would need weak references to make the caching work.

> 
> Also, we would be a lot better off to dump stabs+ and use whatever
> latest version of dwarf that gdb already has support for.  But that
> is also a job that should be done separately, with its own tag, after
> a new merge is working with the existing mechanisms.
> 
> 
>>
>> Thanks,
>>  - Jay
>>
>>
>>
>>
>>                            
>