> 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
