Mail Archives: djgpp/1997/07/09/23:39:31
> I'll try (and it DOES work correctly).
As seems to be typical for me, immediately after I hit the send button
for a djlist message I come up with a new idea to try that
usually (this time anyway) straightens things out.
> static void __attribute__((constructor)) set_x(void)
Ahh, i didn't think it looked like valid C code. Leave it to gnu
to have an attribute to do it.
> It should be working for C++ (I've never had any problems).
Turns out my libc was broken (again...). I think I must have left
it compiled by my unreleased pgcc 0621 snapshot, which was really lousy.
I pulled _main.c into my test directory and compiled it into my
test application and everything worked as it should.
> But I have
> no idea what gcc does with what you were doing in C.
Doesn't compile.
> (actually, gcc places a call to _main() at the beginning of main(), but
> libc calls _main itself (don't know why (dj, can you say why?)) and so
> _main() also has a test to see if it has done the .ctor calls yet).
I noticed this too while debugging, strange...
> As to why you can't break on f(), I don't know. If it was with the C
I guess I just don't understand the label names. I tried to type
break _GLOBAL_$I$f__Fv
which was exactly what I saw in the assembly file. GDB just wants
the f__Fv part though. I examined the first pointer from djgpp_first_ctor
and then told gdb to break on that absolute address and it told me it was
line 4 in function f__Fv which clued me in.
Now that I've got this fixed I can go back to trying to figure out
why my pgcc isn't emitting a .section ctor at the end of the
file when it should..
Thanks
Andrew
- Raw text -