Re: Question re symbols, symtabs and blocks

On Thu, 2024-08-29 at 10:41 -0400, Simon Marchi wrote:


> 
> On 2024-08-28 06:08, Jan Vrany via Gdb wrote:
> 
> > Hi,
> > 
> > in GDB, are there any constraints for blocks belonging to
> > to particular symtab? Like: must each blocks' start and end address
> > be within its superblocks' start and end address?
> 
> 
> This is how my mental model works, that children blocks must be
entirely
> within their parents (even considering that blocks may be
> non-contiguous), but I don't have proof of that.  It's just what
would
> make sense to me.


Thanks, it makes sense.



> 
> > Also, must blocks of different symtabs be always disjunct
> > (meaning, their start-end ranges must not overlap)?
> 
> 
> What kind of symtab are you talking about? "struct symtab" or "struct
> compunit_symtab"?  I don't think that blocks care about "struct
symtab".


Sorry. I meant compunit_symtab.


> However, blocks are part of a blockvector, and each compunit_symtab
has
> its own blockvector.  So my intuition is that blocks belonging to
> different compunit_symtabs should be disjoint, as compilation unit
> address ranges are typically disjoints.  

> But then I don't know if there

> are weird cases, 


Yeah, I have somewhat weird use case where I have an  
executable that contains a static buffer which  
is at runtime filled with with JIT-compiled code.  
In order to debug that jitted code, I create  
compunit_symtab, block, symtab, linetable and  
all that and for example "b jitted_function" but   
"disass jitted_function" disassembles the whole  
buffer. But looking at code more closely, it seems  
"disass" uses different way to figure out what range  
to disassemble.

Anyways, I'll try to rework the code to add blocks for  
jitted code to the existing compunit_symtab rather than  
creating new one.

Thanks!

Jan


> for instance I don't know how LTO affects this, if
> compilation units start sharing some code.
> 
> Simon