[Dwarf-discuss] dwarf information for mutiple statements at thesame line.

[Ron Brender]

Michael Eager wrote:
> Keith Walker wrote:
>>  
>>
>>     I have a question about how dwarf deals with multiple statements at
>>     one line. For example, suppose there is code
>>
>>     f1(); f2(); 
>>
>> One sort of related question that I have here is what line/column 
>> numbers should the compiler generate when multiple statements 
>> are created by macros.
>>  
>> Suppose that we have a macro:
>>  
>>     #define    MY_CODE    f1(); f2();
>>  
>> and then some code that uses the macro:  
>>  
>>     MY_CODE
>>  
>> Now I can see that the line number could be that in which the use of 
>> MY_CODE occurs.    However it isn't obvious to me what the column 
>> information (if any) should be in this case.    Any suggestions?
>>  
>> Keith
> 
> The source/column information should be for the line which contains
> the macro invocation.  If the invocation is in column 1, as in your
> example, that's the value to use.  Many compilers do not generate
> any column info.
> 
> While macros may expand into additional statements, these are not
> present in the source.  (They may only be represented as sequences
> of tokens and never have even a transient textual existence.)
> 

I believe Michael is correct. Basically, just treat every token in the 
macro expansion as though it occurred at the location of the macro 
invocation (although you can get a bit fancier for any formal parameter 
substitions in the body by using the location of the actual in the 
invocation--maybe or maybe not worth the trouble).

If you work at it, it is possible that *some* macros might be made to 
"look" like inlined procedure calls with the macro definition serving as 
a kind of abstract origin. But this is really reaching and not obviously 
worth the implementation cost, even when possible. You'd end up 
inventing a lot of DWARF structure to fake that model and/or extending 
the existing DWARF mechanisms.

There are two basic approaches to representing procedure inlining. One 
is based on what I'll call "source tree copying" technology. DWARF falls 
in this camp. It works quite well for real inlining but does not extend 
very well to C-like macros. (It does OK for Ada generics and C++ templates).

The other approach is a more token stream based approach whose debugging 
representation is almost completely embedded in the line number table. 
This approach is described in outstanding detail in the Zellweger thesis 
(Zellweger, Polle Trescott.  Interactive  Source-Level Debugging of 
Optimized Programs. Ph.D. Dissertation, University of California, Xerox 
PARC CSL-84-5, May 1984. 270pp.) which I highly recommend reading, even 
if using the DWARFsih model. I think this model can treat C-like macros 
quite well.

Ron