In pondering the ELF issue, I was looking over the stage0 in Coreboot-v3. It contains some workarounds for gas/binutils issues that have been hit in the past, as well as .globl symbols.
On reading about Gas, I found that gcc output passes through it, implying that Gas can emit rich debugging information. I didn't see any -g flags to cause a symbol table to be emitted, so just for fun I built arch/x86/geodelx/stage0.S using -g.
It turns out you can load stage0.o into gcc, and disassemble 32bit "functions", show source file lines, all that fun stuff, and objdump can manage the 16bit stuff.
Then it occurred to me, couldn't everything be built with debug symbols, and then strip that into a separate symbol file to go with the final ROM image?
With some cleanups, even structures in stage0 could be examined conveniently with gdb, ie (gdb) print gdt, would show the C struct formatted nicely.
$ gdb stage0.o (gdb) disassemble DCacheSetupGood Dump of assembler code for function DCacheSetupGood: 0x0000019a <DCacheSetupGood+0>: mov $0x87ffc,%eax 0x0000019f <DCacheSetupGood+5>: mov %eax,%esp 0x000001a1 <DCacheSetupGood+7>: mov $0x20,%ax 0x000001a5 <DCacheSetupGood+11>: movl %eax,%ds 0x000001a7 <DCacheSetupGood+13>: movl %eax,%es 0x000001a9 <DCacheSetupGood+15>: movl %eax,%ss End of assembler dump.
I like the idea of the bios always being debuggable. Proprietary bios'es strip this info out, of course, and in a lot of cases you can learn a lot if you just have the symbol names.
It has to fit, however. Or we can make a symbol file available on the web site for each known good board build. I.e., you want to walk through some code, you wget the symbol file and use it to examine your in-flash coreboot image.
ron
On 20.04.2008 20:04, ron minnich wrote:
I like the idea of the bios always being debuggable. Proprietary bios'es strip this info out, of course, and in a lot of cases you can learn a lot if you just have the symbol names.
It has to fit, however. Or we can make a symbol file available on the web site for each known good board build. I.e., you want to walk through some code, you wget the symbol file and use it to examine your in-flash coreboot image.
Is there a way to strip out the debugging information from an image compiled with -g? I would like to have an image without debugging info, especially for the bootblock and initram because both are uncompressed and storing uncompressed debug info in a ROM is a total waste of space. The debugging info for each LAR member can be stored in a separate (always compressed) member.
By the way, the debugging info is similar to one of the pet projects I have: Providing a symbol file for the boot block, enabling people to build initram and stage2 against a given bootblock.
Patch available if anybody is interested.
Regards, Carl-Daniel
On Mon, 2008-04-21 at 00:04 +0200, Carl-Daniel Hailfinger wrote:
Is there a way to strip out the debugging information from an image compiled with -g? I would like to have an image without debugging info, especially for the bootblock and initram because both are uncompressed and storing uncompressed debug info in a ROM is a total waste of space. The debugging info for each LAR member can be stored in a separate (always compressed) member.
There is the question of including the debug symbols in the ROM (compiler default), provided with the ROM in a separate file (put both in a .tgz for distribution from a website), or offering as a separate download. There's probably a use case for all 3, so configure/build option?
Debian/Ubuntu has separate -dbg packages for some things, which contain the debug symbol files. (separate from the .so libraries) The man page for "strip" suggests:
$ objcopy --only-keep-debug foo foo.dbg $ objcopy --strip-debug foo $ objcopy --add-gnu-debuglink=foo.dbg foo
By the way, the debugging info is similar to one of the pet projects I have: Providing a symbol file for the boot block, enabling people to build initram and stage2 against a given bootblock.
This sounds like a special case, but in general, "there's nothing new under the sun" and compilers/assemblers/linkers do this every day... wouldn't that just be a matter of providing the .o/.a object file and/or .h header file?
On 21.04.2008 01:22, Jeremy Jackson wrote:
On Mon, 2008-04-21 at 00:04 +0200, Carl-Daniel Hailfinger wrote:
Is there a way to strip out the debugging information from an image compiled with -g? I would like to have an image without debugging info, especially for the bootblock and initram because both are uncompressed and storing uncompressed debug info in a ROM is a total waste of space. The debugging info for each LAR member can be stored in a separate (always compressed) member.
There is the question of including the debug symbols in the ROM (compiler default), provided with the ROM in a separate file (put both in a .tgz for distribution from a website), or offering as a separate download. There's probably a use case for all 3, so configure/build option?
Debian/Ubuntu has separate -dbg packages for some things, which contain the debug symbol files. (separate from the .so libraries) The man page for "strip" suggests:
$ objcopy --only-keep-debug foo foo.dbg $ objcopy --strip-debug foo $ objcopy --add-gnu-debuglink=foo.dbg foo
Well, it's not that easy AFAICS. The bootblock is very sensitive to offset and code location differences and unless some magic happens, the chance to break the boot block by stripping out debug symbols that were compiled in is really big.
By the way, the debugging info is similar to one of the pet projects I have: Providing a symbol file for the boot block, enabling people to build initram and stage2 against a given bootblock.
This sounds like a special case, but in general, "there's nothing new under the sun" and compilers/assemblers/linkers do this every day... wouldn't that just be a matter of providing the .o/.a object file and/or .h header file?
Yes, but the challenge is to pack only the essential linker information in a file with minimum size so that shipping it in the ROM does not take away a sizable amount of space. I have some scripts which perform a few objcopy/nm/... calls and hand-patch ELF files to create truly minimal symbol tables which also compress well and can be used by ld.
If you are willing to sacrifice lots of ROM space and/or make symbol tables available for download only and/or write your own linker, my solution does not apply.
Regards, Carl-Daniel
On Sun, Apr 20, 2008 at 4:22 PM, Jeremy Jackson jerj@coplanar.net wrote:
On Mon, 2008-04-21 at 00:04 +0200, Carl-Daniel Hailfinger wrote:
By the way, the debugging info is similar to one of the pet projects I have: Providing a symbol file for the boot block, enabling people to build initram and stage2 against a given bootblock.
This sounds like a special case, but in general, "there's nothing new under the sun" and compilers/assemblers/linkers do this every day... wouldn't that just be a matter of providing the .o/.a object file and/or .h header file?
I throught we were almost doing this already? I call printk from initram for example.
ron
On Sun, 2008-04-20 at 18:51 -0700, ron minnich wrote:
This sounds like a special case, but in general, "there's nothing new under the sun" and compilers/assemblers/linkers do this every day... wouldn't that just be a matter of providing the .o/.a object file and/or .h header file?
I throught we were almost doing this already? I call printk from initram for example.
I think Carl is talking about linking against something *in* a ROM (image), not just from .o files resulting from a build... i might be mistaken tho
On 21.04.2008 04:50, Jeremy Jackson wrote:
On Sun, 2008-04-20 at 18:51 -0700, ron minnich wrote:
This sounds like a special case, but in general, "there's nothing new under the sun" and compilers/assemblers/linkers do this every day... wouldn't that just be a matter of providing the .o/.a object file and/or .h header file?
I throught we were almost doing this already? I call printk from initram for example.
I think Carl is talking about linking against something *in* a ROM (image), not just from .o files resulting from a build...
Yes, indeed. Ron, see also my other mail in this thread with Date: Mon, 21 Apr 2008 02:05:39 +0200
I want people to be able to compile initram and stage2 against a shipped/burned ROM (which means the symbol table for the bootblock need to end up in ROM somehow).
Regards, Carl-Daniel
On Mon, 2008-04-21 at 12:41 +0200, Carl-Daniel Hailfinger wrote:
I want people to be able to compile initram and stage2 against a shipped/burned ROM (which means the symbol table for the bootblock need to end up in ROM somehow).
So that's is to say, you want the ELF linking symbols (.symtab section) , not the debug symbols.
In addition, you want to only keep the linker symbols needed for the purpose you stated above, and strip the rest.
I wonder if binutils could handle that. The "strip" command at least lets you specify a list of symbols to keep.
On 22.04.2008 01:08, Jeremy Jackson wrote:
On Mon, 2008-04-21 at 12:41 +0200, Carl-Daniel Hailfinger wrote:
I want people to be able to compile initram and stage2 against a shipped/burned ROM (which means the symbol table for the bootblock need to end up in ROM somehow).
So that's is to say, you want the ELF linking symbols (.symtab section) , not the debug symbols.
In addition, you want to only keep the linker symbols needed for the purpose you stated above, and strip the rest.
Indeed.
I wonder if binutils could handle that. The "strip" command at least lets you specify a list of symbols to keep.
You can use binutils, but the resulting file is still too big for my taste after compression. That's why my script did lots of dirty tricks to squeeze binutils output down do an absolute minimum.
Regards, Carl-Daniel
On Tue, 2008-04-22 at 02:03 +0200, Carl-Daniel Hailfinger wrote:
You can use binutils, but the resulting file is still too big for my taste after compression. That's why my script did lots of dirty tricks to squeeze binutils output down do an absolute minimum.
Well now I'm curious, what else does binutils leave lying around, surely the text/data sections are no different... the section headers/program headers shouldn't be very big. Any other sections can probably be dropped given the right commands/options.
On 22.04.2008 02:21, Jeremy Jackson wrote:
On Tue, 2008-04-22 at 02:03 +0200, Carl-Daniel Hailfinger wrote:
You can use binutils, but the resulting file is still too big for my taste after compression. That's why my script did lots of dirty tricks to squeeze binutils output down do an absolute minimum.
Well now I'm curious, what else does binutils leave lying around, surely the text/data sections are no different... the section headers/program headers shouldn't be very big. Any other sections can probably be dropped given the right commands/options.
When you're optimizing for size, shaving off a hundred bytes of header and other assorted stuff does matter. Absolute minimum is a file which has no header, keeps all required symbol names sorted by name as consecutive zero-terminated strings, followed by a zero byte, followed by an array of addresses. The name list can be compressed with algorithms suited best for sorted printable strings and/or the whole file can be compressed with lzma.
Regards, Carl-Daniel
-
Carl-Daniel Hailfinger -
Jeremy Jackson -
ron minnich