linux-toradex.git/arch/arm/lib/lib1funcs.S, branch v3.0.63 Linux kernel for Apalis and Colibri modules ARM: 6945/1: Add unwinding support for division functions 2011-05-27T21:56:53+00:00 Laura Abbott lauraa@codeaurora.org 2011-05-27T16:23:16+00:00 81479c246c07b703aeb4bf54933b7d928cb5b717 The software division functions never had unwinding annotations added. Currently, when a division by zero occurs the backtrace shown will stop at Ldiv0 or some completely unrelated function. Add unwinding annotations in hopes of getting a more useful backtrace when a division by zero occurs. Signed-off-by: Laura Abbott <lauraa@codeaurora.org> Acked-by: Dave Martin <dave.martin@linaro.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> 
The software division functions never had unwinding annotations
added. Currently, when a division by zero occurs the backtrace shown
will stop at Ldiv0 or some completely unrelated function. Add
unwinding annotations in hopes of getting a more useful backtrace
when a division by zero occurs.

Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
Acked-by: Dave Martin <dave.martin@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Nicolas Pitre has a new email address 2009-09-15T16:37:12+00:00 Nicolas Pitre nico@fluxnic.net 2009-09-14T07:25:28+00:00 2f82af08fcc7dc01a7e98a49a5995a77e32a2925 Due to problems at cam.org, my nico@cam.org email address is no longer valid. FRom now on, nico@fluxnic.net should be used instead. Signed-off-by: Nicolas Pitre <nico@fluxnic.net> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 
Due to problems at cam.org, my nico@cam.org email address is no longer
valid.  FRom now on, nico@fluxnic.net should be used instead.

Signed-off-by: Nicolas Pitre <nico@fluxnic.net>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[ARM] 5227/1: Add the ENDPROC declarations to the .S files 2008-09-01T11:06:34+00:00 Catalin Marinas catalin.marinas@arm.com 2008-08-28T10:22:32+00:00 93ed3970114983543bbebd195bef65db84444ea2 This declaration specifies the "function" type and size for various assembly functions, mainly needed for generating the correct branch instructions in Thumb-2. Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> 
This declaration specifies the "function" type and size for various
assembly functions, mainly needed for generating the correct branch
instructions in Thumb-2.

Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
[ARM] 3104/1: ARM EABI: new helper function names 2006-01-14T16:18:29+00:00 Nicolas Pitre nico@cam.org 2006-01-14T16:18:29+00:00 ba95e4e4a0a8a3c6aba363d45f78d5f2e2d111eb Patch from Nicolas Pitre The ARM EABI defines new names for GCC helper functions. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> 
Patch from Nicolas Pitre

The ARM EABI defines new names for GCC helper functions.

Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
[ARM] 3103/1: ARM EABI: stack pointer must be 64-bit aligned (part 2) 2006-01-14T16:18:09+00:00 Nicolas Pitre nico@cam.org 2006-01-14T16:18:09+00:00 499b2ea11ff00c624d63af23516404fa2156639a Patch from Nicolas Pitre We must make sure that assembly code that modifies the stack pointer before calling a C function does it so it remains 64-bit aligned. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> 
Patch from Nicolas Pitre

We must make sure that assembly code that modifies the stack pointer
before calling a C function does it so it remains 64-bit aligned.

Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Linux-2.6.12-rc2 2005-04-16T22:20:36+00:00 Linus Torvalds torvalds@ppc970.osdl.org 2005-04-16T22:20:36+00:00 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 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! 
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!