Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Mike Frysinger <vapier@gentoo.org>
To: Pedro Alves <pedro@codesourcery.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH v5] sim: bfin: new port
Date: Tue, 01 Mar 2011 23:42:00 -0000	[thread overview]
Message-ID: <201103011702.22120.vapier@gentoo.org> (raw)
In-Reply-To: <201103012119.26255.pedro@codesourcery.com>

[-- Attachment #1: Type: Text/Plain, Size: 4979 bytes --]

On Tuesday, March 01, 2011 16:19:25 Pedro Alves wrote:
> On Tuesday 22 February 2011 20:26:44, Mike Frysinger wrote:
> > --- /dev/null
> > +++ b/sim/bfin/linux-fixed-code.h
> > @@ -0,0 +1,23 @@
> > +/* DO NOT EDIT: Autogenerated.  */
> > +/* Fixed code region of Linux userspace starting at 0x400.  Last
> > produced +   from Linux-2.6.37 (not that the fixed code region changes
> > often).  */ +static const unsigned char bfin_linux_fixed_code[] = {
> > +0x28, 0xe1, 0xad, 0x00, 0xa0, 0x00, 0x00, 0x20,
> 
> (...)
> 
> > +0xa4, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> > +};
> 
> Now this kernel code in question was probably (haven't
> checked) largely written by ADI, and as such ADI could
> probably contribute a standalone version of its source
> to the FSF under GPLv3, along with some script or makefile
> that compiles it with a bfin-gcc and then generates
> the blob array.  Or you could write simple dumb
> replacement implementations of the interface instead?

this code was written purely by ADI employees (2 or 3 of them to be exact), is 
written in pure Blackfin assembly, and we've explicitly licensed this file 
under GPLv2 or later.  so i dont think this is an issue.  it is not used by 
the kernel at all ... the code is placed in a fixed location for userspace 
binaries to call and is defined as part of the Blackfin ABI.  see below.
-mike

/*
 * This file contains sequences of code that will be copied to a
 * fixed location, defined in <asm/fixed_code.h>.  The interrupt
 * handlers ensure that these sequences appear to be atomic when
 * executed from userspace.
 * These are aligned to 16 bytes, so that we have some space to replace
 * these sequences with something else (e.g. kernel traps if we ever do
 * BF561 SMP).
 *
 * Copyright 2007-2008 Analog Devices Inc.
 *
 * Licensed under the GPL-2 or later.
 */

#include <linux/linkage.h>
#include <linux/init.h>
#include <linux/unistd.h>
#include <asm/entry.h>

__INIT

ENTRY(_fixed_code_start)

.align 16
ENTRY(_sigreturn_stub)
	P0 = __NR_rt_sigreturn;
	EXCPT 0;
	/* Speculative execution paranoia.  */
0:	JUMP.S 0b;
ENDPROC (_sigreturn_stub)

.align 16
	/*
	 * Atomic swap, 8 bit.
	 * Inputs:	P0: memory address to use
	 *		R1: value to store
	 * Output:	R0: old contents of the memory address, zero extended.
	 */
ENTRY(_atomic_xchg32)
	R0 = [P0];
	[P0] = R1;
	rts;
ENDPROC (_atomic_xchg32)

.align 16
	/*
	 * Compare and swap, 32 bit.
	 * Inputs:	P0: memory address to use
	 *		R1: compare value
	 *		R2: new value to store
	 * The new value is stored if the contents of the memory
	 * address is equal to the compare value.
	 * Output:	R0: old contents of the memory address.
	 */
ENTRY(_atomic_cas32)
	R0 = [P0];
	CC = R0 == R1;
	IF !CC JUMP 1f;
	[P0] = R2;
1:
	rts;
ENDPROC (_atomic_cas32)

.align 16
	/*
	 * Atomic add, 32 bit.
	 * Inputs:	P0: memory address to use
	 *		R0: value to add
	 * Outputs:	R0: new contents of the memory address.
	 *		R1: previous contents of the memory address.
	 */
ENTRY(_atomic_add32)
	R1 = [P0];
	R0 = R1 + R0;
	[P0] = R0;
	rts;
ENDPROC (_atomic_add32)

.align 16
	/*
	 * Atomic sub, 32 bit.
	 * Inputs:	P0: memory address to use
	 *		R0: value to subtract
	 * Outputs:	R0: new contents of the memory address.
	 *		R1: previous contents of the memory address.
	 */
ENTRY(_atomic_sub32)
	R1 = [P0];
	R0 = R1 - R0;
	[P0] = R0;
	rts;
ENDPROC (_atomic_sub32)

.align 16
	/*
	 * Atomic ior, 32 bit.
	 * Inputs:	P0: memory address to use
	 *		R0: value to ior
	 * Outputs:	R0: new contents of the memory address.
	 *		R1: previous contents of the memory address.
	 */
ENTRY(_atomic_ior32)
	R1 = [P0];
	R0 = R1 | R0;
	[P0] = R0;
	rts;
ENDPROC (_atomic_ior32)

.align 16
	/*
	 * Atomic and, 32 bit.
	 * Inputs:	P0: memory address to use
	 *		R0: value to and
	 * Outputs:	R0: new contents of the memory address.
	 *		R1: previous contents of the memory address.
	 */
ENTRY(_atomic_and32)
	R1 = [P0];
	R0 = R1 & R0;
	[P0] = R0;
	rts;
ENDPROC (_atomic_and32)

.align 16
	/*
	 * Atomic xor, 32 bit.
	 * Inputs:	P0: memory address to use
	 *		R0: value to xor
	 * Outputs:	R0: new contents of the memory address.
	 *		R1: previous contents of the memory address.
	 */
ENTRY(_atomic_xor32)
	R1 = [P0];
	R0 = R1 ^ R0;
	[P0] = R0;
	rts;
ENDPROC (_atomic_xor32)

.align 16
	/*
	 * safe_user_instruction
	 * Four NOPS are enough to allow the pipeline to speculativily load
	 * execute anything it wants. After that, things have gone bad, and
	 * we are stuck - so panic. Since we might be in user space, we can't
	 * call panic, so just cause a unhandled exception, this should cause
	 * a dump of the trace buffer so we can tell were we are, and a reboot
	 */
ENTRY(_safe_user_instruction)
	NOP; NOP; NOP; NOP;
	EXCPT 0x4;
ENDPROC(_safe_user_instruction)

ENTRY(_fixed_code_end)

__FINIT

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

  reply	other threads:[~2011-03-01 23:42 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-16  1:41 [PATCH] " Mike Frysinger
2010-12-31 23:12 ` [PATCH v2] " Mike Frysinger
2011-02-14 20:18   ` [PATCH v3] " Mike Frysinger
2011-02-14 20:49     ` Pedro Alves
2011-02-14 21:12       ` Mike Frysinger
2011-02-14 21:55         ` Pedro Alves
2011-02-14 22:11           ` Mike Frysinger
2011-02-14 22:23             ` Mike Frysinger
2011-02-15 16:25             ` Pedro Alves
2011-02-16  1:34               ` Mike Frysinger
2011-02-16  5:34                 ` Joel Brobecker
2011-02-20  7:24     ` Mike Frysinger
2011-02-21 10:13       ` Joel Brobecker
2011-02-21 18:27         ` Mike Frysinger
2011-02-22  8:28           ` Joel Brobecker
2011-02-22 17:58             ` Mike Frysinger
2011-02-22 10:50           ` Pedro Alves
2011-02-22 18:07             ` Mike Frysinger
2011-02-22 10:08         ` Pedro Alves
2011-02-22 17:57           ` Mike Frysinger
2011-02-22 18:25             ` Pedro Alves
2011-02-22 20:54               ` Mike Frysinger
2011-02-22 20:29       ` [PATCH v5] " Mike Frysinger
2011-03-01  5:16         ` Mike Frysinger
2011-03-01 10:11         ` Joel Brobecker
2011-03-01 21:19         ` Pedro Alves
2011-03-01 23:42           ` Mike Frysinger [this message]
2011-03-02  1:13             ` Pedro Alves
2011-03-02  2:23               ` Mike Frysinger
2011-03-02  9:30                 ` Pedro Alves
2011-03-02 21:46                   ` Mike Frysinger
2011-03-02 23:32                     ` Pedro Alves
2011-03-02 23:32                     ` Pedro Alves
2011-03-03 21:40         ` [PATCH v6] " Mike Frysinger
2011-03-04 10:19           ` Pedro Alves
2011-03-04 21:12             ` Mike Frysinger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201103011702.22120.vapier@gentoo.org \
    --to=vapier@gentoo.org \
    --cc=gdb-patches@sourceware.org \
    --cc=pedro@codesourcery.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox