Hi Uli, On Thu, 14 Dec 2017 16:44:31 +0100 (CET) "Ulrich Weigand" wrote: > Philipp Rudo wrote: > > > ... I moved init_osabi so early so only the functions which are overwritten by > > the osabi (or needed for other reasons like the dwarf unwinder) are set before > > it. I hoped this would make the gdbarch_init clearer as the list before > > init_osabi is shorter and you can say for sure that all hooks set after are > > shared between all OSes. So you are not surprised with some special cases you > > don't expect. Of course this also means that if you want to overwrite a > > function you first have to move it before osabi_init. For me that is a small > > price to pay. > > > > However when you prefer the osabi_init to be done later I can move it to where > > linux_init_abi is called today. In that case i can avoid moving > > dwarf2_append_unwinders. Otherwise I will move the other > > dwarf2 related routines up. Just tell me what you prefer. > > Yes, please do move init_osabi to be done later. I played around and got the fixup patch attached. For some reason however now some python testcases fail. In particular FAIL: gdb.python/py-breakpoint.exp: test_bkpt_qualified: qualified false FAIL: gdb.python/py-breakpoint.exp: test_bkpt_qualified: qualified true FAIL: gdb.python/py-breakpoint.exp: test_bkpt_qualified: qualified true and explicit FAIL: gdb.python/py-breakpoint.exp: test_bkpt_qualified: qualified false and explicit FAIL: gdb.python/py-breakpoint.exp: test_bkpt_qualified: -q in spec string and qualified false each with the error message Traceback (most recent call last):^M File "", line 1, in ^M TypeError: argument 10 (impossible)^M Error while executing Python code.^M I have absolutely no clue what causes this as the gdbarch'es (with and without the patch) seem to be identical. As this is my last day before the Christmas vacation I cannot have a closer look at it right now. So finalizing the split up will have to wait until next year. Merry Christmas and see you next year Philipp