https://sourceware.org/bugzilla/show_bug.cgi?id=33186
--- Comment #3 from Pavel Labath <labath at google dot com> --- (In reply to Indu Bhagat from comment #2) > Right, most users will only ever see (and need) SFrame sections with name > ".sframe". That's true, but you could also say that (in the future, when everything generates SHT_GNU_SFRAME), most users will only see SFrame sections with SHT_GNU_SFRAME. > > So then, taking a step back though, I am curious if you have some specific > usecase on hand, where SFrame sections with a name distinct from .sframe is > created or multiple SFrame sections are generated per object. > > For ET_DYN, ET_EXEC, there should be only one SFrame section with sorted > FDEs for it to be useful for fast stacktracing. For ET_REL too, I dont see > why multiple SFrame sections will be needed. Is that complexity necessary ? No, I don't have an real use case in mind -- I'm just thinking about the edge cases. We now sort of have two ways to identify an sframe section (via its name and via the section type), so I'm wondering which one should we trust more. So like, imagine we had an object file with two sections: one called ".sframe" but with a random type; and another, whose type was SHT_GNU_SFRAME, but it was *not* called ".sframe". Which of these two should be considered the real SFrame section? To me, it seems more natural to trust the section type more than the section name. It's not an exact equivalent, but I think it's sort of similar to how "readelf -d" will dump the dynamic section even if its not called ".dynamic" (even though it will print some warning about the file not containing a dynamic section). In this case it will not go through the section table, but rather find it using the program headers, but I think it still illustrates the point of trusting magic constants (PT_DYNAMIC in this case) more than names. I definitely don't have a use case for more than one sframe section per file. The idea to dump all of them is just an acknowledgement of the fact that you can't prevent someone from creating a file with more than one SHT_GNU_SFRAME section per file (for better or worse, you also can't prevent someone from creating a file with two sections called ".sframe"). I'm not trying to invent unwind semantics for this case, but for readelf, I think the best thing one could do in this case is to dump both sections. I don't know how complicated it would be to implement this, but I'm hoping it wouldn't be too hard given that readelf already can dump more than one SFrame section when explicitly asked for it (readelf --sframe=.sect1 --sframe=.sect2) -- You are receiving this mail because: You are on the CC list for the bug.
