Hi Karthik, Thanks for your email .
> > Hi Michael, > > > > I had a comment / query regarding Stage 2 where you talk about > > Function cloning for different targets. > > > > I understand that the mechanism is to have a hidden function pointer > > that actually gets initialized based on the cpuid. > > > > I don't know if it is worth the effort to have debug info also > > enhanced to be such that a breakpoint put on the function my_min > > actually sets the breakpoint on any of the clones since the logic > > would be similar to the same. This sounds logically similar to the > > way that gdb currently handles breakpoints to multiple constructors. > > > > If the user has written the clone (for manual dispatch), then the > debug info would point to his code version. If it were generated > automatically (stage 2), the information would pertain to the function > cloned multiple times.The disassembly on those breakpoints might be > different, of course. All I am saying is that while doing the automatic dispatch try and have debug info in sync with the source written by the user. The disassembly is not what I am worrying about. Its only the ability to place breakpoints on all the clones. b do_min and voila gdb will automagically put breakpoints on all the clones. > > > The other option ofcourse is to fake debug information for such to > > actually set a breakpoint on the value of the function pointer that > > you so set up. I am no DWARF expert but there might be other folks on > > the list who might have better ideas about how to implement this. > > > > There is an idea to modify the dynamic linker to take advantage of the > detection; If in such case, setting a breakpoint would be easier. Then > we wouldn't require indirect calls either. The breakpoints can be set > in each of the clones, and they will be processed only after setting > up the pointer and their subsequent execution. Hmmm some kind of dl symbol resolver work where you have a cloned attribute for the symbol in ELF and figure out the best clone based on a runnable hunk which detects the best function . Might increase a bit of overhead at run time but its a one time expense. If we did prelinking that could be removed too. This might preclude my earlier statement. > > The idea is to make use of the debugging information as provided by > the inline-cloner. All I wanted was the requirement of debug information consistency to be a part of the proposal for the inline cloner. cheers Ramana > > > cheers > > Ramana > > Karthik > -- Ramana Radhakrishnan GNU Tools Celunite Inc.
