* gdb questions @ 2001-07-18 11:51 Andrew Zimmerman 2001-07-18 13:44 ` Eli Zaretskii 0 siblings, 1 reply; 8+ messages in thread From: Andrew Zimmerman @ 2001-07-18 11:51 UTC (permalink / raw) To: gdb I am considering the use of gdb on a project and have some questions. The project consists of porting to Linux an application written in assembly language for a 32-bit DOS extender environment. 1. If gdb is used with assembly language what kind of debugging symbols are required? I'd like to use NASM, but it doesn't seem to be able to add symbols. 2. Does gdb have a way to examine the LDT (local descriptor table)? My application creates some additional selectors for segments that reside within the flat memory space allocated to the application. With the Phar Lap Dos Extender we could easily display a list of the segments. And yes, we were in 32-bit protected mode, way back in 1989. Thank you. Andrew Zimmerman ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: gdb questions 2001-07-18 11:51 gdb questions Andrew Zimmerman @ 2001-07-18 13:44 ` Eli Zaretskii 2001-07-18 14:03 ` Andrew Zimmerman 2001-07-18 14:36 ` Jamie Guinan 0 siblings, 2 replies; 8+ messages in thread From: Eli Zaretskii @ 2001-07-18 13:44 UTC (permalink / raw) To: andrew; +Cc: gdb > From: "Andrew Zimmerman" <andrew@zimmerman.net> > Date: Wed, 18 Jul 2001 13:54:07 -0500 > > 1. If gdb is used with assembly language what kind of debugging symbols are > required? I'd like to use NASM, but it doesn't seem to be able to add > symbols. If you use Gas, the GNU assembler, you can invoke it with -gstabs+ or -gdwarf-2 switches, and get stabs or DWARF2 debug info. > 2. Does gdb have a way to examine the LDT (local descriptor table)? My > application creates some additional selectors for segments that reside > within the flat memory space allocated to the application. Do you intend to port that code to Linux? I don't know much about the protection scheme employed by Linux, but from what I know, I'd doubt very much that it will allow you to futz with the LDT. > With the Phar Lap > Dos Extender we could easily display a list of the segments. And yes, we > were in 32-bit protected mode, way back in 1989. That's funny: I've just committed a few days ago a bunch of changes to the DJGPP port of GDB which introduce commands to display LDT, GDT, and other system-related info. You can now say "info dos ldt $cs" and see the LDT entry for the debuggee's CS selector, including base address, limit, and the access right bits. But these command only work in GDB when it is compiled for native debugging of DJGPP programs. DJGPP programs are 32-bit protected-mode programs which can run on DOS and all versions of Windows as DPMI clients. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: gdb questions 2001-07-18 13:44 ` Eli Zaretskii @ 2001-07-18 14:03 ` Andrew Zimmerman 2001-07-18 23:27 ` Eli Zaretskii 2001-07-18 14:36 ` Jamie Guinan 1 sibling, 1 reply; 8+ messages in thread From: Andrew Zimmerman @ 2001-07-18 14:03 UTC (permalink / raw) To: Eli Zaretskii; +Cc: gdb ----- Original Message ----- From: "Eli Zaretskii" <eliz@is.elta.co.il> To: <andrew@zimmerman.net> Cc: <gdb@sources.redhat.com> Sent: Wednesday, July 18, 2001 3:16 PM Subject: Re: gdb questions > > 2. Does gdb have a way to examine the LDT (local descriptor table)? My > > application creates some additional selectors for segments that reside > > within the flat memory space allocated to the application. > > Do you intend to port that code to Linux? I don't know much about the > protection scheme employed by Linux, but from what I know, I'd doubt > very much that it will allow you to futz with the LDT. > What is the purpose of the MODIFY_LDT system call? ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: gdb questions 2001-07-18 14:03 ` Andrew Zimmerman @ 2001-07-18 23:27 ` Eli Zaretskii 0 siblings, 0 replies; 8+ messages in thread From: Eli Zaretskii @ 2001-07-18 23:27 UTC (permalink / raw) To: Andrew Zimmerman; +Cc: gdb On Wed, 18 Jul 2001, Andrew Zimmerman wrote: > > > 2. Does gdb have a way to examine the LDT (local descriptor table)? My > > > application creates some additional selectors for segments that reside > > > within the flat memory space allocated to the application. > > > > Do you intend to port that code to Linux? I don't know much about the > > protection scheme employed by Linux, but from what I know, I'd doubt > > very much that it will allow you to futz with the LDT. > > > What is the purpose of the MODIFY_LDT system call? I have no idea. The main issue is: can an application issue that system call without triggering a GPF? ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: gdb questions 2001-07-18 13:44 ` Eli Zaretskii 2001-07-18 14:03 ` Andrew Zimmerman @ 2001-07-18 14:36 ` Jamie Guinan 2001-07-18 23:28 ` Eli Zaretskii 1 sibling, 1 reply; 8+ messages in thread From: Jamie Guinan @ 2001-07-18 14:36 UTC (permalink / raw) To: Eli Zaretskii; +Cc: andrew, Gdb List On Wed, 18 Jul 2001, Eli Zaretskii wrote: > > From: "Andrew Zimmerman" <andrew@zimmerman.net> > > Date: Wed, 18 Jul 2001 13:54:07 -0500 > > > > 1. If gdb is used with assembly language what kind of debugging symbols are > > required? I'd like to use NASM, but it doesn't seem to be able to add > > symbols. > > If you use Gas, the GNU assembler, you can invoke it with -gstabs+ or > -gdwarf-2 switches, and get stabs or DWARF2 debug info. My Gas [1] only supports: -gstabs, -gdwarf, and -gdwarf2. gcc accepts -gstabs+ and -gdwarf-2, but does not appear to pass them down to the assembler (aside from using -Wa). But -gstabs (and -gdwarf{,2}) do indeed work with assembly source, $ as -gstabs foo.S -o foo.o $ gcc foo.o -o foo $ gdb foo (gdb) list foo_func ... -Jamie [1] stock Red Hat 7.1, gas 2.10.91. I just note this because I don't know if latest CVS Gas is any different. > > 2. Does gdb have a way to examine the LDT (local descriptor table)? My > > application creates some additional selectors for segments that reside > > within the flat memory space allocated to the application. > > Do you intend to port that code to Linux? I don't know much about the > protection scheme employed by Linux, but from what I know, I'd doubt > very much that it will allow you to futz with the LDT. > > > With the Phar Lap > > Dos Extender we could easily display a list of the segments. And yes, we > > were in 32-bit protected mode, way back in 1989. > > That's funny: I've just committed a few days ago a bunch of changes to > the DJGPP port of GDB which introduce commands to display LDT, GDT, > and other system-related info. You can now say "info dos ldt $cs" and > see the LDT entry for the debuggee's CS selector, including base > address, limit, and the access right bits. > > But these command only work in GDB when it is compiled for native > debugging of DJGPP programs. DJGPP programs are 32-bit protected-mode > programs which can run on DOS and all versions of Windows as DPMI > clients. > -- ================================================================ Jamie Guinan Blue Button Solutions, Inc. guinan@bluebutton.com http://www.bluebutton.com/ ================================================================ ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: gdb questions 2001-07-18 14:36 ` Jamie Guinan @ 2001-07-18 23:28 ` Eli Zaretskii 0 siblings, 0 replies; 8+ messages in thread From: Eli Zaretskii @ 2001-07-18 23:28 UTC (permalink / raw) To: Jamie Guinan; +Cc: andrew, Gdb List On Wed, 18 Jul 2001, Jamie Guinan wrote: > > If you use Gas, the GNU assembler, you can invoke it with -gstabs+ or > > -gdwarf-2 switches, and get stabs or DWARF2 debug info. > > My Gas [1] only supports: -gstabs, -gdwarf, and -gdwarf2. gcc accepts > -gstabs+ and -gdwarf-2 Sorry, I should have checked that. But this sounds like something that's worth reporting to the Binutils maintainers: users shouldn't be required to remember two sets of similar but subtly different options. ^ permalink raw reply [flat|nested] 8+ messages in thread
* gdb questions @ 2001-10-01 4:20 Mickael Gicquaire 2001-10-01 7:20 ` Fernando Nasser 0 siblings, 1 reply; 8+ messages in thread From: Mickael Gicquaire @ 2001-10-01 4:20 UTC (permalink / raw) To: gdb Hi all, I have a few enquiries concerning GDB. It seems that there is no way at the moment to see what commands are being issued to gdb while sourcing a file using the source command. I am right? I think it could be useful in some instances. Another thing is why is it not possible to issue mi commands inside a file that is being sourced or why is there not an equivalent command to the source command in the mi set of commands ? cheers mickael -- --------------------------------------------------------------------------- | Mickael Gicquaire | email mickael.gicquaire@.st.com | | | | | _____________ | | STMicroelectronics | | / ___/__ __/ | | 1000 Aztec West | | \__ \ / / | | Almondsbury | Phone 01454-462342 | /____/ /__/ | | BRISTOL | | | --------------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: gdb questions 2001-10-01 4:20 Mickael Gicquaire @ 2001-10-01 7:20 ` Fernando Nasser 0 siblings, 0 replies; 8+ messages in thread From: Fernando Nasser @ 2001-10-01 7:20 UTC (permalink / raw) To: Mickael Gicquaire; +Cc: gdb Mickael Gicquaire wrote: > > Hi all, > I have a few enquiries concerning GDB. > > It seems that there is no way at the moment to see what commands are being > issued to gdb while sourcing a file using the source command. I am right? > I think it could be useful in some instances. > Sure. We just need a volunteer to submit a patch. However, this will require that a switch is added to the "source" command syntax and that will lead us to a long discussion on the syntax of switches ("\" or "-"). > Another thing is why is it not possible to issue mi commands inside a file that > is being sourced or why is there not an equivalent command to the source > command in the mi set of commands ? > IMO, that is conceptually wrong. The MI is not another command line syntax -- it is a machine protocol between two programs. It was chosen to be in ASCII and readable for easy of debugging and implementation. The idea is that the MI source command reads and executes commands (from a file) that are in the normal GDB command line (cli) script language. It was not implemented yet because GDB is slowly being modified to allow switching the format of commands on the fly. This requires adding parameters to functions and passing them down so it takes some time to do. Thanks for the comments and suggestions. -- Fernando Nasser Red Hat Canada Ltd. E-Mail: fnasser@redhat.com 2323 Yonge Street, Suite #300 Toronto, Ontario M4P 2C9 ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2001-10-01 7:20 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2001-07-18 11:51 gdb questions Andrew Zimmerman 2001-07-18 13:44 ` Eli Zaretskii 2001-07-18 14:03 ` Andrew Zimmerman 2001-07-18 23:27 ` Eli Zaretskii 2001-07-18 14:36 ` Jamie Guinan 2001-07-18 23:28 ` Eli Zaretskii 2001-10-01 4:20 Mickael Gicquaire 2001-10-01 7:20 ` Fernando Nasser
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox