Linux PARISC architecture development
 help / color / mirror / Atom feed
From: "Carlos O'Donell Jr." <carlos@baldric.uwo.ca>
To: parisc-linux@lists.parisc-linux.org
Subject: [parisc-linux] kdb_v21 branch updated to -pa26, and kallsyms cross-compile
Date: Mon, 27 May 2002 00:13:21 -0400	[thread overview]
Message-ID: <20020527001321.A6629@systemhalted> (raw)

Parisc,

All the changes from -pa24 to -p26 have been merged into the
kdb-v21 tree (that Randolph graciously started!). Thanks go
to bame's recipe!

A few tests show that it is equivalent to the patches I had 
produced (fixes to traps.c for the soft power button).

If kdb is your bag, then it should all be set to go!

---

On another note... until I get a really fast PA box, I'm going
to be cross-compiling all the time. There are issues cross-compiling 
a kdb'd kernel, and the problem is called 'kallsyms'.

After a bout of idiocy and help from Jess I had a cross version
of kallsyms (never forget to 'unset CC'). 

It seemed like I was home free, except that I ran into the same
problem as before (even with the supposed _new_ cross kallsyms).

.tmp_vmlinux1: ELF file .tmp_vmlinux1 not for this architecture

I check ./src/modutils/obj/obj_load.c and find:

  if (f->header.e_ident[EI_CLASS] != ELFCLASSM
      || f->header.e_ident[EI_DATA] != ELFDATAM
      || f->header.e_ident[EI_VERSION] != EV_CURRENT
      || !MATCH_MACHINE(f->header.e_machine))
    {
       error("ELF file %s not for this architecture", filename);
       return NULL;
    }

So I breakup the values and test individually...

.tmp_vmlinux1: ELF file .tmp_vmlinux1 not for this architecture (!MATCH_MACHINE)

The MATCH_MACHINE macro is pretty dumb.
#define MATCH_MACHINE(x)  (x == EM_PARISC)

printf what e_machine header is set to:

ELF e_machine header is 3840
.tmp_vmlinux1: ELF file .tmp_vmlinux1 not for this architecture (!MATCH_MACHINE)

I'm not sure I've _ever_ seen a EM_??? value that big (EM_PARISC=15).
A closer inspection reveals that 3840 is 15 but byte swapped.

Which leaves me wondering... what else is going to be bytesex broke in
a cross modutils?

Is anyone familiar with modutils?
What would be a good way to include some cross-kallsyms support?

c.

             reply	other threads:[~2002-05-27  4:13 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-05-27  4:13 Carlos O'Donell Jr. [this message]
2002-05-28 14:27 ` [parisc-linux] kdb_v21 branch updated to -pa26, and kallsyms cross-compile Patrick Caulfield
2002-05-28 14:49   ` Orac
2002-05-28 14:58     ` Patrick Caulfield
2002-05-28 17:29   ` Carlos O'Donell Jr.
2002-05-29  7:51     ` Patrick Caulfield
2002-05-29 12:21       ` Carlos O'Donell Jr.
2002-05-29 14:12         ` Patrick Caulfield
2002-05-29 15:01           ` Carlos O'Donell Jr.
2002-05-29 16:24             ` Patrick Caulfield
2002-05-29 17:26               ` Carlos O'Donell Jr.
2002-05-29 18:07                 ` Patrick Caulfield
2002-05-30 14:36                   ` Patrick Caulfield
     [not found]                     ` <20020530133515.B15631@systemhalted>
2002-05-31  7:28                       ` Patrick Caulfield
2002-05-31 12:54                         ` Carlos O'Donell Jr.
2002-06-04 11:55                           ` Patrick Caulfield
2002-06-04 12:44                             ` Carlos O'Donell Jr.
2002-06-04 15:49                               ` Randolph Chung
2002-06-04 16:31                                 ` joel.soete
2002-06-04 17:27                                 ` Carlos O'Donell Jr.
2002-06-04 18:19                                 ` Patrick Caulfield
2002-06-05 15:57                                 ` joel.soete
2002-06-05 17:21                                   ` Randolph Chung
2002-06-05 18:59                                   ` Carlos O'Donell Jr.
2002-06-06 15:41                                     ` joel.soete
2002-06-07 11:43                                       ` [parisc-linux] Verify stack trace address - Joel Carlos O'Donell Jr.
2002-06-07 15:07                                         ` joel.soete

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=20020527001321.A6629@systemhalted \
    --to=carlos@baldric.uwo.ca \
    --cc=parisc-linux@lists.parisc-linux.org \
    /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