Compiling kernel with -g option.

Compiling kernel with -g option.

[Subodh Nijsure]

Sorry if this is "basic" question but I looked through mailing and couldn't
find a solution.

When I compile kernel and some of my own modules together I get tons
of error like --

relocation truncated to fit: R_PPC_REL24 copy_to_user
..
..

However if I compile everything with -O2 options everything works fine,
any way I can fix this so I can debug things....

Thanks.

/Subodh


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Compiling kernel with -g option.

[Tom Rini]

On Tue, Nov 06, 2001 at 04:12:13PM -0800, Subodh Nijsure wrote:

> Sorry if this is "basic" question but I looked through mailing and couldn't
> find a solution.
>
> When I compile kernel and some of my own modules together I get tons
> of error like --
[snip]
> However if I compile everything with -O2 options everything works fine,
> any way I can fix this so I can debug things....

Did you try to use just -g ?  (Ie not -O2 -g ...).  You _need_ at least
-O1 to compile a kernel.

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Compiling kernel with -g option.

[Jerry Van Baren]

Relocation truncated to fit errors are typically caused by your executable
exceeding 16Mbytes (24 bits) in size (assuming it isn't caused by missing
modules and thus unresolved references).  It looks to me like more
aggressive optimizing (O2) is sufficient to get you below the 16Mbyte
mark.  Can you leave some things (less necessary or already debugged
things) out of your kernel or modularize them so that they don't have to be
linked in?

You might try making the code not relocatable to avoid the 24 bit address
limitation on position independent code, but I don't have any experience
with that option and it may cause all sorts of things to break.

 From the gcc manual, "IBM RS/6000 and PowerPC Options"
-mno-relocatable

On embedded PowerPC systems generate code that allows (does not allow) the
program to be relocated to a different address at runtime. If you use
`-mrelocatable' on any module, all objects linked together must be compiled
with `-mrelocatable' or `-mrelocatable-lib'.

gvb


At 04:12 PM 11/6/01 -0800, Subodh Nijsure wrote:

>Sorry if this is "basic" question but I looked through mailing and couldn't
>find a solution.
>
>When I compile kernel and some of my own modules together I get tons
>of error like --
>
>relocation truncated to fit: R_PPC_REL24 copy_to_user
>..
>..
>
>However if I compile everything with -O2 options everything works fine,
>any way I can fix this so I can debug things....
>
>Thanks.
>
>/Subodh
>
>


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

RE: Compiling kernel with -g option.

[Wright, David]

> -----Original Message-----
> From: Jerry Van Baren [mailto:vanbaren_gerald@si.com]
> Relocation truncated to fit errors are typically caused by
> your executable exceeding 16Mbytes (24 bits) in size (assuming
> it isn't caused by missing modules and thus unresolved references).

In this case, however, it was clear that the problem WAS due to
unresolved references -- specifically, the "copy_to_user" refs.
That's always going to happen if you turn off optimization, because
those are inlined functions, and you have to use at least -O1 to
get those to be compiled as inlines (at least with gcc).

I've never seen a 16 MB linux kernel, even with -g turned on; I
guess you might be able to do it if you enabled every driver and
option, but my mid-sized vmlinux, with -g, is 8 MB.

  -- David Wright, Consulting Engineer, InfiniSwitch Corp.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

RE: Compiling kernel with -g option.

[Jerry Van Baren]

Thanks for the clarification.  "copy_to_user" didn't ring any bells with me
(will now :-) and the original message didn't show it as an obvious
unresolved reference.  This means that this could also be fixed by removing
the "inline" attribute, but -O1 is a MUCH better option.

I also was incorrect on my allowable relative branch range (stoopid memory
going flaky on me again -- one of these days I'll to look things up before
saying stupid things).  The branch is a signed 26 bit number (2 LSBs are
zero because the destination must be 32-bit aligned) which gives a
+/-32MByte range.  Pretty generous.

gvb


At 12:11 PM 11/7/01 -0500, Wright, David wrote:

> > -----Original Message-----
> > From: Jerry Van Baren [mailto:vanbaren_gerald@si.com]
> > Relocation truncated to fit errors are typically caused by
> > your executable exceeding 16Mbytes (24 bits) in size (assuming
> > it isn't caused by missing modules and thus unresolved references).
>
>In this case, however, it was clear that the problem WAS due to
>unresolved references -- specifically, the "copy_to_user" refs.
>That's always going to happen if you turn off optimization, because
>those are inlined functions, and you have to use at least -O1 to
>get those to be compiled as inlines (at least with gcc).
>
>I've never seen a 16 MB linux kernel, even with -g turned on; I
>guess you might be able to do it if you enabled every driver and
>option, but my mid-sized vmlinux, with -g, is 8 MB.
>
>   -- David Wright, Consulting Engineer, InfiniSwitch Corp.
>


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/