[M3devel] aligned_procedures: suggest "closure_marker_size"

[Rodney M. Bates]

Well, there are many aspects of the runtime organization that affect
m3gdb, and I am afraid they are scattered far and wide in the source
code, so it might be hard to do this systematically.  I have, on
one or two occasions in the past, put a comment in the compiler
or runtime source code, regarding some specific matter that affects
m3gdb.

Maybe I'll look for a good place to note about closure markers.

Olaf Wagner wrote:
> Shouldn't we insert a short version of this warning into the source
> code? Or is there no central location where it could be placed and
> will be noticed?
> 
> This is a non-obvious dependency, and though Jay and Tony will remember
> now, there may be others in a few years who don't.
> 
> Olaf
> 
> Quoting "Rodney M. Bates" <rodney_bates at lcwb.coop>:
> 
>> Before anybody fiddles with closure markers, *please* do *both* the  
>> following:
>>
>> 1)  Let me know.  M3gdb needs to both recognize and construct closures
>>     (and it currently does.)  Changing them will break it, unless it is
>>     modified accordingly.
>>
>> 2)  Make sure there is some reasonable way m3gdb can tell by looking at
>>     the object code being debugged, whether it was generated by a
>>     compiler version that uses the old or the new closure marker
>>     representation.
>>
>> I have worked hard to make m3gdb able to adapt to the various compilers
>> and versions, but periodically I get undermined on 1) and/or 2) above
>> by some quiet change somebody makes without thinking about m3gdb.
>>
>> Also, think about the implications on linking together code produced
>> by different compiler versions.  I am quite sure changing the closure
>> representation would mean *all* linked-in libraries would have to be
>> recompiled, along with the main program, by the same compiler version.
>>
>> Right now, closure markers are always the same size as pointers, and I 
>> think
>> there are multiple places in the compiler and runtime, in addition to 
>> m3gdb,
>> that rely on this.  They would all have to be located and fixed.  And I
>> don't think they all key off any single declaration, e.g.  
>> closure_marker_size.
>>
>> Jay K wrote:
>>> yes, but I think it is target-specific. IA64 would use 16 bytes.
>>> It isn't even in library code, but generated code.
>>>  - Jay
>>>
>>> ------------------------------------------------------------------------
>>> From: hosking at cs.purdue.edu
>>> Date: Wed, 27 Jan 2010 10:57:09 -0500
>>> To: jay.krell at cornell.edu
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] aligned_procedures: suggest "closure_marker_size"
>>>
>>> If we declare it as a 32-bit subrange it should just work, right?
>>>
>>> Antony Hosking | Associate Professor | Computer Science | Purdue 
>>> University
>>> 305 N. University Street | West Lafayette | IN 47907 | USA
>>> Office +1 765 494 6001 | Mobile +1 765 427 5484
>>>
>>>
>>>
>>>
>>> On 27 Jan 2010, at 09:01, Jay K wrote:
>>>
>>>    MIPS64, SPARC64 and maybe others could probably all benefit slightly
>>>    from
>>>      the closure marker being a 4 byte -1 instead of an INTEGER.
>>>               That is: 64bit architectures with a fixed size 4 byte 
>>>  instruction
>>>    where alignment is checked
>>>
>>>          That is, we should probably make their be a per-target variable
>>>    "closure marker size"
>>>      that is 4 for all current targets (IA64 should probably be 16 
>>> though),
>>>      though one would have to look into the various instruction 
>>> encodings.
>>>
>>>
>>>     - Jay
>>>
>>>
> 
> 
>