This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: loc2c-test with dwarf_entry_breakpoints


Hey Mark,

Continuing from our thread earlier, 

> Nice thanks. Two comments:
> 
> - When you found the matching function name you can return DWARF_CB_ABORT
>   to indicate you are done so you don't have to handle any other functions.
> - There doesn't seem to check whether the function was actually found.
>   Initialize a.pc to zero and produce an error if it is still zero
>   after the dwarf_getfuncs () loop.

Fixed in the first patch attached.
> 
> > > Maybe as bonus allow @functionname to select the (first) breakpoint
> > > address (if there are multiple just list them to the user and give up).
> > > And for extra bonus allow functionname+offset so you can easily see the
> > > variables location expressions at an address a bit inside the function
> > > (which would be helpful to simulate fche's +5 hack).
> > 
> > Given the above is acceptable I'll implement this next week
> 
> That would be great, that will make loc2c-test much more useful for
> testing which dwarf location expressions are produced where.

Pending the former patch I've attached loc2c-test.patch.1 (which builds
on the first patch), implementing @functionname to use the first
breakpoint address and exiting with a message if there are multiple
breakpoints.

Cheers,

Lukas

Attachment: loc2c-test.patch
Description: Text document

Attachment: loc2c-test.patch.1
Description: Unix manual page

Attachment: pgp00000.pgp
Description: PGP signature


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]