Em Thu, Jan 28, 2021 at 11:31:26AM +0800, Jin, Yao escreveu:
> On 1/28/2021 7:13 AM, Jiri Olsa wrote:
> > > @@ -709,6 +725,26 @@ int machine__resolve(struct machine *machine, struct
> > > addr_location *al,
> > > ret = strlist__has_entry(symbol_conf.sym_list,
> > > al_addr_str);
> > > }
> > > + if (!ret && al->map) {
> > > + snprintf(al_addr_str, sz, "0x%"PRIx64,
> > > + al->map->unmap_ip(al->map, al->addr));
> > > + ret = strlist__has_entry(symbol_conf.sym_list,
> > > + al_addr_str);
> > > + if (!ret) {
> > > + /* Check for hex without "0x" prefix */
> > > + snprintf(al_addr_str, sz, "%"PRIx64,
> > > + al->map->unmap_ip(al->map, al->addr));
> > > + ret = strlist__has_entry(symbol_conf.sym_list,
> > > + al_addr_str);
> > > + }
> > that seems tricky.. what if user specify more leading zeros,
> > I think it'd be better to search intlist instead
> > we could move all 'address' entries from sym_list to
> > new intlist (in symbol__init) and use it for this search
> intlist now only supports 'int' type.
> I'm considering to use 'long' to replace original 'int' in struct int_node.
> struct int_node {
> struct rb_node rb_node;
> - int i;
> + long i;
> void *priv;
> };
> On 32 bits platform, sizeof(long) is 4, and on 64 bits platform,
> sizeof(long) is 8. So that should be OK for storing the values such as
> pid/tid and address.
> I'm not very clear why currently it uses 'int' for i in struct int_node,
> maybe something I don't understand correctly. Please correct me if my
> understanding is wrong.
I think its ok to make it a long, it won't even enlarge the struct
because:
[acme@quaco pahole]$ pahole -C int_node ~/bin/perf
struct int_node {
struct rb_node rb_node __attribute__((__aligned__(8))); /*
0 24 */
int i; /*
24 4 */
/* XXX 4 bytes hole, try to pack */
void * priv; /*
32 8 */
/* size: 40, cachelines: 1, members: 3 */
/* sum members: 36, holes: 1, sum holes: 4 */
/* forced alignments: 1 */
/* last cacheline: 40 bytes */
} __attribute__((__aligned__(8)));
[acme@quaco pahole]$
:-)
- Arnaldo
