Debug format problem with -ggdb flag
Hi,
I'm running into problems with the debug information that is generated by the kernel compilation process. Basically, I'm seeing that multiple function symbols have the same begin address in the .mdebug section. For example -- the init_arch and r3081_wait functions in my build have differnet addresses as far as compilation is concerned, and code executes correctly. When I look into the .mdebug section, I see that the begin, end, stab, and external records are all correct for the r3081_wait function, but that the begin record for the init_arch function is the same as that for the the r3081_wait function! This in turn seems to be causing the stab and external records to be incorrect, causing symbolic problems in my debugger.
I've traced the problem down, and it seems to be a side-effect of partial linking. When the linker links multiple .o files into another .o file (which is later used as input to another ld command), the debug records inside the .mdebug section are getting corrupted. Has anyone run into this problem before? Any suggestions of other flags I can pass into the partial link that may help? I'm using the mipsel rpm of binutils 2.9.5-3. Or, are there any alternatives to partial linking that don't involve a lot of makefile manipulation?
I've tried using the -gcoff option to remove the stab records, but that option does not allow the 2.4 kernel to compile under egcs 2.91.66.
Any ideas? Thanks,
-ian
Signature · 4 lines
---------------------------------------- Ian Thompson tel: 408.952.2023 Firmware Engineer fax: 408.570.0910 Palmchip Corporation www.palmchip.com
Quoted 21 lines · Ian Thompson
I'm running into problems with the debug information that is generated by the kernel compilation process. Basically, I'm seeing that multiple function symbols have the same begin address in the .mdebug section. For example -- the
init_archandr3081_waitfunctions in my build have differnet addresses as far as compilation is concerned, and code executes correctly. When I look into the .mdebug section, I see that the begin, end, stab, and external records are all correct for ther3081_waitfunction, but that the begin record for theinit_archfunction is the same as that for the ther3081_waitfunction! This in turn seems to be causing the stab and external records to be incorrect, causing symbolic problems in my debugger.I've traced the problem down, and it seems to be a side-effect of partial linking. When the linker links multiple .o files into another .o file (which is later used as input to another ld command), the debug records inside the .mdebug section are getting corrupted. Has anyone run into this problem before? Any suggestions of other flags I can pass into the partial link that may help? I'm using the mipsel rpm of binutils 2.9.5-3. Or, are there any alternatives to partial linking that don't involve a lot of makefile manipulation?
Quoted 2 lines
I've tried using the -gcoff option to remove the stab records, but that option does not allow the 2.4 kernel to compile under egcs 2.91.66.
So then is a binutils and not a compiler problem. What binutils are you using? Binutils 2.8.1 which I'm still recommending (mostly to avoid sending people into a maze of version dependencies) is getting dated and the bug may well have been fixed in the meantime.
Ralf
Re: binutils 2.8.1 problems
Quoted 4 lines
So then is a binutils and not a compiler problem. What binutils are you using? Binutils 2.8.1 which I'm still recommending (mostly to avoid sending people into a maze of version dependencies) is getting dated and the bug may well have been fixed in the meantime.
I have met a weird bug in binutils 2.8.1 on mips lately: when using ".weak" directive in some module which make use of the same asliased symbol, during linkage the symbol doesn't get relocated to a "strong" symbol:
----------------------
in foo.c:
----------------------
extern void bar();
void foo(){
printf("A\n");
}__asm__(".weak bar; bar = foo");
void f1(){
bar();
}
-----------------------
in bar.c:
----------------------
void bar(){
printf("B\n");
}
----------------------
in main.c:
----------------------
extern void bar();
extern void f1();
int main(){
f1();
bar();
}
-----------------------
This code produce printout of
A
B
since f1() always calls foo() no matter that bar() is defined outside. AFIAIK, there is no ".weakext" macro in 2.8.1.
Using objdump on foo.o I see there is no relocation entry for bar, however using gas-2.10 on exactly same assembly does produce relocation entry. So it must definitely be a "gas" problem.
Sincerely yours,
Michael Shmulevich
______________________________________
Software Developer
Jungo - R&D
email: [email protected]
web: http://www.jungo.com
Phone: 1-877-514-0537(USA) +972-9-8859365(Worldwide) ext. 233
Fax: 1-877-514-0538(USA) +972-9-8859366(Worldwide)