C-struct dismantling tool...
Does anyone know of an existing tool which for a given C struct can output a list of elements, their types, size and byteoffset ? I have considered parsing the information out of .stabs records from gcc -g output, but if an existing tool already exists that would save me quite some time. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Debugging BTX Faults
On 20-Mar-2002 Hiten Pandya wrote: On 20-Mar-2002 Hiten Pandya wrote: Hi all, How does one debug faults in the BTX Loader? I am currently trying to work on PR i386/21559, and after reading jhb's document on the loading process, I was curious to know.. Well, you need to be fairly familiar with how IA32 works. The int= number is the fault that was triggered. Then, use a program to convert the hex dump at cs:eip to binary Which tool can be used for this task? Any available in the ports? Not that I'm aware of, I just wrote a little util in C. Not very hard to one to write. :) -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: C-struct dismantling tool...
In article [EMAIL PROTECTED], Poul-Henning Kamp [EMAIL PROTECTED] wrote: Does anyone know of an existing tool which for a given C struct can output a list of elements, their types, size and byteoffset ? No, but I'd like one too -- one that can handle the files in /usr/include with all their idiosyncrasies. I have considered parsing the information out of .stabs records from gcc -g output, but if an existing tool already exists that would save me quite some time. I thought about the .stabs approach too, and thought it seemed promising. Even better might be to use -gdwarf -g3, which in theory at least would provide information about #defines. For well-behaved structs, it's possible that rpcgen could be hacked up to do what you want. John -- John Polstra John D. Polstra Co., Inc.Seattle, Washington USA Disappointment is a good sign of basic intelligence. -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
a 250Meg ramdisk
Hi, Would anyone know if how to pre-load modules of type `md_image' is documented anywhere? I'm trying to create a 250Meg ramdisk , but have only managed one of 10 Meg so far . So far what I can surmise is that it has to be done in loader.conf: 1) Setting [mfs_load=NO] to YES 2) Somehow indicated I want 250Meg for a memory disk as hinted to by one of the last paragraphs of the md MAN page. the md driver will search for pre-loaded modules of type `md_image' and instantiate a md device for each of these modules. The type `mfs_root' is also allowed for backward compatibility. These devices are backed by the RAM reserved by the loader(8), and as such not limited by the malloc(9) size constraints To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: C-struct dismantling tool...
On Thu, 21 Mar 2002, John Polstra wrote: I thought about the .stabs approach too, and thought it seemed promising. Even better might be to use -gdwarf -g3, which in theory at least would provide information about #defines. For well-behaved structs, it's possible that rpcgen could be hacked up to do what you want. Sounds like a job for an objdump mutant. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: a 250Meg ramdisk
mwest wrote: Would anyone know if how to pre-load modules of type `md_image' is documented anywhere? I'm trying to create a 250Meg ramdisk , but have only managed one of 10 Meg so far . So far what I can surmise is that it has to be done in loader.conf: 1) Setting [mfs_load=NO] to YES 2) Somehow indicated I want 250Meg for a memory disk as hinted to by one of the last paragraphs of the md MAN page. the md driver will search for pre-loaded modules of type `md_image' and instantiate a md device for each of these modules. The type `mfs_root' is also allowed for backward compatibility. These devices are backed by the RAM reserved by the loader(8), and as such not limited by the malloc(9) size constraints The loader itself uses BIOS calls. THere is a 16M limitation on size. Probably, you don't want to do a pre-loaded version of the RAM disk anyway, if you want it taht large: you are trying to have a large read/write space for running a system, right? You want ot establish MFS's after the system is up. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: How to correctly detect POSIX 1003.1b features on FreeBSD?
On Tue, Mar 12, 2002 at 09:40:07PM -0500, Craig Rodrigues wrote: I am a contributor to ACE, a cross-platform C++ library for doing systems programming: http://www.cs.wustl.edu/~schmidt/ACE.html. My intent is to fix the macros in ACE which define the configuration on FreeBSD (all FreeBSD specific configuration data is in ACE's config-freebsd-pthread.h). Right now the ACE macros which detect AIO and RT signals are broken, so I am trying to fix these macros, hence my questions on this mailing list. I'm not looking to specifically use POSIX RT signals on FreeBSD, I just want to get ACE to cleanly compile on FreeBSD, so that FreeBSD users can use and enjoy ACE on their projects if they choose. Craig, does this mean there is likely to be a port of ACE (and TAO) anytime soon? My company is using TAO in one of our products and I had started looking into getting it to compile nicely on FreeBSD with a view to creating a port eventually. If you're already an ACE contributor you'll no doubt do a better job of that than me, but feel free to pick on me for beta-testing as necessary :-) Scott -- === Scott Mitchell | PGP Key ID | Eagles may soar, but weasels Cambridge, England | 0x54B171B9 | don't get sucked into jet engines [EMAIL PROTECTED] | 0xAA775B8B | -- Anon To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: C-struct dismantling tool...
At 12:57 PM -0800 3/21/02, Julian Elischer wrote:
On Thu, 21 Mar 2002, John Polstra wrote:
I thought about the .stabs approach too, and thought it seemed
promising. Even better might be to use -gdwarf -g3, which in
theory at least would provide information about #defines.
For well-behaved structs, it's possible that rpcgen could be
hacked up to do what you want.
Sounds like a job for an objdump mutant.
Or write a C-program which prints offset(x) and sizeof(x) for
each field in the struct. It might not be too hard to write
a perl or ruby script which could generate such a program for
a given struct+include file. Here's a quick dirty example.
Perhaps someone C-smarter than I am could figure out how to
reliably add a column indicating if the variable is signed or
unsigned, integer or floating-point, plus any other interesting
characteristics. The tricky lines below are only tricky in
the sense that it would be tricky to get a script to *know* to
add the lines for those fields, such they are a sub-structure.
With a little more thought, it could also map out the struct,
indicating any bytes which were skipped over. Though it seems
to me there should be some way to get the compiler itself to
dump out something like this. I know I have seen that in some
non-C compilers, and I thought I had also seen it in some C
compilers...
/*
* Grungy little program to print out a stat structure.
* Garance/Mar 21/2002
*
* cc -Wall -o dumpstat.o dumpstat.c
*/
#include sys/stat.h
#include stddef.h
#include stdio.h
#define showheader(xStruct) {\
printf(Dump of '%s':\n, #xStruct);\
printf( offset size fieldname\n);\
}
#define showfield(xStruct,xVar) {\
indent = 1; \
for (cp = #xVar; *cp != '\0'; cp++) \
if (*cp == '.') indent += 2;\
printf( 0x%04lX %4lu%*s- %-1s\n, \
(unsigned long) offsetof(xStruct, xVar), \
(unsigned long) sizeof(((xStruct *)0)-xVar), \
indent, , #xVar);\
}
#define showtotal(xStruct) {\
printf(Total size = 0x%04lX aka %lu bytes)\n, \
(unsigned long) sizeof(xStruct), \
(unsigned long) sizeof(xStruct));\
}
int
main(int argc, char **argv)
{
const char *cp;
int indent;
showheader(struct stat);
showfield(struct stat, st_dev);
showfield(struct stat, st_ino);
showfield(struct stat, st_mode);
showfield(struct stat, st_nlink);
showfield(struct stat, st_uid);
showfield(struct stat, st_gid);
showfield(struct stat, st_rdev);
#ifndef _POSIX_SOURCE
showfield(struct stat, st_atimespec);
showfield(struct stat, st_atimespec.tv_sec);/* tricky */
showfield(struct stat, st_atimespec.tv_nsec); /* tricky */
showfield(struct stat, st_mtimespec);
showfield(struct stat, st_mtimespec.tv_sec);/* tricky */
showfield(struct stat, st_mtimespec.tv_nsec); /* tricky */
showfield(struct stat, st_ctimespec);
showfield(struct stat, st_ctimespec.tv_sec);/* tricky */
showfield(struct stat, st_ctimespec.tv_nsec); /* tricky */
#else
showfield(struct stat, st_atime);
showfield(struct stat, st_atimensec);
showfield(struct stat, st_mtime);
showfield(struct stat, st_mtimensec);
showfield(struct stat, st_ctime);
showfield(struct stat, st_ctimensec);
#endif
showfield(struct stat, st_size);
showfield(struct stat, st_blocks);
showfield(struct stat, st_blksize);
showfield(struct stat, st_flags);
showfield(struct stat, st_gen);
showfield(struct stat, st_qspare);
showtotal(struct stat);
return 0;
}
--
Garance Alistair Drosehn= [EMAIL PROTECTED]
Senior Systems Programmer or [EMAIL PROTECTED]
Rensselaer Polytechnic Instituteor [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Job security??
Easy 50-80% Return and here's how. Learn how you can receive a monthly check for 6, 7, or 8% a month until your initial investment is paid off...then a monthly check for 4% for years to come... We know it sounds impossible, but it's happening today and here's where. In the merchant business-What's that?? You know those little black boxes where businesses swipe your credit cards! That's called P.O.S. Point of sale technology! And these numbers are verifiable. This multi-trillion dollar industry in which our business will supply cedit cards, debit cards, check verification, funds transfer, prepaid cell phone, prepaid phone cards, bill payment and many other services for the consumer in the retail environment with plenty of growth ahead. Success P.O.S. will professionally manage and service your business daily. Established and proven locations available nationwide. To find out how you can participate and achieve a monthly income of between 4% and 8% (50% to 80% yearly) with a relatively small investment contact us now: http://61.129.78.70/cl6 Opt-Out Instructions: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
