> Yes, but I would expect this table lookup to be faster than going to the > disk to read the CU DIE and abbrev in order to check for the attribute. > OTOH, I suppose you need to read it anyway if you want to check somehow > whether you should trust the pub* information.
Right. I also need to read the top-level DIE to get the range list for the CU. >> Building >> the .gdb_index in gold is still too slow, but these attributes help >> make it a bit faster than it was without them. >> >> Are these two attributes a showstopper issue for you? > > No, I'm just reluctant to add more relocations. Could we make them just > flags? That might be workable. Let me take a look at the gold changes I'd need to make for that. They don't have to be relocations, though -- since they're only used by the linker, a raw section-relative offset would be sufficient. >> Yes, I understand that's broken, but there are no consumers at this >> point that make any use of that offset. Would it be acceptable if we >> just put 0 there? (Given that I expect .debug_pub* to go away soon, I >> don't think it's worth the trouble of filling in the offset with >> anything more meaningful.) > > I wouldn't expect it to be much harder to put the skeleton there than plain > 0. I was concerned that we might not always have a skeleton type to point to, but I confess I haven't looked closely enough to know whether that's a valid concern. -cary
