[llvm-dev] Linking Linux kernel with LLD

Alexander Benikowski via llvm-dev llvm-dev at lists.llvm.org
Tue Jan 31 03:28:37 PST 2017


I am unknown to all the stuff happening in and around LLVM, as i am
interested in the project but had not time to dig in, yet. Just reading
here and there a bit. But i wanted to share my 2 cents on the Lexer topic.
I have written multiple lexer/parser for private purpose and recently one
for our product to compile Mathematical expressions into an internal format
for evaluation.

So far i usually write a Lexer which does the tokenizing on very basic
rules. What is a number, what is a single symbolor a whole Identifier, and
what to skip(like spaces). Each token has metadata like relative offset to
the previous one. A Parser on top uses the lexer to process the Tokens. My
approach of storing the relative offsets allows to regroup tokens to single
symbols respecting whitespaces at a later time.

Let's say we have(without quotes ofcourse)
"2 * 3"
The lexer always produces 3 tokens, 2 with the content and identification
for a numeraical value(for 2 and 3) and one for an operator token. I can
now either go for it and use these tokens to process as part of a
mathematical evaluation or reconstruct the original stream. However this
means that the stream below:
"(foo)"
is always lexed to 3 tokens (2 for the brackets and one for the
identifier). The Parser then has the context on how to process these tokens.

My example has some drawbacks. By always splitting into the basic tokens
and possibly regrouping you'll need more rellocations for processing. And
therefore losing performance. However i find this approach simple to test
and write tests for.

2017-01-31 10:47 GMT+01:00 George Rimar via llvm-dev <
llvm-dev at lists.llvm.org>:

> >> I have a question also. You added -m elf_i386 to workaround emulation
> conflict issue in LLD, do you know
> >> does output produced by BFD boot fine after that change ?
> >Doesn't seem to affect BFD at all.
>
> Thanks !
>
> ​George.
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170131/c770d45f/attachment-0001.html>


More information about the llvm-dev mailing list