Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [linuxtools-dev] Change ValgrindCoreParser to support different valgrind output format

----- Original Message -----
> From: "Doug Schaefer" <dschaefer@xxxxxxx>
> To: "Linux Tools developer discussions" <linuxtools-dev@xxxxxxxxxxx>
> Sent: Thursday, December 5, 2013 8:45:56 PM
> Subject: Re: [linuxtools-dev] Change ValgrindCoreParser to support different valgrind output format
> 
> Of course we¹d start contributing improvements to the rest of the valgrind
> plug-ins to make things better once we can use it. And yes, I¹m cursing
> our guys for changing the output format but they say it¹s better.
> Hopefully they will contribute it upstream, at which time you¹ll need this
> extensibility anyway to deal with different valgrind versions.

In case you are not aware of it - valgrind is gonna have a devroom at FOSDEM, so this is probably good opportunity. 
More info at https://lists.fosdem.org/pipermail/fosdem/2013-October/001871.html .

Alexander Kurtakov
Red Hat Eclipse team

> 
> Doug.
> 
> On 12/5/2013, 1:05 PM, "Aleksandar Kurtakov" <akurtako@xxxxxxxxxx> wrote:
> 
> >----- Original Message -----
> >> From: "David Meng" <dmeng@xxxxxxxxxxxxxx>
> >> To: linuxtools-dev@xxxxxxxxxxx
> >> Sent: Thursday, December 5, 2013 7:32:08 PM
> >> Subject: [linuxtools-dev] Change ValgrindCoreParser to support
> >>different valgrind output format
> >> 
> >> 
> >> 
> >> Hello,
> >> 
> >> 
> >> 
> >> We have our own version of valgrind executable running on a remote
> >>target,
> >> however the output format is a little different from the standard
> >>format,
> >> which cause trouble parsing the filename and line number using
> >> ValgrindCoreParser.
> >
> >In general, adding support for custom(not-upstream) formats is not of
> >interest, but if one is willing to help us making better tool we are more
> >than interested to work together.
> >
> >> 
> >> 
> >> 
> >> There are two possible solutions:
> >> 
> >> 1) Move ValgrindCoreParser to a public package and introduce a new
> >> ŒparseFilename¹ method
> >
> >What semantics would you put in such a method? Do you mean
> >parse(fileName) or parseFilename as a workaround to plugin currently
> >retrieving pid from filename and if you use different naming scheme it
> >will fail for you.
> >
> >> 
> >> 2) Modify the ValgrindCoreParse to support different formats
> >> 
> >This might be a better option if done carefully to really define and
> >document good API for valgrind plugin.
> >> 
> >> 
> >> Could you please advise what the best solution would be for this case?
> >
> >Start with opening a bug about that.
> >
> >Alexander Kurtakov
> >Red Hat Eclipse team
> >
> >> 
> >> 
> >> 
> >> Thank you!
> >> 
> >> 
> >> 
> >> David
> >> 
> >> 
> >> ---------------------------------------------------------------------
> >> This transmission (including any attachments) may contain confidential
> >> information, privileged material (including material protected by the
> >> solicitor-client or other applicable privileges), or constitute
> >>non-public
> >> information. Any use of this information by anyone other than the
> >>intended
> >> recipient is prohibited. If you have received this transmission in
> >>error,
> >> please immediately reply to the sender and delete this information from
> >>your
> >> system. Use, dissemination, distribution, or reproduction of this
> >> transmission by unintended recipients is not authorized and may be
> >>unlawful.
> >> 
> >> _______________________________________________
> >> linuxtools-dev mailing list
> >> linuxtools-dev@xxxxxxxxxxx
> >> https://dev.eclipse.org/mailman/listinfo/linuxtools-dev
> >> 
> >_______________________________________________
> >linuxtools-dev mailing list
> >linuxtools-dev@xxxxxxxxxxx
> >https://dev.eclipse.org/mailman/listinfo/linuxtools-dev
> 
> _______________________________________________
> linuxtools-dev mailing list
> linuxtools-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/linuxtools-dev
> 


Back to the top