Problem with linking a debug library into a project

I have written a software debugger for Arduino, designed for novice users to be able to single-step their sketches and inspect variables, without having to install big applications like Atmel Studio or Eclipse. I have written a simple-to-use user Windows interface (written in c#) which talks to the Ardunio via the AVR debugger (avr-gdb.exe) and allows setting of breakpoints etc. For the Arduino itself I have written (or, rather, modified someone else's) debug stub which uses interrupts to talk to avr-gdb.

It all works fine if I have all the debug stub files loaded into my project as 'added' C++ files (and one assembler file). But if I build a library with the stub files , there is a problem.

#include "qdebug.h"

setup()
{
    Qdebug mydebug;
    .....
}
loop
{
    .....
}

This works OK insofar as the resulting sketch will talk to avr-gdb. When I break into the program, it's running some simple test code inside 'loop()' (as expected). As yet I haven't found a way of getting it to stop at the second line of 'setup', i.e. after calling the Qdebug constructer. That's not my question here but it's answer might be easier if I can place the Qdebug call where it should be, i.e. before 'Setup()':

#include "qdebug.h"
Qdebug mydebug;

setup()
{
    .....
}
loop
{
    .....
}

With this arrangement, avr-gdb simply fails to connect to the running sketch. Now, the last line of the QDebug constructer is 'sei()', which sets off the connection route to avr-gdb. By looking at the disassembled code, I note that in the Arduino core file 'wiring'c' there's this:

void init()
{
    // this needs to be called before setup() or some functions won't work there
    sei();
        ....
        ....

so it's possible that the problem is that with my constructor called before 'setup()', the interrupts start too early and generally mess things up.

In conclusion, what I'm looking for is a way to include the library and call it's constructor before setup() is called, without having other core code stopping it functioning correctly. Hope this makes sense!

quilkin: In conclusion, what I'm looking for is a way to include the library and call it's constructor before setup() is called, without having other core code stopping it functioning correctly.

Why?

Arduino users are used to calling a startup method in setup. The method even has a common name...

void setup( void )
{
  mydebug.begin();
}

Java can do this via a static initialization block, but it has to be used with care because there may be dependencies that have not yet been initialized.

I am just guessing here but I would bet that C++ has a way to do this same thing, possibly with the same danger.

[quote author=Coding Badly date=1491500324 link=msg=3209600] Why? [/quote] Maybe I didn't explain the situation enough! Having the debug initialiser in Setup() gets in the way of landing the user , by default, at the beginning of Setup(), which seems the logical place to start. I also thought that not having to modify Setup() or Loop() was just a cleaner approach.

Anyway I've solved it now, thanks; funny how writing down problems often helps you fix them. It was the early call to sei() in the core code causing the difference - I've just added a cli() before initialising the debug stub, then sei() again when it's ready to go.