llvm dev - Jan 2017 - Linking Linux kernel with LLD

>> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170131/a91cad77/attachment.html>

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>

On Tue, Jan 31, 2017 at 12:28:37PM +0100, Alexander Benikowski via llvm-dev
wrote:
> 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.
The problem with the linker script grammar is that "foo *" and
"foo*"
can't both tokenize to IDENTIFIER STAR, since in the context of a
wildcard expression they mean different things. It certainly can be
dealt with by making the tokens whitespace sensitive or doing post
processing, but it is certainly not a nice grammar.

Joerg