Re: Bug#396365: please add a gdb .udeb, for easier debugging inside d-i
On Tue, Oct 31, 2006 at 09:36:54AM -0500, Daniel Jacobowitz wrote:
> On Tue, Oct 31, 2006 at 03:30:23PM +0100, Sven Luther wrote:
> > So, i am not entirely sure how d-i handles the case at hand here, where
> > libraries are part of the actual image, but symbols are removed during
> > reduction, because they are not needed by the .udebs in the image, but they
> > are needed by .udebs loaded later on.
> >
> > My impression is that d-i loads the full libraries later on, or something
> > such.
>
> If they did that, you could just wget a full GDB binary. It doesn't
Mmm.
> need anything else in the package besides the executable. But I don't
> think d-i does what you describe (since I tried to use this approach
> for strace recently, and there were missing symbols in libc.so.6).
I really don't see how reduction could work if it has to take into account all
.udebs which can possibly or not be loaded into d-i. I also have not noticed
the d-i build process loading not-in-the-ramdisk .udebs, but i have missed
them. Also, i don't see how such a process could survive for example a package
which was added after the build of the image, or modified or whatever.
What did you do with strace ? Create a .udeb out of it and include this one ?
or just load in the binary ? Or did you include the strace.udeb into the
ramdisk image ?
> If someone more familiar with d-i than I am can confirm that the udeb
> will be useful, I can try to get GDB to build one, but it seems like
> a very strange package to have a udeb.
Well, gdb and strace would be two great packages to have as .udeb. Also,
.udebs can be useful even outside of d-i, at least those not having any menu
item thingy, like libraries, and utility packages (like ssh or parted or
whatever for example).
Friendly,
Sven Luther
Reply to: