Re: RFD: New language to write dissectors

[Richard Sharpe <realrichardsharpe () gmail com>]

On Sun, Jul 15, 2012 at 2:20 AM, Jakub Zawadzki
<darkjames-ws () darkjames pl> wrote:
> On Sun, Jul 15, 2012 at 10:28:23AM +0100, Tyson Key wrote:
> > What about implementing a compiler that generates C dissector source code,
> > from NPLt m, or WSGD dissector code?
>
> Yes, I plan to have one:
>
> > > But anyway we need compiler to C. For prototype (does it work?) and later
> > > as fallback for people who don't have LLVM.
>
> > Or would that be overkill for what we're trying to do?
>
> It depends what we're trying to do ;-)
>
> For me compiler to C is must-have, and even if we write only it.
> It'll help to fix some bugs, like yours bug #6520.
> Translating 4K lines of NPL code to C looks stupid to me, and it'll be great to have
> automatic translator.
> (of course if we base grammar on NPL).

Well, it might look stupid to you, but it represents a quick way to
get simplify the process of producing dissectors, and writing a
dissector is very boring.

When I wrote the initial SMB dissector I wrote a language to describe
the SMB protocol, and wrote a parser in Perl to parse the description
into an AST and spit out a dissector.

The same could be done with NPL, in my view, but it misses something
important. Compiling an NPL-described protocol into a Wireshark
dissector loses a lot of information.

On the other hand, having an NPL compiler would make it easier for
others to create new dissectors.

Of course, it would be useful if we had access to ParserLanguage.Doc.

In addition, to produce Wireshark C-based dissectors from NPL would
seem not to require LLVM. A simple recursive descent parser should
suffice.

> Later we could support interpreting (or JIT) NPL, which would make
> easier (and much faster) developing new dissectors.
>
> In next step we could generate dependency graph (field foo.B exists only
> when field foo.A = 5, etc...) and field to offset (field foo.A @ 10B, field foo.B @ 20B)
> or other informations which would speedup filtering.
>
> (Or generate completely new code like Guy suggested).
>
> and here we can start rewriting existsing old dissectors to new language.
>
> Anyway, Lot of possible work, which some might be seen as overkill ;-)
> ___________________________________________________________________________
> Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
> Archives:    http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>              mailto:wireshark-dev-request () wireshark org?subject=unsubscribe



-- 
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe