This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH 1/2] gcc symbol database
- From: Yunfeng ZHANG <zyf dot zeroos at gmail dot com>
- To: Dodji Seketeli <dodji at redhat dot com>
- Cc: gcc-patches at gcc dot gnu dot org, "Joseph S. Myers" <joseph at codesourcery dot com>, Dave Korn <dave dot korn dot cygwin at googlemail dot com>, Tom Tromey <tromey at redhat dot com>
- Date: Mon, 16 Jul 2012 18:09:20 +0800
- Subject: Re: [PATCH 1/2] gcc symbol database
- References: <CA+dUcj3G+MhuQSOQVo5H=wK7R8PQ0MSOdX_s0+xM_ZvXXJkCJQ@mail.gmail.com> <m3aa0j18gf.fsf@redhat.com> <CA+dUcj2p5DbZkJbzBcD955EGv6H9YGM1cQ38Bd9i8daUs4SgPA@mail.gmail.com> <CA+dUcj151pDt82wbG1OrwgUp=24TiPM2MkQkDiUdYBcatbhZGw@mail.gmail.com> <87mx332614.fsf@seketeli.org>
> 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