[PATCH 1/2] gcc symbol database

[Yunfeng ZHANG]

> But the "meaning" of the macro_end_arg event is really not clear to
> ...
> .... and so on.

Let's see a sample:
    #define Z(a) a
    #define Y Z
    #define X(p) p + Y
    X(1)(2);
With my solution, user get
    1) `X' -- leader macro token by macro_start_expand.
    2) `(', `1', `)', `(', `2', `)' -- macro tokens, by cb_lex_token.
    3) macro_end_arg.
    4) `1', `+', `2' -- macro replacement tokens, by symdb_cpp_token.
    5) macro_end_expand.
Item 2 is very important since if `X(1)' doesn't return any macro replacement
tokens, then `(2)' is a legal clause.
So please review my former mail again.

And it seems in gcc-4.8, gcc can trace several contiguous macro expansion
contexts can be associated to the same macro, so macro cascaded case has
disappeared.

> Please reply to these questions so that I understand why you need this
> field at all, rather than getting it from the linemap infrastructure
> by calling, for instance, linemap_expand_location.

linemap_expand_location can return the column and row of a token, not file
offset of its, there's no more explanation why using token file-offset, when I
started my project, I think file-offset is better than current
linemap+source_location because it costed less time to encode/decode
source_location field and can act just like previous solution, it's an
improvement to gcc too, with it gcc can store symbol+fileoffset to elf intern
for ld/gdb usage, of course, my database can benefit from  it -- less space and
use it as sort field directly. The only thing is it make challenge on gcc
infrastructure, so I leave it to a seperate patch called gcc_negotiate_patch
and hope to discuss the first two patches only.

And to the field file-offset, when the token is macro-replacement token, I
recommend token.file_offset = -1 * <leader macro token>.file_offset. I think
gdb is happy to this.

Sincerely
Yunfeng