Debug format problem with -ggdb flag

Debug format problem with -ggdb flag

[Ian Thompson]

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

-- 
----------------------------------------
Ian Thompson           tel: 408.952.2023
Firmware Engineer      fax: 408.570.0910
Palmchip Corporation   www.palmchip.com

Re: Debug format problem with -ggdb flag

[Ralf Baechle]

On Wed, May 02, 2001 at 04:31:03PM -0700, Ian Thompson wrote:

> 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.

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

[Michael Shmulevich]

> 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: michaels@jungo.com
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)