[M3devel] LINUXLIBC6

[Jay K]

Again, stabs in the context of Modula-3/cm3cg/m3gdb I believe has almost nothing to do with stabs in any other "normal" context.
We use it just to transport our own custom data.
That data may or may not be compromised by optimization.


For example, what are the types of parameters to functions?
Assuming the optimizer does not change the signature of any function?


This data is NOT available at all to stock gdb for Modula-3.
It is available to m3gdb via a completely custom/private data form.


And by "types" here, I mean pretty complete information -- if records are involved,
then all their fields are described.


It is likely the case that on systems that don't support stabs (MacOSX/Darwin), the custom data
could be transported via some other mechanism. Heck, put it in data files on the side.


ok ok, the data does have *something* to do with stabs, but not much.
e.g. that function signature is associated with a function at some address/offset.


Line number information is presumably represented in dwarf/stabs/coff "natively" via gcc's normal paths,
as we do give gcc source line information (at least mostly).


It is when you go beyond mere line number information where things are different.


 - Jay



________________________________
> Subject: Re: [M3devel] LINUXLIBC6 
> From: dragisha at m3w.org 
> Date: Mon, 21 May 2012 10:02:11 +0200 
> CC: dabenavidesd at yahoo.es; m3devel at elegosoft.com 
> To: jay.krell at cornell.edu 
>  
> You can't generate reasonable stabs based debug info and expect it to  
> survive optimization steps. DWARF is another thing, optimizer gets data  
> to work on, as well as code. DWARF decorations have a chance to survive  
> optimizations. Stabs, esp heavily idiosyncratic ones - do not. 
>  
> On May 20, 2012, at 11:28 PM, Jay wrote: 
>  
> For dwarf et al: there "nothing" to it: "just" generate reasonable  
> "code" (LLVM whatever, gcc "tree", C, etc) and the next level down  
> handles it. Er, but for some bigger & smaller problems. 
>