Re: EFBIG with gdb - to you hack gdb to pass O_LARGEFILE in the files open() flags?

Pete/Piet Delaney wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi Dave:
> 
> I was wondering why gdb isn't having a problem with the
crash file
> being too big when started with crash yet when handing
the
> vmcore directly to gdb it gets an error while opening
the file EFBIG.

Because the embedded gdb module in crash doesn't have a
clue
about dumpfiles.  It's invoked internally simply as
"gdb vmlinux"
in order to get the symbol values, debuginfo data, etc.

When you bring up gdb on just a binary executable you can
still
issue gdb commands that in turn generate read commands from
the
the executable.  But one of the many hacks to the embedded
gdb module
is to hijack any read attempts, and pass them back up to
the
crash-based module for resolution.

Dave

--
Crash-utility mailing list
Crash-utilityredhat.com
https://www.redhat.com/mailman/listinfo/crash-utility

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dave Anderson wrote:
| Pete/Piet Delaney wrote:
|> -----BEGIN PGP SIGNED MESSAGE-----
|> Hash: SHA1
|>
|> Hi Dave:
|>
|> I was wondering why gdb isn't having a problem with
the crash file
|> being too big when started with crash yet when handing
the
|> vmcore directly to gdb it gets an error while opening
the file EFBIG.
|
| Because the embedded gdb module in crash doesn't have a
clue
| about dumpfiles.  It's invoked internally simply as
"gdb vmlinux"
| in order to get the symbol values, debuginfo data, etc.

I just thought, gdb can't get thread info from a core file
like kgdb can via the simulated ptrace or /proc interface.
There are other problems; for example ddd is passing a -q
option to gdb and crash doesn't know what to do with it.

I don't suppose anyone has hacked ddd to access gdb via
crash.
There's a --debugger option to ddd but as I recall with
crash
gdb commands need to be prefixed with 'gdb' so the data
browser
wouldn't know to do that.

- -piet

|
| When you bring up gdb on just a binary executable you can
still
| issue gdb commands that in turn generate read commands
from the
| the executable.  But one of the many hacks to the embedded
gdb module
| is to hijack any read attempts, and pass them back up to
the
| crash-based module for resolution.
|
| Dave
|

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


iD8DBQFH0emIJICwm/rv3hoRAgKRAJ0d0BTMFl0LB04CI+5oevgDnNRISwCd
GyTc
MTsqK7edWFpCGTo1Y6mKNPU=
=LgRQ
-----END PGP SIGNATURE-----

--
Crash-utility mailing list
Crash-utilityredhat.com
https://www.redhat.com/mailman/listinfo/crash-utility

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dave Anderson wrote:
| Pete/Piet Delaney wrote:
|> -----BEGIN PGP SIGNED MESSAGE-----
|> Hash: SHA1
|>
|> Hi Dave:
|>
|> I was wondering why gdb isn't having a problem with
the crash file
|> being too big when started with crash yet when handing
the
|> vmcore directly to gdb it gets an error while opening
the file EFBIG.
|
| Because the embedded gdb module in crash doesn't have a
clue
| about dumpfiles.a

But the stock gdb knows how to read kexec vmcore files.
Right?



|    It's invoked internally simply as "gdb
vmlinux"
| in order to get the symbol values, debuginfo data, etc.

Right it's not accessing the core file directly.

|
| When you bring up gdb on just a binary executable you can
still
| issue gdb commands that in turn generate read commands
from the
| the executable.

Right but I want to use ddd on the core file in addition to
crash
to browse data structures with the data window. I use it all
the time
with kgdb. Problem is here the panic is holding a spinlock
and KGDB
over ethernet doesn't work when a spinlock is held. KGDB
over serial
isn't working in my image last I tried to use it.

|  But one of the many hacks to the embedded gdb module
| is to hijack any read attempts, and pass them back up to
the
| crash-based module for resolution.

I was thinking of just pulling one of the DIMMS and getting
memory low
enough that gdb isn't confused.

- -piet

|
| Dave
|
| --
| Crash-utility mailing list
| Crash-utilityredhat.com
| https://www.redhat.com/mailman/listinfo/crash-utility
|

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


iD8DBQFH0eX/JICwm/rv3hoRAk8vAJ0b++xC00j+GGx8FD+T0dtiRPsTFwCe
Ibml
iGaLrvN9s/EtIoCOjw6Nj+0=
=1s4/
-----END PGP SIGNATURE-----

--
Crash-utility mailing list
Crash-utilityredhat.com
https://www.redhat.com/mailman/listinfo/crash-utility