Skip to contentSkip to conversation

Debug format problem with -ggdb flag

DISCUSSION Ian Thompson 3 participants 3 messages May 2, 2001 – May 8, 2001 MIPS

lore
Share & tools
lore
#0 lore raw

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
#1 lore raw
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_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?

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

#2 lore raw

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)