diff options
author | James Bottomley <James dot Bottomley at HansenPartnership dot com> | 2008-07-08 16:45:16 -0500 |
---|---|---|
committer | Frank Ch. Eigler <fche@elastic.org> | 2008-07-09 07:09:15 -0400 |
commit | 0b8f65798e0b454ccaab1d93925c3e034d4f5624 (patch) | |
tree | c55c5fe88afa3ffc5beddee997e19fa582a057ff /testsuite/parseko/cmdline10.stp | |
parent | d99a656a615dd78773316b7ac3972f3f1bcd5fca (diff) | |
download | systemtap-steved-0b8f65798e0b454ccaab1d93925c3e034d4f5624.tar.gz systemtap-steved-0b8f65798e0b454ccaab1d93925c3e034d4f5624.tar.xz systemtap-steved-0b8f65798e0b454ccaab1d93925c3e034d4f5624.zip |
Fix semantic error: empty struct
On Tue, 2008-07-08 at 14:57 -0400, Frank Ch. Eigler wrote:
> Hi -
>
> > you need a global cache for resolution ... it's not tied to any local
> > class instance. For class dwflpp it probably doesn't matter, since that
> > class is effectively static (by its survival for a session) but
> > logically because the DW_AT_declaration resolution is global, so should
> > the cache that does it.
>
> .. except it's not actually global, in that the kernel is not the only
> code that will go through the dwarf family of probe processors -
> user-space dwarf files are coming its way soon. Plus, if in the
> future the systemtap frontend attempts distributed probing of multiple
> target systems concurrently, "global" will be even more local.
In that context its as global as a lot of the other static data in that
structure (like this_session) which would also have to be fixed to do a
multiple target system.
Regardless, it can become per instance: it will only screw up if dwflpp
moves to being short lived.
James
Diffstat (limited to 'testsuite/parseko/cmdline10.stp')
0 files changed, 0 insertions, 0 deletions