aboutsummaryrefslogtreecommitdiff
path: root/scripts/reference_discarded.pl
AgeCommit message (Collapse)Author
2006-01-08kbuild: reference_discarded additionDave Jones
Error: ./fs/quota_v2.o .opd refers to 0000000000000020 R_PPC64_ADDR64 .exit.text Been carrying this for some time in Red Hat trees. Keith Ownes <kaos@sgi.com> commented: For our future {in}sanity, add a comment that this is the ppc .opd section, not the ia64 .opd section. ia64 .opd should not point to discarded sections. Any idea why ppc .opd points to discarded sections when ia64 does not? AFAICT no ia64 object has a useful .opd section, they are all empty or (sometimes) a dummy entry which is 1 byte long. ia64 .opd data is built at link time, not compile time. Signed-off-by: Dave Jones <davej@redhat.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
2005-09-10[PATCH] kbuild: ignore all debugging info sections in ↵Roland McGrath
scripts/reference_discarded.pl GCC 4 emits more DWARF debugging information than before and there is now a .debug_loc section as well. This causes "make buildcheck" to fail. Rather than just add that one to the special case list, I used a regexp to ignore any .debug_ANYTHING sections in case more show up in the future. Signed-off-by: Roland McGrath <roland@redhat.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
2005-07-14kbuild: fix buildcheckSam Ravnborg
From: Randy Dunlap <rddunlap@osdl.org> I should not have added init.text test here; it's more than useless, it actually degrades the output. Signed-off-by: Randy Dunlap <rddunlap@osdl.org> Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
2005-07-14buildcheck: reduce DEBUG_INFO noise from reference* scriptsSam Ravnborg
From: Randy Dunlap <rddunlap@osdl.org> Reduce noise in 'make buildcheck' that is caused by CONFIG_DEBUG_INFO=y. Signed-off-by: Randy Dunlap <rddunlap@osdl.org> Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
2005-04-16Linux-2.6.12-rc2Linus Torvalds
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!