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] |
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] |